Re: [cdt-dev] objdump/addr2line problems

["Alain Magloire" <alain@xxxxxxx>]

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

This is what the IBinaryParser is doing although it is not
explicitely say "addr2line"

Now, whether no one read this:

	http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/cdt-core-home/docs/binaryparser.html?cvsroot=Tools_Project


or it was not well understood or it did not "feel" right and did not address the concerns.
In any case, I'm open,  make a proposition/draft let discuss it.
***** It does not have to be an implementation *****
but rather the interface wanted.  We can worry about providing a default implementation
later, lets rather agree on the interface needed to examine a binary.

There is also a lot of talk to move things in the build model, the target model etc ..
IMHO, the unification of those things can be done later in time via iterations, I would
say its probably not the right time to overload those API at this point.