https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78937
Bug ID: 78937
Summary: New data.rel.ro.local section in TW's gcc
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: jengelh at inai dot de
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
$ cat x.c
static const struct { int i; } foobar = {42};
static const struct { const char *n; } foobaz = {"moo"};
When compiled with the openSUSE Leap 42.2 + devel:gcc "gcc version 6.2.1
20161214 [gcc-6-branch revision 243648] (SUSE Linux)", the result is
anticipated; both symbols end up in rodata:
$ gcc-6 -std=gnu11 -c x.c && nm x.o | grep fooba
0000000000000000 r foobar
0000000000000008 r foobaz
$ gcc-6 -std=gnu11 -S x.c && grep section x.s
.section .rodata
.section .note.GNU-stack,"",@progbits
However, when compiled with pretty much the same compiler, openSUSE Tumbleweed
"gcc version 6.2.1 20161209 [gcc-6-branch revision 243481] (SUSE Linux)", the
following sections are output instead:
$ gcc-6 -std=gnu11 -c x.c -fno-use-linker-plugin && nm x.o | grep fooba
0000000000000000 r foobar
0000000000000000 d foobaz
$ gcc-6 -std=gnu11 -S x.c -fno-use-linker-plugin && grep section x.s
.section .rodata
.section .data.rel.ro.local,"aw",@progbits
.section .note.GNU-stack,"",@progbits
This section seems to be new; why does foobaz end up in .data now? Is this a
result of how gcc itself was built? The only difference is
42.2 gcc -v: [...] --with-default-libstdcxx-abi=gcc4-compatible
TW gcc -v: [...] --enable-plugin
C++ is not used in this case, so is the plugin thing the cause (and if, should
-fno-use-linker-plugin not disable it)?
