`.LANCHR0' referenced in section `.text' of libc_pic.a(strtoul_l.os):
defined in discarded section `' of
libc_pic.a(strtoul_l.os)
`.LANCHR1' referenced in section `.text' of libc_pic.a(strtoul_l.os):
defined in discarded section `' of
libc_pic.a(strtoul_l.os)
-fno-section-anchors strtoul_l.os
000000fe 00000f0e R_PPC_GT16 00000000 __strtol_ul_max_tab + 0
00000102 0000100e R_PPC_GT16 00000000 __strtol_ul_rem_tab + 0
15: 00000000 140 BJECT GLBAL HIDDEN 5 __strtol_ul_max_tab
16: 00000000 35 BJECT GLBAL HIDDEN 6 __strtol_ul_rem_tab
-fsection-anchors strtoul_l_os
000000fe 0000060e R_PPC_GT16 00000000 .LANCHR0 + 0
00000102 0000080e R_PPC_GT16 00000000 .LANCHR1 + 0
6: 00000000 0 NTYPE LCAL DEFAULT 5 .LANCHR0
8: 00000000 0 NTYPE LCAL DEFAULT 6 .LANCHR1
GT relocs work by creating one entry in .got per symbol, so for example
if there are a dozen GT relocs referencing __strtol_ul_max_tab you get
just one entry in .got. Global symbols merge. There can only be one
strong definition of a global symbol, and all references resolve to
that single definition. However, .LANCHR0 is local, so is a different
symbol to .LANCHR0 in some other file. Thus the GT reloc referencing
LANCHR0 in this file creates a separate .got entry to a GT reloc in
another file referencing .LANCHR0.
I'd say this is a gcc bug. (The GT reloc can't really use section
anchors anyway because sym+off@got has rather useless semantics, so why
can't gcc use the original symbol?) ld can't treat the local symbols in
linkonce sections as if they were global because .LANCHR0 in
must be different from .LANCHR0 in

Comment #1 from dje at gcc dot gnu dot org 2006-08-04 13:50
Created an attachment (id=12017)
()
pre-processed source file

Comment #2 from dje at gcc dot gnu dot org 2006-08-04 13:58
Glibc explicitly is placing the symbols in the linkonce section:

const unsigned long __strtol_ul_max_tab[] __attribute__ ((visibility
("hidden"))) __attribute__((section(".gnu.linkonce.r." "__strtol_ul_max_tab")))

const unsigned char __strtol_ul_rem_tab[] __attribute__ ((visibility
("hidden"))) __attribute__((section(".gnu.linkonce.r." "__strtol_ul_rem_tab")))

Comment #3 from mmitchel at gcc dot gnu dot org 2006-08-04 15:27
From subsequent discussion by email, it sounds like we think that this is a
case where GLIBC has been making overly aggressive assumptions about GCC
semantics, and that, therefore, GLIBC should be changed. Given that, can this
PR be closed?

Thanks,
-- Mark

Comment #4 from pinskia at gcc dot gnu dot org 2006-08-04 15:29
Note Someone reported this back in May to glibc and nobody in glibc looked at
it and it was automatically closed as a dup of glibc bug 333.

Comment #5 from dje at gcc dot gnu dot org 2006-08-04 17:18
Using GCC attribute extension to place a symbol into a section with special
linking semantics cannot work reliably.