From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9060 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: dynamic linker command line invocation Date: Tue, 5 Jan 2016 12:32:00 -0500 Message-ID: <20160105173200.GZ238@brightrain.aerifal.cx> References: <20160104205920.GW238@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1452015153 3967 80.91.229.3 (5 Jan 2016 17:32:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 Jan 2016 17:32:33 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9073-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jan 05 18:32:20 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 1aGVT0-0005w5-3S for gllmg-musl@m.gmane.org; Tue, 05 Jan 2016 18:32:18 +0100 Original-Received: (qmail 26214 invoked by uid 550); 5 Jan 2016 17:32:15 -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 26193 invoked from network); 5 Jan 2016 17:32:14 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9060 Archived-At: 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.