Date: Tue, 5 Jan 2016 11:45:01 -0500 From: N Jain <jain61@...il.com> To: musl@...ts.openwall.com, Rich Felker <dalias@...c.org> Subject: Re: dynamic linker command line invocation Hi Rich, Thanks. Right now I am following second approach due to simplicity. I understand about race condition so does it mean that currently the MUSL dynamic linker will not gracefully handle such situation where the executable is moved/replaced ? During further debug I found that passed parameters to dynamic linker are correct and argv does have dynamically "app.elf". Also I am loading the dynamic linker at fixed load offset 0x8000 so I needed to adjust my all dynamic linker LOAD sections accordingly which was causing issues previously. Now I am facing issue during __dls3 API (stage 3). I would like to know if I can enable "dprintfs" in MUSL code in order to easily debug ? What I have to do in order to enable these "dprintfs" ? Thanks, NJ On Mon, Jan 4, 2016 at 3:59 PM, Rich Felker <dalias@...c.org> wrote: > On Mon, Jan 04, 2016 at 11:59:16AM -0500, N Jain wrote: > > Hi All, > > > > I am trying to add ldso functionality in my kernel. I am loading the > > dynamic linker "ld-musl-arm.so.1" into memory and passing the other > > application as command line which requires the dynamic libraries but the > > linker is generating fault during stage 2 "__dls2" at some random > location > > 0x464cc57f. > > > > I am fairly new to dynamic linking code and trying to understand > _dlstart_c > > code functionality. Can any one explain what are the command line > arguments > > dynamic linker expects at this entry point ? I am giving numArgs = 1 and > > argv = app.elf after loading "ld-musl-arm.so.1" into memory ? Is this > > approach correct ? Do I have to also load app.elf into memory or the > > dynamic linker will take care of loading it ? > > Are you providing a complete and correct aux vector after the argv > and environ? If it's missing or contains incorrect information this > would surely cause crashing. > > The ideal way to load dynamic-linked programs is to have the kernel > load both the main executable and the dynamic linker (where the latter > is obtained from the PT_INTERP header in the main program). In this > case, AT_BASE needs to point to the offset at which the dynamic linker > was loaded, and AT_PHDR needs to point to the main program's program > headers (and AT_PHENT and AT_PHNUM should also be valid). AT_ENTRY > also needs to point to the main program's entry point (from the ELF > Ehdr). > > On the other hand, if you want to just load the dynamic linker and > pass the name of the program to run as an argument, AT_BASE must be > either unset or 0, and AT_PHDR must point to the dynamic linker's > program headers. This approach is undesirable however because it's > subject to race conditions if the executable is moved/replaced. > There's also the issue that the address you loaded the dynamic linker > at may conflict with the address where the main program is to be > loaded, but this is a non-issue for PIE executables. > > 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.