Re: How to compress the size of a field in a structure?

[Richard Biener via Gcc]

On Sat, Jan 13, 2024 at 8:46 AM Hanke Zhang via Gcc  wrote:
>
> Hi, I'm attempting to compress the size of a field in a structure for
> memory-friendly purposes. I created an IPA pass to achieve this, but I
> ran into some issues as follows:
>
> // original
> struct Foo {
>   long a1;
>   int a2;
> };
>
> // modified
> struct Foo_update {
>   int a1;
>   int a2;
> };
>
> For the example structure Foo, I use `TREE_TYPE (field) =
> integer_type_node` to compress the type of a1 from `long` to `int`.
>
> But I don't know how to update its corresponding SSA variables,
> because the number of them is huge. Is there any way to do it quickly?

There's no way to map back a structure field to all of its [implicit]
uses.  But the
set of variables to adjust should fall out trivially of the analysis phase that
determines whether the transform is valid (which is indeed the most complicated
part).

It might be possible to restrict the transform to certain objects
(rather than the "type").

There were several similar attempts on doing "struct reorg", the most recent by
people from amerecomputing IIRC.  I've always commented that trying to do
this on the types (and computing sth like "type escape") is wrong, analysis and
transform should be on individual instances of the type instead - those you can
actually analyze.

Richard.

>
> Thanks
> Hanke Zhang

Why is -ffold-mem-offsets a target option?

[Georg-Johann Lay]

Just noticed that -ffold-mem-offsets is a target option, i.e. it is
shown with --help=target

> grep -A3 mem-off common.opt
ffold-mem-offsets
Target Bool Var(flag_fold_mem_offsets) Init(1)
Fold instructions calculating memory offsets to the memory access 
instruction if possible.


Is that "Target" a typo or what?

Johann

Re: Why is -ffold-mem-offsets a target option?

[Richard Biener via Gcc]

On Mon, Jan 15, 2024 at 11:22 AM Georg-Johann Lay  wrote:
>
> Just noticed that -ffold-mem-offsets is a target option, i.e. it is
> shown with --help=target
>
>  > grep -A3 mem-off common.opt
> ffold-mem-offsets
> Target Bool Var(flag_fold_mem_offsets) Init(1)
> Fold instructions calculating memory offsets to the memory access
> instruction if possible.
>
> Is that "Target" a typo or what?

I think it is indeed.  Can you file a bugreport?

> Johann

Re: New TLS usage in libgcc_s.so.1, compatibility impact

[Szabolcs Nagy via Gcc]

