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[0] 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@libc.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
>