Re: dynamic linker command line invocation

[N Jain <jain61@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2312 bytes --]

> You never answered whether
> you were setting up the aux vector right, but if not, that's
> definitely going to cause problems.

I am not setting any aux vectors. I only pass argv = "app.elf" and argc = 1
to dynamic linker.
What and where I need to set "aux" vectors ? Any pointers will help..

Thanks,
NJ

On Tue, Jan 5, 2016 at 12:32 PM, Rich Felker <dalias@libc.org> wrote:

> On Tue, Jan 05, 2016 at 11:45:01AM -0500, N Jain wrote:
> > 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 ?
>
> No, it's not something you can "handle" but an inherent race
> condition. To avoid it the kernel would have to refrain from passing
> the actual pathname to the file but instead some virtual pathname like
> /proc/self/main_exe (hypothetical) that would be tied to the original
> inode the user tried to execute.
>
> > 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.
>
> Hm? You should not be making any adjustments. The dynamic linker
> applies its own relocations to itself when run. You just need to pass
> it the right pointers in the aux vector. You never answered whether
> you were setting up the aux vector right, but if not, that's
> definitely going to cause problems.
>
> > 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" ?
>
> dprintf is a standard function for printing to a file descriptor, not
> a debug function. It's definitely usable by the time you reach stage 3
> and should also be usable during stage 2. On x86 linked with
> -Bsymbolic-functions (as we do now) it may even work at stage 1.
>
> Rich
>
> P.S. Please don't top-post to the list but instead reply inline/below
> the text you're replying to, and edit to include only relevant
> context.
>

[-- Attachment #2: Type: text/html, Size: 3145 bytes --]