Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 322309

Summary: enhance PEFileExecutableSymbolReader to better perform getSymbolAtAddress()
Product: [Tools] CDT Reporter: Kirk Beitz <kirk.beitz>
Component: cdt-debug-edcAssignee: Ken Ryall <ken.ryall>
Status: RESOLVED FIXED QA Contact: Ken Ryall <ken.ryall>
Severity: normal    
Priority: P3 CC: cdtdoug
Version: 7.0   
Target Milestone: 8.0   
Hardware: PC   
OS: Windows All   
Whiteboard:
Bug Depends on: 322297    
Bug Blocks:    
Attachments:
Description Flags
patch to ignore "NO SYMBOL" coff-symbols and override getSymbolAtAddress() not to perform size check cdtdoug: iplog+

Description Kirk Beitz CLA 2010-08-11 00:22:55 EDT
Created attachment 176293 [details]
patch to ignore "NO SYMBOL" coff-symbols and override getSymbolAtAddress() not to perform size check

context: class PEFileExecutableSymbolReader currently relies on class BaseExecutableSymbolReader for its implementation of getSymbolAtAddress().

however, since PEFileExecutableSymbolReader construtor (in private member function recordSegments() ) indiscriminately collects all symbols found in the Coff symbol-table in the Collection of symbols and sets the size of every segment to 1, then the member BaseExecutableSymbolReader#getSymbolAtAddress() fails when attempting to find addresses in functions (whereas the other executable symbol readers that maintain a proper size succeed), because getSymbolAtAddress() performs a size check.

the attachment PEFileExecutableSymbolReader.java.1.4.patch attempts to solve this problem in two ways:

(1) do not add symbols to the Collection<symbol> symbols that have a Coff type of T_NULL which translates to "NO SYMBOL"
(2) create an @override PEFileExecutableSymbolReader#getSymbolAtAddress that does not perform a size check.

caveat: the solution is still not perfect, just a lot better (at least for my testing purposes); what is not perfect is (a) the size of each symbol is still listed as 1 (as before); not enough time/resource to properly figure out the size of each symbol within PEFileExecutableSymbolicsReader, nor from the existing Coff.java code; and (b) it doesn't account for multiple symbols found at the same exact address, though it will at least act the same in this case as it has in the past, returning the symbol at the point found in the Collection<symbol>#binary_search call.
Comment 1 Ken Ryall CLA 2010-08-12 12:53:48 EDT
Committed to HEAD.
Comment 2 CDT Genie CLA 2010-08-12 13:23:02 EDT
*** cdt cvs genie on behalf of kryall ***
Bug 322309 -  enhance PEFileExecutableSymbolReader to better perform getSymbolAtAddress()

[*] PEFileExecutableSymbolicsReader.java 1.5 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/edc/org.eclipse.cdt.debug.edc/src/org/eclipse/cdt/debug/edc/internal/symbols/files/PEFileExecutableSymbolicsReader.java?root=Tools_Project&r1=1.4&r2=1.5