From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9844 Path: news.gmane.org!not-for-mail From: Patrick Oppenlander Newsgroups: gmane.linux.lib.musl.general Subject: Re: vfork on ARM Date: Mon, 4 Apr 2016 16:56:42 +1000 Message-ID: <5702102A.4060004@gmail.com> References: <56FDC407.2030405@gmail.com> <20160401015301.GY21636@brightrain.aerifal.cx> <5701A4B7.9020200@gmail.com> <20160404001443.GH21636@brightrain.aerifal.cx> <5701D07C.6010504@gmail.com> <20160404033758.GI21636@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1459753097 2524 80.91.229.3 (4 Apr 2016 06:58:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Apr 2016 06:58:17 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9857-gllmg-musl=m.gmane.org@lists.openwall.com Mon Apr 04 08:58:16 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 1amySm-0003Hx-Gb for gllmg-musl@m.gmane.org; Mon, 04 Apr 2016 08:58:16 +0200 Original-Received: (qmail 28309 invoked by uid 550); 4 Apr 2016 06:58:14 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 28284 invoked from network); 4 Apr 2016 06:58:12 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 In-Reply-To: <20160404033758.GI21636@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:9844 Archived-At: On 04/04/16 13:37, Rich Felker wrote: > PIE does not hard-code a load address (the loader can pick the load > address, and could match it to ROM) but the relative offset between > load segments (the read-only text and read-write data) is fixed at > ld-time as usual for ELF. This certainly precludes using the text > in-place if there can be more than once instance executing (since they > can't both have their data at the same offset from text) and makes it > difficult to even run one instance in-place (only possible if you can > arrange for free RAM to exist at the right fixed offset. If you really > wanted to hack up such a setup, you would want non-PIE ELF files where > you pick the absolute addresses for load segments, not PIE where you > can only pick the relative address. I see the problem in my understanding. I had assumed that for a PIC executable the GOT was always accessed through a register rather than linked at a fixed location. In my testing this only happens for ARM under gcc with a combination of "-fpic -msingle-pic-base -mno-pic-data-is-text-relative". Then r9 is used to hold the GOT location and needs to be initialised by the program loader. That might be enough to be able to XIP on arm for static executables. I think I have some issues with my compiler flags or link script. -fpie is generating identical code to -fpic and the resultant ELF is still flagged EXEC_P rather than DYNAMIC. > I'm not sure what you mean by relocatable code here. I was talking about linking with the --relocatable option to ld then processing the relocations at program load time. This is how the project I forked from works. The result is still a complete copy of text/data for each process. Also, thank you for taking the time to discuss this now off-topic topic. Patrick