Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] objdump/addr2line problems

This is what the IBinaryParser is doing although it is not
explicitely say "addr2line"

I see it differently. Here's why.

At a practical level, if you go type your addr2line path into Addr2Line and your c++filt path into CppFilt, and your objdump into EditorUtility, you will see CDT start to work properly with GNU tools of a different target that uses the elf format. That's three one line changes.

Perhaps I'm wrong, but we looked at it a bit and to do the same with IBinaryParser, you (on 1.0.1) would have to:

- Copy and create a new Addr2line class and replace the path used for the addr2line call with yours. - Copy and create a new CppFilt class and replace the path used for the c++filt call with yours. - Copy or subclass, replace the Addr2Line and CppFile instantiations with your own new ones (not sure if you can do this with subclassing). - Copy or subclass, replace the Elf references with your custom Elf (not sure if you can do this with subclassing).
- Copy, replace the Elf references with your own Elf.
- Subclass ElfBinaryFile, copying methods getHelper and getContents, replacing them with your custom AR and custom ElfHelper classes. - Sublcass ElfBinaryArchive, copying the method getObjects() and replacing the AR reference with the new one. - Write your IBinaryParser by copying ElfParser and replacing Elf. ElfBinaryFile, AR and ElfBinaryArchive with yours.

Additionally, IBinaryParser does not cover the use of objdump in EditorUtility, covering that gets a little messier because not all paths through EditorUtility end up invoking objdump. Simplest would be:

- Copy EditorUtility, changing the objdump path to yours.
- Change CView, OpenIncludeAction and OpenOnSelectionAction to use the new EditorUtility.

Perhaps all this is my misunderstanding of what's required, but that seems like it would have been a lot more copied code and work than putting in a mechanism to be able to supply the exe paths to the three places in the CDT that need them.

Anyway, lots of text on this subject, more than it deserves perhaps -- sorry about that, I'm long winded sometimes.

Not to lose sight of the big picture: I don't think it's an issue until you want folks shipping vanilla CDT so that tools interoperate. As long as the interoperability platform is Eclipse rather than CDT it's a moot point really.


Back to the top