Re: [cdt-dev] objdump/addr2line problems

["Alain Magloire" <alain@xxxxxxx>]

> 
> 
> >This is what the IBinaryParser is doing although it is not
> >explicitely say "addr2line"
> 
> I see it differently. Here's why.
> 
> At a practical level, if you go type your addr2line path into Addr2Line and 
> your c++filt path into CppFilt, and your objdump into EditorUtility, you 
> will see CDT start to work properly with GNU tools of a different target 
> that uses the elf format. That's three one line changes.
> 
> Perhaps I'm wrong, but we looked at it a bit and to do the same with 
> IBinaryParser, you (on 1.0.1) would have to:
> 
> - Copy and create a new Addr2line class and replace the path used for the 
> addr2line call with yours.
> - Copy and create a new CppFilt class and replace the path used for the 
> c++filt call with yours.
> - Copy or subclass Elf.java, replace the Addr2Line and CppFile 
> instantiations with your own new ones (not sure if you can do this with 
> subclassing).
> - Copy or subclass AR.java, replace the Elf references with your custom Elf 
> (not sure if you can do this with subclassing).
> - Copy ElfHelper.java, replace the Elf references with your own Elf.
> - Subclass ElfBinaryFile, copying methods getHelper and getContents, 
> replacing them with your custom AR and custom ElfHelper classes.
> - Sublcass ElfBinaryArchive, copying the method getObjects() and replacing 
> the AR reference with the new one.
> - Write your IBinaryParser by copying ElfParser and replacing Elf. 
> ElfBinaryFile, AR and ElfBinaryArchive with yours.
> 

8-) you make it sound more cumbersome then it is, the simplest thing,
is to do it once and reuse the code.

public GenericGNUBinaryParser implements IBinaryParser {
	// do the common stuff
	// things that can be shared, if we all do Elf with binutils. 
}

public TensilicaBinarParser extends GenericGNUBinaryParser {
..
}

public QNXBinarParser extdens GenericGNUBinaryParser {
..
}


Again I'm not tied to anything, if you have some other ways, proposed/submit,
sure we can come up with a consensus.

> Additionally, IBinaryParser does not cover the use of objdump in 
> EditorUtility,

Yes, IBinaryParser was a first draft submitted open to change/modification/enhancement
I've just never received any feedbacks .. 'til now 8).

> covering that gets a little messier because not all paths 
> through EditorUtility end up invoking objdump. Simplest would be:
> 
> - Copy EditorUtility, changing the objdump path to yours.
> - Change CView, OpenIncludeAction and OpenOnSelectionAction to use the new 
> EditorUtility.
> 
> Perhaps all this is my misunderstanding of what's required, but that seems 
> like it would have been a lot more copied code and work than putting in a 
> mechanism to be able to supply the exe paths to the three places in the CDT 
> that need them.
> 

I see your point.

We could supply, as you pointed , an abstract class doing just that

public class IBinToolProvider ... {
..
	void setAddr2line(IPath path);
	void setObjdump(IPath path);
	void setNM(IPath path);
..
}

It may be in the end that we do not need the heavy artillery of IBinaryParser
or need to enhance this interface more to take to account tools like objdump,
objcopy etc ...

If this is satisfactory, submit a PR for it to be schedule.

> Anyway, lots of text on this subject, more than it deserves perhaps -- 
> sorry about that, I'm long winded sometimes.
> 

8-), not at all, very informative, proper feedback is needed, we can
only propose solutions biais to our needs.

> Not to lose sight of the big picture: I don't think it's an issue until you 
> want folks shipping vanilla CDT so that tools interoperate. As long as the 
> interoperability platform is Eclipse rather than CDT it's a moot point really.
>