[
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 Elf.java, replace the Addr2Line and CppFile
instantiations with your own new ones (not sure if you can do this with
subclassing).
- Copy or subclass AR.java, replace the Elf references with your custom Elf
(not sure if you can do this with subclassing).
- Copy ElfHelper.java, 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.
Thanks!
-Chris