Can you please provide info which project is affected (I guess Linux kernel). Can you help me how to reproduce that?

Created attachment 41724 [details]
Reproduce lto crash with LD

Hi

I indeed observe the issue in a kernel project. It is a custom x86 kernel that is not published yet.

I tried to narrow down use case and I think I found how to reproduce the issue easily. It looks like a trigger pattern is:

1) compile one file as 32bit code (-m32)
2) convert it to 64bit elf object using objcopy
3) link the object above with regular 64bit elf

If "-flto" is not used then linking works fine otherwise I have the crash above.

Here is an attached repo case for your convenience.

(In reply to Anatol from comment #3)
> Hi
> 
> I indeed observe the issue in a kernel project. It is a custom x86 kernel
> that is not published yet.
> 
> I tried to narrow down use case and I think I found how to reproduce the
> issue easily. It looks like a trigger pattern is:
> 
> 1) compile one file as 32bit code (-m32)
> 2) convert it to 64bit elf object using objcopy
> 3) link the object above with regular 64bit elf
> 
> If "-flto" is not used then linking works fine otherwise I have the crash
> above.
> 
> Here is an attached repo case for your convenience.

Well how does it make sense to combine -m32 and -m64 in a single binary?
Without -flto having a cross-reference:

$ cat code32.c
int hello(int a)
{
  return a * a;
}

$ cat code64.c
void main(void) {
  return hello(1);
}

One gets:

$ gcc -g -ggdb -nostdlib -ffreestanding -std=c11 -fno-stack-protector -mno-red-zone -fno-common -W -Wall -Wextra -O3 code32.o code64.o -o code_bin
/usr/bin/ld: warning: cannot find entry symbol _start; defaulting to 00000000004000f0

Thus without LTO it does not work.

Having 32bit preamble in 64bit code is a standard situation in x86 OS development. Bootloader (such as GRUB multiboot) leaves the system in 32bit protected mode. It is responsibility of the OS to finish 32bit initialization (where only i386 instructions can be used) and switch to 64bit code. Once 32bit initialization is done switching to 64code happens with "far jump with selector" instruction
 "jmp $CODE_SELECTOR, $START64"


You cannot link 32bit and 64bit together (and least LD linker does not allow it). Thus one have to use a trick, either:
1) objcopy code32.o from elf32 to elf64 format
2) if code32 was an ASM code then use ".code32" GAS directive and compile file with 64bit flags.

Here is an example of #2 from LK operation system https://github.com/littlekernel/lk/blob/master/arch/x86/64/start.S#L210

I tried both solution and they both work with GCC and CLANG. GCC crashes if I enable LTO for #1.

Well, if you do

 gcc -m32 -flto -c x.c

you can't simply "objcopy" that x.o file to 64bits as objcopy doesn't know
how to handle LTO bytecode.

I suppose lto-wrapper could diagnose mismatched -m32/-m64 (but those are
target flags).

The solution is to _not_ use -flto for the 32bit bootloader part.  Thus

${PREFIX}gcc -c $CFLAGS -m32 code32.c -o code32.o32 -fno-lto
${PREFIX}objcopy -O elf64-x86-64 code32.o32 code32.o