Re: [PATCH] Use GCC5/DWARF5 DW_AT_noreturn to mark functions that don't return normally.

[Pedro Alves <palves@redhat.com>]

On 12/10/2014 11:24 AM, Mark Wielaard wrote:
> Hi Stan,
> 
> On Tue, 2014-12-09 at 10:57 -0800, Stan Shebs wrote:
>> On 12/9/14, 2:49 AM, Mark Wielaard wrote:
>>> On Thu, 2014-12-04 at 14:02 +0000, Pedro Alves wrote:
>>>> I wonder if we could have a test?  Could e.g., make sure we don't
>>>> crash when the user confirms a return in a noreturn function.
>>>
>>> I am not sure how to write such a test. This is mainly interactive code,
>>> which will only trigger from_tty. I also am not sure such a test really
>>> tests this new feature. Trying to return from a noreturn function
>>> triggers undefined behavior. GDB probably won't crash, but the inferior
>>> might since the result is unpredictable (that is precisely why I added
>>> this, you forcibly return from a function and end up somewhere
>>> unexpected). Which makes testing the expected output of the user
>>> ignoring the warning somewhat hard.
>>
>> Chiming in here, just write the test so that it passes whether or not
>> the inferior crashes - as you note, its behavior is undefined anyway.
>> If GDB crashes or hangs, on any platform, that's a bug that we have to
>> fix in GDB.
> 
> I am afraid I still don't understand what we would be testing (whether
> the user if there is a tty gets to say yes or no?) or how to write such
> a test where we don't seem interested in the actual result. Is there an
> example to follow?

The point is just to test the new/related code paths, and making sure
the commands do what you propose they do.

E.g., to make sure the new dwarf code (and future changes around it) don't
crash.  And then in the "return->no" path, make sure we really cancel the
command (that the backtrace looks the same after canceling), which also potentially
exercises bad/missing cleanups, for example.  By testing the "return->yes" path,
we'd  be making sure the unwinder doesn't crash (now and in the future)
in this situation, and that the current frame ends up being the one expected.
For the "finish" case, we'd be making sure that GDB doesn't crash when trying
to figure out where the function's return value is stored ("finish" prints the
function's return value when the function actually finishes).

There are some tests for "return" in the testsuite -- return.exp or
return2.exp -- and at least one for "finish" -- finish.exp.  I'd suggest
using these as inspiration.

Thanks,
Pedro Alves