From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9062 Path: news.gmane.org!not-for-mail From: N Jain Newsgroups: gmane.linux.lib.musl.general Subject: Re: dynamic linker command line invocation Date: Tue, 5 Jan 2016 13:00:37 -0500 Message-ID: References: <20160104205920.GW238@brightrain.aerifal.cx> <20160105173200.GZ238@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113aca4ed1c5ee05289a03ac X-Trace: ger.gmane.org 1452016854 32516 80.91.229.3 (5 Jan 2016 18:00:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 Jan 2016 18:00:54 +0000 (UTC) To: musl@lists.openwall.com, Rich Felker Original-X-From: musl-return-9075-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jan 05 19:00:53 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aGVue-0007Id-Qo for gllmg-musl@m.gmane.org; Tue, 05 Jan 2016 19:00:52 +0100 Original-Received: (qmail 10219 invoked by uid 550); 5 Jan 2016 18:00:50 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 10189 invoked from network); 5 Jan 2016 18:00:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=hoaLHmpci+rkRo189qqFKtAjyaS8IxspA3fiPyaevgU=; b=NX3ebK8BuRoW2FRNEylOjYkWn60HpYzoz8pezQH7Foa26WIy6WC9NSTXH9/BgkHClk o8ZXUA7/21lin/Kwdb7SkqOQaAF8WyN8fA4kwsafHF7GQZBwDrU264eeRh3RADJT/reC gi/x5WmEkxvVpO0J3WWvIT40jCTmIaPCraqqj9aUVYHPCs+PdrOjqjQOicY8XgSbYVdo JtZOFjOUr15PXj/HwLbZkb7xqX6tJkyBgJyT83P4eCqgr5K/w9RPZ2C89LpFd4EOkZra TQo8qvwzRdkx318f+rL2OT3pyHXStDsL7MEcwG0NcLJV3UkoG7mYZb2nuDFZim16Wjju GX4w== X-Received: by 10.202.213.78 with SMTP id m75mr55873547oig.56.1452016837693; Tue, 05 Jan 2016 10:00:37 -0800 (PST) In-Reply-To: <20160105173200.GZ238@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:9062 Archived-At: --001a113aca4ed1c5ee05289a03ac Content-Type: text/plain; charset=UTF-8 > 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 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. > --001a113aca4ed1c5ee05289a03ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


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

I am not s= etting any aux vectors. I only pass argv =3D "app.elf" and argc = =3D 1 to dynamic linker.
What and where I need to set "aux&q= uot; vectors ? Any pointers will help..

Thanks,
NJ

On = Tue, Jan 5, 2016 at 12:32 PM, Rich Felker <dalias@libc.org> wr= ote:
On Tue, Jan 05, 2016 at 11:45:01A= M -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 M= USL
> dynamic linker will not gracefully handle such situation where the
> executable is moved/replaced ?

No, it's not something you can "handle" but an inheren= t 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<= br> > 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 kno= w if
> I can enable "dprintfs"=C2=A0 in MUSL code in order to easil= y debug ?
> What I have to do in order to enable these "dprintfs" ?

dprintf is a standard function for printing to a file descriptor, no= t
a debug function. It's definitely usable by the time you reach stage 3<= br> 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.

--001a113aca4ed1c5ee05289a03ac--