The 01/13/2024 13:49, Florian Weimer wrote:
> This commit
> 
> commit 8abddb187b33480d8827f44ec655f45734a1749d
> Author: Andrew Burgess 
> Date:   Sat Aug 5 14:31:06 2023 +0200
> 
> libgcc: support heap-based trampolines
> 
> Add support for heap-based trampolines on x86_64-linux, aarch64-linux,
> and x86_64-darwin. Implement the __builtin_nested_func_ptr_created and
> __builtin_nested_func_ptr_deleted functions for these targets.
> 
> Co-Authored-By: Maxim Blinov 
> Co-Authored-By: Iain Sandoe 
> Co-Authored-By: Francois-Xavier Coudert 
> 
> added TLS usage to libgcc_s.so.1.  The way that libgcc_s is currently
> built, it ends up using a dynamic TLS variant on the Linux targets.
> This means that there is no up-front TLS allocation with glibc (but
> there would be one with musl).
> 
> There is still a compatibility impact because glibc assigns a TLS module
> ID upfront.  This seems to be what causes the
> ust/libc-wrapper/test_libc-wrapper test in lttng-tools to fail.  We end
> up with an infinite regress during process termination because
> libgcc_s.so.1 has been loaded, resulting in a DTV update.  When this
> happens, the bottom of the stack looks like this:
> 
> #4447 0x77f288f0 in free () from /lib64/liblttng-ust-libc-wrapper.so.1
> #4448 0x77fdb142 in free (ptr=)
> at ../include/rtld-malloc.h:50
> #4449 _dl_update_slotinfo (req_modid=3, new_gen=2) at ../elf/dl-tls.c:822
> #4450 0x77fdb214 in update_get_addr (ti=0x77f2bfc0, 
> gen=) at ../elf/dl-tls.c:916
> #4451 0x77fddccc in __tls_get_addr ()
> at ../sysdeps/x86_64/tls_get_addr.S:55
> #4452 0x77f288f0 in free () from /lib64/liblttng-ust-libc-wrapper.so.1
> #4453 0x77fdb142 in free (ptr=)
> at ../include/rtld-malloc.h:50
> #4454 _dl_update_slotinfo (req_modid=2, new_gen=2) at ../elf/dl-tls.c:822
> #4455 0x77fdb214 in update_get_addr (ti=0x77f39fa0, 
> gen=) at ../elf/dl-tls.c:916
> #4456 0x77fddccc in __tls_get_addr ()
> at ../sysdeps/x86_64/tls_get_addr.S:55
> #4457 0x77f36113 in lttng_ust_cancelstate_disable_push ()
>from /lib64/liblttng-ust-common.so.1
> #4458 0x77f4c2e8 in ust_lock_nocheck () from /lib64/liblttng-ust.so.1
> #4459 0x77f5175a in lttng_ust_cleanup () from /lib64/liblttng-ust.so.1
> #4460 0x77fca0f2 in _dl_call_fini (
> closure_map=closure_map@entry=0x77fbe000) at dl-call_fini.c:43
> #4461 0x77fce06e in _dl_fini () at dl-fini.c:114
> #4462 0x77d82fe6 in __run_exit_handlers () from /lib64/libc.so.6
> 
> Cc:ing  for awareness.
> 
> The issue also requires a recent glibc with changes to DTV management:
> commit d2123d68275acc0f061e73d5f86ca504e0d5a344 ("elf: Fix slow tls
> access after dlopen [BZ #19924]").  If I understand things correctly,
> before this glibc change, we didn't deallocate the old DTV, so there was
> no call to the free function.

with 19924 fixed, after a dlopen or dlclose every thread updates
its dtv on the next dynamic tls access.

before that, dtv was only updated up to the generation of the
module being accessed for a particular tls access.

so hitting the free in the dtv update path is now more likely
but the free is not new, it was there before.

also note that this is unlikely to happen on aarch64 since
tlsdesc only does dynamic tls access after a 512byte static
tls reservation runs out.

> 
> On the glibc side, we should recommend that intercepting mallocs and its
> dependencies use initial-exec TLS because that kind of TLS does not use
> malloc.  If intercepting mallocs using dynamic TLS work at all, that's
> totally by accident, and was in the past helped by glibc bug 19924.  (I

right.

> don't think there is anything special about libgcc_s.so.1 that triggers
> the test failure above, it is just an object with dynamic TLS that is
> implicitly loaded via dlopen at the right stage of the test.)  In this
> particular case, we can also paper over the test failure in glibc by not
> call free at all because the argument is a null pointer:
> 
> diff --git a/elf/dl-tls.c b/elf/dl-tls.c
> index 7b3dd9ab60..14c71cbd06 100644
> --- a/elf/dl-tls.c
> +++ b/elf/dl-tls.c
> @@ -819,7 +819,8 @@ _dl_update_slotinfo (unsigned long int req_modid, size_t 
> new_gen)
>dtv entry free it.  Note: this is not AS-safe.  */
> /* XXX Ideally we will at some point create a memory
>pool.  */
> -   free (dtv[modid].pointer.to_free);
> +   if (dtv[modid].pointer.to_free != NULL)
> + free (dtv[modid].pointer.to_free);
> dtv[modid].pointer.val = TLS_DTV_UNALLOCATED;
> dtv[modid].pointer.to_free = NULL;

can be done, but !=NULL is more likely since we do modid reuse
after dlclose.

there is also a realloc in dtv resizing which happens when more
than 16 modules with tls are loaded after thread creation
(DTV_SURPLUS).

i'm not sure if it's worth supporting malloc

Re: Why is -ffold-mem-offsets a target option?

[Georg-Johann Lay]

Am 15.01.24 um 13:20 schrieb Richard Biener:

On Mon, Jan 15, 2024 at 11:22 AM Georg-Johann Lay  wrote:


Just noticed that -ffold-mem-offsets is a target option, i.e. it is
shown with --help=target

  > grep -A3 mem-off common.opt
ffold-mem-offsets
Target Bool Var(flag_fold_mem_offsets) Init(1)
Fold instructions calculating memory offsets to the memory access
instruction if possible.

Is that "Target" a typo or what?


I think it is indeed.  Can you file a bugreport?


Johann


https://gcc.gnu.org/PR113399

Re: New TLS usage in libgcc_s.so.1, compatibility impact

[Adhemerval Zanella Netto via Gcc]

On 15/01/24 09:46, Szabolcs Nagy wrote:
> The 01/13/2024 13:49, Florian Weimer wrote:
>> This commit
>>
>> commit 8abddb187b33480d8827f44ec655f45734a1749d
>> Author: Andrew Burgess 
>> Date:   Sat Aug 5 14:31:06 2023 +0200
>>
>> libgcc: support heap-based trampolines
>> 
>> Add support for heap-based trampolines on x86_64-linux, aarch64-linux,
>> and x86_64-darwin. Implement the __builtin_nested_func_ptr_created and
>> __builtin_nested_func_ptr_deleted functions for these targets.
>> 
>> Co-Authored-By: Maxim Blinov 
>> Co-Authored-By: Iain Sandoe 
>> Co-Authored-By: Francois-Xavier Coudert 
>>
>> added TLS usage to libgcc_s.so.1.  The way that libgcc_s is currently
>> built, it ends up using a dynamic TLS variant on the Linux targets.
>> This means that there is no up-front TLS allocation with glibc (but
>> there would be one with musl).
>>
>> There is still a compatibility impact because glibc assigns a TLS module
>> ID upfront.  This seems to be what causes the
>> ust/libc-wrapper/test_libc-wrapper test in lttng-tools to fail.  We end
>> up with an infinite regress during process termination because
>> libgcc_s.so.1 has been loaded, resulting in a DTV update.  When this
>> happens, the bottom of the stack looks like this:
>>
>> #4447 0x77f288f0 in free () from 
>> /lib64/liblttng-ust-libc-wrapper.so.1
>> #4448 0x77fdb142 in free (ptr=)
>> at ../include/rtld-malloc.h:50
>> #4449 _dl_update_slotinfo (req_modid=3, new_gen=2) at ../elf/dl-tls.c:822
>> #4450 0x77fdb214 in update_get_addr (ti=0x77f2bfc0, 
>> gen=) at ../elf/dl-tls.c:916
>> #4451 0x77fddccc in __tls_get_addr ()
>> at ../sysdeps/x86_64/tls_get_addr.S:55
>> #4452 0x77f288f0 in free () from 
>> /lib64/liblttng-ust-libc-wrapper.so.1
>> #4453 0x77fdb142 in free (ptr=)
>> at ../include/rtld-malloc.h:50
>> #4454 _dl_update_slotinfo (req_modid=2, new_gen=2) at ../elf/dl-tls.c:822
>> #4455 0x77fdb214 in update_get_addr (ti=0x77f39fa0, 
>> gen=) at ../elf/dl-tls.c:916
>> #4456 0x77fddccc in __tls_get_addr ()
>> at ../sysdeps/x86_64/tls_get_addr.S:55
>> #4457 0x77f36113 in lttng_ust_cancelstate_disable_push ()
>>from /lib64/liblttng-ust-common.so.1
>> #4458 0x77f4c2e8 in ust_lock_nocheck () from /lib64/liblttng-ust.so.1
>> #4459 0x77f5175a in lttng_ust_cleanup () from 
>> /lib64/liblttng-ust.so.1
>> #4460 0x77fca0f2 in _dl_call_fini (
>> closure_map=closure_map@entry=0x77fbe000) at dl-call_fini.c:43
>> #4461 0x77fce06e in _dl_fini () at dl-fini.c:114
>> #4462 0x77d82fe6 in __run_exit_handlers () from /lib64/libc.so.6
>>
>> Cc:ing  for awareness.
>>
>> The issue also requires a recent glibc with changes to DTV management:
>> commit d2123d68275acc0f061e73d5f86ca504e0d5a344 ("elf: Fix slow tls
>> access after dlopen [BZ #19924]").  If I understand things correctly,
>> before this glibc change, we didn't deallocate the old DTV, so there was
>> no call to the free function.
> 
> with 19924 fixed, after a dlopen or dlclose every thread updates
> its dtv on the next dynamic tls access.
> 
> before that, dtv was only updated up to the generation of the
> module being accessed for a particular tls access.
> 
> so hitting the free in the dtv update path is now more likely
> but the free is not new, it was there before.
> 
> also note that this is unlikely to happen on aarch64 since
> tlsdesc only does dynamic tls access after a 512byte static
> tls reservation runs out.
> 
>>
>> On the glibc side, we should recommend that intercepting mallocs and its
>> dependencies use initial-exec TLS because that kind of TLS does not use
>> malloc.  If intercepting mallocs using dynamic TLS work at all, that's
>> totally by accident, and was in the past helped by glibc bug 19924.  (I
> 
> right.
> 
>> don't think there is anything special about libgcc_s.so.1 that triggers
>> the test failure above, it is just an object with dynamic TLS that is
>> implicitly loaded via dlopen at the right stage of the test.)  In this
>> particular case, we can also paper over the test failure in glibc by not
>> call free at all because the argument is a null pointer:
>>
>> diff --git a/elf/dl-tls.c b/elf/dl-tls.c
>> index 7b3dd9ab60..14c71cbd06 100644
>> --- a/elf/dl-tls.c
>> +++ b/elf/dl-tls.c
>> @@ -819,7 +819,8 @@ _dl_update_slotinfo (unsigned long int req_modid, size_t 
>> new_gen)
>>   dtv entry free it.  Note: this is not AS-safe.  */
>>/* XXX Ideally we will at some point create a memory
>>   pool.  */
>> -  free (dtv[modid].pointer.to_free);
>> +  if (dtv[modid].pointer.to_free != NULL)
>> +free (dtv[modid].pointer.to_free);
>>dtv[modid].pointer.val = TLS_DTV_UNALLOCATED;
>>dtv[modid].pointer.to_free = NULL;
> 
> can be done, but !=NULL is more likely since we do modid reuse
> after dlclose.
> 
> there is also

Office Hours for the GNU Toolchain on 2024-01-25 at 11am EST5EDT.

[Carlos O'Donell via Gcc]

Office Hours for the GNU Toolchain on 2024-01-25 at 11am EST5EDT.

Agenda:
* https://gcc.gnu.org/wiki/OfficeHours#Next

Meeting Link:
* https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6

-- 
Cheers,
Carlos.

Re: New TLS usage in libgcc_s.so.1, compatibility impact

[Carlos O'Donell via Gcc]

On 1/15/24 08:55, Adhemerval Zanella Netto wrote:
> 
> 
> On 15/01/24 09:46, Szabolcs Nagy wrote:
>> The 01/13/2024 13:49, Florian Weimer wrote:
>>> This commit
>>>
>>> commit 8abddb187b33480d8827f44ec655f45734a1749d
>>> Author: Andrew Burgess 
>>> Date:   Sat Aug 5 14:31:06 2023 +0200
>>>
>>> libgcc: support heap-based trampolines
>>> 
>>> Add support for heap-based trampolines on x86_64-linux, aarch64-linux,
>>> and x86_64-darwin. Implement the __builtin_nested_func_ptr_created and
>>> __builtin_nested_func_ptr_deleted functions for these targets.
>>> 
>>> Co-Authored-By: Maxim Blinov 
>>> Co-Authored-By: Iain Sandoe 
>>> Co-Authored-By: Francois-Xavier Coudert 
>>>
>>> added TLS usage to libgcc_s.so.1.  The way that libgcc_s is currently
>>> built, it ends up using a dynamic TLS variant on the Linux targets.
>>> This means that there is no up-front TLS allocation with glibc (but
>>> there would be one with musl).
>>>
>>> There is still a compatibility impact because glibc assigns a TLS module
>>> ID upfront.  This seems to be what causes the
>>> ust/libc-wrapper/test_libc-wrapper test in lttng-tools to fail.  We end
>>> up with an infinite regress during process termination because
>>> libgcc_s.so.1 has been loaded, resulting in a DTV update.  When this
>>> happens, the bottom of the stack looks like this:
>>>
>>> #4447 0x77f288f0 in free () from 
>>> /lib64/liblttng-ust-libc-wrapper.so.1
>>> #4448 0x77fdb142 in free (ptr=)
>>> at ../include/rtld-malloc.h:50
>>> #4449 _dl_update_slotinfo (req_modid=3, new_gen=2) at ../elf/dl-tls.c:822
>>> #4450 0x77fdb214 in update_get_addr (ti=0x77f2bfc0, 
>>> gen=) at ../elf/dl-tls.c:916
>>> #4451 0x77fddccc in __tls_get_addr ()
>>> at ../sysdeps/x86_64/tls_get_addr.S:55
>>> #4452 0x77f288f0 in free () from 
>>> /lib64/liblttng-ust-libc-wrapper.so.1
>>> #4453 0x77fdb142 in free (ptr=)
>>> at ../include/rtld-malloc.h:50
>>> #4454 _dl_update_slotinfo (req_modid=2, new_gen=2) at ../elf/dl-tls.c:822
>>> #4455 0x77fdb214 in update_get_addr (ti=0x77f39fa0, 
>>> gen=) at ../elf/dl-tls.c:916
>>> #4456 0x77fddccc in __tls_get_addr ()
>>> at ../sysdeps/x86_64/tls_get_addr.S:55
>>> #4457 0x77f36113 in lttng_ust_cancelstate_disable_push ()
>>>from /lib64/liblttng-ust-common.so.1
>>> #4458 0x77f4c2e8 in ust_lock_nocheck () from 
>>> /lib64/liblttng-ust.so.1
>>> #4459 0x77f5175a in lttng_ust_cleanup () from 
>>> /lib64/liblttng-ust.so.1
>>> #4460 0x77fca0f2 in _dl_call_fini (
>>> closure_map=closure_map@entry=0x77fbe000) at dl-call_fini.c:43
>>> #4461 0x77fce06e in _dl_fini () at dl-fini.c:114
>>> #4462 0x77d82fe6 in __run_exit_handlers () from /lib64/libc.so.6
>>>
>>> Cc:ing  for awareness.
>>>
>>> The issue also requires a recent glibc with changes to DTV management:
>>> commit d2123d68275acc0f061e73d5f86ca504e0d5a344 ("elf: Fix slow tls
>>> access after dlopen [BZ #19924]").  If I understand things correctly,
>>> before this glibc change, we didn't deallocate the old DTV, so there was
>>> no call to the free function.
>>
>> with 19924 fixed, after a dlopen or dlclose every thread updates
>> its dtv on the next dynamic tls access.
>>
>> before that, dtv was only updated up to the generation of the
>> module being accessed for a particular tls access.
>>
>> so hitting the free in the dtv update path is now more likely
>> but the free is not new, it was there before.
>>
>> also note that this is unlikely to happen on aarch64 since
>> tlsdesc only does dynamic tls access after a 512byte static
>> tls reservation runs out.
>>
>>>
>>> On the glibc side, we should recommend that intercepting mallocs and its
>>> dependencies use initial-exec TLS because that kind of TLS does not use
>>> malloc.  If intercepting mallocs using dynamic TLS work at all, that's
>>> totally by accident, and was in the past helped by glibc bug 19924.  (I
>>
>> right.
>>
>>> don't think there is anything special about libgcc_s.so.1 that triggers
>>> the test failure above, it is just an object with dynamic TLS that is
>>> implicitly loaded via dlopen at the right stage of the test.)  In this
>>> particular case, we can also paper over the test failure in glibc by not
>>> call free at all because the argument is a null pointer:
>>>
>>> diff --git a/elf/dl-tls.c b/elf/dl-tls.c
>>> index 7b3dd9ab60..14c71cbd06 100644
>>> --- a/elf/dl-tls.c
>>> +++ b/elf/dl-tls.c
>>> @@ -819,7 +819,8 @@ _dl_update_slotinfo (unsigned long int req_modid, 
>>> size_t new_gen)
>>>  dtv entry free it.  Note: this is not AS-safe.  */
>>>   /* XXX Ideally we will at some point create a memory
>>>  pool.  */
>>> - free (dtv[modid].pointer.to_free);
>>> + if (dtv[modid].pointer.to_free != NULL)
>>> +   free (dtv[modid].pointer.to_free);
>>>   dtv[modid].pointer.val = TLS_DTV_UNALLOCATED;
>

Re: New TLS usage in libgcc_s.so.1, compatibility impact

[Florian Weimer via Gcc]

* Carlos O'Donell:

> I agree. TLS should be seen more like .bss/.data rather than something
> that is allocated with malloc().

There wasn't consensus regarding this in 2014.  See below.

> If we leak memory via TLS that is a glibc bug that we can deal with,

This is something that libgcc_s.so.1 does in GCC 14 if the heap
trampolines are used.

> but making it easier to find glibc bugs is also a benefit to the
> community, but not as valuable a benefit as making TLS correctly
> async-signal safe.
>
> Likewise we need to discuss when the memory is allocated, regardless
> of which allocator is used, including allocation up-front at dlopen()
> time.
>> [1] https://sourceware.org/pipermail/libc-alpha/2014-January/047931.html

The change conflated multiple issues: sanitizer support,
async-signal-safe TLS access, and eager allocation of all TLS-related
memory, so that subsequent accesses cannot fail.  My impression was the
main point of contention was eager allocation because it was perceived
as a breaking semantic change.  Nowadays, as long as we are willing to
maintain both allocator variants, we could offer a choice between them
controlled by a tunable.  For sanitizer compatibility, we could perform
eager allocation using malloc.  It's probably a good idea to do it this
way anyway because a separate mmap-based allocator would increase TLB
pressure.

Thanks,
Florian

Re: New TLS usage in libgcc_s.so.1, compatibility impact

[Iain Sandoe]

> On 15 Jan 2024, at 15:35, Florian Weimer  wrote:
> 
> * Carlos O'Donell:
> 
>> I agree. TLS should be seen more like .bss/.data rather than something
>> that is allocated with malloc().
> 
> There wasn't consensus regarding this in 2014.  See below.
> 
>> If we leak memory via TLS that is a glibc bug that we can deal with,
> 
> This is something that libgcc_s.so.1 does in GCC 14 if the heap
> trampolines are used.

Is there a GCC BZ for this?
(if there is something we should address in GCC, it would be better sooner)

Iain


>> but making it easier to find glibc bugs is also a benefit to the
>> community, but not as valuable a benefit as making TLS correctly
>> async-signal safe.
>> 
>> Likewise we need to discuss when the memory is allocated, regardless
>> of which allocator is used, including allocation up-front at dlopen()
>> time.
>>> [1] https://sourceware.org/pipermail/libc-alpha/2014-January/047931.html
> 
> The change conflated multiple issues: sanitizer support,
> async-signal-safe TLS access, and eager allocation of all TLS-related
> memory, so that subsequent accesses cannot fail.  My impression was the
> main point of contention was eager allocation because it was perceived
> as a breaking semantic change.  Nowadays, as long as we are willing to
> maintain both allocator variants, we could offer a choice between them
> controlled by a tunable.  For sanitizer compatibility, we could perform
> eager allocation using malloc.  It's probably a good idea to do it this
> way anyway because a separate mmap-based allocator would increase TLB
> pressure.
> 
> Thanks,
> Florian
> 

Re: New TLS usage in libgcc_s.so.1, compatibility impact

[Joseph Myers via Gcc]

On Mon, 15 Jan 2024, Florian Weimer via Gcc wrote:

> The change conflated multiple issues: sanitizer support,
> async-signal-safe TLS access, and eager allocation of all TLS-related
> memory, so that subsequent accesses cannot fail.  My impression was the
> main point of contention was eager allocation because it was perceived
> as a breaking semantic change.  Nowadays, as long as we are willing to
> maintain both allocator variants, we could offer a choice between them
> controlled by a tunable.  For sanitizer compatibility, we could perform
> eager allocation using malloc.  It's probably a good idea to do it this
> way anyway because a separate mmap-based allocator would increase TLB
> pressure.

Related to eager allocation is the question of whether libgcc_s.so.1 
should be loaded unconditionally by glibc at startup - doing so has much 
the same motivation (avoiding subsequent failures from interfaces that 
don't have any good way to signal failure, when glibc currently loads 
libgcc_s.so.1 dynamically), but also no doubt compatibility risk.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: New TLS usage in libgcc_s.so.1, compatibility impact

[Florian Weimer via Gcc]

* Iain Sandoe:

>> On 15 Jan 2024, at 15:35, Florian Weimer  wrote:
>> 
>> * Carlos O'Donell:
>> 
>>> I agree. TLS should be seen more like .bss/.data rather than something
>>> that is allocated with malloc().
>> 
>> There wasn't consensus regarding this in 2014.  See below.
>> 
>>> If we leak memory via TLS that is a glibc bug that we can deal with,
>> 
>> This is something that libgcc_s.so.1 does in GCC 14 if the heap
>> trampolines are used.
>
> Is there a GCC BZ for this?
> (if there is something we should address in GCC, it would be better sooner)

Sorry, I wanted to write a reproducer first.  With it, I found two more
issue.

  Memory (resource) leak in -ftrampoline-impl=heap
  

  Incorrect symbol versions for __builtin_nested_func_ptr_created,
  __builtin_nested_func_ptr in libgcc_s.so.1
  

  __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be
  dynamically linked by default
  

Thanks,
Florian

GCC GSoC 2024: Call for project ideas and mentors

[Martin Jambor]

Hello,

another year has passed, Google has announced there will be again Google
Summer of Code (GsoC) in 2024 and the deadline for organizations to
apply is already approaching (February 6th).  I'd like to volunteer to
be the main org-admin for GCC again but let me know if you think I
shouldn't or that someone else should or if you want to do it instead.
Otherwise I'll assume that I will and I hope that I can continue to rely
on David Edelsohn and Thomas Schwinge to back me up and help me with
some decision making along the way as my co-org-admins.

 The most important bit: 

I would like to ask all (moderately) seasoned GCC contributors to
consider mentoring a contributor this year and ideally also come up with
a project that they would like to lead.  I'm collecting proposal on our
wiki page https://gcc.gnu.org/wiki/SummerOfCode - feel free to add yours
to the top list there.  Or, if you are unsure, post your offer and
project idea as a reply here to the mailing list.

Additionally, if you have added an idea to the list in the recent years,
please review it whether it is still up-to-date or needs adjusting or
should be removed altogether.

=

At this point, we need to collect list of project ideas.  Eventually,
each listed project idea should have:

  a) a project title,
  b) more detailed description of the project (2-5 sentences),
  c) expected outcomes (we do have a catch-almost-all formulation that
 outcome is generally patches at the bottom of the list on the
 wiki),
  d) skills required/preferred,
  e) project size - whether it is expected to take approximately 350,
 175 or just 90 hours (the last option in new in 2024, see below),
  f) difficulty (easy, hard or medium, but we don't really have easy
 projects), and
  g) expected mentors.

