[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Toolchains in CDT
|
At 04:37 PM 2/4/2004 -0500, Alain Magloire wrote:
>
> This just keeps coming up. :)
>
> For what it's worth, we were able to do this with a change to
EditorUtility
> (which is said to have been put in the head) and our own IBinaryParser
that
> subclassed the Elf and/or GNU binary parser.
>
This may not be flexible enough for a long term solution.
Sometimes you may want to see the binary differently, per section,
with debug-info, disassembly, hex-dump etc ...
You can picture adding some of these things to IBinaryParser. Turning
address information to line and file references, or turning a mangled name
into an unmangled name seems part and parcel of the binary format and
natural additions to IBinaryParser. Others functions, like disassembling,
could be put there too but are perhaps better suited in some processor /
architecture abstraction layer with IBinaryParser just supplying the
section information, address ranges, data and properties to the higher layers.
But then, most tool chains come with their own subtly different object file
format and their own disassembler, so that's why I'm torn. Putting the
fundamental "get information out of the object file" methods into
IBinaryParser might be the way to go. If you want to delegate to command
line tools, fine. If that's too much latency per operation, write a java
version.
I've been mulling this over in the back of my head because we added a
disassembly server to Xplorer, but you can only see the disassembly for
executables that you have profiled. We have some requests for disassembly
on unprofiled executables. The "right" way to add that with the extension
points available today seems to be to push some sort of disassemble
interface into IBinaryParser.
As always, if we do it in the CDT, I'll send a patch.
Thanks!
-Chris
