Re: [cdt-dev] Toolchains in CDT

["Alain Magloire" <alain@xxxxxxx>]

> 
> At 03:49 PM 2/5/2004 -0500, Alain Magloire wrote:
> >A simple implementation of this editor can be just the dump output of
> >the objdump utility or something more complex.
> 
> I think that certain information specific to the object file format should 
> be available through IBinaryObject / IBinaryParser. Translating address to 
> line and file, dealing with mangled names, retrieving section names and 
> section data. Maybe disassembly.
> 

Right.

> After all, if the Parser for the Binary is not reading the debug sections 
> to figure out what address goes where, who is?
> 
> Allowing an editor plugin for binaries in is a super idea, but what if I 
> want to make a view that shows disassembly for a selected binary function 
> in the CView? What if I want an editor ruler that translates profile data 
> per address into line information? Or, if having made such a ruler, I want 
> it to work with someone else's binary format?
> 

It was more for the viewing of a binary i.e.  when you double-click on it.

> I also think that extending IBinaryParser to provide additional binary 
> specific information alleviates the need for the toolchain because all 
> those tool chain entries that people want to use are providing information 
> about the binary. Addr2line, cppfilt, objdump, size -- there's a reason GNU 
> calls them binutils.
> 

I think what Jeremiah proposed, was more a point of entry to find tools.
It could be important for folks who distribute multiple targets.
One of the example, was the managed builder.

> Abstract that functionality behind IBinaryParser and now it's just a matter 
> of writing your plugin to the existing IBinaryParser extension and invoking 
> the new tools. It also better supports non-gnu based toolchains as well as 
> implementation directly in java if that's the right route.
> 

I see where you are heading, I'll bounce the ideas with the folks here
and reread Jeremiah's email.

Later,