Bugzilla – Full Text Bug Listing
| Summary: | COFF binaries, org.eclipse.cdt.core.IBinaryParser.IBinaryObject.getSymbol(IAddress) and org.eclipse.cdt.utils.coff.parser.PEBinaryObject.addSymbols(Symbol[], byte[], List<Symbol>) | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Xavier Raynaud <xavier.raynaud> | ||||||||||
| Component: | cdt-core | Assignee: | Ken Ryall <ken.ryall> | ||||||||||
| Status: | RESOLVED FIXED | QA Contact: | Doug Schaefer <cdtdoug> | ||||||||||
| Severity: | normal | ||||||||||||
| Priority: | P3 | CC: | daniel.thomas, jjohnstn, ken.ryall, xraynaud | ||||||||||
| Version: | 8.0 | ||||||||||||
| Target Milestone: | --- | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | Windows XP | ||||||||||||
| Whiteboard: | |||||||||||||
| Attachments: |
|
||||||||||||
Created attachment 194573 [details]
patch PEBinaryObject, in order to be able to retrieve symbol from an address
A straightforward solution is to do not take symbol size into account when trying to retrieve a symbol from an address.
A better solution might be to alter org.eclipse.cdt.debug.edc.internal.symbols.files.PEFileExecutableSymbolicsReader.recordSections(PE) org.eclipse.cdt.utils.coff.parser.PEBinaryObject.addSymbols(Symbol[], byte[], List<Symbol>) to use the auxiliary symbol records to find out what the size of the symbol is and then use that as the symbol size - then behavior would be the same as for ELF and the Symbol (org.eclipse.cdt.utils.Symbol and org.eclipse.cdt.debug.edc.internal.symbols.Symbol) would have the correct size. This involves reading a Coff symbol record using auxiliary format 1. However this would be a little more work. Changing CDT version to 8.0. (In reply to comment #2) > A better solution might be to alter > org.eclipse.cdt.debug.edc.internal.symbols.files.PEFileExecutableSymbolicsReader.recordSections(PE) > org.eclipse.cdt.utils.coff.parser.PEBinaryObject.addSymbols(Symbol[], byte[], > List<Symbol>) to use the auxiliary symbol records to find out what the size of > the symbol is and then use that as the symbol size - then behavior would be the > same as for ELF and the Symbol (org.eclipse.cdt.utils.Symbol and > org.eclipse.cdt.debug.edc.internal.symbols.Symbol) would have the correct size. > This involves reading a Coff symbol record using auxiliary format 1. > However this would be a little more work. Would it not make more sense to add getSize() method to Coff.Symbol and use it in the addSymbol() calls much like ELF does. AFAICT, the auxilliary records are only needed for the length of an array, struct, or union. The symbol length for basic types such as short int, long int, float, double, could easily be coded and would go a long way to correcting some of the problems that Xavier is seeing. If this reasonable, I can post a patch that could fill in the sizes of basic types for Coff.Symbol and use the auxilliary record where needed. From what I can tell, PE-COFF is either LP32 or LLP64 (long/ints are 32-bits but pointers are 64-bits). Created attachment 202160 [details] Patch to get Coff symbol size and use it when adding symbols Attached is the proposed patch I was mentioning whereby the Coff.Symbol class would have a getSize() which can be used when adding the symbols. It uses the auxiliary entries when needed, otherwise it hard-codes the value. It needs to know when the system is 64-bit to determine the size of a pointer and this is passed to the constructor. The code either assumes ILP32 or LLP64 based on the boolean input. There are two potential issues. 1. Figuring out when a 64-bit pointer is warranted. For this, I used the file header F_AR32WR flag to determine if 32-bit. If this flag is not on, then 64-bit is assumed. According to the COFF architecture document I found: http://download.microsoft.com/download/e/b/a/eba1050f-a31d-436b-9281-92cdfeae4b45/pecoff.doc this is the correct flag to check. 2. Long double size. I assumed it is 16 bytes, but this may not be correct for Windows COFF. I couldn't find any info in the doc. If it should be 8 bytes, then feel free to change this. Created attachment 202161 [details]
Second part of patch that fixes edc to use new Coff.Symbol.getSize() method
This is the edc patch needed.
I'm testing this out and the EDC unit tests are failing because getSize is returning 0 instead of 1. I'd like to track this down before committing the patch. (In reply to comment #7) > I'm testing this out and the EDC unit tests are failing because getSize is > returning 0 instead of 1. I'd like to track this down before committing the > patch. Yes, by all means. Thanks for looking at it. Committed second, third, and a slightly modified fourth version of the attached patches. *** cdt git genie on behalf of kryall ***
Bug 337821 - Fixes for COFF binaries
[*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=01d3c53747c10ba5487ecd1c59dff3f11e29771e
*** cdt git genie on behalf of kryall ***
Bug 337821 - Fixes for COFF binaries
[*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=5f97a24187c27cb4c58f8c1d3b07dee84b64b745
|
Created attachment 189477 [details] example of COFF binary file, generated with cygwin. Hi, I had some trouble when using org.eclipse.cdt.core.IBinaryParser.IBinaryObject.getSymbol(IAddress) on a COFF object. This methods return a Symbol only if address match /exactly/ the begin address of the symbol. Is it the expected behaviour (it's not the same for ELF objects) ? Example: (see attached file a.exe) - getSymbol(0x401316) returns _func_a - getSymbol(0x401330) returns null - cygwin command "addr2line -f -e a.exe 0x401316" returns "_func_a" - cygwin command "addr2line -f -e a.exe 0x401330" returns "_func_a" After investigation, it appears that COFF symbols size is always "1" (see org.eclipse.cdt.utils.coff.parser.PEBinaryObject.addSymbols(Symbol[], byte[], List<Symbol>)). Xavier