Hello Wolfgang,
On ma, 2014-05-19 at 14:33 +0200, Wolfgang Denk wrote:
Dear Jeroen,
In message 1400485047.1998.17.camel@yellow you wrote:
"ADRP Xd, label
...
And apparently gcc choose to use it as such. Since the instructions in
Where exactly does it chose to do so?
In the code emitter which decide to use the following instructions to look up a label, as mentioned by David [1]. Since it only uses _part of_ the pc, it introduces the need to have the relocation offset be a multiple of 4k.
adrp x0, ... add x0, x0, 0x30No. I mean: to which exact lines of U-Boot C source code will be translated into that?
I mean, from what has been discussed here that would be the relocation loop, right? And there this should not happen, as we deal with random addresses. So I wonder if this is either a coding error in the armv8 related assembler code, or a compiler bug, or something else?
mm, forget about U-Boot for a second and please consider the following, complicated, program:
#include <stdio.h>
int main(int c, char *argv[]) { puts("Hello World"); return 0; }
compiled with `aarch64-linux-gnu-gcc -g -Wall hello.c` results in:
int main(int c, char *argv[]) { 400590: a9be7bfd stp x29, x30, [sp,#-32]! 400594: 910003fd mov x29, sp 400598: b90013a0 str w0, [x29,#16] 40059c: f9000fa1 str x1, [x29,#24] puts("Hello World"); 4005a0: 90000000 adrp x0, 400000 <_init-0x3b8> 4005a4: 91194000 add x0, x0, #0x650 4005a8: 97ffff9e bl 400420 puts@plt return 0; 4005ac: 52800000 mov w0, #0x0 // #0 } 4005b0: a8c27bfd ldp x29, x30, [sp],#32 4005b4: d65f03c0 ret
Notice the adrp and hardcoded offset to load the location of the argument. The 90000000 decodes to adrp x0, 0, the value of the program counter with its lower 12bits cleared -> which is the 400000 when not being relocated. Then the harcoded 650 offset is added to point to:
Contents of section .rodata: 400648 01000200 00000000 48656c6c 6f20576f ........Hello Wo 400658 726c6400 00000000 rld.....
---- Now suppose the code is moved 0x20 up, then the adrp will still return 400000, the constant #0x650 it still added, but Hello World is now at 400670 and it won't work.
If 0x1000 (4k) is added, the adrp sets 401000, the fixed 650 is added again and properly points to the repositioned "Hello World". This will work for any multiple of 4k.
I cannot understand why that should be a problem for _start, but not for any of the other symbols we're relocating?
It is not a problem of _start. Any label / symbol which is looked up with only the adrp + compile time offset will be incorrect if the relocation offset is not n * 4k. It just that moving _start around makes the relocation offset not obey this requirement.
Well, in this case relocation can never work correctly, so we're back at my question above: bad assembly code of the armv8 port, or a compiler bug?
Relocation will work fine, as long as (relocation_offset % 4096) == 0. Note that this is only about the offset, the label / symbol itself can be aligned to anything, since the hardcoded "add" will take care of that part.
The question is - where does such code get emitted? Is it generated from C code, or manually created assembly?
It is generated, there are no literal adrp instructions in U-boot. As far as I understand it, it is a compiler feature..
Regards, Jeroen