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