* Dynamic linker refactoring @ 2012-01-21 1:05 Rich Felker 2012-01-21 12:19 ` aep 0 siblings, 1 reply; 4+ messages in thread From: Rich Felker @ 2012-01-21 1:05 UTC (permalink / raw) To: musl Hi all, After the recent dynamic linker fixes, I've looked into refactoring (mainly eliminating logic duplication) and cleaning up the dynamic linker. As a heads-up, I'm leaning towards stripping out the vdso (linux-gate) support at the dynamic linker level entirely, and instead using Nik's original design for vdso-assisted clock_gettime which can work with static linking too. This cuts out some complexity and code duplication in the dynamic linker (at the expense of duplicating the same code elsewhere for use outside the dynamic linker), but the real benefit is that we don't have to worry about the kernel devs doing something stupid and polluting the userspace symbol namespace (and potentially redirecting functions to do the wrong thing) if they add stuff to the vdso that doesn't belong there. If anyone's against these changes or wants to discuss them more, please reply in this thread in the next day or so.. Rich ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Dynamic linker refactoring 2012-01-21 1:05 Dynamic linker refactoring Rich Felker @ 2012-01-21 12:19 ` aep 2012-01-22 4:30 ` Rich Felker 0 siblings, 1 reply; 4+ messages in thread From: aep @ 2012-01-21 12:19 UTC (permalink / raw) To: musl On Fri, 20 Jan 2012 20:05:54 -0500, Rich Felker wrote: > Hi all, > > I'm leaning towards stripping out the vdso > (linux-gate) support at the dynamic linker level entirely, and > instead > using Nik's original design for vdso-assisted clock_gettime which can > work with static linking too. isn't the vdso there for much more then just clock_gettime? Ie for a whole bunch of syscalls that otherwise need to go through the slow interrupt path? ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Dynamic linker refactoring 2012-01-21 12:19 ` aep @ 2012-01-22 4:30 ` Rich Felker 2012-01-22 12:45 ` aep 0 siblings, 1 reply; 4+ messages in thread From: Rich Felker @ 2012-01-22 4:30 UTC (permalink / raw) To: musl On Sat, Jan 21, 2012 at 01:19:40PM +0100, aep wrote: > On Fri, 20 Jan 2012 20:05:54 -0500, Rich Felker wrote: > >Hi all, > > > > I'm leaning towards stripping out the vdso > >(linux-gate) support at the dynamic linker level entirely, and > >instead > >using Nik's original design for vdso-assisted clock_gettime which can > >work with static linking too. > > isn't the vdso there for much more then just clock_gettime? Ie for a > whole bunch of syscalls that otherwise need to go through the slow > interrupt path? I wouldn't say a whole bunch. At present there are only one or two other functions provided by vdso and their applicability is so limited I can't see them benefitting anything. Certainly there is a fair bit more that could be implemented by the kernel in userspace in the future, though. What I originally thought was useful, but now I'm rethinking, is the practice of actually including the vdso as a dso in the main chain of loaded dsos, where its symbols become globally visible (including accessible by the application using dlsym, for example). In principle, it could replace symbols from the libc with its own versions. The fact that I ordered it after libc rather than before partly ameliorates this problem, but if the symbol in libc is weak, it can still be overridden by a strong symbol in the vdso. (In fact this is how __vdso_clock_gettime currently works!) If used correctly, it's no big deal, but it would be quite unfortunate if the kernel developers went and added some override that was intended to work with glibc but broke horribly with musl.. Anyway with that in mind, I'd thought about at least 2 possible alternatives: 1. Load the vdso through the dynamic linker code, but don't insert it in the dso list, and instead search out the symbols we want from it directly. 2. Include the vdso-linking code directly in the functions (like clock_gettime) that might want vdso code. Option 2 has the advantage of working even with static linking, but in the immediate it would cause more code duplication. In the long term, on the other hand, it might lead to better code factoring by allowing us to move some of the hash, symbol table search, etc. code out of dynlink.c and into a module that could be reused both for the vdso search in static binaries and by the dynamic linker. Rich ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Dynamic linker refactoring 2012-01-22 4:30 ` Rich Felker @ 2012-01-22 12:45 ` aep 0 siblings, 0 replies; 4+ messages in thread From: aep @ 2012-01-22 12:45 UTC (permalink / raw) To: musl Ah now i see what you're doing there, thanks for the explanation. > 2. Include the vdso-linking code directly in the functions (like > clock_gettime) that might want vdso code. Perfect. I like the kernel-code-in-userspace hack, but doing it through a dso seemed not very well thought out. Your idea sounds a lot cleaner. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-01-22 12:45 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-01-21 1:05 Dynamic linker refactoring Rich Felker 2012-01-21 12:19 ` aep 2012-01-22 4:30 ` Rich Felker 2012-01-22 12:45 ` aep
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).