Home Original page

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

Jan Beulich jbeulich@suse.com
Thu Jun 12 06:53:35 GMT 2025 
On 12.06.2025 07:28, Indu Bhagat wrote:
> On 6/9/25 11:17 PM, Jan Beulich wrote:
>> On 07.06.2025 07:37, Indu Bhagat wrote:
>>> 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?
>>
>> I fear I can't answer this question, as - just to repeat - my understanding
>> is that on an arch where (when it's that target of a binutils build) we'd
>> set OCTETS_PER_BYTE to greater than 1, there's not going to be uint8_t. I
>> simply don't see how it could be defined there, fulfilling the requirements
>> of the standard. (By implication, my understanding is that for such targets
>> only cross builds of binutils are presently possible.)
>>
> 
> IIUC, it appears to me that there will simply be build failures in those 
> cases.  BTW, as I pointed out, its not just the SFrame standard, there 
> are other usages of uint8_t in bfd/, binutils/ etc.

Yes, there are more problems in this area. But why make existing problems
worse?

> Overall, I am not sure what the ask here is.

See the original question: Is there a particular reason you need to switch
from "unsigned char" to "uint8_t" here? Especially when such a change is
entirely unrelated to the purpose of the patch?

Jan
More information about the Binutils mailing list