Project ideas that come without an offer to also mentor them are always
fun to discuss, by all means feel free to reply to this email with yours
and I will attempt to find a mentor, but please be aware that we can
only use the suggestion it if we actually find one or ideally two.

Everybody in the GCC community is invited to go over
https://gcc.gnu.org/wiki/SummerOfCode and remove any outdated or
otherwise bad project suggestions and help improve viable ones.

Finally, please continue helping (prospective) students figure stuff out
about GCC like you have always done in the past.

As far as I know, GSoC 2024 should be quite similar to the last year,
the most important parameters probably are these:

  - Contributors (formerly students) must either be full-time students
or be "beginners to open source."

  - There are now three project sizes: roughly 90 hors (small), roughly
175 hours (medium-sized) and roughly 350 hours (large) of work in
total.  The small option is new this year but because our projects
usually have a lengthy learning period, I think we will usually want
to stick to the medium and large variants.

  - Timing should be pretty much as flexible as last year.  The
recommended "standard" duration is 12 weeks but depending on
contributor's and mentor's needs and circumstances, projects can
take anywhere between 10 and 22 weeks.  There will be one mid-term
and one final evaluation.

For further details you can see:

  - The announcement of GSoC 2024:

https://opensource.googleblog.com/2023/11/google-summer-of-code-2024-celebrating-20th-year.html

  - GSoC rules:
