From: Florian Weimer <fweimer@redhat.com>
To: Sergey Bugaev <bugaevc@gmail.com>
Cc: Joseph Myers <joseph@codesourcery.com>,
Samuel Thibault <samuel.thibault@gnu.org>,
libc-alpha@sourceware.org, bug-hurd@gnu.org
Subject: Re: [RFC PATCH 06/10] hurd: Make sure to not use tcb->self
Date: Fri, 19 May 2023 11:39:24 +0200 [thread overview]
Message-ID: <87a5y0lkxf.fsf@oldenburg3.str.redhat.com> (raw)
In-Reply-To: <CAN9u=HcurRo2LMa_Zjp1NENQik4x7UrJgFRH9Ji4jxM-be+NDw@mail.gmail.com> (Sergey Bugaev's message of "Fri, 19 May 2023 11:22:10 +0300")
* Sergey Bugaev:
> On Thu, May 18, 2023 at 11:16 PM Joseph Myers <joseph@codesourcery.com> wrote:
>> Strictly there are two separate issues: (a) calling an exported symbol
>> should be done via a hidden alias, to avoid going via the PLT, and (b)
>> functions in a standard namespace should not call names in the user's
>> namespace, which requires using a name such as __hurd_thread_self instead
>> (which should also be marked hidden to make the call optimally efficient).
>
> While we're talking about this, could you please say if my
> understanding below is correct (and correct me if not)?
>
> 'foo' is a public symbol, to be used by the user, and also
> interposable by the user. Always called via PLT (except from inside
> the user's code when redefined inside the executable, in which case
> the compiler/linker will see that no PLT is needed), and should not be
> called from inside glibc.
>
> '__foo' is a (public? private? semi-private?) symbol, the user code is
> not supposed to use it, but it's exported from libc.so for the benefit
> of other glibc code that ends up in different DSOs and still wants to
> call the original version even when 'foo' gets interposed. Invoked via
> PLT from other DSOs, not invoked from libc.so because of...
__foo may be exported or not. We have some __ symbols that are used by
the implementation (so GCC etc.), and probably some that are expected to
be used by users. Truely exported symbols have a GLIBC_2.y symbol
version, internal exported symbols (usually added for coordination
between different shared objects that make up glibc) have a
GLIBC_PRIVATE symbol version.
Some old internal symbols have GLIBC_2.0 or similar early versions
because GLIBC_PRIVATE did not exist then.
> '__GI___foo' is a private non-exported symbol created by the
> hidden_def/hidden_proto macro being used on '__foo', this is what the
> code in libc.so (or: whatever DSO the symbol is hidden_def'ed in)
> calls to avoid PLT jumps.
Correct.
> Q: why '__foo', why not use hidden_def/hidden_proto on the 'foo' directly?
> A: that would only work for code that ends up in libc.so (or rather,
> the same DSOs as 'foo'), but we still want other code to also call the
> non-interposed, original version of 'foo'
hidden_def/hidden_proto does not do anything for static linking, given
the macros are defined today.
It's of course possible to do all this quite differently.
Thanks,
Florian
next prev parent reply other threads:[~2023-05-19 9:39 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-17 19:14 [PATCH 00/10] Stack setup & misc fixes for x86_64-gnu Sergey Bugaev
2023-05-17 19:14 ` [PATCH 01/10] Remove sysdeps/generic/thread_state.h Sergey Bugaev
2023-05-17 20:50 ` Samuel Thibault
2023-05-17 19:14 ` [PATCH 02/10] mach: Define MACHINE_THREAD_STATE_SETUP_CALL Sergey Bugaev
2023-05-17 20:52 ` Samuel Thibault
2023-05-17 19:14 ` [PATCH 03/10] hurd: Use MACHINE_THREAD_STATE_SETUP_CALL Sergey Bugaev
2023-05-17 20:52 ` [PATCH 03/10] hurd: Use MACHINE_THREAD_STATE_SETUP_CALLo Samuel Thibault
2023-05-17 19:14 ` [PATCH 04/10] mach: Add __mach_setup_thread_call () Sergey Bugaev
2023-05-17 20:56 ` Samuel Thibault
2023-05-17 19:14 ` [PATCH 05/10] hurd: Use " Sergey Bugaev
2023-05-17 20:57 ` Samuel Thibault
2023-05-17 19:14 ` [RFC PATCH 06/10] hurd: Make sure to not use tcb->self Sergey Bugaev
2023-05-17 20:59 ` Samuel Thibault
2023-05-18 18:55 ` Joseph Myers
2023-05-18 19:33 ` Sergey Bugaev
2023-05-18 20:16 ` Joseph Myers
2023-05-18 23:47 ` Samuel Thibault
2023-05-19 8:22 ` Sergey Bugaev
2023-05-19 9:39 ` Florian Weimer [this message]
2023-05-19 16:50 ` Joseph Myers
2023-05-19 14:47 ` [PATCH] hurd: Fix using interposable hurd_thread_self Sergey Bugaev
2023-05-19 18:57 ` Samuel Thibault
2023-05-17 19:14 ` [PATCH 07/10] hurd: Fix x86_64 _hurd_tls_fork Sergey Bugaev
2023-05-17 21:01 ` Samuel Thibault
2023-05-17 19:14 ` [PATCH 08/10] hurd: Fix setting up pthreads Sergey Bugaev
2023-05-17 21:02 ` Samuel Thibault
2023-05-17 19:14 ` [PATCH 09/10] hurd: Also make it possible to call strlen very early Sergey Bugaev
2023-05-17 21:04 ` Samuel Thibault
2023-05-17 19:14 ` [RFC PATCH 10/10] hurd: Regenerate errno.h Sergey Bugaev
2023-05-17 19:39 ` Joseph Myers
2023-05-17 21:04 ` Samuel Thibault
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=87a5y0lkxf.fsf@oldenburg3.str.redhat.com \
--to=fweimer@redhat.com \
--cc=bug-hurd@gnu.org \
--cc=bugaevc@gmail.com \
--cc=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
--cc=samuel.thibault@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).