Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] objdump/addr2line problems

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

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 ...


Back to the top