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

[Stan Shebs <stanshebs@earthlink.net>]

On 12/9/14, 2:49 AM, Mark Wielaard wrote:
> On Thu, 2014-12-04 at 14:02 +0000, Pedro Alves wrote:
>> On 11/27/2014 02:53 PM, Mark Wielaard wrote:
>>> Add a flag field is_noreturn to struct func_type. Make calling_convention
>>> a small bit field to not increase the size of the struct. Set is_noreturn
>>> if the new GCC5/DWARF5 DW_AT_noreturn is set on a DW_TAG_subprogram.
>>> Use this information to warn the user before doing a finish or return from
>>> a function that does not return normally to its caller.
>>>
>>> (gdb) finish
>>> Warning. Function endless does not return normally.
>>> Try to finish anyway? (y or n)
>>>
>>> (gdb) return
>>> warning: Function does not return normally to caller!
>>> Make endless return now? (y or n)
>>
>> I'd suggest making the warnings a bit more consistent.
>>
>> - "Warning." vs "warning: "
>>
>>   Prefer the latter, as that's what the "warning" function uses.
>>
>> - "." vs "!"
>>
>>   I'd keep it calm and get rid of the "!".  :-)
> 
> Fixed both.
> 
>>>
>>> gdb/ChangeLog
>>>
>>> 	* dwarf2read.c (read_subroutine_type): Set TYPE_NO_RETURN from
>>> 	DW_AT_noreturn.
>>> 	* gdbtypes.h (struct func_type): Add is_noreturn field flag. Make
>>> 	calling_convention an 8 bit bit field.
>>> 	(TYPE_NO_RETURN): New macro.
>>> 	* infcmd.c (finish_command): Query if function does not return
>>> 	normally.
>>> 	* stack.c (return_command): Likewise.
>>>
>>> include/ChangeLog
>>>
>>> 	* dwarf2.def (DW_AT_noreturn): New DWARF5 attribute.
>>
>> 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.

Stan
stan@codesourcery.com