[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20150912204124.GA10172@brightrain.aerifal.cx>
Date: Sat, 12 Sep 2015 16:41:24 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Next steps in fdpic support
As of commit d4c82d05b8d0ee97f6356d60986799a95ed5bd74, the fdpic on sh
should be generally working for static linking. There are a few places
where function calls from asm take place that I still need to review,
and at least cancellation probably has a remaining bug, but this is
all simple stuff. If anything else seems broken, bug reports are
welcome!
The next big step is dynamic linking. I jokingly suggested on irc that
we could treat each LOAD segment of fdpic libraries as a separate
library, since that fits with the current model where every DSO has a
single "base" address it's loaded relative to. However I don't think
that really makes sense; it would just offload the complexity onto
managing the list of libraries where it's uglier, and still wouldn't
get rid of all the complexity in symbol lookup.
As an alternative, I started auditing dynlink.c for places where the
base address of a DSO is actually used. They're almost all of the
form: given a DSO and an address within that DSO's virtual address
space, translate it to an address where it's loaded in the process's
(virtual on mmu, or physical on nommu; no need to care which) address
space. So I think the problem of no longer having a single base
address is easily solved by abstracting this operation as a function.
On non-fdpic targets it would just be a function that adds its two
arguments, and which is thus trivially inlinable. For fdpic there's
likely to be some runtime cost involved, but that's inevitable.
Before starting on the dynamic linker itself, though, the first step
is the entry point. Having the static PIE (rcrt1.o) entry point in
musl using the same framework as the dynamic linker bootstrap makes it
easy to do this as a first step independent of actually having working
dynamic linker code. Unfortunately this will require some changes that
impact all archs (in crt_arch.h) but that was going to be the case
anyway because of the problems (for static-PIE) with depending on
exported symbols. Fixing this should clear the way for pushing
ready-to-use static-PIE patches into GCC upstream.
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.
