On Mon, Jan 28, 2019 at 11:12:29AM -0800, Andrey Smirnov wrote: > > > _However_, older toolchains (tested on 5.5.0), will only issue a > > > R_AARCH64_RELATIVE, so memory location will contain only zeroes: > > > > > > 00000000000000a0 <get_runtime_offset>: > > > a0: 10000000 adr x0, a0 <get_runtime_offset> > > > a4: 58000061 ldr x1, b0 <linkadr> > > > a8: eb010000 subs x0, x0, x1 > > > ac: d65f03c0 ret > > > > > > 00000000000000b0 <linkadr>: > > > ... > > > > > > This leads to an very early crash and complete boot failure in the > > > latter case. > > > > I can reproduce this issue here. As you can imagine I do not really like > > this "fix". I have no idea what the proper solution is (other than > > deprecating gcc5), so I am fine removing the "a" flag as you suggested. > > I think though that we should add a big comment above this function > > Sure, will add the comment in v2. > > > *why* this lacks the "a" flag and that we can add it back once gcc5 > > is retired. > > > > AFAICT, we don't want a relocation there even if GCC5 is deprecated > and it will always be conveniently initialized for us. To turn the > tables a bit, why do we need that "a" there? What's its purpose? The "a" is for "allocatable" meaning that space should be allocated in the output binary. If you put get_runtime_offset into its own section (outside .text) without the "a" flag then the linker linker bails out moaning about overlapping sections. I think the .text segment is inherently allocatable somehow, but then I wonder why the "a" flag makes a difference at all. It may just be a bug in the early aarc64 toolchains, who knows... Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
