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

[Jan Beulich]

On 08.07.2025 09:31, Indu Bhagat wrote:
> 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.

Including that header ought to be permissible anywhere, including gas
sources. If gas (and maybe other components) are interested in the
#define-s (and possibly types) only, can the header file maybe gain a
mode (off by default) by which the function declarations would be
hidden?

More generally though I think that it would be better to avoid any
name collisions. Two entities of exactly the same name can easily be
confusing.

Jan