RE: [PATCH] arm64: Make CPU_BIG_ENDIAN depend on !LD_IS_LLD
> -Original Message-
> From: Arnd Bergmann
> Sent: 02 February 2021 20:44
> To: Nathan Chancellor
> Cc: Catalin Marinas ; Will Deacon
> ; Linux ARM ; linux-
> ker...@vger.kernel.org; Nick Desaulniers ;
> clang-built-linux ; Arnd Bergmann
> ; Peter Smith
> Subject: Re: [PATCH] arm64: Make CPU_BIG_ENDIAN depend on !LD_IS_LLD
>
> On Tue, Feb 2, 2021 at 8:51 PM Nathan Chancellor
> wrote:
> > On Tue, Feb 02, 2021 at 09:04:34AM +0100, Arnd Bergmann wrote:
> > > On Tue, Feb 2, 2021 at 3:25 AM Nathan Chancellor
> wrote:
> > > >
> > > > Similar to commit 28187dc8ebd9 ("ARM: 9025/1: Kconfig:
> > > > CPU_BIG_ENDIAN depends on !LD_IS_LLD"), ld.lld does not support
> > > > aarch64 big endian, leading to the following build error when
> > > > CONFIG_CPU_BIG_ENDIAN is
> > > > selected:
> > > >
> > > > ld.lld: error: unknown emulation: aarch64linuxb
> > >
> > > While this is the original error message I reported, I think it
> > > would be better to explain that lld actually does support linking
> > > big-endian kernels but they don't boot, for unknown reasons.
> >
> > That statement seems to contradict what Peter Smith says:
> >
> > https://github.com/ClangBuiltLinux/linux/issues/1288#issuecomment-7706
> > 93582
> >
> > https://reviews.llvm.org/D58655#1410282
>
> Right, adding Peter to Cc for clarification. Peter, what I can tell from
> experiments is that lld behaves just you describe it should, and (aside from
> the command like flag handling) like ld.bfd, so I'm not sure if there are any
> known deficiencies or just minor bugs when dealing with the kernel.
>
If an emulation (-m) is present then current LLD maps all known Arm and AArch
emulations to little endian
https://github.com/llvm/llvm-project/blob/main/lld/ELF/Driver.cpp#L147
In this case we'll get an error message with a big-endian object.
ld.lld: error: be.o is incompatible with aarch64linux
If there are no emulations present then LLD will auto-detect big-endian from
the first object file.
https://github.com/llvm/llvm-project/blob/main/lld/ELF/Driver.cpp#L1467
This will switch the generic LLD write functions to write big-endian. This will
mean that any write to instructions will need to use explicit write32le and any
data relocations will need to use write32/write64 as appropriate and not use
the explicit le versions. The relocations for instructions look to be using
explicit le writes as we'd want them to. I've spotted at least one case of
using write64le for what looks like data
https://github.com/llvm/llvm-project/blob/main/lld/ELF/Arch/AArch64.cpp#L198
I've not know anyone try LLD on big-endian before so there are no known
deficiencies. I expect that without an active search and tests there will be
some problems. I think every write will need looking at, if it is to
instructions it needs to explicitly use le, if to data (that could be either
little or big endian) it must not force little endian.
Peter
> FWIW, I have now built a big-endian musl C library and a helloworld binary,
> which I linked with ld.lld and successfully tested using qemu-aarch64_be-
> static
>
> Arnd
>
> > > I can send a patch to address the build error and mark big-endian as
> > > "depends on !LD_IS_LLD || COMPILE_TEST" to reflect that and help
> > > with randconfig testing.
> >
> > I have no strong opinion on handling this though.
Re: [PATCH] arm64: vdso32: force vdso32 to be compiled as -marm
> From: Nick Desaulniers > Sent: 27 May 2020 21:31 > To: Robin Murphy > Cc: Catalin Marinas; Will Deacon; Naohiro Aota; Stephen Boyd; Masahiro > Yamada; LKML; Manoj Gupta; Luis Lozano; Nathan Chancellor; Vincenzo Frascino; > Linux ARM; Kristof Beyls; Victor Campos; david.spick...@linaro.org; Arnd > Bergmann; Peter Smith > Subject: Re: [PATCH] arm64: vdso32: force vdso32 to be compiled as -marm > > On Wed, May 27, 2020 at 1:14 PM Nick Desaulniers > wrote: > > > > On Wed, May 27, 2020 at 12:28 PM Robin Murphy wrote: > > > > > > On 2020-05-27 18:55, Nick Desaulniers wrote: > > > > On Wed, May 27, 2020 at 6:45 AM Robin Murphy > > > > wrote: > > > >> > > > >> On 2020-05-26 18:31, Nick Desaulniers wrote: > > > >>> Custom toolchains that modify the default target to -mthumb cannot > > > >>> compile the arm64 compat vdso32, as > > > >>> arch/arm64/include/asm/vdso/compat_gettimeofday.h > > > >>> contains assembly that's invalid in -mthumb. Force the use of -marm, > > > >>> always. > > > >> > > > >> FWIW, this seems suspicious - the only assembly instructions I see > > > >> there > > > >> are SWI(SVC), MRRC, and a MOV, all of which exist in Thumb for the > > > >> -march=armv7a baseline that we set. > > > >> > > > >> On a hunch, I've just bodged "VDSO_CFLAGS += -mthumb" into my tree and > > > >> built a Thumb VDSO quite happily with Ubuntu 19.04's > > > >> gcc-arm-linux-gnueabihf. What was the actual failure you saw? > > > > > > > > From the link in the commit message: `write to reserved register 'R7'` > > > > https://godbolt.org/z/zwr7iZ > > > > IIUC r7 is reserved for the frame pointer in THUMB? > > > > > > It can be, if you choose to build with frame pointers and the common > > > frame pointer ABI for Thumb code that uses r7. However it can also be > > > for other things like the syscall number in the Arm syscall ABI too. > > > > Ah, right, with -fomit-frame-pointer, this error also goes away. Not > > sure if we prefer either: > > - build the compat vdso as -marm always or > > - disable frame pointers for the vdso (does this have unwinding > > implications?) > > - other? > > > > > I > > > take it Clang has decided that writing syscall wrappers with minimal > > > inline asm is not a thing people deserve to do without arbitrary other > > > restrictions? > > > > Was the intent not obvious? We would have gotten away with it, too, if > > wasn't for you meddling kids and your stupid dog! /s > > https://www.youtube.com/watch?v=hXUqwuzcGeU > > Anyways, this seems to explain more the intentions: > > https://reviews.llvm.org/D76848#1945810 > > + Victor, Kristof (ARM) > > And maybe some other useful data points regarding warning on use of r7 > and frame pointers. > https://github.com/ClangBuiltLinux/linux/issues/701#issuecomment-591325758 > https://bugs.llvm.org/show_bug.cgi?id=45826 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94986 > > + Peter (ARM) > + David, Arnd (Linaro) > -- > Thanks, > ~Nick Desaulniers Hello Nick, The AAPCS has only recently (28th January 2020) been updated with a specification of the frame pointer and frame chain. My understanding is that neither gcc nor clang implement this part yet. Historically the frame pointer in Thumb has not been defined in the AAPCS with implementations falling back to historic definitions of fp = r7 in Thumb and fp = r11 in Arm. The use of different frame pointer registers in Arm and Thumb state makes it difficult to construct a frame chain with interworking. My understanding of the AAPCS is that it has been changed to make the frame pointer r11 on both Arm and Thumb to make unwinding possible, at the expense of r11 being harder to access from 16-bit Thumb instructions. There are 4 levels of conformance with respect to construction of frame records and frame chain as it is likely some platforms will want to persist with r7. An implementation of the latest version of the AAPCS would permit a frame pointer and use of r7 as a reserved register. Although as you'll need to support older compilers this may not be an option. I suggest using Arm if you need a frame pointer, and disable the frame pointer if you want/need to use Thumb. My understanding is that runtime unwinding using the frame pointer in Thumb is already difficult due to Arm and Thumb functions using different registers for the frame pointer. Hope this helps Peter
Re: [PATCH v2] x86, realmode: explicitly set entry via command line
From: Nick Desaulniers
Sent: 25 September 2019 17:35
To: Borislav Petkov
Cc: H. Peter Anvin; Jarkko Sakkinen; Thomas Gleixner; Ingo Molnar;
clang-built-linux; maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT); Tri Vo;
Masahiro Yamada; Rob Herring; George Rimar; LKML; Fangrui Song; Peter Smith;
Rui Ueyama
Subject: Re: [PATCH v2] x86, realmode: explicitly set entry via command line
+ Fangrui, Peter, Rui, George (LLD)
On Wed, Sep 25, 2019 at 3:20 AM Borislav Petkov wrote:
>
> + some more people who did the unified realmode thing.
>
> On Tue, Sep 24, 2019 at 12:33:08PM -0700, Nick Desaulniers wrote:
> > Linking with ld.lld via $ make LD=ld.lld produces the warning:
> > ld.lld: warning: cannot find entry symbol _start; defaulting to 0x1000
> >
> > Linking with ld.bfd shows the default entry is 0x1000:
> > $ readelf -h arch/x86/realmode/rm/realmode.elf | grep Entry
> > Entry point address: 0x1000
> >
> > While ld.lld is being pedantic, just set the entry point explicitly,
> > instead of depending on the implicit default.
> >
> > Link: https://github.com/ClangBuiltLinux/linux/issues/216
> > Signed-off-by: Nick Desaulniers
> > ---
> > Changes V1 -> V2:
> > * Use command line flag, rather than linker script, as ld.bfd produces a
> > syntax error for `ENTRY(0x1000)` but is happy with `-e 0x1000`
> >
> > arch/x86/realmode/rm/Makefile | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/realmode/rm/Makefile b/arch/x86/realmode/rm/Makefile
> > index f60501a384f9..338a00c5257f 100644
> > --- a/arch/x86/realmode/rm/Makefile
> > +++ b/arch/x86/realmode/rm/Makefile
> > @@ -46,7 +46,7 @@ $(obj)/pasyms.h: $(REALMODE_OBJS) FORCE
> > targets += realmode.lds
> > $(obj)/realmode.lds: $(obj)/pasyms.h
> >
> > -LDFLAGS_realmode.elf := -m elf_i386 --emit-relocs -T
> > +LDFLAGS_realmode.elf := -m elf_i386 --emit-relocs -e 0x1000 -T
>
> So looking at arch/x86/realmode/rm/realmode.lds.S: what's stopping
> people from adding more sections before the first
>
> . = ALIGN(PAGE_SIZE);
>
> which, with enough bytes to go above the first 4K, would cause that
> alignment to go to 0x2000 and then your hardcoded address would be
> wrong, all of a sudden.
Thanks for the consideration Boris. So IIUC if the preceding sections
are larger than 0x1000 altogether, setting the entry there will be
wrong?
Currently, .text looks like it's currently at 0x1000 for a defconfig,
and I assume that could move in the case I stated above?
$ readelf -S arch/x86/realmode/rm/realmode.elf | grep text
[ 3] .text PROGBITS1000 201000 000f51 00 AX
0 0 4096
...
In that case, it seems that maybe I should set the ENTRY in the linker
script as:
diff --git a/arch/x86/realmode/rm/realmode.lds.S
b/arch/x86/realmode/rm/realmode.lds.S
index 3bb980800c58..64d135d1ee63 100644
--- a/arch/x86/realmode/rm/realmode.lds.S
+++ b/arch/x86/realmode/rm/realmode.lds.S
@@ -11,6 +11,7 @@
OUTPUT_FORMAT("elf32-i386")
OUTPUT_ARCH(i386)
+ENTRY(pa_text_start)
SECTIONS
{
--
Thanks,
~Nick Desaulniers
If I've understood the thread correctly, sorry jumping in late.
- LLD will set the entry point to the start of the .text section in absence of
any of the other ways to communicate an entry point. It gives a warning in this
case.
- Setting the entry point to an address that is the current start of the .text
section silences the warning, but is potentially fragile.
I think LLD is on balance right to give a warning as in many cases the start of
the .text section is not going to coincide with the desired entry point.
I recommend doing this via using a symbol defined at the entry point, for
example Nick's last suggestion. This will be most resistant to changes such as
the .text section changing address or the entry point isn't first in the .text
section.
Peter
Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option
On Wed, 5 Dec 2018 at 18:22, Nick Desaulniers wrote: > > On Wed, Dec 5, 2018 at 12:10 AM Ard Biesheuvel > wrote: > > > > (+ Arnd) > > > > On Wed, 5 Dec 2018 at 09:06, Nathan Chancellor > > wrote: > > > > > > On Wed, Dec 05, 2018 at 08:37:05AM +0100, Ard Biesheuvel wrote: > > > > On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor > > > > wrote: > > > > > > > > > > This flag is not supported by lld: > > > > > > > > > > ld.lld: error: unknown argument: --pic-veneer > > > > > > > > > > Signed-off-by: Nathan Chancellor > > > > > > > > Hi Nate, > > > > > > > > Does this mean ld.lld is guaranteed to produce position independent > > > > veneers if you build kernels that are bigger than the typical range of > > > > a relative branch? > > (+ Peter) who might be able to answer this. > LLD will only use position independent veneers when --shared or --pie is used, otherwise it will use veneers with absolute addresses. If the kernel must use position independent veneers even when the rest of the code isn't then we'll have to implement --pic-veneer. Peter > > > > > > > > > > Hi Ard, > > > > > > Honestly, I'm not quite sure. I saw your commit that introduced this > > > flag and I wasn't quite sure what to make of it for lld. What > > > configuration would I use to verify and what would I check for? > > > > > > > Try building allyesconfig, and check the resulting binary for veneers > > (which have 'veneer' in the symbol name, at least when ld.bfd emits > > them). These veneers should not take the [virtual] address of the > > branch target directly, but take a PC relative offset (as in the > > example in the commit log of that patch you are referring to) > > Not sure clang can compile an arm32 allyesconfig (haven't tried > personally, yet, TODO), but we could try gcc+lld. > > > > > > Additionally, I have filed an LLVM bug for the lld developers to > > > check and see if this is a flag they should support: > > > > > > https://bugs.llvm.org/show_bug.cgi?id=39886 > > > > > > Thanks for the quick reply, > > > Nathan > > > > > > > > --- > > > > > arch/arm/Makefile | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile > > > > > index e2a0baf36766..4fab2aa29570 100644 > > > > > --- a/arch/arm/Makefile > > > > > +++ b/arch/arm/Makefile > > > > > @@ -10,7 +10,7 @@ > > > > > # > > > > > # Copyright (C) 1995-2001 by Russell King > > > > > > > > > > -LDFLAGS_vmlinux:= --no-undefined -X --pic-veneer > > > > > +LDFLAGS_vmlinux:= --no-undefined -X $(call > > > > > ld-option,--pic-veneer) > > > > > ifeq ($(CONFIG_CPU_ENDIAN_BE8),y) > > > > > LDFLAGS_vmlinux+= --be8 > > > > > KBUILD_LDFLAGS_MODULE += --be8 > > > > > -- > > > > > 2.20.0.rc1 > > > > > > > > > -- > Thanks, > ~Nick Desaulniers
Good news
Hello, This is to inform you that you have been deceived by the so called Nigerian/British Officials for long. They have extorted enough of your hard earned money from you and it is time to say enough to that. The Federal Government has set up this committee to ensure that all beneficiaries are paid their long over due funds without asking you to pay any dime. Therefore, I am sending this email to inform you that your funds will be paid to you without asking you to pay any fee for anything whatsoever. We are very sorry for your ugly experiences in the hands of these criminals. You are required to get in touch with this office urgently to direct you further on how to receive your funds unconditionally. Your urgent response is highly expected. Regards, Peter Smith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
