_rtld_global, _rtld_global_ro (and local aliases) as an optimization

_rtld_global, _rtld_global_ro (and local aliases) as an optimization

[Florian Weimer]

We currently use _rtld_global, _rtld_global_ro to pass information from
ld.so to the other shared objects.  For this purpose, it is convenient
to have everything in two structs because we do not need to add
additional exports.

There is another effect, though.  Due to the local hidden aliases
_rtld_local, _rtld_local_ro in ld.so (similar to
rtld_hidden_proto/rtld_hidden_def, but implemented differently), the
instruction sequence for field access is potentially shorter than it
would be if all these fields were separate global variables (still with
hidden visibility).  On many RISC targets, constructing the address of a
hidden global variable or a struct member needs two instructions.
However, obtaining the address of a different struct member is just one
instruction if you already have the address of another member.

Is this optimization still important?  It's often preferable not to add
new fields to _rtld_global/_rtld_global_ro for data that is internal to
ld.so, to avoid changing the internal GLIBC_PRIVATE ABI.  This helps
with backporting because it enables zero-downtime upgrades.

Thanks,
Florian

Re: _rtld_global, _rtld_global_ro (and local aliases) as an optimization

[Adhemerval Zanella Netto]

On 06/06/23 09:14, Florian Weimer via Libc-alpha wrote:
> We currently use _rtld_global, _rtld_global_ro to pass information from
> ld.so to the other shared objects.  For this purpose, it is convenient
> to have everything in two structs because we do not need to add
> additional exports.
> 
> There is another effect, though.  Due to the local hidden aliases
> _rtld_local, _rtld_local_ro in ld.so (similar to
> rtld_hidden_proto/rtld_hidden_def, but implemented differently), the
> instruction sequence for field access is potentially shorter than it
> would be if all these fields were separate global variables (still with
> hidden visibility).  On many RISC targets, constructing the address of a
> hidden global variable or a struct member needs two instructions.
> However, obtaining the address of a different struct member is just one
> instruction if you already have the address of another member.
> 
> Is this optimization still important?  It's often preferable not to add
> new fields to _rtld_global/_rtld_global_ro for data that is internal to
> ld.so, to avoid changing the internal GLIBC_PRIVATE ABI.  This helps
> with backporting because it enables zero-downtime upgrades.

It is not really clear which optimization are you referring here, do mean
using __rtld_local_attribute__ with section (".sdata") when the architecture 
supports it (like mostly RISC targets)? Or having _rtld_global_ro being an
alias to _rtld_local_ro within the loader?

Also, what kind of changing are you proposing? 

Re: _rtld_global, _rtld_global_ro (and local aliases) as an optimization

[Florian Weimer]

* Adhemerval Zanella Netto:

> On 06/06/23 09:14, Florian Weimer via Libc-alpha wrote:
>> We currently use _rtld_global, _rtld_global_ro to pass information from
>> ld.so to the other shared objects.  For this purpose, it is convenient
>> to have everything in two structs because we do not need to add
>> additional exports.
>> 
>> There is another effect, though.  Due to the local hidden aliases
>> _rtld_local, _rtld_local_ro in ld.so (similar to
>> rtld_hidden_proto/rtld_hidden_def, but implemented differently), the
>> instruction sequence for field access is potentially shorter than it
>> would be if all these fields were separate global variables (still with
>> hidden visibility).  On many RISC targets, constructing the address of a
>> hidden global variable or a struct member needs two instructions.
>> However, obtaining the address of a different struct member is just one
>> instruction if you already have the address of another member.
>> 
>> Is this optimization still important?  It's often preferable not to add
>> new fields to _rtld_global/_rtld_global_ro for data that is internal to
>> ld.so, to avoid changing the internal GLIBC_PRIVATE ABI.  This helps
>> with backporting because it enables zero-downtime upgrades.
>
> It is not really clear which optimization are you referring here, do mean
> using __rtld_local_attribute__ with section (".sdata") when the architecture 
> supports it (like mostly RISC targets)? Or having _rtld_global_ro being an
> alias to _rtld_local_ro within the loader?

Maintaining global variables as _rtld_global/_rtld_global_ro fields even
if they are not needed outside ld.so.

> Also, what kind of changing are you proposing? 

As a concrete example, we could turn GLRO(dl_dso_sort_algo) into

static int dso_sort_algo;

in elf/dl-sort-maps.c because it's not used outside the file.

Thanks,
Florian

Re: _rtld_global, _rtld_global_ro (and local aliases) as an optimization

[Andreas Schwab]

On Jun 07 2023, Florian Weimer via Libc-alpha wrote:

> As a concrete example, we could turn GLRO(dl_dso_sort_algo) into
>
> static int dso_sort_algo;
>
> in elf/dl-sort-maps.c because it's not used outside the file.

I think it was just a mistake to put it there initially.  None of the
definitions related to the DSO sort algo (except _dl_sort_maps_init)
need to be visible outside that file.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: _rtld_global, _rtld_global_ro (and local aliases) as an optimization

