GCC 11.1.0 ARM cross-compiler lto1 ICE segfault, trying to debug

Gabriel Marcano gabemarcano@yahoo.com
Tue May 25 17:05:00 GMT 2021


 Hello,

I'm working with a Gentoo crossdev built GCC 11.1.0 with some user patches (in
case anyone cares, this cross-compiler is for compiling for the Nintendo 3DS,
so I am borrowing some patches from the devKitPro project). There is still a
chance the patches are to blame, but I am not sure yet as the segfault happens
inside lto1.

I would love to be able to submit a bug report (if this turns out to be a
proper bug) but I'm having a hard time reducing this to something not requiring
a full project build. Part of the problem is the project I'm building against
requires custom patches to newlib (adds an extra system library, or something
like that, to newlib).

Here's the specific lto1 invocation that segfaults (this is more for reference
so that it's more clear where in the LTO phase things are going sideways):

 /usr/libexec/gcc/arm-3ds-none-eabi/11.1.0/lto1 -quiet -dumpbase ./arm9.elf.wpa
 -mfloat-abi=soft -mtune=arm946e-s -mthumb -mfloat-abi=soft -mcpu=arm946e-s
 -march=armv5te -g -O3 -version -fno-openmp -fno-openacc -fno-pie
 -fcf-protection=none -fltrans-output-list=./arm9.elf.ltrans.out -fwpa
 -fresolution=arm9.elf.res -flinker-output=exec @./arm9.elf.wpa.args.0

It blows up with the following output:

 $ /usr/libexec/gcc/arm-3ds-none-eabi/11.1.0/lto1 -quiet -dumpbase
  ./arm9.elf.wpa -mfloat-abi=soft -mtune=arm946e-s -mthumb -mfloat-abi=soft
  -mcpu=arm946e-s -march=armv5te -g -O3 -version -fno-openmp -fno-openacc
  -fno-pie -fcf-protection=none -fltrans-output-list=./arm9.elf.ltrans.out -fwpa
  -fresolution=arm9.elf.res -flinker-output=exec @./arm9.elf.wpa.args.0
 GNU GIMPLE (Gentoo 11.1.0 p1) version 11.1.0 (arm-3ds-none-eabi)
        compiled by GNU C version 11.1.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version none
 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
 GNU GIMPLE (Gentoo 11.1.0 p1) version 11.1.0 (arm-3ds-none-eabi)
        compiled by GNU C version 11.1.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version none
 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
 during IPA pass: inline
 lto1: internal compiler error: Segmentation fault
 0x1145488 crash_signal
        /usr/src/debug/cross-arm-3ds-none-eabi/gcc-11.1.0/gcc-11.1.0/gcc/toplev.c:327
 0x7f524fb6c4ff ???
        ../sysdeps/unix/sysv/linux/sigaction.c:10
 0x7f524fbccdf3 ???
        ../sysdeps/x86_64/multiarch/../strchr.S:32
 0x218cbc6 arm_parse_cpu_option_name(cpu_option const*, char const*, char const*, bool)
        /usr/src/debug/cross-arm-3ds-none-eabi/gcc-11.1.0/gcc-11.1.0/gcc/common/config/arm/arm-common.c:386
 0x1644e47 arm_configure_build_target(arm_build_target*, cl_target_option*, gcc_options*, bool)
        /usr/src/debug/cross-arm-3ds-none-eabi/gcc-11.1.0/gcc-11.1.0/gcc/config/arm/arm.c:3211
 0x169c476 arm_can_inline_p
        /usr/src/debug/cross-arm-3ds-none-eabi/gcc-11.1.0/gcc-11.1.0/gcc/config/arm/arm.c:32812
 0x1fe8712 can_inline_edge_p
        /usr/src/debug/cross-arm-3ds-none-eabi/gcc-11.1.0/gcc-11.1.0/gcc/ipa-inline.c:378
 0x1fedec4 inline_small_functions
        /usr/src/debug/cross-arm-3ds-none-eabi/gcc-11.1.0/gcc-11.1.0/gcc/ipa-inline.c:2016
 0x1ff0b62 ipa_inline
        /usr/src/debug/cross-arm-3ds-none-eabi/gcc-11.1.0/gcc-11.1.0/gcc/ipa-inline.c:2723
 0x1ff1a50 execute
        /usr/src/debug/cross-arm-3ds-none-eabi/gcc-11.1.0/gcc-11.1.0/gcc/ipa-inline.c:3122
 Please submit a full bug report,
 with preprocessed source if appropriate.
 Please include the complete backtrace with any bug report.
 See <https://bugs.gentoo.org/> for instructions.

Using GDB, I can see that the problem is that by line gcc/config/arm/arm.c:3212
the opts->x_arm_tune_string variable is actually NULL even though the
opts_set->x_arm_tune_string variable is not. From a lot more digging, the
closest I can come up as to understanding what's going on is that this project
builds with an explicit -mtune parameter, but the libc it's linking against is
the default mulitlib thumb one, which does not appear to have any mtune
information associated with it. At least, if I iterate through the function
cl_target_option_stream_in in what appears to be a generated source file
build/gcc/options-save.c:9102 (or thereabouts), I see the parameter
x_arm_tune_string being extracted for all the different files in the project
(specifically, if I do a "display data_in->file_data->file_name" I can see
which files are being loaded in). All of the project object files have
x_arm_tune_string as "arm946e-s". libc, on the other hand, doesn't:

 2: ptr->x_arm_tune_string = 0x0
 3: data_in->file_data->file_name = 0x2c83890
   "/usr/lib/gcc/arm-3ds-none-eabi/11.1.0/../../../../arm-3ds-none-eabi/lib/thumb/libc.a"

I think this is the source of the problem. It appears something is assuming
that since global_options_set.x_arm_tune_string is not NULL that every object
file should have this value set. This isn't the case for libc.

I don't have a strong understanding of GCC, though, so I could be completely
off the mark. Am I thinking about this correctly? Anything else I should be
looking at? And are there any suggestions on how to reduce this to an example I
can send as a bug report? Even if for some reason libc is bad, GCC shouldn't
segfault.

Thanks for reading my wall of text.

Gabriel Marcano



More information about the Gcc-help mailing list