[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Toolchains in CDT
|
Hi!
The disassembly feature is "below the line" on our current POR but I'll see
if I can find some personal free time to do it myself this weekend. If so
I'll submit the patch so as to be perfectly clear.
Ironically, I think I am arguing Alain's position from a year ago. :)
Thanks!
-Chris
At 04:16 PM 2/6/2004 -0500, you wrote:
>
> 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,
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev
