[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH 06/10] hurd: Make sure to not use tcb->self
From: |
Joseph Myers |
Subject: |
Re: [RFC PATCH 06/10] hurd: Make sure to not use tcb->self |
Date: |
Fri, 19 May 2023 16:50:29 +0000 |
On Fri, 19 May 2023, Sergey Bugaev via Libc-alpha wrote:
> '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.
Should not be called from within glibc via the PLT within the same
library.
It's OK for foo to be called from bar if foo is part of all the standards
that contain bar. But in that case, if the call is from the same library,
*_hidden_def / *_hidden_proto should be used to avoid calling via the PLT.
If foo is not part of all the standards that contain bar, then glibc code
for bar should use __foo instead to avoid namespace issues, especially for
static linking.
If __foo is needed by executables, *_nonshared.a or other shared
libraries, then it also needs to be exported from the library it's in (in
which case PLT avoidance is also relevant for __foo, so *_hidden_* should
be used for __foo).
If __foo is only used within a single library and doesn't need to be
exported, it's OK to declare it directly with attribute_hidden rather than
using *_hidden_* to create __GI___foo as an alias. (In this case, if you
forget to use attribute_hidden, you won't get test failures - the symbol
in fact won't get exported, because only symbols explicitly listed in the
version maps get exported, and so it won't get a PLT entry. But in some
cases, code generation is more efficient if the compiler knows that the
symbol is hidden. So when you're calling an unexported symbol in the same
library, it's still desirable for it to be declared as hidden in a way
visible to the compiler.) The more complicated hidden_proto / hidden_def
approach also works for unexported symbols used within a single library,
it's just more complicated than necessary in that case.
--
Joseph S. Myers
joseph@codesourcery.com
- [PATCH 05/10] hurd: Use __mach_setup_thread_call (), (continued)
- [PATCH 05/10] hurd: Use __mach_setup_thread_call (), Sergey Bugaev, 2023/05/17
- [RFC PATCH 06/10] hurd: Make sure to not use tcb->self, Sergey Bugaev, 2023/05/17
- Re: [RFC PATCH 06/10] hurd: Make sure to not use tcb->self, Samuel Thibault, 2023/05/17
- Re: [RFC PATCH 06/10] hurd: Make sure to not use tcb->self, Joseph Myers, 2023/05/18
- Re: [RFC PATCH 06/10] hurd: Make sure to not use tcb->self, Sergey Bugaev, 2023/05/18
- Re: [RFC PATCH 06/10] hurd: Make sure to not use tcb->self, Joseph Myers, 2023/05/18
- Re: [RFC PATCH 06/10] hurd: Make sure to not use tcb->self, Samuel Thibault, 2023/05/18
- Re: [RFC PATCH 06/10] hurd: Make sure to not use tcb->self, Sergey Bugaev, 2023/05/19
- Re: [RFC PATCH 06/10] hurd: Make sure to not use tcb->self, Florian Weimer, 2023/05/19
- Re: [RFC PATCH 06/10] hurd: Make sure to not use tcb->self,
Joseph Myers <=
- [PATCH] hurd: Fix using interposable hurd_thread_self, Sergey Bugaev, 2023/05/19
- Re: [PATCH] hurd: Fix using interposable hurd_thread_self, Samuel Thibault, 2023/05/19
[PATCH 07/10] hurd: Fix x86_64 _hurd_tls_fork, Sergey Bugaev, 2023/05/17
[PATCH 08/10] hurd: Fix setting up pthreads, Sergey Bugaev, 2023/05/17
[PATCH 09/10] hurd: Also make it possible to call strlen very early, Sergey Bugaev, 2023/05/17
[RFC PATCH 10/10] hurd: Regenerate errno.h, Sergey Bugaev, 2023/05/17