Messages in this thread | | | Date | Wed, 18 Mar 2020 21:48:50 +0200 | From | Remi Denis-Courmont <> | Subject | Re: [PATCH 1/3] arm64: clean up trampoline vector loads |
| |
Le 2020-03-18 20:29, Rémi Denis-Courmont a écrit : > Le keskiviikkona 18. maaliskuuta 2020, 20.06.30 EET Catalin Marinas a > écrit : >> On Wed, Mar 18, 2020 at 05:57:09PM +0000, Catalin Marinas wrote: >> > On Mon, Mar 16, 2020 at 02:40:44PM +0200, Rémi Denis-Courmont wrote: >> > > From: Rémi Denis-Courmont <remi.denis.courmont@huawei.com> >> > > >> > > This switches from custom instruction patterns to the regular large >> > > memory model sequence with ADRP and LDR. In doing so, the ADD >> > > instruction can be eliminated in the SDEI handler, and the code no >> > > longer assumes that the trampoline vectors and the vectors address both >> > > start on a page boundary. >> > > >> > > Signed-off-by: Rémi Denis-Courmont <remi.denis.courmont@huawei.com> >> > >> > I queued the 3 trampoline patches for 5.7. Thanks. >> >> ... and removed. I applied them on top of arm64 >> for-next/asm-annotations >> and with defconfig I get: >> >> LD .tmp_vmlinux1 >> arch/arm64/kernel/entry.o: in function `tramp_vectors': >> arch/arm64/kernel/entry.S:838:(.entry.tramp.text+0x43c): relocation >> truncated to fit: R_AARCH64_LDST64_ABS_LO12_NC against symbol >> `__entry_tramp_data_start' defined in .rodata section in >> >> I haven't bisected to see which patch caused this issue.
It's the third patch.
> Uho, right :-( It only builds with SDEI enabled :-$ > > I'll check further.
It seems that the SYM_DATA_START macro does not align the data on its natural boundary. I guess that is all fine on x86 where data needs not be aligned, but it leads to this kind of mischief on arm64. Though even then, the address is of course actually aligned correctly on an 8-bytes boundary, so I suppose binutils is just being pointlessly pedantic here?
-- Rémi Denis-Courmont
| |