[PATCH v3 08/11] s390: Store SFrame CFA offset adjusted

Indu Bhagat indu.bhagat@oracle.com
Tue Jul 8 07:31:01 GMT 2025


On 7/7/25 11:49 PM, Jan Beulich wrote:
> On 07.07.2025 19:48, Indu Bhagat wrote:
>> On 7/7/25 8:07 AM, Jens Remus wrote:
>>>>> @@ -134,10 +134,26 @@ sframe_fre_set_cfa_base_reg (struct sframe_row_entry *fre,
>>>>>       fre->merge_candidate = false;
>>>>>     }
>>>>>     +static offsetT
>>>>> +sframe_fre_get_cfa_offset (const struct sframe_row_entry * fre)
>>> The recent fix of relocatable SFrame links now include "sframe-api.h".
>>> This cases above new internal helper to clash with the external SFrame
>>> API function of same name.  For V4 I have prefixed the internal helper
>>> with "__", which I somewhat dislike.  Any better suggestion to resolve?
>>
>> Ugh, I did not like bringing in the "sframe-api.h" at all into
>> gas/gen-sframe.c just for the the SFRAME_F_LD_MUSTHAVE_FLAGS.
> 
> To answer the question below I'd first like to understand why using this
> header in gas/gen-sframe.c is (deemed) bad. It looks quite natural to me
> that to be able to use any part of what's defined there (even if only
> flag values), that header needs including. Or of that was a problem, the
> header may need splitting.
> 

(sframe-api.h is the implementation header file for consumers using 
libsframe APIs.)  gas has its own SFrame writing logic (via fragment 
creation etc.) and has not needed the libsframe APIs so far.  To include 
it only for SFRAME_F_LD_MUSTHAVE_FLAGS just seemed like tieing up an 
interface which is not necessary.

Inclusion of sframe-api.h causing collisions like Jens runs into, and 
then needing to bypass them are both unpalatable, I thought.

Thanks

> Jan
> 
>>   I am
>> having second thoughts about it, perhaps we remove it and remove the
>> assert too:
>>
>>     /* gas must ensure emitted SFrame sections have at least the required
>> flags
>>        set.  */
>>     gas_assert ((sframe_flags & SFRAME_F_LD_MUSTHAVE_FLAGS)
>>                 == SFRAME_F_LD_MUSTHAVE_FLAGS);
>>
>> Jan, what is your opinion on this ?
>>
>> (And apologies for back and forth, but now I find including sframe-api.h
>> is not worth it.)
>>
>>
> 



More information about the Binutils mailing list