mirror of
git://gcc.gnu.org/git/gcc.git
synced 2025-04-08 02:40:31 +08:00
76a553587f
Fix a testsuite failure:
/tmp/ccL65Mmt.s: Assembler messages:
/tmp/ccL65Mmt.s:36: Warning: Symbol n used as immediate operand in PIC mode.
FAIL: gcc.dg/lto/pr55660 c_lto_pr55660_0.o-c_lto_pr55660_1.o link, -O0 -flto -flto-partition=none -fuse-linker-plugin
where non-PIC code is substituted by the LTO compiler at the link stage
for what used to be PIC code in the original compilation. This happens
because in the de-facto VAX ELF psABI we rely on code being PIC for GOT
support in dynamic executables and arrange that by having `-fPIC' passed
to the compiler by default by means of a specs recipe.
That is however canceled where the LTO wrapper is used, by an internal
arrangement in the LTO compiler that clears the PIC flag whenever the
`-flinker-output=exec' option has been used. This has been deliberately
introduced with commit 1ff9ed6fb282 ("re PR lto/67548 (LTO drops weak
binding with "ld -r")")[1]:
"In the log of PR67548 HJ actually pointed out that we do have API at
linker plugin side which says what type of output is done. This is cool
because we can also use it to drop -fpic when building static binary.
This is common in Firefox, where some objects are built with -fpic and
linked to both binaries and libraries."
with this code:
case LTO_LINKER_OUTPUT_EXEC: /* Normal executable */
flag_pic = 0;
flag_pie = 0;
flag_shlib = 0;
break;
Consequently code like:
.L6:
addl3 -8(%fp),$n,%r0
pushl %r0
calls $1,foo
addl2 %r0,-12(%fp)
incl -8(%fp)
.L5:
is produced by the LTO compiler, where a reference to `n' is used that
is invalid in PIC code, because it uses the immediate addressing mode,
denoted by the `$' prefix.
For that not to happen we must never pass `-flinker-output=exec' to the
LTO compiler unless non-PIC code has been explicitly requested. Using
`-flinker-output=dyn' except for relocatable output would seem the
simplest approach, as it does not fiddle with any of the internal code
model settings beyond what the command-line options have arranged and
therefore lets them remain the same as with the original compilation,
but it breaks as well causing PR lto/69866 to retrigger, as that code
seems sensitive to `flag_shlib':
lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:152
0x105be1cb add_symbol_to_partition_1
.../gcc/lto/lto-partition.c:152
0x105be443 add_symbol_to_partition_1
.../gcc/lto/lto-partition.c:194
0x105be80f add_symbol_to_partition
.../gcc/lto/lto-partition.c:270
0x105bee6f add_sorted_nodes
.../gcc/lto/lto-partition.c:395
0x105c0903 lto_balanced_map(int, int)
.../gcc/lto/lto-partition.c:815
0x105aa91f do_whole_program_analysis
.../gcc/lto/lto.c:499
0x105aac97 lto_main()
.../gcc/lto/lto.c:637
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
lto-wrapper: fatal error: .../gcc/xgcc returned 1 exit status
compilation terminated.
.../usr/bin/vax-netbsdelf-ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
compiler exited with status 1
FAIL: gcc.dg/lto/pr69866 c_lto_pr69866_0.o-c_lto_pr69866_1.o link, -O0 -flto -fuse-linker-plugin -fno-fat-lto-objects (internal compiler error)
Substitute `-flinker-output=pie' for `-flinker-output=exec' in the specs
then unless `-no-pie' has also been used, preserving the original intent
of emitting PIC code by default for executables while keeping the linker
arrangement unchanged. The LTO compiler uses the `cc1' spec, so keep
`cc1plus' unmodified.
This makes code like:
.L6:
movab n,%r0
addl2 -8(%fp),%r0
pushl %r0
calls $1,foo
addl2 %r0,-12(%fp)
incl -8(%fp)
.L5:
be produced instead corresponding to the fragment quoted above, which is
valid PIC code as it uses the PC-relative addressing mode denoted by the
absence of a prefix to `n' (which can be redirected to GOT as required,
by changing the addressing mode to PC-relative indirect in the operand
specifier).
Ideally we would instead default to the PIE model for executables, but
that triggers a BFD bug where for a change the LTO wrapper is not used:
.../usr/bin/vax-netbsdelf-ld: /tmp/ccV2sWQt.ltrans0.ltrans.o: warning: GOT addend of 3 to `n' does not match previous GOT addend of 0
FAIL: gcc.dg/lto/pr55660 c_lto_pr55660_0.o-c_lto_pr55660_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin
which is due to assembly code like:
main:
.word 0
subl2 $4,%sp
movab n,%r0
movab n+3,%r2
clrl %r3
movb $98,%r1
.L4:
and consequently object code like:
00000000 <main>:
0: 00 00 .word 0x0000 # Entry mask: < >
2: c2 04 5e subl2 $0x4,sp
5: 9e ef 00 00 movab b <main+0xb>,r0
9: 00 00 50
7: R_VAX_GOT32 n
c: 9e ef 00 00 movab 12 <main+0x12>,r2
10: 00 00 52
e: R_VAX_GOT32 n+0x3
13: d4 53 clrf r3
15: 90 8f 62 51 movb $0x62,r1
being produced. This would be problematic for external `n', because we
do not support multiple GOT entries for the same symbol referred to with
different offsets in a single link unit. In this case however the LTO
compiler correctly observes that `n' is defined by the executable and
not preemptible and therefore no GOT entry will be made for it.
Indeed a valid executable is produced:
00010548 <main>:
10548: 00 00 .word 0x0000 # Entry mask: < >
1054a: c2 04 5e subl2 $0x4,sp
1054d: 9e ef dd 14 movab 11a30 <n>,r0
10551: 00 00 50
10554: 9e ef d9 14 movab 11a33 <__bss_start>,r2
10558: 00 00 52
1055b: d4 53 clrf r3
1055d: 90 8f 62 51 movb $0x62,r1
despite the warning, but it would be rather bad to have users annoyed
with this message from BFD, however harmless, especially as it triggers
outside LTO compilations as well.
Therefore this change is the best we can do until binutils have been
fixed.
References:
[1] Jan Hubicka, "Getting LTO incremental linking work",
<https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02986.html>
gcc/
* config/vax/elf.h (VAX_CC1_SPEC, VAX_CC1PLUS_SPEC): New macros.
* config/vax/netbsd-elf.h (CC1_SPEC): Use VAX_CC1_SPEC rather
than VAX_CC1_AND_CC1PLUS_SPEC.
(CC1PLUS_SPEC): Use VAX_CC1PLUS_SPEC rather than
VAX_CC1_AND_CC1PLUS_SPEC.
This directory contains the GNU Compiler Collection (GCC). The GNU Compiler Collection is free software. See the files whose names start with COPYING for copying permission. The manuals, and some of the runtime libraries, are under different terms; see the individual source files for details. The directory INSTALL contains copies of the installation information as HTML and plain text. The source of this information is gcc/doc/install.texi. The installation information includes details of what is included in the GCC sources and what files GCC installs. See the file gcc/doc/gcc.texi (together with other files that it includes) for usage and porting information. An online readable version of the manual is in the files gcc/doc/gcc.info*. See http://gcc.gnu.org/bugs/ for how to report bugs usefully. Copyright years on GCC source files may be listed using range notation, e.g., 1987-2012, indicating that every year in the range, inclusive, is a copyrightable year that could otherwise be listed individually.