public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Edelsohn <dje.gcc@gmail.com>
To: "CHIGOT, CLEMENT" <clement.chigot@atos.net>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] aix: ensure reference to __tls_get_addr is in text section.
Date: Thu, 14 Oct 2021 10:37:48 -0400	[thread overview]
Message-ID: <CAGWvny=xYqrZqjbda1xGrmTmnZLwsWMm_BEQe1mBXonyBE3DcA@mail.gmail.com> (raw)
In-Reply-To: <PA4PR02MB6686532672C90781193A31C8EAB89@PA4PR02MB6686.eurprd02.prod.outlook.com>

On Thu, Oct 14, 2021 at 10:10 AM CHIGOT, CLEMENT
<clement.chigot@atos.net> wrote:
>
> Hi David,
>
> The fact that csect .data is referencing csect .text doesn't mean that
> if .text is kept, .data is kept too. It means the opposite. if .data is kept
> then .text must be kept.

Yes, we are in agreement about the purpose of the other reference
between text and data.

The __tls_get_addr reference is an effort to artificially elicit an
error if pthread is not linked in a program that uses TLS.  It is not
truly necessary for correct TLS code generation from GCC.

Your patch moves the __tls_get_addr referenced from the data section
to the text section.  As we agree, the logic of the other code implies
that the data section is used to pull in the text section, so moving
__tls_get_addr to the text section seems more fragile.  It's a game of
which section will be preserved to ensure that __tls_get_addr is
referenced to ensure that an artificial error is generated.  And it's
possible that neither text nor data sections will be referenced if
fine-grained CSECTs are used.  There is no way to make this logic
perfect.

Thanks, David


>
> That's actually what is being done by the linker with the TLS support test
> in configure.
> $ cat test.c
> __thread int a; int b; int main() { return a = b; }
>
> With ".ref __tls_get_addr" in .data:
> $ gcc -maix64 test.c -S -o test.s
> $ cat test.s
> ...
> _section_.text:
>         .csect .data[RW],4
>         .llong _section_.text
>         .extern __tls_get_addr
>         .ref __tls_get_addr
> $ gcc -maix64 test.s -o test
> $ dump -X64 -tv test
> ...
> [142]   m   0x00000097     debug     0    FILE        C:PPC64     test.c
> [143]   m   0x100006c0     .text     1  unamex                    .text
> [144]   a4  0x0000005c       0    0     SD       PR    -    -
> [147]   m   0x20001298      .bss     1  extern                    b
> [148]   a4  0x00000004       0    0     CM       BS    -    -
> [149]   m   0xffffffffffff8800     .tbss     1  extern                    a
> [150]   a4  0x00000004       0    0     CM       UL    -    -
> ...
>
> Csect .data is garbage-collected by the linker. Thus the .ref doesn't matter.
>
> With ".ref __tls_get_addr" in .text:
> $ cat test.s
> _section_.text:
>         .csect .data[RW],4
>         .llong _section_.text
>         .csect .text[PR],5
>         .extern __tls_get_addr
>         .ref __tls_get_addr
> $ gcc  -maix64 test.s -o test
> ld: 0711-317 ERROR: Undefined symbol: __tls_get_addr
> ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
> collect2: error: ld returned 8 exit status
>
> As csect .text is kept (because of main function), the .ref is still there and the error
> is raise correctly. As "-pthread" isn't passed, __tls_get_addr is not available.
>
> However, writing this mail, I'm wondering if we don't want to always keep both
> csects. If .data is kept, then .text is and if .text is kept, then .data is.
> Or always keeping .data would have too much side effects ?
>
> Thanks,
> Clément
>
> ________________________________
> From: David Edelsohn <dje.gcc@gmail.com>
> Sent: Thursday, October 14, 2021 3:42 PM
> To: CHIGOT, CLEMENT <clement.chigot@atos.net>
> Cc: gcc-patches@gcc.gnu.org <gcc-patches@gcc.gnu.org>
> Subject: Re: [PATCH] aix: ensure reference to __tls_get_addr is in text section.
>
> Caution! External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe.
>
> The reference to __tls_get_addr is in the data section.  And the code
> just above creates a symbol in the text section referenced from the
> data section to ensure the text section is retained.  So this change
> doesn't make sense.  You're essentially saying that the data section
> is not used, which makes the other code useless to ensure that the
> text section is referenced.
>
> Thanks, David
>
> On Thu, Oct 14, 2021 at 3:06 AM CHIGOT, CLEMENT <clement.chigot@atos.net> wrote:
> >
> > The garbage collector of AIX linker might remove the reference to
> > __tls_get_addr if it's added inside an unused csect.
> >
> >
> > Clément Chigot
> > ATOS Bull SAS
> > 1 rue de Provence - 38432 Échirolles - France
> >

  reply	other threads:[~2021-10-14 14:38 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-14  7:06 CHIGOT, CLEMENT
2021-10-14 13:42 ` David Edelsohn
2021-10-14 14:10   ` CHIGOT, CLEMENT
2021-10-14 14:37     ` David Edelsohn [this message]
2021-10-19 12:40 CHIGOT, CLEMENT

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGWvny=xYqrZqjbda1xGrmTmnZLwsWMm_BEQe1mBXonyBE3DcA@mail.gmail.com' \
    --to=dje.gcc@gmail.com \
    --cc=clement.chigot@atos.net \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).