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

Chris Songer wrote:



Hi!
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.
The reliance of addr2line is not in the core, its currently in a particular (contributed) binary parser (GNU binary parser)
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.
Again, I don't see the need here to add this to BinaryParser, IBinaryParser.ISymbol has start/end line and I can get a ISymbol from IBinaryObject on a given address. Oh and if you would like to contribute other interfaces to IBinaryFile it is IAdaptable.
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.
Maybe the managed build configuration could contribute this type of binary parser then it can tie it to the underly set of tools that is has, hence consolidating this toolchain concept into one integration point (or well defined set of...). 

Dave.



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

Thanks!
-Chris

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
> http://dev.eclipse.org/mailman/listinfo/cdt-dev
>

--
GMX ProMail (250 MB Mailbox, 50 FreeSMS, Virenschutz, 2,99 EUR/Monat...)
jetzt 3 Monate GRATIS + 3x DER SPIEGEL +++ http://www.gmx.net/derspiegel +++ 

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev



_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev

Back to the top