[PATCH] gdb: work around negative DW_AT_data_member_location GCC 11 bug

[Simon Marchi]

On 2022-01-26 13:30, Keith Seitz wrote:
> On 1/26/22 10:17, Keith Seitz via Gdb-patches wrote:
>> On 1/26/22 09:45, Simon Marchi via Gdb-patches wrote:
>>>> diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
>>>> index 737d8a4c81b..0c66a6daf97 100644
>>>> --- a/gdb/dwarf2/read.c
>>>> +++ b/gdb/dwarf2/read.c
>>>> @@ -14489,6 +14489,16 @@ handle_member_location (struct die_info *die, struct dwarf2_cu *cu,
>>>>         if (attr->form_is_constant ())
>>>>       {
>>>>         LONGEST offset = attr->constant_value (0);
>>>> +
>>>> +      /* Work around this GCC 11 bug, where it would erroneously use -1
>>>> +         data member locations, instead of 0:
>>>> +
>>>> +           Negative DW_AT_data_member_location
>>>> +           https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101378
>>>> +         */
>>>> +      if (offset == -1)
>>>> +        offset = 0;
>>>> +
> 
> I apologize, I forgot to ask: would the more general " < 0" be
> appropriate to catch other related bugs, such as fuzzing?

In this case, we want to handle a very specific known bug by a specific
compiler.  We know that GCC meant 0 and not -1.  But I wouldn't turn any
negative value into 0, because that might not be the value the compiler
intended.  For example, another compiler could put -4 when it meant 4.
If we turned that into 0, we would just add to the confusion.

In fact, I am tempted to add a producer check and only apply the fixup
if the producer is gcc 11.

Since GDB doesn't know how to handle negative data member offsets (if
that's even possible), I think that if we encounter a negative offset
(other than the case above), we should just emit a complaint and leave
the field's location as unknown.

Simon