https://summerofcode.withgoogle.com/rules

  - The detailed GSoC 2024 timeline:
https://developers.google.com/open-source/gsoc/timeline

  - Elaborate project idea guidelines:
https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list

Thank you very much for your participation and help.  Let's hope we
attract some great contributors again this year.

Martin

Re: [lttng-dev] New TLS usage in libgcc_s.so.1, compatibility impact

[Mathieu Desnoyers via Gcc]

On 2024-01-13 07:49, Florian Weimer via lttng-dev wrote:

This commit

commit 8abddb187b33480d8827f44ec655f45734a1749d
Author: Andrew Burgess 
Date:   Sat Aug 5 14:31:06 2023 +0200

 libgcc: support heap-based trampolines
 
 Add support for heap-based trampolines on x86_64-linux, aarch64-linux,

 and x86_64-darwin. Implement the __builtin_nested_func_ptr_created and
 __builtin_nested_func_ptr_deleted functions for these targets.
 
 Co-Authored-By: Maxim Blinov 

 Co-Authored-By: Iain Sandoe 
 Co-Authored-By: Francois-Xavier Coudert 

added TLS usage to libgcc_s.so.1.  The way that libgcc_s is currently
built, it ends up using a dynamic TLS variant on the Linux targets.
This means that there is no up-front TLS allocation with glibc (but
there would be one with musl).


