Re: [PATCH 0/2] Python testcases to check DWARF output

[Jeff Law <law@redhat.com>]

On 08/03/2017 02:27 AM, Pierre-Marie de Rodat wrote:
> On 08/02/2017 05:43 PM, Jeff Law wrote:
>> I hate to throw in a wrench at this point, but has anyone looked at
>> dwgrep from Petr Machata?  He's not doing much with it anymore, but it
>> might provide enough of a dwarf scanning framework to be useful for
>> testing purposes.
> 
> Sure, no problem: I first started talking publicly about this one week
> ago, so it’s definitely not too late to mention alternatives. ;-) I
> learned about dwgrep two years ago and forgot about it, so thank you for
> the idea. I started to have a look at it, and for now I don’t think it’s
> a good match in this context:
> 
>  1. it’s an ELF only tool;
>  2. it must be built, requiring external dependencies: cmake and
>     elfutils;
>  3. in order to use it, one must learn a dedicated post-fix language
>     (Zwerg)
> 
> For 1. I think this is a true problem, as it means for instance that we
> could not test DWARF on Windows and Darwin setups. Unless we add PE and
> Mach-O handling in dwgrep of course, but that does not sound easy and
> will bring other external dependencies.
> 
> For 3. I feel that, for someone who is comfortable with Python, it will
> be easier to deal with a Python library (the dwarfutils in my patch)
> than having to learn yet another DSL. I think that’s precisely why some
> people would like to have a Python test framework rather than a TCL one.
> Working with a “usual” imperative language looks easier than with
> postfix expressions. Smaller cognitive load.
> 
> Actually I see another problem: pattern will have to vary depending on
> the target platform (for instance 32/64bit or depending on the DWARF
> version). Of course we could duplicate whole patterns in testcases to
> take this into account, but that’s like code duplication: I think we
> should be able to include small “X if 32bit else Y” in patterns, and I
> don’t think we can do that with Zwerg (no way to pass something like
> environment variables).
> 
> Of course, I have written a “competitor” tool: I guess my judgment is
> biased. :-) So other opinions are welcome!
Thanks.  I just wanted to raise it as a possibility.  It looks like it's
not a good fit here, so let's not let it be a distraction.

jeff