On Mon, Feb 24, 2025 at 1:37 AM Heinrich Schuchardt <xypron.g...@gmx.de> wrote:
>
> On 2/24/25 06:55, Sam Edwards wrote:
> > The EFI apps are built using ELF only as an intermediate "linker output"
> > format, with the final PE header crafted within the ELF to take effect
> > after the objcopy conversion to raw binary. As such, we really don't
> > care what the ELF header indicates as the entry point.
> >
> > Because nothing that uses this linker script even defines a _start
> > symbol, this directive has no effect. On GNU ld, it is silently ignored.
> > On certain linkers (e.g. LLVM lld), a warning is logged. But in any
> > case, no entry point is set.
>
> I can understand the first part of your reasoning. But the statement
> about _start is wrong. _start is defined on all EFI architectures, e.g.
>
> arch/arm/lib/crt0_aarch64_efi.S:147:
> _start
>
> arch/riscv/lib/crt0_riscv_efi.S:182:
> _start:
>
> Why does lld complain? Is it because we lack
>
>         .globl _start
>
> on ARM and RISC-V?

Hi Heinrich,

Yeah, pretty much. The .globl _start directive is required to turn
_start into a global symbol, rather than just a local label (which
might as well not even exist, as far as the linker is concerned).

I admit I only grepped in lib/efi* at first, but after looking in
arch/ it doesn't seem like anything creates this entry point for that
linker script to use (x86/64 do, but they have their own lds).

Cheers,
Sam

>
> Best regards
>
> Heinrich
>
> >
> > Therefore, remove it to silence warnings and avoid confusion.
> >
> > Signed-off-by: Sam Edwards <cfswo...@gmail.com>
> > ---
> >   lib/efi_loader/elf_efi.ldsi | 1 -
> >   1 file changed, 1 deletion(-)
> >
> > diff --git a/lib/efi_loader/elf_efi.ldsi b/lib/efi_loader/elf_efi.ldsi
> > index 190a88fb69e..dc4d1a3660e 100644
> > --- a/lib/efi_loader/elf_efi.ldsi
> > +++ b/lib/efi_loader/elf_efi.ldsi
> > @@ -10,7 +10,6 @@ PHDRS
> >       data PT_LOAD FLAGS(3); /* SHF_WRITE | SHF_ALLOC */
> >   }
> >
> > -ENTRY(_start)
> >   SECTIONS
> >   {
> >       .text 0x0 : {
>

Reply via email to