[PATCH, V2 4/9] include: sframe: doc: define new flag SFRAME_F_FDE_FUNC_START_ADDR_PCREL

[Indu Bhagat]

On 6/6/25 3:00 AM, Jan Beulich wrote:
> On 04.06.2025 09:08, Indu Bhagat via Binutils wrote:
>> --- a/libsframe/sframe.c
>> +++ b/libsframe/sframe.c
>> @@ -205,7 +205,8 @@ flip_fde (sframe_func_desc_entry *fdep)
>>   static bool
>>   sframe_header_sanity_check_p (sframe_header *hp)
>>   {
>> -  unsigned char all_flags = SFRAME_F_FDE_SORTED | SFRAME_F_FRAME_POINTER;
>> +  uint8_t all_flags = (SFRAME_F_FDE_SORTED | SFRAME_F_FRAME_POINTER
>> +		       | SFRAME_F_FDE_FUNC_START_ADDR_PCREL);
> 
> Why the switch to uint8_t? From an abstract pov, unsigned char will be
> available everywhere. Whether uint8_t exists is in principle uncertain;
> none of the uint<N>_t are required to be provided. They may, aiui, in
> particular be absent on architectures where (in binutils) we end up with
> OCTETS_PER_BYTE != 1 (TI C4x / C54x). IOW using basic types is generally
> preferable, wherever possible.
> 

RE: why switch to uint8_t. The data type used in the format 
specification for flags is uint8_t.

Elsewhere in bfd/elf-sframe.c too, the code also uses uint8_t for 
flags/version. So this was for consistency sake ATM: make sure to use 
uint8_t for flags.

There is the commit 6b258591644cf1db97113cc00f5373135d8755ba which makes 
me think that uin8_t being available is relied on by other components 
too; perhaps I am missing something.  In any case, if more flags are 
added, and OCTETS_PER_BYTE != 1, its more correct to use uint8_t, no?