Re: [musl] Getting access to section data during dynlink.c

[Rich Felker <dalias@libc.org>]

On Tue, Oct 17, 2023 at 10:28:00AM +0200, Szabolcs Nagy wrote:
> * 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,

Indeed, that's what makes it difficult. crt_start.h could compute it
along with _DYNAMIC, but that's more per-arch burden I would not like
to see, and it's not clear how it would distinguish the undefined
case if we're supporting that.

> e.g. 'weak' would create a got reloc so not usable before relocs are done.

A GOT reloc for a hidden symbol will be relative and already resolved
by dlstart.c. I'm not sure if we're making use of such a property
right now but it seems reasonable to do so; the symbol name cannot
exist in a form satisfiable by the symbolic relocations performed
later, so it must have been done at this point. At first I was
thinking of storing the address in a static var that dlstart.c would
have filled in, but this seems no better than (and equivalent to) just
letting the GOT do its thing.

Rich