Date: Wed, 21 Nov 2018 16:52:53 +0100 From: Gernot Reisinger <Gernot.Reisinger@...ino.at> To: dalias@...c.org Cc: musl@...ts.openwall.com Subject: Re: Question regarding dynamic loader Thanks for your swift and extensive reply. Your explanations make a lot of sense. (sorry for my sloppy description - __libc_start_main invoked by *crt is the place where constructor calls happen as you did outline). I did no extensive research how glibc executes these constructor calls. At least the call stack indicates that they are partially executed in dynamic linker context - _dl_start_user () in /lib64/ld-linux-x86-64.so calling _dl_init. I will add a reference to reply to the Go ticket. Am Mi., 21. Nov. 2018 um 15:25 Uhr schrieb Rich Felker <dalias@...c.org>: > On Wed, Nov 21, 2018 at 02:55:19PM +0100, Gernot Reisinger wrote: > > Hi, > > I recently stumbled upon an issue with preloading a shared object into a > Go > > application (see related Go ticket > https://github.com/golang/go/issues/28909 > > ). > > > > In short - Go comes with an internal linker which will not link crt code > to > > the application. The entry point will directly execute Go standard > library > > code. As musl libc calls shared object constructors in crt code, the > shared > > I don't think this assessment of what musl does is correct. It calls > the (initially loaded) shared object constructor via > __libc_start_main. If the program is not entered via > __libc_start_main, libc is not usable. Necessary initialization will > have been bypassed. This has little to do with whether the crt code > was linked, except that *crt1.o is normally responsible for calling > __libc_start_main. If the linking process bypasses crt1, it needs to > ensure that __libc_start_main ends up getting called in some other > way. As far as I know this is also true for glibc, so I'm not sure why > it differs. > > > objects constructors subsequently will never be invoked. Things will work > > on glibc systems / processes. it It seems to be a subtle - but in this > case > > wide reaching - behavioral difference to glibc. > > > > I wonder if calling constructor functions from crt code is an intended > musl > > libc behavior. My personal - non expert - gut feeling considers glibc > > behavior "more correct". Is there a chance that musl will change this > > behavior? > > The musl behavior here is intentional. For FDPIC targets, it's > impossible to run *any* application code, in the main application or > shared libraries, before the main application's crt1 has executed, > because there are (essentially -- the equivalent of) self-relocations > performed at that stage that the dynamic linker can't see. If any > ctors were invoked directly by the dynamic linker before passing > control the the main application's entry point, they would run without > these relocations in the main application having been performed, > possibly resulting in runaway-wrong execution. > > I believe Go is doing some bad hacks here with regard to its C FFI, > but it's likely fixable in some reasonable way. We should get more > eyes looking at it. > > Rich > > Content of type "text/html" skipped
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.