From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: dynamic linker command line invocation
Date: Tue, 5 Jan 2016 12:32:00 -0500 [thread overview]
Message-ID: <20160105173200.GZ238@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAOkOUed2cuJ7-U5ampagqpgVzD0W6cZEQzScxw46sHSFBS2GLg@mail.gmail.com>
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.
next prev parent reply other threads:[~2016-01-05 17:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-04 16:59 N Jain
2016-01-04 19:22 ` Markus Wichmann
2016-01-04 20:52 ` Rich Felker
2016-01-04 20:59 ` Rich Felker
2016-01-05 16:45 ` N Jain
2016-01-05 17:32 ` Rich Felker [this message]
2016-01-05 18:00 ` N Jain
2016-01-05 18:23 ` Rich Felker
2016-01-07 23:29 ` N Jain
2016-01-08 11:09 ` Markus Wichmann
2016-01-11 17:03 ` N Jain
2016-01-12 16:24 ` Markus Wichmann
2016-01-14 22:30 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160105173200.GZ238@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).