From: Wolfgang Denk Date: Mon, 19 May 2014 23:05:09 +0200 Subject: [U-Boot] armv8 relocation questions In-Reply-To: <1400532143.1985.57.camel@yellow> References: <537290F3.4000905@broadcom.com> <61F81D9C-81BA-4567-9B5F-3F5069473201@phytium.com.cn> <53763B78.6030801@broadcom.com> <20140516202825.240C838554C@gemini.denx.de> <20140516211514.GE7207@bill-the-cat> <1400279219.4133.22.camel@yellow> <20140517165301.E49DE38042B@gemini.denx.de> <1400416665.2394.20.camel@yellow> <20140518195128.ACDA238554D@gemini.denx.de> <1400485047.1998.17.camel@yellow> <20140519123342.763BC385554@gemini.denx.de> <1400523005.1985.33.camel@yellow> <20140519183033.95208385554@gemini.denx.de> <1400532143.1985.57.camel@yellow> Message-ID: <20140519210509.334DF38049A@gemini.denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Jeroen, In message <1400532143.1985.57.camel@yellow> you wrote: > > > I have no idea how the tool chain was configured here, and what the > > linker script might look like. > > for what it is worth: > aarch64-linux-gnu-gcc (Ubuntu/Linaro 4.8.1-10ubuntu7) 4.8.1 > with its default linker script. OK, now I know where it's coming from; did you look into this? > > Maybe. This is with some (unknown here) specific set of compiler > > options and linker statements. This does not mean that the same or > > silimar code will be generated for U-Boot, > > Could be, but the vexpress_aemv8a shows the same pattern. It has around > 1688 of adrp instructions. Probably with the same / similar compiler options? > I wondered about that. I could not find such a flag, nor did David think > it exists.. [1] You mean this statement: We can not make gcc-aarch64 do not use adrp instruction when constructing address of label. ? David, can you definitely confirm that there are no compiler / linker flags for relocatable code that might influence code generation / use of adrp here? > > That depends on specific compiler options / linker settings, > > eventually? > > Perhaps eventually. But for now it seems that also U-boot is forced to > keep the relocation offset a multiple of 4k. For aarch64, you mean? Because the tool chain and/or our current understanding how it generates code requires it, right? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de I'd rather be led to hell than managed to heaven.