Bug 65252 - Link time optimization breaks use of filenames in linker scripts
Summary: Link time optimization breaks use of filenames in linker scripts
Status: RESOLVED WONTFIX
Alias: None
Product: gcc
Classification: Unclassified
Component: lto (show other bugs)
Version: 4.8.3
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-28 10:10 UTC by Goswin von Brederlow
Modified: 2015-03-02 08:50 UTC (History)
1 user (show)

See Also:
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
Build: arm-none-eabi
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Goswin von Brederlow 2015-02-28 10:10:21 UTC
I'm building a kernel for a Rapsberry Pi 2 with -flto. Most of the code will be linked to 0x8000xxxx. The kernel image will be loaded to 0x8000 and I have set up LMA and VMA in my linker script accordingly. But I have some bootstrap code (boot.S and early.cc) that needs to at the physical address. So I put the following in my linker script:

ENTRY(_start)
PHYS_TO_VIRT = 0x80000000;
SECTIONS
{
    . = 0x8000;
    .early : {
        boot.o(.*)
        early.o(.*)
    }

    /* rest of the code runs in higher half virtual address */
    . = . + PHYS_TO_VIRT;
    .text : AT(ADDR(.text) - PHYS_TO_VIRT) {
    ...

Using objdump -d I see the boot.o contents show up at 0x8000 exactly as it should. But all the code from early.o only appears later in the .text section and at the virtual adress. If I drop the -flto then everything works as expected. It would be nice if -flto could preserve which file each function and variable comes from so the linker can place them properly.
Comment 1 Markus Trippelsdorf 2015-02-28 10:16:21 UTC
You could use -fno-lto when compiling early.cc.
Comment 2 Goswin von Brederlow 2015-03-01 07:57:34 UTC
As long as it's only one C/C++ file that works. But if one has multiple files then -fno-lto would optimize less. I was thinking of a more general case than mine.
Comment 3 Richard Biener 2015-03-02 08:50:12 UTC
LTO doesn't know about linker scripts and their effects (see other related bugreports).  For your case LTO partitioning might simply tear boot.o and early.o
apart and put parts in differen LTRANS units.

I don't see any way to fix this but to teach WPA to parse linker scripts and guide partitioning.

That means basically a WONTFIX with the known workaround to compile boot.o and
early.o without -flto.

Another workaround that might work is to use -flto-partition=1to1 (but the
filenames will still get wrong I think).