Re: [PATCH][gdb/symtab] Fix unhandled dwarf expression opcode with gcc-11 -gdwarf-5

[Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>]

On 2021-07-26 10:41 a.m., Tom de Vries wrote:
>> However, this high bounds value stored as a location expression won't be
>> very useful anyway.  In most places (see get_discrete_high_bound), we
>> just return 0 if the property is not constant.  But we did evaluate it,
>> the current interfaces that evaluate dynamic properties return CORE_ADDR
>> or LONGEST, all 64-bit values, so we could not return that value.  So if
>> the property that you create was ever evaluated, it wouldn't yield a
>> valid result anyway.  I quickly tried to find a way to make GDB evaluate
>> it to see what happens, but couldn't find one.
>>
>> If we ever want such a large high bound value to be useful, I think that
>> some interfaces and some code would need to be converted to use
>> arbitrary precision integers (using GMP maybe).  And then
>> dynamic_prop_data::const_val could be a GMP type instead of a LONGEST,
>> allowing it to store that 16 bytes value.  In which case we would
>> probably undo your patch here, because, if we can store the 16-byte
>> value as a constant directly, there's no need to convert it to a
>> location expression.
>>
> 
> Yes, if we'd address PR20991 then this patch might be reverted.  I don't
> see that as a problem.
> 
> What I see as a problem is that we currently give the user the confusing
> "Unhandled dwarf expression opcode 0xff" which suggests either:
> - there's a compiler problem, or
> - gdb needs to handle the dwarf expression opcode 0xff,
> and neither is correct.
> 
> With this patch, we give:
> ...
> That operation is not available on integers of more than 8 bytes.
> ...
> which points nicely to PR20991.

I agree with the user-visible behavior / change, so even though the
implementation does not look pretty, I can live with it.

Simon