From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Mon, 04 Oct 2010 17:52:26 +0200 Subject: [U-Boot] ARM relocation, question to Heiko In-Reply-To: <4CA9F294.8080007@comcast.net> References: <4CA49746.2050301@emk-elektronik.de> <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 <1286167382.22760.19.camel@ptyser-laptop> <4CA99141.5020104@free.fr> <4CA999EE.5030309@free.fr> <20101004101308.94E27153A7E@gemini.denx.de> <4CA9F294.8080007@comcast.net> Message-ID: <4CA9F83A.6030000@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 04/10/2010 17:28, J. William Campbell a ?crit : > On 10/4/2010 3:13 AM, Wolfgang Denk wrote: >> Dear Albert ARIBAUD, >> >> In message<4CA999EE.5030309@free.fr> you wrote: >>> Note however that linking for base address 0 is not mandatory for >>> achieving true position independence. What is required is that the code >>> which runs from power-up until relocation be able to run anywhere, i.e., >>> this code should not require any relocation fixup. That can be achieved >>> on ARM by using only relative branches and accessing data only relative >>> to pc (e.g. literals) or truly absolute (e.g. HW registers etc). >> That means you need to build all of U-Boot that way, because >> significant parts of the code already run before relocation >> (including all clocks and timers setup, console setup, printf and all >> routines these pull in). >> > Yes, I think Wolfgang is correct. This is not going to be easy to do in > general. To run anywhere, the code must be true Position Independent > code. If you intend to use any C code in the initialization, this will > result in needing -fPIC for at least that code. I am not sure you can > mix -fPIC and non -fPIC code in the same link, but I expect not. I am a > bit surprised that it is possible to get even the initialization code to > be Position Independent, but it appears that on at least some PPC it is > possible/has been done. I'm not entirely sure about -fPIC, but it is possible indeed that true position independence might need it. For the moment, I'll settle for ELF relocatable. :) > On a related topic, I did find some information on the -mrelocatable > history. Take a look at > http://www.mail-archive.com/gcc at gcc.gnu.org/msg02528.html. > If you read both thread entries, it explains -mrelocatable as more or > less the post-processor that re-formats the ELF relocation information > into a smaller format and puts it in the text as another segment. What > Albert is doing now, and Graeme did before, is the first option, > creating a loader that understands ELF. This has the advantage that it > will work on all architectures. However, once this understanding is in > place, it would be easy to write a small post-processing program that > would reduce the size of the relocation entries, much like -mrelocatable > does. This may or may not be necessary, but it is certainly possible. > > Best Regards, > Bill Campbell Thanks Bill. I'll look into it once I get the current issues resolved; however it seems GOT-related, and -pie is not GOT-based -- and unlike GOT, -pie handles pointers in data, for instance, removing the need for manual fixups. Amicalement, -- Albert.