Re: [PATCH] cc-with-tweaks: show dwz stderr and check exit code

[Simon Marchi <simark@simark.ca>]

On 2019-05-10 3:49 p.m., Tom de Vries wrote:
> The point I was trying to make, is that in a test-case there may be
> dwarf related to the test-case, and other, run-of-the-mill dwarf that is
> not at all related to the feature being tested, and when dwz has changed
> the executable, there's no way of knowing which of the two, or both has
> been affected. So, testing a test-case in combination with dwz, and
> seeing that the dwarf has been changed by dwz, does not guarantee you
> that the dwarf related to the feature being tested has in fact been changed.

Indeed.

>> I have included your suggestion in the patch below and made a few adjustments.
>>
>> By the way, do you have a way to reproduce the case where dwz doesn't optimize anything
>> in single file mode?  Even with a file with just an empty main, dwz manages to do some
>> optimization.
>>
> 
> I guess if you make a start.c with an empty _start function and compile
> with -stdlib (so, the start testcase in the dwz testsuite), and then
> furhter prune down the generated .s file, you'll end up with triggering
> that warning.

Ok, that's a bit further than I am willing to go right now to test the script :).

>> Another question: in multifile mode, we check if the output dwz file exists.  Should we also
>> check that the original file now contains a .gnu_debugaltlink section?  If dwz succeeded to
>> generated the external dwz file, but failed to modify the original executable, we could also
>> end up running a test with a non-dwzified executable.
>>
> 
> Agreed, we could do that, but I haven't seen any problems with dwz
> related to that, so I'm not sure it's worth the churn atm.

Ok.

> LGTM.

Thanks for all the comments, I am pushing the patch.

Simon