From: Alexander Shpilkin <ashpilkin@gmail.com>
To: gcc-help@gcc.gnu.org
Subject: Re: Get TLS information without readelf
Date: Sat, 30 Oct 2021 16:33:29 +0300 [thread overview]
Message-ID: <4f183af5fbf3fc739edd06eda289bdcffc855cba.camel@gmail.com> (raw)
In-Reply-To: <20211030074112.D9FC7140175@vultr155>
[-- Attachment #1: Type: text/plain, Size: 2124 bytes --]
On Sat, 2021-10-30 at 03:41 -0400, Jeff Andrews wrote:
> Hi all. I'd like to use tls (specifically __thread) with g++ but
> without a standard library. For the moment all my variables are zero
> initalized. How should I get the TLS memory size? I can see all the
> information I need in the TLS header after I build the binary by using
> "readelf -l". I'll need "MemSiz", possibly "Align" and once I have non
> zero thread locals I'll need VirtAddr and FileSiz. Is there a way to
> export these as a symbol/global variable?
You can always define whatever symbols you need if you use your own GNU
linker script[1] or amend the default[2], and in fact the default one
already does this for some things (e.g. save the beginning and end of
BSS so that the initialization code can zero it out). As objects are
linked in command line order unless the linker script says otherwise,
another approach is to include sentinel values in crt{begin,end}.o[3]
or whatever you are replacing them with in your no-libc setup.
Finally, if you are on an ELF system such as Linux or the BSDs, all
this may be unnecessary, because the kernel will actually include a
pointer to your executable’s ELF program header table as the AT_PHDR
entry in the auxiliary vector[4] provided as part of the startup
information, and you’ll find the things you need in the PT_TLS
header[5] (though IMO it makes more sense to do this work at link time
as above—the header seems to be necessary in a dynamic linking
situation, where the loader will have to stitch together the TLS
layouts from multiple ELF images and relocate accordingly).
Actually following the platform ABI on TLS[6] is another matter, of
course, and quite arcane, so I don’t feel qualified to comment on it.
[1]: https://wiki.osdev.org/Linker_Scripts
[2]: https://sourceware.org/binutils/docs/ld/Implicit-Linker-Scripts.html
[3]: https://dev.gentoo.org/~vapier/crt.txt
[4]: https://lwn.net/Articles/519085/
[5]: https://www.akkadia.org/drepper/tls.pdf
[6]: https://maskray.me/blog/2021-02-14-all-about-thread-local-storage
--
Cheers,
Alex
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
prev parent reply other threads:[~2021-10-30 13:33 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-30 7:41 Jeff Andrews
2021-10-30 13:33 ` Alexander Shpilkin [this message]
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=4f183af5fbf3fc739edd06eda289bdcffc855cba.camel@gmail.com \
--to=ashpilkin@gmail.com \
--cc=gcc-help@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).