Re: [cdt-dev] objdump/addr2line problems

[Chris Songer <songer@xxxxxxxxxxxxx>]

At 12:06 AM 7/4/2003 -0400, Alain Magloire wrote:
> IMO, the problem is that they return strings, what to do with them ?
> If you want to pass certain arguments?  Where do you do the parsing
> addr2line from Qnx maybe slightly different from  the default breaking
> parsing.

Non-uniformity in the gnu tools certainly happens. At the same time, this 
issue keeps coming up because you are glossing over the uniformity of the 
gnu tools by putting in interfaces for the worst case (when tools and 
binary formats differ) and not accommodating the usual case (when Elf and 
the gnu tools just work when replaced.).

The CDT works well when you use simple strings coming back from this kind 
of interface as the path of what to exec. I don't think anyone is arguing 
against a higher level interface that lets you replace more of the 
functionality like the existing one, we simply keep getting requests for 
this lower level "let me tell CDT what to exec" interface because it works.

The only downside to not providing this lower level interface is that folks 
will realize how easy it is to do themselves and ship with modified 
versions of CDT. That's certainly what we are doing now. That's only an 
issue if we care about interoperability with different CDT tool providers.

I agree with your critique of the tools interface, Strings were simply the 
expedient way to go in the absence of a CDT abstraction of "external 
tool.". It was my hope that build model (now target model) would take care 
of this, though based on this discussion, it seems it has not yet.

The target model has to have someway to identify a tool so that it can be 
used either for makefile generation or for direct execing by the 
environment. Something like....

public interface ITool {
        public IPath getToolPath();
        public IToolArg[] getArgs( IToolArg passed in args[] );
};

In this world, hopefully the default implementation of IAddr2Line would 
somehow get an ITool from extension point for addr2line so that if we just 
want to replace the executable by providing an ITool for addr2line, it will 
just work. If someone has some totally strange way of getting addr2line 
information, they can replace IAddr2Line. On the other hand, if they are 
using gnu tools and just want to plug in theirs, they can.

Picture a IBinToolProvider that looks like this:

public interface IBinToolProvider {
        public ITool addr2line();
        public ITool objdump();
        public ITool cppfilt();
        public ITool ...
};

Thanks!
-Chris