Trying to wrap my head around this:

If I get this right, the previous behavior was that glibc did allocate
global-dynamic variables from libraries which are preloaded and loaded
on c startup as if they were initial-exec, but now that libgcc_s.so.1
has a dynamic TLS variable, all those libraries loaded on c startup that
have global-dynamic TLS do not get the initial allocation special
treatment anymore. Is that more or less correct ?

(note: it's entirely possible that my understanding is entirely wrong,
please correct me if it's the case)



There is still a compatibility impact because glibc assigns a TLS module
ID upfront.  This seems to be what causes the
ust/libc-wrapper/test_libc-wrapper test in lttng-tools to fail.  We end
up with an infinite regress during process termination because
libgcc_s.so.1 has been loaded, resulting in a DTV update.  When this
happens, the bottom of the stack looks like this:

#4447 0x77f288f0 in free () from /lib64/liblttng-ust-libc-wrapper.so.1
#4448 0x77fdb142 in free (ptr=)
 at ../include/rtld-malloc.h:50
#4449 _dl_update_slotinfo (req_modid=3, new_gen=2) at ../elf/dl-tls.c:822
#4450 0x77fdb214 in update_get_addr (ti=0x77f2bfc0,
 gen=) at ../elf/dl-tls.c:916
#4451 0x77fddccc in __tls_get_addr ()
 at ../sysdeps/x86_64/tls_get_addr.S:55