[Florian Weimer]

* Andreas Schwab:

> On Jun 07 2023, Florian Weimer via Libc-alpha wrote:
>
>> As a concrete example, we could turn GLRO(dl_dso_sort_algo) into
>>
>> static int dso_sort_algo;
>>
>> in elf/dl-sort-maps.c because it's not used outside the file.
>
> I think it was just a mistake to put it there initially.  None of the
> definitions related to the DSO sort algo (except _dl_sort_maps_init)
> need to be visible outside that file.

We have more cases that are somewhat similar, where we could use an
extern attribute_hidden variable instead of a struct member.  What about
those?

Thanks,
Florian

Re: _rtld_global, _rtld_global_ro (and local aliases) as an optimization

[Adhemerval Zanella Netto]

On 07/06/23 06:37, Florian Weimer wrote:
> * Andreas Schwab:
> 
>> On Jun 07 2023, Florian Weimer via Libc-alpha wrote:
>>
>>> As a concrete example, we could turn GLRO(dl_dso_sort_algo) into
>>>
>>> static int dso_sort_algo;
>>>
>>> in elf/dl-sort-maps.c because it's not used outside the file.
>>
>> I think it was just a mistake to put it there initially.  None of the
>> definitions related to the DSO sort algo (except _dl_sort_maps_init)
>> need to be visible outside that file.
> 
> We have more cases that are somewhat similar, where we could use an
> extern attribute_hidden variable instead of a struct member.  What about
> those?

I think it makes sense to cleanup the _rtld_global/_rtld_global_ro variables,
as Andreas has put there are multiple examples that we shouldn't had to
update it.

Re: _rtld_global, _rtld_global_ro (and local aliases) as an optimization

[Florian Weimer]

* Adhemerval Zanella Netto:

> On 07/06/23 06:37, Florian Weimer wrote:
>> * Andreas Schwab:
>> 
>>> On Jun 07 2023, Florian Weimer via Libc-alpha wrote:
>>>
>>>> As a concrete example, we could turn GLRO(dl_dso_sort_algo) into
>>>>
>>>> static int dso_sort_algo;
>>>>
>>>> in elf/dl-sort-maps.c because it's not used outside the file.
>>>
>>> I think it was just a mistake to put it there initially.  None of the
>>> definitions related to the DSO sort algo (except _dl_sort_maps_init)
>>> need to be visible outside that file.
>> 
>> We have more cases that are somewhat similar, where we could use an
>> extern attribute_hidden variable instead of a struct member.  What about
>> those?
>
> I think it makes sense to cleanup the _rtld_global/_rtld_global_ro variables,
> as Andreas has put there are multiple examples that we shouldn't had to
> update it.

So the consensus is that we should use this only for cross-DSO
information sharing, and not for optimizing address computation of
global data variables?

Thanks,
Florian

Re: _rtld_global, _rtld_global_ro (and local aliases) as an optimization

[Adhemerval Zanella Netto]

On 07/06/23 09:21, Florian Weimer wrote:
> * Adhemerval Zanella Netto:
> 
>> On 07/06/23 06:37, Florian Weimer wrote:
>>> * Andreas Schwab:
>>>
>>>> On Jun 07 2023, Florian Weimer via Libc-alpha wrote:
>>>>
>>>>> As a concrete example, we could turn GLRO(dl_dso_sort_algo) into
>>>>>
>>>>> static int dso_sort_algo;
>>>>>
>>>>> in elf/dl-sort-maps.c because it's not used outside the file.
>>>>
>>>> I think it was just a mistake to put it there initially.  None of the
>>>> definitions related to the DSO sort algo (except _dl_sort_maps_init)
>>>> need to be visible outside that file.
>>>
>>> We have more cases that are somewhat similar, where we could use an
>>> extern attribute_hidden variable instead of a struct member.  What about
>>> those?
>>
>> I think it makes sense to cleanup the _rtld_global/_rtld_global_ro variables,
>> as Andreas has put there are multiple examples that we shouldn't had to
>> update it.
> 
> So the consensus is that we should use this only for cross-DSO
> information sharing, and not for optimizing address computation of
> global data variables?

Which cases are uses solely for optimizing address computation? For, instance
the _dl_pagesize along with _dl_auxv. On Linux, we don't really _dl_pagesize,
but it is simpler and faster than iterate over _dl_auxv.

Re: _rtld_global, _rtld_global_ro (and local aliases) as an optimization

[Florian Weimer]

* Adhemerval Zanella Netto:

>> So the consensus is that we should use this only for cross-DSO
>> information sharing, and not for optimizing address computation of
>> global data variables?
>
> Which cases are uses solely for optimizing address computation? For, instance
> the _dl_pagesize along with _dl_auxv. On Linux, we don't really _dl_pagesize,
> but it is simpler and faster than iterate over _dl_auxv.

I believe GL (dl_rtld_map) is only used within ld.so.

Thanks,
Florian