On 7/28/22 15:10, Joel Brobecker wrote:
>>> Thanks for the patch.
>>>
>>> My question is whether it actually makes sense that -1 be
>>> a valid output for the print command above. I tried the addition
>>> of ...
>>>
>>>       | /* Note: Interprets ULLONG_MAX as -1.  */
>>>       | yylval.typed_val.type = type_long_long (par_state);
>>>
>>> ... to a patch of yours:
>>>
>>>       | commit ac3afe36d73c84096685fece885d70b28bc9629f
>>>       | Author: Tom de Vries <tdevries@suse.de>
>>>       | Date:   Sat Jun 4 13:17:33 2022 +0200
>>>       | Subject: [gdb/ada] Fix literal truncation
>>>       |
>>>       | Make sure we error out on overflow instead of truncating in all cases.
>>>       |
>>>       | Tested on x86_64-linux, with a build with --enable-targets=all.
>>>
>>> Do you remember why we do this? Intuitively, you'd expect that GDB
>>> would behave the same regardless of whether it selects type "long"
>>> or "long long" for its processing, as long as both types are 64-bit.
>>>
>>
>> I have no idea.  AFAICT it's been in gdb since the "Add base ada language
>> files" commit from 2002 that we avoid "unsigned long long".
>>
>> I've taken care to preserve the behaviour in the commit you refer to (and
>> this patch), since I don't have the knowledge to decide that things should
>> be different.
>>
>>> With the above, we can take this patch as an intermediate remedy,
>>> but I think we might need to dig deeper into why we use a signed
>>> type in the case of long long but not long, particularly when both
>>> types are the same size.
>>>
>>> WDYT?
>>>
>>
>> I'd be happy to write a patch to change the behaviour of gdb.  But somebody
>> knowledgeable in Ada needs to specify what that needs to be.
> 
> We're really outside of the Ada language. Would you mind checking
> what the C language does? I think it would make sense to do the same,
> here. E.g., on x86_64-linux, I get:
> 
>      (gdb) p 0xffffffffffffffff
>      $1 = 18446744073709551615
> 

Ack, that's what the C language does.

This patch changes gdb to print 18446744073709551615 for ada as well.

So, pick your favorite patch ;)

Thanks,
- Tom