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

[Pierre-Marie de Rodat]

Thank you for your feedback.

On 07/27/2017 09:52 AM, Richard Biener wrote:
>> I'm fine with the direction if a reviewer wants to go in that
>> direction.  I wish python didn't have a built-in speed penalty,
>> that's the only downside I don't like about it.  Aside from that,
>> even switching all of the testsuite to be python based isn't a
>> terrible idea.
> 
> But is it worse than TCL?

Good point. Actually for Python there are ways to make it faster. If we 
can somehow manage to have a limited set of Python interpreter instances 
(instead of one per test), we could use pypy, which is very good I heard 
to make long running instances fast.

As to switch all of the testsuite to Python, I don’t have an educated 
opinion on this. I just want to say that, here I’m using Python to 
pattern match DIEs, but if needed we could perfectly use it to do other 
complex tasks. This is why I kept the DWARF-specific stuff 
(gcc-dwarf.exp and the dwarfutils Python package, from second commit) 
separate from just Python interpreter handling (gcc-python.exp, from 
first commit).

Note that having a Python only testsuite would make it easier to have 
only one Python instance for all the testsuite run, so it would, in 
theory, make it easier to get a fast execution.

… now, I’m not familiar with DejaGNU but I have the feeling that it does 
a lot with respect to the handling of a great variety of 
targets/remote/etc. combinations. Re-writing it (and making sure it 
works!) sounds like a huuuge task. I’ll let experts in this area 
comment. :-)

-- 
Pierre-Marie de Rodat