Skip to main content

[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.


Back to the top