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, 0x30
No. 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?
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?
Sorry, I cannot follow. where exactly does this happen, and why there, and not anywhere else?
In any code emitted which uses above pattern. And above code works fine if text is 4k natural aligned before and after relocation. It also works fine when the same offset is used before and after relocation.
The question is - where does such code get emitted? Is it generated from C code, or manually created assembly?
I would like to see the exact source code reference into U-Boot code...
Best regards,
Wolfgang Denk