Re: [cdt-dev] Toolchains in CDT

["Alain Magloire" <alain@xxxxxxx>]

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

Ok, how about this:
Basically we are talking about viewing some contents in the Editor.
The view may change (by section, disassembly etc ...).

So why not have an objdumpEditor, or a BinaryEditor that can be contributed.
It seems that we are trying to push down the IBinaryParser to many requirements,
just to be able to see a binary inside an editor.

A simple implementation of this editor can be just the dump output of 
the objdump utility or something more complex.