Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Toolchains in CDT


Lets just talk about addr2line as a microcosm of the ToolChain problem. Other binutils are more complex, but the essence is the same.

Here are the issues I think we have today:

- any reliance of the core on addr2line will make CDT not work for non-gnu based tool chains or toolchains where the addr2line command line interface or response format changed. - not all toolchains are gnu based and have a utility called addr2line that presents output in the GNU fashion.
- addr2line invocations can be heavyweight.

What do I think should be done? First, ISourceRange getSourceRange( IBinaryFile bFile, long address) needs to be added to IBinaryParser. This breaks the reliance of the core on addr2line. Now a given binary parser can decide how to provide this information. If you need it low latency, you can write your own java version. If you don't have addr2line, you can invoke whatever crazy commands you need in your binary parser. Direct tool invocations in the core are bad, they need to sit behind an extension point.

Second, the GNUBinaryParser needs to support an extension point that allows users to specify their toolchain. There are enough of us on GNU based systems that the need to plug in a "new" set of tools is quite common. Now that we have an IBinaryParser that abstracts any idea of command line tools from the core, having an implementation of that interface that supports tool chain specification via extension point is a good idea.

I'm working on a proposed patch in my copious free time.


At 12:40 AM 2/12/2004 +0100, Henning Riedel wrote:

> >
> > > Ok, here is an example, the binaryParser.
> >
> > > The way it is done now, IBinaryParser is an extension point, It is set
> > on the=20
> > > project via the PropertyPage, some parsers say the GNUElf parser needs
> > tools, and > they provide a UI to set the paths, for things like
> > addr2line, c++filt etc ..
> >
> > > What will be the workflow now ?
> >
> Bonjour
>   The folks here bounce your ideas on the toolchain on different
> scenarios.
> It seems a more appropriate thing for the Managed Builder, specially when
> dealing
> with paths.

May I once again bring in my ideas in bugzilla #37124 and #44279. I think
37124 is actually obsolete, as the current managed builders just do it. (Well,
ok with quirks, but they do.) ;)

But I still would say that the issues in 44279, would maybe bring some
relief in the path problems.
Just select you toolchain, but give the user an option, where its toolchain
is located. Then use this base path, not only for calling tools, but also for
the base to standard headers and libraries (hmm, that's part of the
toolchain adapters info-provider anyway).

my 0.02?, Henning

> In the case of the CDT/Core, folks here seem to thing that they can make
> things work
> with the IBinaryParser.  We will update the specs on this to better
> illustrate.
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx

GMX ProMail (250 MB Mailbox, 50 FreeSMS, Virenschutz, 2,99 EUR/Monat...)
jetzt 3 Monate GRATIS + 3x DER SPIEGEL +++ +++

cdt-dev mailing list

Back to the top