From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Sun, 03 Oct 2010 09:10:09 +0200 Subject: [U-Boot] ARM relocation, question to Heiko In-Reply-To: <4CA7BB24.80201@gmail.com> References: <4CA49746.2050301@emk-elektronik.de> <4CA570D3.9040406@denx.de> <4CA57468.6090702@free.fr> <4CA57762.3000201@denx.de> <4CA5821E.3070108@emk-elektronik.de> <4CA5873B.6040907@free.fr> <4CA590E6.6070701@emk-elektronik.de> <4CA59B89.6090207@denx.de> <4CA5BB7A.8050304@emk-elektronik.de> <20101001105506.A64D41539A0@gemini.denx.de> <4CA5BFEF.3090208@emk-elektronik.de> <20101001112125.4076E153A7E@gemini.denx.de> <4CA5C7DE.6010300@emk-elektronik.de> <20101001115908.A34411539A0@gemini.denx.de> <4CA5D26D.2090505@emk-elektronik.de> <4CA5D857.5010009@emk-elektronik.de> <20101001125502.D0B4E1539A0@gemini.denx.de> <4CA6DC16.5040409@emk-elektronik.de> <4CA6E517.9040701@fr <4CA6F687.1080600@denx.de> <4CA75BFB.5030208@comcast.net> <4CA79896.2010606@emk-elektronik.de> <4CA79F96.9060702@free.fr> <4CA7BB24.80201@gmail.com> Message-ID: <4CA82C51.7030300@free.fr> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Le 03/10/2010 01:07, Graeme Russ a ?crit : > On 03/10/10 08:09, Albert ARIBAUD wrote: >> Le 02/10/2010 22:39, Reinhard Meyer a ?crit : >> >>> And as an idea, if position independent code is used, only pointers >>> in initialized data need adjustment. Cannot the linker emit a table >>> of addresses that need fixing? >> >> IIU Bill C, yes the linker can emit the information and the startup code >> could use this information instead of relying on hand-provided info; the >> linker file probably needs to be modified in order to provide such info. >> I intend to look into this, but feel free to do too. > > As mentioned previously, I have already done this for x86. The linker flags > used are -pic and --emit-relocs. The linker produces a section named > rel.dyn which needs to be processed but not loaded into RAM. rel.dyn > contains a simple list of address (within .text, .data, .rodata etc) each > of which need a simple adjustment equal to the relocation offset. Bill just said that -pic (or, for ARM, -fPIC or -fPIE) was unnecessary for relocation. You seem to imply it actually is... In my experience, -fPIC and-fPIE do increase code by adding GOT relocation to symbols that need fixing, so they would indeed be redundant to any other relocation mechanism -- I just did some test with basic code and this seems to confirm, no -fPIx is needed to get relocation the way you do on ARM. > The size increase of the code + data loaded into RAM is 104012 bytes to > 104296 bytes which is only 284 bytes or a mere 0.3% (which is negligible) > with an additional 22424 bytes in rel.dyn (22%) not loaded into RAM > > The additional bonus is that .got is not referenced during run-time, so > there is no run-time performance penalty. However, the penalty of > processing 2803 relocation records at startup may not be wholly recovered > during a typical u-boot run-time session. > > All this is for x86, and may not apply so neatly to other arches Of course. :) Amicalement, -- Albert.