[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150408231911.GK6817@brightrain.aerifal.cx>
Date: Wed, 8 Apr 2015 19:19:11 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Dynamic linker changes
So far I've been hitting some ugly obstacles:
1. If we want the new code to eliminate the need for platform-specific
__reloc_self functions for mips/microblaze/powerpc/etc., the first
phase needs to perform relative relocations without making _any_
function calls, since even calls to static functions go through
(anonymous) got entries. That's not such a bad idea if it would
eliminate this ugly per-arch code, but...
2. The current method of making relocations generic rather than
arch-specific uses a function/switch statement to remap them. This is
not going to be usable for solving item 1 above in an arch-agnostic
manner. So perhaps we should replace this function with a set of
macros. Rather than having generic values for the REL_* macros and
mapping the R_{arch}_* values to them with switch, we could do
something like (example for microblaze):
#define REL_SYMBOLIC R_MICROBLAZE_32
#define REL_GOT R_MICROBLAZE_GLOB_DAT
...
However it's not clear to me whether the mapping from arch-specific
reloc types to generic ones is one-to-one in all archs, so we'd
potentially have to have extra macros like REL_SYMBOLIC_2.
One benefit of this approach, on the other hand, is that the switch in
the portable reloc processing code can have #ifdef around each case
and eliminate code for relocations a given arch doesn't support.
(Technically the compiler's dead code elimination could already after
inlining the mapping function or performing inter-procedural range
analysis, but I seriously doubt it did so.)
3. The original plan was to have one early-ldso-relocation step and
avoid all possible GOT/globals use and everything after that free to
use arbitrary global data and symbols, with a single barrier in
between to prevent reordering of GOT loads before they're relocated.
This seems impractical since it's hard, due to issue 1, do to symbolic
relocations without being able to make function calls.
Instead I'd like to treat the early-ldso-relocation process as two
steps. The first is generalizing and making arch-agnostic the work
mips, microblaze, and powerpc are doing now to get to a state where
all non-symbolic global accesses are safe. The second would be a
separate function call from the asm (or chained from the first if
there's an obvious way to do it) that performs symbolic relocations on
itself. It would end by (as proposed in the sketch before) doing a
symbol lookup and final call into the code that will setup the dso
chain, load dependencies, perform all remaining relocations, and pass
control to the program's entry point.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
