Re: [cdt-dev] objdump/addr2line problems

["Alain Magloire" <alain@xxxxxxx>]

> 
> > > For a non-managed project, yes, I can see where you
> > > might want to explicitly set the binary parser to use.
> > >=20
> > > For a managed build project - one that identifies a build
> > > target, and a toolchain to use when building for that target -
> >=20
> > addr2line, objdump, nm, etc ..  are not necessaryly Build tools.
> 
> No - but they are generally associated with build tools as
> part of the toolchain as a whole.  In other words, given a
> set of build tools, there's generally a set of associated
> tools (addr2line, objdump, nm, etc.) that are intended for
> manipulating the output from those build tools.
> 

Lets look at it this way, the CDT model needs to do some probing
on executables and provide the information back to other
modules(debugger, profile, launcher etc ..), how it is done is usually
highly platform dependent, so an extension/contribution is provided
that can be implemented by a third party, the extension interface
can do a certain number of actions on executable.

Lets not focus on GNU binutils (addr2line, etc ..) although
they can be use to implement the actions.

> > If you really want this, I would advocate to define an interface
> > on what the tools should do:
> >=20
> > public interface IAddr2line {
> >=20
> > 	String getFilename();
> >=20
> > 	int getLinenumber();
> >=20
> > 	int getAddress();
> > }
> >=20
> > etc ..
> 
> This is more along the lines of what I had in mind: given a
> project, query for the toolchain associated with the project.
> Once you obtain the toolchain, query for the tools used to
> convert program addresses to line info, cast the interface
> to IAddr2Line, and use that interface to drive the tool.
> 

Then this one step closer of what the current IBinaryParser
interface is doing, take another look at it:

	org.eclipse.cdt.core.IBinaryParser.java

The difference here is that we do not try to separate things
in term of binutils tools, but rather a general interface to
retrieve information from a binary.  It is one extension-point
and an IFile is pass to the BinaryParser to analyse/probe/inspect
in whatever means(Elf, COFF/PE, nm, addr2line, ar, foobar, etc ...).

We could have implement things like this:

public class ToolFactory {
	IAddr2line getAddr2line(..);
	IArchiver getArchiver(..);
...
}

this is probably more inline to what people expect, because of the
habit of using binutils tools.