#4452 0x77f288f0 in free () from /lib64/liblttng-ust-libc-wrapper.so.1
#4453 0x77fdb142 in free (ptr=)
 at ../include/rtld-malloc.h:50
#4454 _dl_update_slotinfo (req_modid=2, new_gen=2) at ../elf/dl-tls.c:822
#4455 0x77fdb214 in update_get_addr (ti=0x77f39fa0,
 gen=) at ../elf/dl-tls.c:916
#4456 0x77fddccc in __tls_get_addr ()
 at ../sysdeps/x86_64/tls_get_addr.S:55
#4457 0x77f36113 in lttng_ust_cancelstate_disable_push ()
from /lib64/liblttng-ust-common.so.1
#4458 0x77f4c2e8 in ust_lock_nocheck () from /lib64/liblttng-ust.so.1
#4459 0x77f5175a in lttng_ust_cleanup () from /lib64/liblttng-ust.so.1
#4460 0x77fca0f2 in _dl_call_fini (
 closure_map=closure_map@entry=0x77fbe000) at dl-call_fini.c:43
#4461 0x77fce06e in _dl_fini () at dl-fini.c:114
#4462 0x77d82fe6 in __run_exit_handlers () from /lib64/libc.so.6

Cc:ing  for awareness.


I've prepared a change for lttng-ust to move the lttng-ust libc wrapper
"malloc nesting" guard variable from global-dynamic to initial-exec:

