https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81342
--- Comment #4 from Martin Liška <marxin at gcc dot gnu.org> ---
(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.
