From: Szabolcs Nagy <nsz@port70.net>
To: Rich Felker <dalias@libc.org>
Cc: Farid Zakaria <fmzakari@ucsc.edu>, musl@lists.openwall.com
Subject: Re: [musl] Getting access to section data during dynlink.c
Date: Tue, 17 Oct 2023 10:28:00 +0200 [thread overview]
Message-ID: <20231017082800.GF1427497@port70.net> (raw)
In-Reply-To: <20231016220410.GM4163@brightrain.aerifal.cx>
* Rich Felker <dalias@libc.org> [2023-10-16 18:04:11 -0400]:
> On Mon, Oct 16, 2023 at 11:53:07PM +0200, Szabolcs Nagy wrote:
> > note that (not too old) bfd ld and lld defines a hidden linker symbol
> > __ehdr_start that at runtime resolves to where the ehdr is.
> >
> > example:
> >
> > #include <elf.h>
> > #include <stdio.h>
> >
> > __attribute__((visibility("hidden"), weak)) extern char __ehdr_start[];
> >
> > int main()
> > {
> > if (__ehdr_start) {
> > Elf64_Ehdr *ehdr = (void *)__ehdr_start;
> > printf("ehdr %p\n", ehdr);
> > Elf64_Phdr *phdr = (void *)(__ehdr_start + ehdr->e_phoff);
> > printf("phdr %p\n", phdr);
> > } else
> > printf("__ehdr_start is undefined\n");
> >
> > // to compare against the actual mappings
> > char buf[9999];
> > FILE *f = fopen("/proc/self/maps","r");
> > size_t n = fread(buf, 1, sizeof buf, f);
> > fwrite(buf, 1, n, stdout);
> > }
> >
> > this should work for 64bit elf exe if ehdr is mapped into memory.
> >
> > if you want link time error on an old linker instead of 0 __ehdr_start,
> > then just drop "weak" and the runtime check. (the code as written assumes
> > ehdr is not at exact 0 address, which is guaranteed by usual linux setups)
>
> Interesting -- perhaps we should find a way to use this in ldso to
> find its own ehdr.
for that use it is a bit target specific:
the symbol address computation must be pc-relative with no dynamic reloc,
e.g. 'weak' would create a got reloc so not usable before relocs are done.
glibc switched using it (but can use auxv too), requires binutils >= 2.23.
i think lld had issues with setting GOT[0] up with vaddr of _DYNAMIC
which is what glibc was relying on previously on many targets.
next prev parent reply other threads:[~2023-10-17 8:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-16 1:06 Farid Zakaria
2023-10-16 14:26 ` Rich Felker
2023-10-16 21:09 ` Farid Zakaria
2023-10-16 21:16 ` Farid Zakaria
2023-10-16 21:53 ` Szabolcs Nagy
2023-10-16 22:04 ` Rich Felker
2023-10-17 3:39 ` Farid Zakaria
2023-10-17 8:28 ` Szabolcs Nagy [this message]
2023-10-17 12:24 ` Rich Felker
2023-10-17 17:37 ` Farid Zakaria
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=20231017082800.GF1427497@port70.net \
--to=nsz@port70.net \
--cc=dalias@libc.org \
--cc=fmzakari@ucsc.edu \
--cc=musl@lists.openwall.com \
/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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
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 NNTP newsgroup(s).