[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOkOUeevQ28qsyHEF+pmfpXY8MXgkt_s-y43qis_z=+CY6UMBQ@mail.gmail.com>
Date: Tue, 5 Jan 2016 13:00:37 -0500
From: N Jain <jain61@...il.com>
To: musl@...ts.openwall.com, Rich Felker <dalias@...c.org>
Subject: Re: dynamic linker command line invocation
> 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@...c.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.
>
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.
