Re: [PATCHv2 2/2] gdb/python: add Type.signedness attribute

[Simon Marchi <simon.marchi@polymtl.ca>]

On 2021-12-08 04:56, Andrew Burgess wrote:
> * Simon Marchi <simon.marchi@polymtl.ca> [2021-12-07 22:13:40 -0500]:
> 
>>> +@vindex TYPE_SIGNEDNESS_NONE
>>> +@item gdb.TYPE_SIGNEDNESS_NONE
>>> +This type is considered neither signed, or unsigned.  This applies to
>>> +all non-scalar types (e.g.@: c language structs), but can sometimes be
>>> +the value return for scalar type, one example of where this can be
>>> +seen is in C++, where @code{char}, @code{signed char}, and
>>> +@code{unsigned char} are all considered distinct types.
>>
>> I'm curious, why would type `unsigned char` not return
>> gdb.TYPE_SIGNEDNESS_UNSIGNED?  I see the corresponding code in
>> gdbtypes.c, with the m_flag_nosign flag, so I understand that you would
>> implementation the Python binding based on that, but I am wondering
>> about the historical reason.
> 
> Sorry, but I don't understand the question.  I'm assuming you actually
> meant to ask a slightly different question, but, just for clarity,
> I'll answer your actual question first.  I added these declarations to
> gdb.python/py-type.c:
> 
>   unsigned char global_unsigned_char;
>   char global_char;
>   signed char global_signed_char;
> 
> And these tests to gdb.python/py-type.exp:
> 
>   gdb_test "python print (gdb.parse_and_eval ('global_unsigned_char').type.signedness == gdb.TYPE_SIGNEDNESS_UNSIGNED)" "True"
>   gdb_test "python print (gdb.parse_and_eval ('global_char').type.signedness == gdb.TYPE_SIGNEDNESS_NONE)" "True"
>   gdb_test "python print (gdb.parse_and_eval ('global_signed_char').type.signedness == gdb.TYPE_SIGNEDNESS_SIGNED)" "True"
> 
> So you can see that `unsigned char` does return
> gdb.TYPE_SIGNEDNESS_UNSIGNED.

Ah, from the sentence in the doc, I assumed that all three would return
NONE.

> 
> If your question is why would `char` not return UNSIGNED, then it
> appears that plain char is not defined as unsigned in the standard.
> This appears to be described in 6.2.5/15 of the C language draft that
> I have to hand:
> 
>   "The three types char, signed char, and unsigned char are
>    collectively called the character types. The implementation shall
>    define char to have the same range, representation, and behavior as
>    either signed char or unsigned char.)"
> 
> But I guess the problem is that whether char is signed or unsigned is
> not encoded into the DWARF.

If I look at one of my executables, compiled with gcc 11:

0x00000069:   DW_TAG_base_type
                DW_AT_byte_size [DW_FORM_data1] (0x01)
                DW_AT_encoding [DW_FORM_data1]  (DW_ATE_signed_char)
                DW_AT_name [DW_FORM_strp]       ("char")

And if I build with -funsigned-char:

0x00000069:   DW_TAG_base_type
                DW_AT_byte_size [DW_FORM_data1] (0x01)
                DW_AT_encoding [DW_FORM_data1]  (DW_ATE_unsigned_char)
                DW_AT_name [DW_FORM_strp]       ("char")

Yet, the DWARF reader does:

  if (type->code () == TYPE_CODE_INT
      && name != nullptr
      && strcmp (name, "char") == 0)
    type->set_has_no_signedness (true);

I'd like to know the rationale for this, it doesn't make sense to me.
This is pretty much orthogonal to your patch though, your patch in
itself looks good to me.

Simon