https://review.lttng.org/c/lttng-ust/+/11677 Fix: libc wrapper: use 
initial-exec for malloc_nesting TLS

This should help for the infinite recursion issue, but if my understanding
is correct about the impact of effectively changing the behavior used
for global-dynamic variables in preloaded and on-startup-loaded libraries
introduced by this libgcc change, I suspect we have other new issues here,
such as problems with async-signal safety of other global-dynamic variables
within LTTng-UST.

But moving all TLS variables used by lttng-ust from global-dynamic to
initial-exec is tricky, because a prior attempt to do so introduced regressions
in use-cases where lttng-ust was dlopen'd by Java or Python, AFAIU situations
where the runtimes were already using most of the extra memory pool for
dlopen'd libraries initial-exec variables, causing dlopen of lttng-ust
to fail.

Thanks Florian for letting us know about this,

Mathieu



The issue also requires a recent glibc with changes to DTV management:
commit d2123d68275acc0f061e73d5f86ca504e0d5a344 ("elf: Fix slow tls
access after dlopen [BZ #19924]").  If I understand things correctly,
before this glibc change, we didn't deallocate the old DTV, so there was
no call to the free function.

On the glibc side, we should recommend that intercepting mallocs and its
dependencies use initial-exec TLS because that kind of TLS does not use
malloc.  If intercepting mallocs using dynamic TLS work at all, that's
totally by accident, and was in the past helped by glibc bug 19924.  (I
don't think there is anything special about libgcc_s.so.1 that triggers
the test failure above, it is just an object with dynamic TLS that is
implicitly loaded via dlopen at the right stage of the test.)  In this

Re: [lttng-dev] New TLS usage in libgcc_s.so.1, compatibility impact

[Florian Weimer via Gcc]

* Mathieu Desnoyers:

> On 2024-01-13 07:49, Florian Weimer via lttng-dev wrote:
>> This commit
>> commit 8abddb187b33480d8827f44ec655f45734a1749d
>> Author: Andrew Burgess 
>> Date:   Sat Aug 5 14:31:06 2023 +0200
>>  libgcc: support heap-based trampolines
>>   Add support for heap-based trampolines on x86_64-linux,
>> aarch64-linux,
>>  and x86_64-darwin. Implement the __builtin_nested_func_ptr_created and
>>  __builtin_nested_func_ptr_deleted functions for these targets.
>>   Co-Authored-By: Maxim Blinov 
>>  Co-Authored-By: Iain Sandoe 
>>  Co-Authored-By: Francois-Xavier Coudert 
>> added TLS usage to libgcc_s.so.1.  The way that libgcc_s is
>> currently
>> built, it ends up using a dynamic TLS variant on the Linux targets.
>> This means that there is no up-front TLS allocation with glibc (but
>> there would be one with musl).
>
> Trying to wrap my head around this:
>
> If I get this right, the previous behavior was that glibc did allocate
> global-dynamic variables from libraries which are preloaded and loaded
> on c startup as if they were initial-exec, but now that libgcc_s.so.1
> has a dynamic TLS variable, all those libraries loaded on c startup that
> have global-dynamic TLS do not get the initial allocation special
> treatment anymore. Is that more or less correct ?

Ahh.  I had forgotten about this aspect.  The allocation from the static
TLS area still happens as before.

> I've prepared a change for lttng-ust to move the lttng-ust libc wrapper
> "malloc nesting" guard variable from global-dynamic to initial-exec:
>
> https://review.lttng.org/c/lttng-ust/+/11677 Fix: libc wrapper: use 
> initial-exec for malloc_nesting TLS

I don't know if this is completely sufficient if there are other TLS
variables in the lttng stack.

> This should help for the infinite recursion issue, but if my understanding
> is correct about the impact of effectively changing the behavior used
> for global-dynamic variables in preloaded and on-startup-loaded libraries
> introduced by this libgcc change, I suspect we have other new issues here,
> such as problems with async-signal safety of other global-dynamic variables
> within LTTng-UST.

This didn't change, and the allocation is not done lazily (contrary to
what I might have written before).  But even on the __tls_get_addr fast
path, we check the TLS generation counter, and if that has changed, we
do extra bookkeeping work.  TLS usage in libgcc_s.so.1 means that in the
now-failing test, the generation counter changed.  Before bug 19924

  TLS performance degradation after dlopen 
  

was fixed, we did not do this bookkeeping work, which is why the problem
didn't occur.

General use of lttng should be fine, I think, only the malloc wrapper
has this problem.

> But moving all TLS variables used by lttng-ust from global-dynamic to
> initial-exec is tricky, because a prior attempt to do so introduced
> regressions in use-cases where lttng-ust was dlopen'd by Java or
> Python, AFAIU situations where the runtimes were already using most of
> the extra memory pool for dlopen'd libraries initial-exec variables,
> causing dlopen of lttng-ust to fail.

Oh, right, that makes it quite difficult.  Could you link a private copy
of the libraries into the wrapper that uses initial-exec TLS?

Thanks,
Florian

Re: [lttng-dev] New TLS usage in libgcc_s.so.1, compatibility impact

[Mathieu Desnoyers via Gcc]

On 2024-01-15 14:42, Florian Weimer wrote:

* Mathieu Desnoyers:


[...]


General use of lttng should be fine, I think, only the malloc wrapper
has this problem.


The purpose of the nesting counter TLS variable in the malloc wrapper
is to catch situations like this where a global-dynamic TLS access
(or any unexpected memory access done as a side-effect from calling
libc) from within LTTng-UST instrumentation would internally attempt to
call recursively into the malloc wrapper. In that nested case, we skip
the instrumentation and call the libc function directly.

I agree with your conclusion that only this nesting counter gating variable
actually needs to be initial-exec.




But moving all TLS variables used by lttng-ust from global-dynamic to
initial-exec is tricky, because a prior attempt to do so introduced
regressions in use-cases where lttng-ust was dlopen'd by Java or
Python, AFAIU situations where the runtimes were already using most of
the extra memory pool for dlopen'd libraries initial-exec variables,
causing dlopen of lttng-ust to fail.


Oh, right, that makes it quite difficult.  Could you link a private copy
of the libraries into the wrapper that uses initial-exec TLS?


Unfortunately not easily, because by design LTTng-UST is meant to be a
singleton per-process. Changing this would have far-reaching impacts on
interactions with the LTTng-UST tracepoint instrumentation, as well as
impacts on synchronization between the LTTng-UST agent thread and
application calling fork/clone. Also AFAIR, the LTTng session daemon
(at least until recently) does not expect multiple concurrent
registrations from a given process.

Thanks,

Mathieu

--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com