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.