From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: dynamic linker command line invocation
Date: Mon, 4 Jan 2016 15:59:20 -0500 [thread overview]
Message-ID: <20160104205920.GW238@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAOkOUedcOLRBgmB7ez+bvdcau1g-86ymNHpOSU1AKD8ArqgWsA@mail.gmail.com>
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
next prev parent reply other threads:[~2016-01-04 20:59 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 [this message]
2016-01-05 16:45 ` N Jain
2016-01-05 17:32 ` Rich Felker
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=20160104205920.GW238@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).