[Bug ld/13600] New: protected visibility creates bogus relocation
http://sourceware.org/bugzilla/show_bug.cgi?id=13600
Bug #: 13600
Summary: protected visibility creates bogus relocation
Product: binutils
Version: 2.22
Status: NEW
Severity: normal
Priority: P2
Component: ld
AssignedTo: unassig...@sourceware.org
ReportedBy: rgue...@gcc.gnu.org
Classification: Unclassified
.file "t1.c"
.text
.globl foo
.protected foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
leaqfoo(%rip), %rax
popq%rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident "GCC: (GNU) 4.7.0 20120116 (experimental)"
.section.note.GNU-stack,"",@progbits
does not link:
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld:
/tmp/cc43SbHJ.o: relocation R_X86_64_PC32 against protected symbol `foo' can
not be used when making a shared object
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld:
final link failed: Bad value
collect2: error: ld returned 1 exit status
C testcase:
__attribute__((visibility("protected"))) void * foo (void) { return (void
*)foo; }
gcc t1.c -o libt1.so -shared -fPIC.
Sounds similar to PR584, but this time with a self-reference.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/13600] protected visibility creates bogus relocation
http://sourceware.org/bugzilla/show_bug.cgi?id=13600 --- Comment #3 from Richard Guenther 2012-01-18 09:13:09 UTC --- (In reply to comment #1) > I think it is a gcc bug: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520 That one mixes in the issue of comparing function addresses of protected symbols - that's sth entirely different (and a QOI issue, which is probably why ICC generates the more funky variant, see http://gcc.gnu.org/ml/gcc-bugs/2012-01/msg01892.html). -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/13600] protected visibility creates bogus relocation
http://sourceware.org/bugzilla/show_bug.cgi?id=13600 --- Comment #5 from Richard Guenther 2012-01-19 09:16:32 UTC --- (In reply to comment #4) > Both ld and ld.so go extra efforts to make sure that > the same function pointer value is used for protected > function in the entire process. If we drop this requirement, > we can simplify ld and ld.so quite a bit. Well, if we make sure ld.so resolves the GOT entry to the function address instead of the PLT then that will work - in the module the protected symbol binds locally we get it resolved to the function address directly anyway (see GCC assembly from the testcase). Sounds easier allover the place, no? -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/14915] New: --copy-dt-needed-entries not working
http://sourceware.org/bugzilla/show_bug.cgi?id=14915 Bug #: 14915 Summary: --copy-dt-needed-entries not working Product: binutils Version: 2.23 Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassig...@sourceware.org ReportedBy: rgue...@gcc.gnu.org Classification: Unclassified > gcc -o libt1.so -shared -lm > gcc -o libt2.so -shared -Wl,--copy-dt-needed-entries -L. -lt1 libt1.so is as expected: > readelf -d libt1.so Dynamic section at offset 0xe48 contains 22 entries: TagType Name/Value 0x0001 (NEEDED) Shared library: [libm.so.6] 0x0001 (NEEDED) Shared library: [libc.so.6] 0x000c (INIT) 0x480 ... but libt2.so does not have a NEEDED entry for libm.so.6: > readelf -d libt2.so Dynamic section at offset 0xe48 contains 22 entries: TagType Name/Value 0x0001 (NEEDED) Shared library: [libt1.so] 0x0001 (NEEDED) Shared library: [libc.so.6] 0x000c (INIT) 0x480 ... (trying to come up with a testcase where --[no-]copy-dt-needed-entries matters) Same behavior with ld 2.18 (and --[no-]add-needed) btw. Same behavior if libt2.so is not a shared object. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/14915] --copy-dt-needed-entries not working
http://sourceware.org/bugzilla/show_bug.cgi?id=14915 --- Comment #6 from Richard Guenther 2012-12-04 14:41:12 UTC --- (In reply to comment #5) > (In reply to comment #4) > > This option is renamed from --add-needed: > > > > http://sourceware.org/ml/binutils/2004-07/msg00093.html > > Yes, but why are you mentioning that? Btw, I explicitely stated that even before the rename, with ld 2.18, it did not work as expected (using --[no-]add-needed). -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/15930] New: Excessive memory usage assembling file
https://sourceware.org/bugzilla/show_bug.cgi?id=15930 Bug ID: 15930 Summary: Excessive memory usage assembling file Product: binutils Version: 2.23 Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: rguenth at gcc dot gnu.org Assembling the file that I'll momentarily try to attach requires 6.5GB of memory on a x86_64 host using gas 2.23.2 and the assembler command /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/as -v -I . -I ../.. -I ../../src -I ../../src -I ../../utils -I ../../tests --64 -o mipproblem1.o mipproblem1.s That seems a little excessive for assembler memory usage. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/15930] Excessive memory usage assembling file
https://sourceware.org/bugzilla/show_bug.cgi?id=15930 --- Comment #1 from Richard Guenther --- Ok, the assembler file is 1GB in size and doesn't compress enough. It can be generated by compiling the testcase at gcc.gnu.org/PR58315 with GCC 4.8 and -O2 -g on x86_64. Or you can download it from http://gcc.opensuse.org/mipproblem1.s.bz2 (it should appear there in not too distant future) -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/13227] GCC now produce slim LTO files. Those can't be linked/archived or nm w/o plugin used. It would be useful to output diagnostics when user attempts so
https://sourceware.org/bugzilla/show_bug.cgi?id=13227 Richard Guenther changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Depends on||14698 --- Comment #1 from Richard Guenther --- See 14698. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/14698] ar, nm and ranlib don't use gcc's liblto_plugin.so in BINDIR/../lib/bfd-plugins automatically
https://sourceware.org/bugzilla/show_bug.cgi?id=14698 Richard Guenther changed: What|Removed |Added Blocks||13227 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/14698] ar, nm and ranlib don't use gcc's liblto_plugin.so in BINDIR/../lib/bfd-plugins automatically
https://sourceware.org/bugzilla/show_bug.cgi?id=14698 --- Comment #4 from Richard Guenther --- Patch that seems to work for me: https://sourceware.org/ml/binutils/2014-01/msg00213.html -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/14698] ar, nm and ranlib don't use gcc's liblto_plugin.so in BINDIR/../lib/bfd-plugins automatically
https://sourceware.org/bugzilla/show_bug.cgi?id=14698 Richard Guenther changed: What|Removed |Added Status|RESOLVED|REOPENED CC||rguenth at gcc dot gnu.org Resolution|WONTFIX |--- --- Comment #3 from Richard Guenther --- Re-open. Makes the new GCC 4.9 default behavior quite broken - it better transparently supports LTO, even at link-stage but also has slim LTO objects by default. That means most projects should just "work" with adding -flto to CFLAGS (no need to adjust LDFLAGS anymore). But all projects using archives are broken if they are not adjusted to use ar/nm/ranlib with plugin. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/16746] New: ld complains about .gnu.warning symbols referenced by linker plugin inputs
https://sourceware.org/bugzilla/show_bug.cgi?id=16746
Bug ID: 16746
Summary: ld complains about .gnu.warning symbols referenced by
linker plugin inputs
Product: binutils
Version: 2.24
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: rguenth at gcc dot gnu.org
t.c
---
extern void foobar (void);
int
main (int argc, char **argv)
{
if (__builtin_constant_p (argc))
foobar ();
return 0;
}
t2.c
---
static const char __evoke_link_warning_foobar[]
__attribute__ ((used, section (".gnu.warning.foobar\n\t#")))
= "foobar";
> gcc -c t2.c
> gcc t.c t2.o -O -flto
/tmp/cctYGzQc.o (symbol from plugin): warning: foobar
the symbol table from the t.o input claimed by lto-plugin contains
a reference to foobar () - which is the point LD already warns - but
the replacement object fed from lto-plugin to the linker doesn't contain
this reference anymore.
Thus, LD shouldn't complain about references in files claimed by a
linker plugin but only about references in files provided by the
linker plugin.
This works correctly with gold.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/16746] ld complains about .gnu.warning symbols referenced by linker plugin inputs
https://sourceware.org/bugzilla/show_bug.cgi?id=16746
--- Comment #1 from Richard Guenther ---
Fix maybe as simple as doing
diff --git a/ld/ldmain.c b/ld/ldmain.c
index ffc9f84..71d41bf 100644
--- a/ld/ldmain.c
+++ b/ld/ldmain.c
@@ -1160,6 +1160,9 @@ warning_callback (struct bfd_link_info *info
ATTRIBUTE_UNUSED,
asection *section,
bfd_vma address)
{
+ if (abfd->flags & BFD_PLUGIN)
+return TRUE;
+
/* This is a hack to support warn_multiple_gp. FIXME: This should
have a cleaner interface, but what? */
if (! config.warn_multiple_gp
?
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/16746] ld complains about .gnu.warning symbols referenced by linker plugin inputs
https://sourceware.org/bugzilla/show_bug.cgi?id=16746
--- Comment #3 from Richard Guenther ---
(In reply to Richard Guenther from comment #2)
> Hmm, but that breaks the case where the symbol is still referenced from the
> linker plugin provided input
>
> extern void foobar (void);
> int
> main (int argc, char **argv)
> {
> if (!__builtin_constant_p (argc))
> foobar ();
> return 0;
> }
>
> add void foobar () {} to t2.c to make the link succeed.
Which of course may simply mean that the path through lang_add_input_file
misses
to emit warnings at all.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/16746] ld complains about .gnu.warning symbols referenced by linker plugin inputs
https://sourceware.org/bugzilla/show_bug.cgi?id=16746
--- Comment #2 from Richard Guenther ---
Hmm, but that breaks the case where the symbol is still referenced from the
linker plugin provided input
extern void foobar (void);
int
main (int argc, char **argv)
{
if (!__builtin_constant_p (argc))
foobar ();
return 0;
}
add void foobar () {} to t2.c to make the link succeed.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/16746] ld complains about .gnu.warning symbols referenced by linker plugin inputs
https://sourceware.org/bugzilla/show_bug.cgi?id=16746 --- Comment #5 from Richard Guenther --- (In reply to H.J. Lu from comment #4) > _bfd_generic_link_add_one_symbol needs change to properly > handle it. It should check BFD_PLUGIN for WARN. Can you try to fix it? That would certainly be faster than me trying to dig into ld sources for my first time... -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/13227] GCC now produce slim LTO files. Those can't be linked/archived or nm w/o plugin used. It would be useful to output diagnostics when user attempts so
https://sourceware.org/bugzilla/show_bug.cgi?id=13227 --- Comment #6 from Richard Guenther --- (In reply to Alan Modra from comment #5) > So is it sufficient (and safe) to warn just on the presence of > __gnu_slim_lto? Yes, I think so. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/18834] New: Gold does not accept linker-script input only with -T
https://sourceware.org/bugzilla/show_bug.cgi?id=18834 Bug ID: 18834 Summary: Gold does not accept linker-script input only with -T Product: binutils Version: 2.25 Status: NEW Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: rguenth at gcc dot gnu.org CC: ian at airs dot com Target Milestone: --- using > ld.gold -o x -Tscript results in ld.gold: fatal error: no input files ld.gold appears to accept > ld.gold -o x script though but the result is unexpected (script doesn't work at all, see separate bug). -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/18835] New: GAS complains about incorrect section attributes
https://sourceware.org/bugzilla/show_bug.cgi?id=18835 Bug ID: 18835 Summary: GAS complains about incorrect section attributes Product: binutils Version: 2.25 Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- For the testcase below gas complains with > as -o t.o t.s t.s: Assembler messages: t.s:13: Warning: setting incorrect section attributes for .gnu.lto_.debug_str for no good reason (it seems to special-case .gnu.lto_ prefixed sections somehow). .section.gnu.lto_.debug_info,"",@progbits .hidden t.c.f0aceea6 .globl t.c.f0aceea6 t.c.f0aceea6: .long 0x31 .value 0x4 .long .Ldebug_abbrev1 .section.gnu.lto_.debug_abbrev,"",@progbits .Ldebug_abbrev1: .uleb128 0x1 .section.gnu.lto_.debug_str,"MS",@progbits,1 .string "/abuild/rguenther/trunk-g/gcc" -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/18836] New: ld handles .gnu.lto_ prefixed sections oddly, /DISCARD/ semantics unclear
https://sourceware.org/bugzilla/show_bug.cgi?id=18836
Bug ID: 18836
Summary: ld handles .gnu.lto_ prefixed sections oddly,
/DISCARD/ semantics unclear
Product: binutils
Version: 2.25
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
For t.s
.section.gnu.lto_.debug_info,"",@progbits
.hidden t.c.f0aceea6
.globl t.c.f0aceea6
t.c.f0aceea6:
.long 0x31
.value 0x4
.long .Ldebug_abbrev1
.section.gnu.lto_.debug_abbrev,"",@progbits
.Ldebug_abbrev1:
.uleb128 0x1
.section.gnu.lto_.debug_str,"MS",@progbits,1
.string "/abuild/rguenther/trunk-g/gcc"
and the linker script
SECTIONS {
.debug_info : { t.o(.gnu.lto_.debug_info) }
.debug_abbrev : { t.o(.gnu.lto_.debug_abbrev) }
.debug_str : { t.o(.gnu.lto_.debug_str) }
}
desired to link .gnu.lto_ debug-info sections from LTO input to a final
executable by linking them as regular debug-info sections like with
> as -o t.o t.s
> ld -o x script
ld: warning: cannot find entry symbol _start; defaulting to 00400040
ld produces
> readelf -S x
There are 5 section headers, starting at offset 0x138:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL
0 0 0
[ 1] .debug_strPROGBITS 0040
001e 0001 MS 0 0 1
[ 2] .shstrtab STRTAB 005e
0026 0 0 1
[ 3] .symtab SYMTAB 0088
0090 0018 4 2 8
[ 4] .strtab STRTAB 0118
0020 0 0 1
so it dropped all but .debug_str, presumably because of the default
/DISCARD/ : { *(.gnu.lto*) }
rule in effect for non-partial links. But oddly this rule didn't apply
to .debug_str.
Also there is no way to "override" this DISCARD as it seems to apply
in "order" of the linker scripts(?) rather than in the order suggested
by -M:
Discarded input sections
.gnu.lto_.debug_info
0x0xa t.o
.gnu.lto_.debug_abbrev
0x0x1 t.o
Memory Configuration
Name Origin Length Attributes
*default*0x 0x
Linker script and memory map
...
.debug_info
*(.debug_info .gnu.linkonce.wi.*)
t.o(.gnu.lto_.debug_info)
.debug_abbrev
*(.debug_abbrev)
t.o(.gnu.lto_.debug_abbrev)
...
.debug_str 0x 0x1e
*(.debug_str)
t.o(.gnu.lto_.debug_str)
.gnu.lto_.debug_str
0x 0x1e t.o
...
/DISCARD/
*(.note.GNU-stack)
*(.gnu_debuglink)
*(.gnu.lto_*)
OUTPUT(x elf64-x86-64)
which I hope is a bug. Otherwise I'd need a new feature to be able to
get at inputs discarded sections... (doing a partial link now as a
workaround, but that creates additional I/O and a quite big temporary file)
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/18837] New: gold does not handle linker-scripts with inputs
https://sourceware.org/bugzilla/show_bug.cgi?id=18837
Bug ID: 18837
Summary: gold does not handle linker-scripts with inputs
Product: binutils
Version: 2.25
Status: NEW
Severity: critical
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: rguenth at gcc dot gnu.org
CC: ian at airs dot com
Target Milestone: ---
.section.gnu.lto_.debug_info,"",@progbits
.hidden t.c.f0aceea6
.globl t.c.f0aceea6
t.c.f0aceea6:
.long 0x31
.value 0x4
.long .Ldebug_abbrev1
.section.gnu.lto_.debug_abbrev,"",@progbits
.Ldebug_abbrev1:
.uleb128 0x1
.section.gnu.lto_.debug_str,"MS",@progbits,1
.string "/abuild/rguenther/trunk-g/gcc"
> as -o t.o t.s
and script
SECTIONS {
.debug_info : { t.o(.gnu.lto_.debug_info) }
.debug_abbrev : { t.o(.gnu.lto_.debug_abbrev) }
.debug_str : { t.o(.gnu.lto_.debug_str) }
}
and trying to have it link from t.o input sections to debug-info sections
doesn't result in any success (nor do I have an idea how to debug it).
> ld.gold -o x script
> readelf -S x
There are 5 section headers, starting at offset 0xb0:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL
0 0 0
[ 1] .note.gnu.gold-ve NOTE 0040
001c 0 0 4
[ 2] .symtab SYMTAB 0060
0018 0018 3 1 8
[ 3] .strtab STRTAB 0078
0001 0 0 1
[ 4] .shstrtab STRTAB 0079
0032 0 0 1
using a partial link or adding a dummy object and using -T script doesn't
change anything. GOLD also doesn't like parsing
SECTIONS {
.debug_info : { HIDDEN(t.c.f0aceea6 = .); t.o(.gnu.lto_.debug_info) }
}
btw. so assigning new symbols doesn't work (fortunately I ended up not
needing that).
This bug makes gold completely unable to handle what will be the new way
to do debuginfo with GCC and -flto (so called early debug with LTO).
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/18837] gold does not handle linker-scripts with inputs
https://sourceware.org/bugzilla/show_bug.cgi?id=18837 --- Comment #1 from Richard Guenther --- > This bug makes gold completely unable to handle what will be the new way > to do debuginfo with GCC and -flto (so called early debug with LTO). which means resorting to objcopy (and thus BFD) for the task of section extraction and renaming. I am not filing another bug right now - gold not accepting a linker script as output from a linker plugin (GNU ld happily does). This is needed to provide minimal-I/O early debug for LTO, picking the early-debug sections from the compile-time objects and linking them to the executable in the final link (need to resort to an incremental link for GNU ld as well due to a bug for now). -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/18836] ld handles .gnu.lto_ prefixed sections oddly, /DISCARD/ semantics unclear
https://sourceware.org/bugzilla/show_bug.cgi?id=18836 --- Comment #1 from Richard Guenther --- This might be related to bug # 18835 - gas setting the 'E' flag on .gnu.lto_ sections (but not when explicitely stating "MS"). Can't find a way to make the script doing the partial link remove that flag. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/18835] GAS complains about incorrect section attributes
https://sourceware.org/bugzilla/show_bug.cgi?id=18835 Richard Guenther changed: What|Removed |Added Status|WAITING |NEW --- Comment #2 from Richard Guenther --- I am storing LTO specific data in them, yes. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/18836] ld handles .gnu.lto_ prefixed sections oddly, /DISCARD/ semantics unclear
https://sourceware.org/bugzilla/show_bug.cgi?id=18836 Richard Guenther changed: What|Removed |Added Status|WAITING |NEW --- Comment #3 from Richard Guenther --- Yes, -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/18836] ld handles .gnu.lto_ prefixed sections oddly, /DISCARD/ semantics unclear
https://sourceware.org/bugzilla/show_bug.cgi?id=18836
--- Comment #4 from Richard Guenther ---
when compiling t.c with -flto -g -ffat-lto-objects you'll get (this is with a
workaround for this bug applied, naming those sections .gnu.debuglto_):
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL
0 0 0
[ 1] .text PROGBITS 0040
000c AX 0 0 1
[ 2] .rela.textRELA 0b30
0018 0018 I 28 1 8
[ 3] .data PROGBITS 004c
WA 0 0 1
[ 4] .bss NOBITS 004c
WA 0 0 1
[ 5] .gnu.debuglto_.de PROGBITS 004c
0035 0 0 1
[ 6] .rela.gnu.debuglt RELA 0b48
0060 0018 I 28 5 8
[ 7] .gnu.debuglto_.de PROGBITS 0081
0037 0 0 1
[ 8] .gnu.debuglto_.de PROGBITS 00b8
0081 0001 MS 0 0 1
[ 9] .gnu.lto_.inline. PROGBITS 0139
0020 E 0 0 1
[10] .gnu.lto_main.186 PROGBITS 0159
0113 E 0 0 1
[11] .gnu.lto_.symbol_ PROGBITS 026c
0026 E 0 0 1
[12] .gnu.lto_.refs.18 PROGBITS 0292
0013 E 0 0 1
[13] .gnu.lto_.decls.1 PROGBITS 02a5
01c4 E 0 0 1
[14] .gnu.lto_.symtab. PROGBITS 0469
0025 E 0 0 1
[15] .gnu.lto_.optsPROGBITS 048e
0094 E 0 0 1
[16] .debug_info PROGBITS 0522
0065 0 0 1
[17] .rela.debug_info RELA 0ba8
00c0 0018 I 2816 8
[18] .debug_abbrev PROGBITS 0587
0048 0 0 1
[19] .debug_arangesPROGBITS 05cf
0030 0 0 1
[20] .rela.debug_arang RELA 0c68
0030 0018 I 2819 8
[21] .debug_line PROGBITS 05ff
0036 0 0 1
[22] .rela.debug_line RELA 0c98
0018 0018 I 2821 8
[23] .comment PROGBITS 0635
002a 0001 MS 0 0 1
[24] .note.GNU-stack PROGBITS 065f
0 0 1
[25] .eh_frame PROGBITS 0660
0038 A 0 0 8
[26] .rela.eh_frameRELA 0cb0
0018 0018 I 2825 8
[27] .shstrtab STRTAB 0698
01ff 0 0 1
[28] .symtab SYMTAB 0898
0270 0018 2923 8
[29] .strtab STRTAB 0b08
0026 0 0 1
the extra sections contain "early" debug-info which gets refered to by
LTRANS unit .debug_info. So it needs to be linked into the final
executable / shared object and there get its mangled section name
"unmangled".
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/18836] ld handles .gnu.lto_ prefixed sections oddly, /DISCARD/ semantics unclear
https://sourceware.org/bugzilla/show_bug.cgi?id=18836 --- Comment #8 from Richard Guenther --- (In reply to H.J. Lu from comment #7) > (In reply to Richard Guenther from comment #4) > > the extra sections contain "early" debug-info which gets refered to by > > LTRANS unit .debug_info. So it needs to be linked into the final > > executable / shared object and there get its mangled section name > > "unmangled". > > I think they should have different section names. I assume that > they can't be merged with normal .debug_xxx sections. On the contrary - they should be merged with the normal .debug_xxx sections emitted in the LTRANS assembly. The early-debug part of an example looks like <0><166>: Abbrev Number: 1 (DW_TAG_compile_unit) <167> DW_AT_producer: (indirect string, offset: 0x163): GNU C11 6.0.0 20150813 (experimental) -mtune=generic -march=x86-64 -g -flto -ffat-lto-objects <16b> DW_AT_language: 12 (ANSI C99) <16c> DW_AT_name: t.c <170> DW_AT_comp_dir: (indirect string, offset: 0x1c1): /abuild/rguenther/trunk-g/gcc <1><174>: Abbrev Number: 2 (DW_TAG_variable) <175> DW_AT_name: a <177> DW_AT_decl_file : 1 <178> DW_AT_decl_line : 1 <179> DW_AT_type: <0x17d> <17d> DW_AT_external: 1 <1><17d>: Abbrev Number: 3 (DW_TAG_base_type) <17e> DW_AT_byte_size : 4 <17f> DW_AT_encoding: 5 (signed) <180> DW_AT_name: int <1><184>: Abbrev Number: 4 (DW_TAG_subprogram) <185> DW_AT_external: 1 <185> DW_AT_name: (indirect string, offset: 0x1df): main <189> DW_AT_decl_file : 1 <18a> DW_AT_decl_line : 2 <18b> DW_AT_type: <0x17d> and the LTRANS unit .debug_info parts refer to it like <0><19b>: Abbrev Number: 1 (DW_TAG_compile_unit) <19c> DW_AT_producer: <19d> DW_AT_language: 12 (ANSI C99) <19e> DW_AT_low_pc : 0x4004e6 <1a6> DW_AT_high_pc : 0xc <1ae> DW_AT_stmt_list : 0xe8 <1><1b2>: Abbrev Number: 2 (DW_TAG_imported_unit) <1b3> DW_AT_import : <0x166> [Abbrev Number: 1] <1><1b7>: Abbrev Number: 3 (DW_TAG_subprogram) <1b8> DW_AT_abstract_origin: <0x184> <1bc> DW_AT_low_pc : 0x4004e6 <1c4> DW_AT_high_pc : 0xc <1cc> DW_AT_frame_base : 1 byte block: 9c(DW_OP_call_frame_cfa) <1ce> DW_AT_GNU_all_call_sites: 1 <1><1ce>: Abbrev Number: 4 (DW_TAG_variable) <1cf> DW_AT_abstract_origin: <0x174> <1d3> DW_AT_location: 9 byte block: 3 3c 10 60 0 0 0 0 0 (DW_OP_addr: 60103c) -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/18836] ld handles .gnu.lto_ prefixed sections oddly, /DISCARD/ semantics unclear
https://sourceware.org/bugzilla/show_bug.cgi?id=18836 --- Comment #13 from Richard Guenther --- The descripion in comment #12 is mostly correct as to the design and its constraints. Slight corrections below. At compile-stage with -flto we generate early-debug information to be consumed by the LTRANS output link. We also generate a separate set of full debug (early+late) for the FAT part of the compile-stage object. Yes, the LTO parts are supposed to be dropped when doing a FAT link, and yes, this was one reason to choose the .gnu.lto_ prefix. As for using a linker script to do the job of extracting and renaming the early-debug sections from the compile-stage objects I was hoping to avoid extra I/O and direct the linker to do that job when it links the LTRANS output objects. GNU ld seems to be happy to take a linker script as linker-plugin output (but we run into that section flag issue at least). Now for the current "workaround" I still use a linker-script and a partial link to do the section copying/renaming (but I still can't get rid of the 'E'xclude flag other than by linking an artifical object with debug-info sections not containing that flag - GNU ld seems to make sure a non-'E'xclude flag prevails if present on any input). Of course doing that partial link separate from the LTRANS object link involves extra I/O and disk-space. Note that "going this far" wasn't very difficult - in fact the approaches simplicity is why I chose it. The approach was also extensively discussed last year in the discussion about early-debug. Now if those implementation issues wouldn't exist... esp. that 'E'xclude flag as puts in on the section drives me crazy. I think I can "fix" the linker script doing the incremental link to also work with gold but it would of course be nice to avoid creating that extra (large) output file. As for using split-dwarf I did not want to start going on the route to effectively "split" the compile-time objects because I am sure we'll run into tooling issues with existing makefiles when we start doing that. Note that an additional constraint on the setup is that incrementally linking the compile-time objects has to work (the kernel does that), not sure what happens to split-dwarf here. split-dwarf is also not generated early but together with late debug. And we'd still need to link the .dwo files back into the executable because split dwarf is not something we can force to all of our users. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/18837] gold does not handle linker-scripts with inputs
https://sourceware.org/bugzilla/show_bug.cgi?id=18837
--- Comment #3 from Richard Guenther ---
(In reply to Cary Coutant from comment #2)
> Let's use PR 18836 for a broader discussion on the topic of LTO and early
> debug.
>
> With the given script, Gnu ld will link t.o as if it had been named on the
> command line. Gold will not; we treat the filenames (with or without
> wildcards) as filters, and gold will not link a file unless it's given on
> the command line or in an INPUT command in a linker script.
>
> In addition, gold does not support partial linker scripts. If you have a
> linker script with a SECTIONS clause, you'll need to provide a complete
> description of the output section, or the final output will almost certainly
> not be usable.
I see. So I'm trying (same input):
SECTIONS {
.debug_info 0 : { *(.gnu.lto_.debug_info*) }
.debug_abbrev 0 : { *(.gnu.lto_.debug_abbrev*) }
.debug_str 0 : { *(.gnu.lto_.debug_str*) }
/DISCARD/ : { *(*) }
}
> ld.gold -o x -T script t.o -r
Segmentation fault
> ld.gold -o x -T script t.o
t.o: plugin needed to handle lto object
ld.gold: internal error in address, at ../../gold/output.h:72
(ok, only the -r link is relevant in the end)
GNU ld:
> ld -o x -T script t.o -r
ld: t.o: plugin needed to handle lto object
> readelf -S x
There are 8 section headers, starting at offset 0x1a0:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL
0 0 0
[ 1] .debug_info PROGBITS 0040
000a E 0 0 1
[ 2] .rela.debug_info RELA 0188
0018 0018 I 6 1 8
[ 3] .debug_abbrev PROGBITS 004a
0001 E 0 0 1
[ 4] .debug_strPROGBITS 004b
001e 0001 MS 0 0 1
[ 5] .shstrtab STRTAB 0069
0045 0 0 1
[ 6] .symtab SYMTAB 00b0
00a8 0018 7 4 8
[ 7] .strtab STRTAB 0158
002a 0 0 1
maybe you can help me writing a linker script that works with GOLD and
a partial link (and also suggest how to drop the 'E'xclude bit during
that link)? golds "error" messages are not exactly helpful :/
Btw, this is gold from the 2.25 branch head.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/18836] ld handles .gnu.lto_ prefixed sections oddly, /DISCARD/ semantics unclear
https://sourceware.org/bugzilla/show_bug.cgi?id=18836 --- Comment #14 from Richard Guenther --- Ok, so let me try to revive the discussion and view the needs from a "need plugin support" angle. What I need is the linker to allow the plugin to claim only a subset of the sections of the input files (those not containing the early debug LTO sections) and direct the linker to feed the remaining sections (or a specially set of marked sections) to the final link, including the possibility to have it "rename" those sections. I am "abusing" the linker script syntax to direct the linker to do the renaming and selecting the set of sections we do not claim. So with that view on the issue how would you suggest to implement this plugin-API wise? (using linker script syntax in a plugin output like the BFD linker already accepts still looks appealing to me) Also when the user passes -g0 at the link command linke we should be able to drop those early debug sections and do not link them. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/19698] [2.26 Regression] mysql qt4 driver plugin not able to open libmysqlclient.so
https://sourceware.org/bugzilla/show_bug.cgi?id=19698 Richard Guenther changed: What|Removed |Added CC||rguenth at gcc dot gnu.org -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19807] [2.26 regression] R_386_GOT32X optimization breaks linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=19807 Richard Guenther changed: What|Removed |Added CC||hjl at sourceware dot org, ||rguenth at gcc dot gnu.org -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19807] [2.26 regression] R_386_GOT32X optimization breaks linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=19807 --- Comment #20 from Richard Guenther --- Hum, so we leave 2.26 broken? -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19827] Wrong relocation with defined symbol in PIE
https://sourceware.org/bugzilla/show_bug.cgi?id=19827 Richard Guenther changed: What|Removed |Added CC||rguenth at gcc dot gnu.org -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20513] New: GNU ld does not ignore symbols defined in sections marked EXCLUDE
https://sourceware.org/bugzilla/show_bug.cgi?id=20513 Bug ID: 20513 Summary: GNU ld does not ignore symbols defined in sections marked EXCLUDE Product: binutils Version: 2.26 Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- When linking two object files, one with a definition of symbol FOO and one with a definition of symbol FOO in a section marked with SHF_EXCLUDE then GNU ld complains about 'multiple definitions of 'FOO''. GOLD handles this situation just fine. t1.s: .text .section.text.startup,"ax",@progbits .p2align 4,,15 .globl main .type main, @function main: t2.s: .text .section.text.startup,"axe",@progbits .p2align 4,,15 .globl main .type main, @function main: (ignore assembler warnings about bogus section attributes) > ld t1.o t2.o -o a.out t2.o: In function `main': (.text.startup+0x0): multiple definition of `main' t1.o:(.text.startup+0x0): first defined here > gold t1.o t2.o -o a.out -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20520] New: ld terminated with signal 11 [Segmentation fault]
https://sourceware.org/bugzilla/show_bug.cgi?id=20520 Bug ID: 20520 Summary: ld terminated with signal 11 [Segmentation fault] Product: binutils Version: 2.26 Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- Created attachment 9478 --> https://sourceware.org/bugzilla/attachment.cgi?id=9478&action=edit object file I get /home/abuild/rguenther/obj-early-lto-debug-g/gcc/testsuite/g++/../../xg++ -B /home/abuild/rguenther/obj-early-lto-debug-g/gcc/testsuite/g++/../../ -B /home/abuild/rguenther/obj-early-lto-debug-g/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs -B /home/abuild/rguenther/obj-early-lto-debug-g/x86_64-pc-linux-gnu/./libitm/ -mtune=generic -march=x86-64 -r -nostdlib -o /tmp/ccdeKWVsdebugobj /tmp/cc5vbUMkdebugobjtem collect2: fatal error: ld terminated with signal 11 [Segmentation fault] compilation terminated. on arguably invalid input (a GROUP section referencing SHT_NULL sections). I expect a diagnostic instead. Object file attached. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20882] New: GNU ld discards sections required by relocations in .debug_info with --gc-sections
https://sourceware.org/bugzilla/show_bug.cgi?id=20882 Bug ID: 20882 Summary: GNU ld discards sections required by relocations in .debug_info with --gc-sections Product: binutils Version: 2.27 Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- > cat t1.s .text .globl main .type main, @function main: ret .section.debug_info,"",@progbits .long t.c.4903c230+2 > cat t2.s .section.debug_info,"",@progbits .hidden t.c.4903c230 .globl t.c.4903c230 t.c.4903c230: .long 0x28 > as -o t1.o t1.s > as -o t2.o t2.s > ld -o t.o t1.o t2.o --gc-sections --entry=main > readelf -S t.o | grep debug_info [ 2] .debug_info PROGBITS 0079 > readelf -x 2 t.o Hex dump of section '.debug_info': 0x while gold is fine: > gold -o t.o t1.o t2.o --gc-sections --entry=main > readelf -S t.o | grep debug_info [ 2] .debug_info PROGBITS 0079 > readelf -x 2 t.o Hex dump of section '.debug_info': 0x 0600 2800 (... -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/21191] New: objcopy --only-keep-debug creates non-monotonically increasing section offsets
https://sourceware.org/bugzilla/show_bug.cgi?id=21191
Bug ID: 21191
Summary: objcopy --only-keep-debug creates non-monotonically
increasing section offsets
Product: binutils
Version: 2.29 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
int main()
{
}
> gcc t.c -g
> objcopy --only-keep-debug a.out a.out.debug
> readelf -S a.out
There are 39 section headers, starting at offset 0x2788:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL
0 0 0
[ 1] .interp PROGBITS 00400238 0238
001c A 0 0 1
[ 2] .note.ABI-tag NOTE 00400254 0254
0020 A 0 0 4
[ 3] .note.gnu.build-i NOTE 00400274 0274
0024 A 0 0 4
[ 4] .hash HASH 00400298 0298
0018 0004 A 6 0 8
[ 5] .gnu.hash GNU_HASH 004002b0 02b0
001c A 6 0 8
[ 6] .dynsym DYNSYM 004002d0 02d0
...
[25] .got.plt PROGBITS 00601000 1000
0020 0008 WA 0 0 8
[26] .data PROGBITS 00601020 1020
0010 WA 0 0 8
[27] .bss NOBITS 00601030 1030
0008 WA 0 0 1
[28] .comment PROGBITS 1030
0018 0001 MS 0 0 1
[29] .debug_arangesPROGBITS 1050
0130 0 0 16
[30] .debug_info PROGBITS 1180
036d 0 0 1
> readelf -S a.out.debug
There are 39 section headers, starting at offset 0x19e8:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL
0 0 0
[ 1] .interp NOBITS 00400238 0238
001c A 0 0 1
[ 2] .note.ABI-tag NOTE 00400254 0254
0020 A 0 0 4
[ 3] .note.gnu.build-i NOTE 00400274 0274
0024 A 0 0 4
[ 4] .hash NOBITS 00400298 0298
0018 0004 A 6 0 8
[ 5] .gnu.hash NOBITS 004002b0 0298
001c A 6 0 8
[ 6] .dynsym NOBITS 004002d0 0298
...
[25] .got.plt NOBITS 00601000 0e00
0020 0008 WA 0 0 8
[26] .data NOBITS 00601020 0e00
0010 WA 0 0 8
[27] .bss NOBITS 00601030 0e00
0008 WA 0 0 1
[28] .comment PROGBITS 0298
0018 0001 MS 0 0 1
[29] .debug_arangesPROGBITS 02b0
0130 0 0 16
[30] .debug_info PROGBITS 03e0
036d 0 0 1
notice how section 28 and 29 start before section 27.
eu-strip gets this correct.
checked 2.27 and git HEAD.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/21191] objcopy --only-keep-debug creates non-monotonically increasing section offsets
https://sourceware.org/bugzilla/show_bug.cgi?id=21191 --- Comment #2 from Richard Biener --- (In reply to Alan Modra from comment #1) > File offset for a SHT_NOBITS section is irrelevant. > > Note that this "bug" can also occur with ld. You don't want to waste space > in the output file with padding for NOBITS sections, but glibc ld.so checks > that p_vaddr and p_offset agree modulo pagesize, even for segments with > p_filesz zero. Thus p_offset needs to be adjusted to pacify glibc. > p_offset is derived from sh_offset so we adjust sh_offset too. > > We could zero all the NOBITS sh_offset values for this specific case of > --only-keep-debug, but I don't see the point given that ld will create out > of order sh_offset. > > What tool was complaining about sh_offset? Fix it please. It is DWZ complaining, I've sent a fix to Jakub zeroing sh_offset (and ignoring NOBITS sections for its sanity checks). He didn't like it too much but we'll see. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/21193] New: objcopy --add-gnu-debuglink adds .gnu_debuglink with ALIGN 1
https://sourceware.org/bugzilla/show_bug.cgi?id=21193
Bug ID: 21193
Summary: objcopy --add-gnu-debuglink adds .gnu_debuglink with
ALIGN 1
Product: binutils
Version: 2.29 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
int main(){}
> gcc t.c -g
> objcopy --add-gnu-debuglink=a.out.debug a.out
> readelf -S a.out
...
[36] .gnu_debuglinkPROGBITS 1d90
0010 0 0 1
you can see ALIGN 1. eu-strip -g creates it with ALIGN 4:
[31] .gnu_debuglinkPROGBITS 1834
0010 0 0 4
and this is what RPMs sepdebugcrcfix expects:
const uint8_t *zerop = memchr (data->d_buf, '\0', data->d_size);
const uint8_t *crcp = (zerop == NULL
? NULL
: (const uint8_t *) ((uintptr_t) (zerop + 1 + 3)
& -4));
if (crcp + 4 != (uint8_t *) data->d_buf + data->d_size)
{
raise (SIGSTOP);
error (0, 0, _("invalid format of section \"%s\" # %zu in \"%s\""),
scnname, elf_ndxscn (scn), fname);
continue;
}
appearantly also objcopy pads the string part to 4 bytes but the above also
requires alignment (on the libelf representation which honors ALIGN).
I will fix the tool but it would be nice to check the "specification" of
.gnu_debuglink as if that padding implicitely assumes alignment of the
section (why would we pad otherwise?).
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21333] New: s390x GNU as uses symbol relocations for .debug_info
https://sourceware.org/bugzilla/show_bug.cgi?id=21333 Bug ID: 21333 Summary: s390x GNU as uses symbol relocations for .debug_info Product: binutils Version: 2.27 Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- I see Relocation section '.rela.debug_info' at offset 0xf460 contains 852 entries: Offset Info Type Sym. ValueSym. Name + Addend 0006 001d0004 R_390_32 .debug_abbrev + 0 000c 006d0004 R_390_32 0d9a .LASF336 + 0 0011 006e0004 R_390_32 001c .LASF337 + 0 0015 006f0004 R_390_32 069a .LASF338 + 0 0019 0024 R_390_32 .debug_ranges + 570 0025 00210004 R_390_32 .debug_line + 0 002a 0074 R_390_32 003d .LASF8 + 0 003c 00710004 R_390_32 05ab .LASF0 + 0 004a 00720004 R_390_32 0260 .LASF1 + 0 0051 00730004 R_390_32 06f3 .LASF2 + 0 0058 00740004 R_390_32 035b .LASF3 + 0 instead of 0058 00740004 R_390_32 .debug_str + 35b that needlessly increases .symtab size plus it confuses elflint (tools/21332). -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21333] s390x GNU as uses symbol relocations for .debug_info
https://sourceware.org/bugzilla/show_bug.cgi?id=21333 Richard Biener changed: What|Removed |Added Target||s390x -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/21382] --as-needed cannot be combined with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=21382 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-04-13 CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- To clarify the linker resolution is bougs: 1 m.o 3 165 e2668d19ae58a8ab PREVAILING_DEF_IRONLY x 180 e2668d19ae58a8ab PREVAILING_DEF main 185 e2668d19ae58a8ab UNDEF y but x should be PREVAILING_DEF_IRONLY_EXP as gold correctly says. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20882] GNU ld discards sections required by relocations in .debug_info with --gc-sections
https://sourceware.org/bugzilla/show_bug.cgi?id=20882 Richard Biener changed: What|Removed |Added CC||amodra at gmail dot com, ||hjl.tools at gmail dot com Version|2.27|2.29 (HEAD) --- Comment #1 from Richard Biener --- Reconfirmed with 2.28 and with master. This breaks the debuginfo in the final link when doing early LTO debug objects. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20882] GNU ld discards sections required by relocations in .debug_info with --gc-sections
https://sourceware.org/bugzilla/show_bug.cgi?id=20882 Richard Biener changed: What|Removed |Added Blocks||21494 Referenced Bugs: https://sourceware.org/bugzilla/show_bug.cgi?id=21494 [Bug 21494] segfault in find_partial_die_in_comp_unit -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/16177] R_ARM_COPY reloc generated for reference in writable section
https://sourceware.org/bugzilla/show_bug.cgi?id=16177
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #15 from Richard Biener ---
It also seems to cause
extern void *stderr;
int main()
{
volatile void *x = stderr;
}
failing to link with
/usr/lib/gcc/armv7hl-suse-linux-gnueabi/12/../../../../armv7hl-suse-linux-gnueabi/bin/ld:
/tmp/ccyhHiPR.o(.text+0x8): unresolvable R_ARM_MOVW_ABS_NC relocation against
symbol `stderr@@GLIBC_2.4'
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/30577] New: No way to prevent BFD plugin auto-loading
https://sourceware.org/bugzilla/show_bug.cgi?id=30577 Bug ID: 30577 Summary: No way to prevent BFD plugin auto-loading Product: binutils Version: 2.41 (HEAD) Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- There is no documented way to disable plugin auto-loading from BFD for tools like NM and AR but this also affects LD. By inspecting the source I can see that for AR at least --plugin="" works but there is no --no-plugin or any way to for example override the search directory in the environment. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30577] No way to prevent BFD plugin auto-loading
https://sourceware.org/bugzilla/show_bug.cgi?id=30577 --- Comment #2 from Richard Biener --- (In reply to Nick Clifton from comment #1) > (In reply to Richard Biener from comment #0) > Hi Richard, > > > There is no documented way to disable plugin auto-loading from BFD for tools > > like NM and AR but this also affects LD. > > True... > > > By inspecting the source I can see that for AR at least --plugin="" works > > This should also work for NM, but not for LD. > > > but there is no --no-plugin > > I am tempted to suggest that we document --plugin="" as doing this, > and make sure that LD supports it as well. That would mean the least > disruption to the sources. (Except see below for a different approach...) I guess that's a good idea independently of what we do in addition to that. > > or any way to for example override the > > search directory in the environment. > > Again true. I dislike having a hard-coded directory in the sources, > so having a way to set it dynamically would be good. I am very wary > of using an environment variable to do this however as it makes > debugging plugin problems very hard. Very few bug reports include > a list of environment variables, and it is easy to imagine that a > user unfamiliar with the binutils plugin code would not even realise > that the problem might be due to a plugin being loaded from an > unexpected location because of an environment variable. Yeah - the issue that made me report this is exactly a bugreport about NM giving odd complaints on a specific archive where the issue was some unrelated installed (buggy) plugin in the BFD auto-load directory ... Still having an environment one can set allows central control to have customer scripts "isolated" from stuff installed in the auto-load directory. At the same time it can introduce these issues of course. > So instead I would suggest adding a --plugin-dir= option which > could be used to override the builtin default. It could even support > --plugin-dir=NUL to stop any auto-loading and --plugin-dir=DEFAULT > to reset the search directory back to the builtin default. > > What do you think ? --plugin-dir sounds useful (as does the environment), since we implement "first found and matching wins" a --plugin-add-dir is probably less useful (you'd expect a match in the specified dir). I think it would be nice to be able to set the default behavior to --plugin-dir=NUL while still enabling plugin support in general. (not sure about configuring a different non-NUL default) Clearly a documented and consistently working --plugin="" is the most important thing. > Cheers > Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/24406] -Wl,--wrap= incompatible with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=24406
Richard Biener changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED|REOPENED
CC||rguenth at gcc dot gnu.org
--- Comment #10 from Richard Biener ---
Just to note with BFD ld from 2.41.0 I see
1
a-t.o 3
194 b4b00c6ef6ad050b PREVAILING_DEF_IRONLY __wrap_cook
198 b4b00c6ef6ad050b PREVAILING_DEF main
214 b4b00c6ef6ad050b RESOLVED_IR cook
when building
int cook(void);
int __wrap_cook(void)
{
return 0;
}
int main()
{
if (cook () == -1)
__builtin_abort ();
return 0;
}
but an LTO link fails with
/usr/lib64/gcc/x86_64-suse-linux/13/../../../../x86_64-suse-linux/bin/ld:
./a.ltrans0.ltrans.o: in function `main':
:(.text+0x10): undefined reference to `__wrap_cook'
GCC emits at LTRANS stage
.file ""
.text
.type __wrap_cook, @function
__wrap_cook:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
movl$0, %eax
popq%rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size __wrap_cook, .-__wrap_cook
.globl main
.type main, @function
main:
.LFB1:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
callcook
cmpl$-1, %eax
jne .L4
callabort
.L4:
movl$0, %eax
popq%rbp
.cfi_def_cfa 7, 8
ret
which I think should be OK. The main difference is that __wrap_cook is
an internal symbol but that's OK since the linker told GCC
194 b4b00c6ef6ad050b PREVAILING_DEF_IRONLY __wrap_cook
it probably should have used
194 b4b00c6ef6ad050b PREVAILING_DEF __wrap_cook
instead.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/25389] - -Wl,--wrap -fuse-ld=bfd not supported with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=25389 Bug 25389 depends on bug 24406, which changed state. Bug 24406 Summary: -Wl,--wrap= incompatible with -flto https://sourceware.org/bugzilla/show_bug.cgi?id=24406 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31956] -Wl,--wrap broken with LTO?
https://sourceware.org/bugzilla/show_bug.cgi?id=31956
--- Comment #16 from Richard Biener ---
(In reply to H.J. Lu from comment #15)
> (In reply to Sam James from comment #14)
> > Sorry, one more question: richi's comment at
> > https://sourceware.org/bugzilla/show_bug.cgi?id=24406#c10 made me wonder.
> >
> > If I modify https://sourceware.org/bugzilla/show_bug.cgi?id=31956#c6 to have
> > noipa or noinline for buffer_write_file, the status is the same (just the
> > hashes change):
> > ```
> > --- a/tls_crypt_testdriver.res
> > +++ b/tls_crypt_testdriver.res
> > @@ -1,11 +1,11 @@
> > 3
> > tls_crypt_testdriver-tls_crypt_testdriver-test_tls_crypt.o 4
> > 194 [-648e684371714953-]{+cc01d97532c69e30+} PREVAILING_DEF
> > __wrap_buffer_write_file
> > 196 [-648e684371714953-]{+cc01d97532c69e30+} PREVAILING_DEF_IRONLY
> > test_tls_crypt_v2_write_server_key_file
> > 200 [-648e684371714953-]{+cc01d97532c69e30+} PREVAILING_DEF main
> > 220 [-648e684371714953-]{+cc01d97532c69e30+} RESOLVED_IR write_pem_key_file
> > tls_crypt_testdriver-tls_crypt_testdriver-buffer.o 1
> > 202 [-cdf5ef9747252c01-]{+a5f22943180ec17d+} PREVAILING_DEF_IRONLY
> > buffer_write_file
> > tls_crypt_testdriver-tls_crypt_testdriver-crypto.o 2
> > 204 [-a3abc8ef456eac42-]{+e3adb2154884903b+} PREVAILING_DEF_IRONLY
> > write_pem_key_file
> > 207 [-a3abc8ef456eac42-]{+e3adb2154884903b+} RESOLVED_IR buffer_write_file
> > ```
> >
> > should it be PREVAILING_DEF instead for buffer_write_file, not
> > PREVAILING_DEF_IRONLY if I've forced a real definition?
>
> No, since there are non-IR references. If there are non-IR references,
> PREVAILING_DEF will be generated.
But the linker itself, via --wrap will create a reference to the symbol.
With PREVAILING_DEF_IRONLY the compiler is free to elide the symbol,
so IMO that's invalid even if the linkers reference will later be "internal".
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/20882] GNU ld discards sections required by relocations in .debug_info with --gc-sections
https://sourceware.org/bugzilla/show_bug.cgi?id=20882 --- Comment #15 from Richard Biener --- The original testcase is fixed tho. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20882] GNU ld discards sections required by relocations in .debug_info with --gc-sections
https://sourceware.org/bugzilla/show_bug.cgi?id=20882
Richard Biener changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #14 from Richard Biener ---
The issue persists in 2.29.1 at least.
Index: libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp
===
--- libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp
(revision 258481)
+++ libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp
(working copy)
@@ -50,7 +50,7 @@ gdb-dg-runtest [lsort [glob $srcdir/$sub
if { [check_effective_target_lto] } {
append cxxflags " -flto"
# work around sourceware.org 20882
- regsub {^(.*)-Wl,--gc-sections(.*)$} $cxxldflags {\1\2} cxxldflags
+ #regsub {^(.*)-Wl,--gc-sections(.*)$} $cxxldflags {\1\2} cxxldflags
gdb-dg-runtest [lsort [glob $srcdir/$subdir/*.cc]] \
"" "$DEFAULT_CXXFLAGS -flto $PCH_CXXFLAGS"
}
shows the issue in a gcc tree with
> make check-target-libstdc++-v3 RUNTESTFLAGS="prettyprinters.exp"
you then get UNSUPPORTED tests with complaints like
spawn gdb -nx -nw -quiet -batch -x cxx11.gdb^M
Dwarf Error: could not find abbrev number 151 [in module
/tmp/obj/x86_64-pc-linux-gnu/libstdc++-v3/testsuite/cxx11.exe]^M
skipping: Dwarf Error: could not find abbrev number 151 [in module
/tmp/obj/x86_64-pc-linux-gnu/libstdc++-v3/testsuite/cxx11.exe]^M
cxx11.gdb:5: Error in sourced command file:^M
No symbol table is loaded. Use the "file" command.^M
skipping: cxx11.gdb:5: Error in sourced command file:^M
skipping: No symbol table is loaded. Use the "file" command.^M
UNSUPPORTED: libstdc++-prettyprinters/cxx11.cc
See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84847
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22981] New: ld: BFD (GNU Binutils) 2.30.0.20180226-0 assertion fail ../../bfd/elf.c:3564
https://sourceware.org/bugzilla/show_bug.cgi?id=22981 Bug ID: 22981 Summary: ld: BFD (GNU Binutils) 2.30.0.20180226-0 assertion fail ../../bfd/elf.c:3564 Product: binutils Version: 2.30 Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- > echo '#define FOO BAR' > t.c > gcc-7 t.c -g3 -c > ld -r -s t.o -o tx.o ld: BFD (GNU Binutils; devel:gcc / openSUSE_Leap_42.2) 2.30.0.20180226-0 assertion fail ../../bfd/elf.c:3564 ld: BFD (GNU Binutils; devel:gcc / openSUSE_Leap_42.2) 2.30.0.20180226-0 assertion fail ../../bfd/elf.c:3564 looks like ld -s doesn't like [ 1] .groupGROUP 0040 000c 0004 2114 4 [ 2] .groupGROUP 004c 000c 0004 2115 4 [11] .debug_macro PROGBITS 00ac 0020 0 0 1 [12] .rela.debug_macro RELA 3258 0060 0018 I 2111 8 [13] .debug_macro PROGBITS 00cc 07ea G 0 0 1 [14] .rela.debug_macro RELA 32b8 1f98 0018 IG 2113 8 [15] .debug_macro PROGBITS 08b6 0022 G 0 0 1 [16] .rela.debug_macro RELA 5250 COMDAT group section [1] `.group' [wm4.0.fade8ac3fef0ae2a926ae61f60e6e0e5] contains 2 sections: [Index]Name [ 13] .debug_macro [ 14] .rela.debug_macro COMDAT group section [2] `.group' [wm4.stdcpredef.h.19.52894a18705f0664f8da17e99c6c0a93] contains 2 sections: [Index]Name [ 15] .debug_macro [ 16] .rela.debug_macro -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22836] "-r -s" doesn't work with -g3 using GCC 7
https://sourceware.org/bugzilla/show_bug.cgi?id=22836 --- Comment #10 from Richard Biener --- Can this be backported? -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22983] --dynamic-list=export is ignored in presence of -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=22983 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23079] Multiple PREVAILING_DEF_IRONLY for a same symbol in an archive
https://sourceware.org/bugzilla/show_bug.cgi?id=23079 Richard Biener changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #1 from Richard Biener --- If you make viewport non-common (-fno-common), does that fix it as well? -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23425] New: unresolved symbol diagnostic ends up calling find_abstract_instance with relocations applied causing spurious 'DWARF error: invalid abstract instance DIE ref'
https://sourceware.org/bugzilla/show_bug.cgi?id=23425
Bug ID: 23425
Summary: unresolved symbol diagnostic ends up calling
find_abstract_instance with relocations applied
causing spurious 'DWARF error: invalid abstract
instance DIE ref'
Product: binutils
Version: 2.30
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
Backtrace from the 2.31 branch:
#0 _bfd_error_handler (
fmt=0x690150 "DWARF error: invalid abstract instance DIE ref")
at /space/rguenther/src/binutils-gdb/bfd/bfd.c:1177
#1 0x004c6214 in find_abstract_instance (unit=0x7056d8,
orig_info_ptr=0x76df90 "\004> ", attr_ptr=0x7fffcd10, pname=0x770f18,
is_linkage=0x770f14, filename_ptr=0x770f00, linenumber_ptr=0x770f0c)
at /space/rguenther/src/binutils-gdb/bfd/dwarf2.c:2843
#2 0x004c6cbe in scan_unit_for_symbols (unit=0x7056d8)
at /space/rguenther/src/binutils-gdb/bfd/dwarf2.c:3169
#3 0x004c789f in comp_unit_find_nearest_line (unit=0x7056d8,
addr=4198435, filename_ptr=0x7fffd018, function_ptr=0x7fffce70,
linenumber_ptr=0x7fffd00c, discriminator_ptr=0x0, stash=0x7054a0)
at /space/rguenther/src/binutils-gdb/bfd/dwarf2.c:3616
#4 0x004c9975 in _bfd_dwarf2_find_nearest_line (abfd=0x6fe880,
symbols=0x705270, symbol=0x0, section=0x700dd0, offset=35,
filename_ptr=0x7fffd018, functionname_ptr=0x7fffd010,
linenumber_ptr=0x7fffd00c, discriminator_ptr=0x0,
debug_sections=0x68f9a0 , addr_size=4,
pinfo=0x700090) at /space/rguenther/src/binutils-gdb/bfd/dwarf2.c:4807
#5 0x00491807 in _bfd_elf_find_nearest_line (abfd=0x6fe880,
symbols=0x705270, section=0x700dd0, offset=35,
filename_ptr=0x7fffd018, functionname_ptr=0x7fffd010,
line_ptr=0x7fffd00c, discriminator_ptr=0x0)
at /space/rguenther/src/binutils-gdb/bfd/elf.c:8752
#6 0x0042574f in vfinfo (fp=0x77bd2080 <_IO_2_1_stderr_>,
fmt=0x555b18 ": undefined reference to `%pT'\n", ap=0x7fffd208,
is_warning=1) at /space/rguenther/src/binutils-gdb/ld/ldmisc.c:350
#7 0x0042643f in einfo (
fmt=0x555b10 "%X%P: %C: undefined reference to `%pT'\n")
at /space/rguenther/src/binutils-gdb/ld/ldmisc.c:626
#8 0x0041fd50 in undefined_symbol (info=0x6ced80 ,
name=0x70506c "_ZNSsC1Ev", abfd=0x6fe880, section=0x700dd0, address=35,
error=1) at /space/rguenther/src/binutils-gdb/ld/ldmain.c:1346
#9 0x0046ad3d in elf_x86_64_relocate_section (output_bfd=0x6e7210,
info=0x6ced80 , input_bfd=0x6fe880, input_section=0x700dd0,
contents=0x701f60 "UH\211", ,
relocs=0x7050f8, local_syms=0x6f32b0, local_sections=0x76dd60)
at /space/rguenther/src/binutils-gdb/bfd/elf64-x86-64.c:2483
The code says it only handles refs within the same file but the guard
for this, a zero die_ref, doesn't work after applying relocations to
.debug_info and this function ends up being called from the unresolved
symbol diagnostic causing a spurious DWARF error to be reported.
/* We only support DW_FORM_ref_addr within the same file, so
any relocations should be resolved already. Check this by
testing for a zero die_ref; There can't be a valid reference
to the header of a .debug_info section.
DW_FORM_ref_addr is an offset relative to .debug_info.
Normally when using the GNU linker this is accomplished by
emitting a symbolic reference to a label, because .debug_info
sections are linked at zero. When there are multiple section
groups containing .debug_info, as there might be in a
relocatable object file, it would be reasonable to assume that
a symbolic reference to a label in any .debug_info section
might be used. Since we lay out multiple .debug_info
sections at non-zero VMAs (see place_sections), and read
them contiguously into stash->info_ptr_memory, that means
the reference is relative to stash->info_ptr_memory. */
size_t total;
info_ptr = unit->stash->info_ptr_memory;
info_ptr_end = unit->stash->info_ptr_end;
total = info_ptr_end - info_ptr;
if (!die_ref || die_ref >= total)
{
_bfd_error_handler
(_("DWARF error: invalid abstract instance DIE ref"));
bfd_set_error (bfd_error_bad_value);
return FALSE;
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23425] unresolved symbol diagnostic ends up calling find_abstract_instance with relocations applied causing spurious 'DWARF error: invalid abstract instance DIE ref'
https://sourceware.org/bugzilla/show_bug.cgi?id=23425 --- Comment #1 from Richard Biener --- Created attachment 11143 --> https://sourceware.org/bugzilla/attachment.cgi?id=11143&action=edit testcase To reproduce do > ./ld-new -o a.out ccELcIbzdebugobjtem cccLlhS9debugobjtem > ccqD9BbN.ltrans0.ltrans.o ./ld-new: warning: cannot find entry symbol _start; defaulting to 00401000 ./ld-new: ./ld-new: DWARF error: invalid abstract instance DIE ref ccqD9BbN.ltrans0.ltrans.o: in function `strerrno(int)': :(.text+0x23): undefined reference to `std::basic_string, std::allocator >::basic_string()' ./ld-new: :(.text+0x3b): undefined reference to `strerrno_s(char*, unsigned long, int)' ./ld-new: :(.text+0x55): undefined reference to `std::string::operator=(char const*)' ./ld-new: :(.text+0x68): undefined reference to `std::string::operator+=(char const*)' ./ld-new: :(.text+0x7d): undefined reference to `std::string::operator=(char const*)' ./ld-new: :(.text+0x8e): undefined reference to `std::basic_string, std::allocator >::~basic_string()' ./ld-new: :(.text+0x99): undefined reference to `_Unwind_Resume' ./ld-new: ccqD9BbN.ltrans0.ltrans.o:(.eh_frame+0x4b): undefined reference to `__gcc_personality_v0' -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23425] unresolved symbol diagnostic ends up calling find_abstract_instance with relocations applied causing spurious 'DWARF error: invalid abstract instance DIE ref'
https://sourceware.org/bugzilla/show_bug.cgi?id=23425 --- Comment #2 from Richard Biener --- A similar issue seems to happen with .debug_str lookups: /usr/bin/x86_64-linux-gnu-ld: Dwarf Error: Offset (1678049557) greater than or equal to .debug_str size (5846). ... later undefined reference diagnostic but I do not have a testcase to verify that. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/24464] rx: Fatal error: Infinite loop encountered whilst attempting to compute the addresses of symbols in section P
https://sourceware.org/bugzilla/show_bug.cgi?id=24464 Richard Biener changed: What|Removed |Added Target||rx-elf CC||rguenth at gcc dot gnu.org Version|unspecified |2.31 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/24464] rx: Fatal error: Infinite loop encountered whilst attempting to compute the addresses of symbols in section P
https://sourceware.org/bugzilla/show_bug.cgi?id=24464 --- Comment #1 from Richard Biener --- Btw, passing -relax to the assembler makes it assemble OK, producing Disassembly of section P: <_copy>: 0: ef 2e mov.l r2, r14 2: 61 0e cmp #0, r14 4: ef 12 mov.l r1, r2 6: 21 0a bne.b 10 <.L7> 8: 02 rts 9: fd 70 40 00 00 00 80nop ; max #0x8000, r0 0010 <.L7>: 10: ef 31 mov.l r3, r1 12: ef e3 mov.l r14, r3 14: 7f 8f smovf 16: 02 rts 17: 03 nop likewise writing bne.b instead of bne in the assembly. That's odd since w/o the .balign and without -relax gas produces the same: <_copy>: 0: ef 2e mov.l r2, r14 2: 61 0e cmp #0, r14 4: ef 12 mov.l r1, r2 6: 21 03 bne.b 9 <_copy+0x9> 8: 02 rts 9: ef 31 mov.l r3, r1 b: ef e3 mov.l r14, r3 d: 7f 8f smovf f: 02 rts -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/24464] rx: Fatal error: Infinite loop encountered whilst attempting to compute the addresses of symbols in section P
https://sourceware.org/bugzilla/show_bug.cgi?id=24464 Richard Biener changed: What|Removed |Added CC||dj at redhat dot com, ||nickc at redhat dot com -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/24623] DWARF errors
https://sourceware.org/bugzilla/show_bug.cgi?id=24623 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/25593] New: --as-needed breaks DT_NEEDED order with linker plugin
https://sourceware.org/bugzilla/show_bug.cgi?id=25593
Bug ID: 25593
Summary: --as-needed breaks DT_NEEDED order with linker plugin
Product: binutils
Version: 2.33
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
echo 'void foo() {}' > libt.c
echo 'void foo(); int main() { foo(); }' > t.c
gcc -o libt.so -shared libt.c -Wl,-soname,libt.so -fPIC -flto
gcc -c t.c -flto
gcc -Wl,--as-needed t.o libt.so
readelf -d a.out | grep NEEDED
0x0001 (NEEDED) Shared library: [libc.so.6]
0x0001 (NEEDED) Shared library: [libt.so]
but libc has to come last so the program can use RTLD_NEXT to arrive at
symbols from libc. Works fine with gold.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/25593] --as-needed breaks DT_NEEDED order with linker plugin
https://sourceware.org/bugzilla/show_bug.cgi?id=25593 Richard Biener changed: What|Removed |Added CC||hjl.tools at gmail dot com See Also||https://bugzilla.suse.com/s ||how_bug.cgi?id=1163744 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26060] New: When configured without a specific target 'strip' corrupts the first archive member
https://sourceware.org/bugzilla/show_bug.cgi?id=26060 Bug ID: 26060 Summary: When configured without a specific target 'strip' corrupts the first archive member Product: binutils Version: 2.32 Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- When you configure binutils for example without support for the avr target then invoking strip on an archive does > strip test.a strip: Unable to recognise the format of the input file `test.a(f7_c_get_s64.o)' note it fails to print the same message for the first archive member which is then corrupted, diff of the ELF header: --- aa 2020-05-29 09:35:53.120535838 +0200 +++ bb 2020-05-29 09:35:48.240467762 +0200 @@ -6,18 +6,18 @@ OS/ABI:UNIX - System V ABI Version: 0 Type: REL (Relocatable file) - Machine: Atmel AVR 8-bit microcontroller + Machine: None Version: 0x1 Entry point address: 0x0 Start of program headers: 0 (bytes into file) - Start of section headers: 568 (bytes into file) the header of the second archive member is OK. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26060] When configured without a specific target 'strip' corrupts the first archive member
https://sourceware.org/bugzilla/show_bug.cgi?id=26060 --- Comment #1 from Richard Biener --- Created attachment 12576 --> https://sourceware.org/bugzilla/attachment.cgi?id=12576&action=edit test archive with two members in AVR format test archive -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26060] When configured without a specific target 'strip' corrupts the first archive member
https://sourceware.org/bugzilla/show_bug.cgi?id=26060 Richard Biener changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #3 from Richard Biener --- Huh, interesting. Did you bisect it to that commit? I would not have thought a memory leak causes this kind of behavior. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/19962] R_ARM_COPY relocation generated with -znocopyreloc
https://sourceware.org/bugzilla/show_bug.cgi?id=19962 Richard Biener changed: What|Removed |Added Target||arm, aarch64 CC||rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- It's reported that the same issue exists for aarch64 (and Nicks patch is meanwhile on master but only addresses arm). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27441] Small inconsistency in between gold and bfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27441 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #9 from Richard Biener --- Note with -flto it is difficult to argue about the order of "source" objects and library references with -l, say you'd have gcc t.c -lpthread t2.c -flto gcc can then, via -flto, happily produce only a single "real" ltrans object. Of course via the plugin it should get the original refs of t.c and t2.c in the correct order but my understanding is that BFD re-scans objects (because GCC is also prone to introduce new refs, for example to memcpy, libm functions or libgcc provided functions). But "placement" of the generated ltrans object on the linker command-line is not well-defined since the plugin merely provides LD with extra objects it should link. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27587] New: BFD (and gold) DWARF reader choke on DWARF5 as generated by LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=27587
Bug ID: 27587
Summary: BFD (and gold) DWARF reader choke on DWARF5 as
generated by LTO
Product: binutils
Version: 2.35.1
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
When BFD ld or gold emit diagnostics they seem to try parse the DWARF in the
object files but they somehow choke if the objects are generated with -gdwarf-5
as opposed to -gdwarf-4 and contain references to abstract DIEs in other CUs
(residing in other object files).
Like so:
> ./xgcc -B. -gdwarf-5 -Werror -O2 t.i -flto -g
> /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld:
> /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld:
> DWARF error: invalid abstract instance DIE ref
/tmp/cch4tY4L.ltrans0.ltrans.o: in function `main':
:(.text.startup+0x1): undefined reference to `stack_size'
collect2: error: ld returned 1 exit status
where t.i is
char main_prompt[1];
int sprintf(char *, char *, ...);
void stack_size();
void main() { sprintf(main_prompt, "", stack_size); }
or simply invoking ld with the object files:
> ld -o a.out a-t.o.debug.temp.o ./a.ltrans0.ltrans.o
ld: warning: cannot find entry symbol _start; defaulting to 004000f0
ld: ld: DWARF error: invalid abstract instance DIE ref
./a.ltrans0.ltrans.o: in function `main':
:(.text.startup+0x1): undefined reference to `stack_size'
ld: :(.text.startup+0x12): undefined reference to `sprintf'
fixing the error by providing a stack_size definition in x.o:
> ld -o a.out a-t.o.debug.temp.o ./a.ltrans0.ltrans.o x.o -lc
ld: warning: cannot find entry symbol _start; defaulting to 004002c0
and the issue is gone.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/27587] BFD (and gold) DWARF reader choke on DWARF5 as generated by LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=27587 --- Comment #1 from Richard Biener --- Created attachment 13315 --> https://sourceware.org/bugzilla/attachment.cgi?id=13315&action=edit a.ltrans0.ltrans.o -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27587] BFD (and gold) DWARF reader choke on DWARF5 as generated by LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=27587 --- Comment #2 from Richard Biener --- Created attachment 13316 --> https://sourceware.org/bugzilla/attachment.cgi?id=13316&action=edit a-t.o.debug.temp.o -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27587] BFD (and gold) DWARF reader choke on DWARF5 as generated by LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=27587 Richard Biener changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=99606 Target||x86_64-*-* -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27587] BFD (and gold) DWARF reader choke on DWARF5 as generated by LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=27587 --- Comment #10 from Richard Biener --- (In reply to H.J. Lu from comment #9) > Fixed for 2.37. Can we have this backported to all active branches please? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28149] debug info with wrong file association
https://sourceware.org/bugzilla/show_bug.cgi?id=28149 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- Note it is also undesirable to reference the (possibly temporary) filename of the assembler file as a "fix", even though that would seem to be the fix if the compiler asked the assembler to produce line info. It's the behavior you get when assembling without any .file directive. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/12388] New: icf_test.sh and icf_safe_test.sh fail
http://sourceware.org/bugzilla/show_bug.cgi?id=12388 Summary: icf_test.sh and icf_safe_test.sh fail Product: binutils Version: 2.21 Status: NEW Severity: normal Priority: P2 Component: gold AssignedTo: i...@airs.com ReportedBy: rgue...@gcc.gnu.org Created attachment 5190 --> http://sourceware.org/bugzilla/attachment.cgi?id=5190 testcase on x86_64-suse-linux I see FAIL: icf_test.sh PASS: icf_keep_unique_test.sh FAIL: icf_safe_test.sh PASS: icf_safe_so_test.sh even though the respective functions in icf_test.o seem to be the same (attached). -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/12388] icf_test.sh and icf_safe_test.sh fail
http://sourceware.org/bugzilla/show_bug.cgi?id=12388
--- Comment #2 from Richard Guenther 2011-01-12
10:30:42 UTC ---
Sure. Just to add, a readelf on the linked binary shows both respective
functions at different addresses.
icf_test.stdout:
00401748 d _DYNAMIC
00401920 d _GLOBAL_OFFSET_TABLE_
00400628 R _IO_stdin_used
w _Jv_RegisterClasses
00400514 T folded_func()
004004f4 T common()
004004ff T kept_func()
00401958 d __CTOR_END__
00401950 d __CTOR_LIST__
...
(I guess the above was the interesting pieces)
shell log:
+ check icf_test.stdout folded_func kept_func
++ grep folded_func icf_test.stdout
++ awk '{print $1}'
+ func_addr_1=00400514
++ grep kept_func icf_test.stdout
++ awk '{print $1}'
+ func_addr_2=004004ff
+ '[' 00400514 '!=' 004004ff ']'
+ echo 'Identical Code Folding failed to fold' folded_func and kept_func
Identical Code Folding failed to fold folded_func and kept_func
+ exit 1
(of course not too interesting with the above fact)
This is from the plain binutils 2.21 release, configured with
../configure 'CFLAGS=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2
-fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wno-error'
'CXXFLAGS=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector
-funwind-tables -fasynchronous-unwind-tables -g -Wno-error' --prefix=/usr
--libdir=/usr/lib64 --infodir=/usr/share/info --mandir=/usr/share/man
--with-bugurl=http://bugs.opensuse.org/ '--with-pkgversion=GNU Binutils;
devel:gcc / openSUSE_Factory' --with-separate-debug-dir=/usr/lib/debug
--with-pic --build=x86_64-suse-linux
--enable-targets=alpha-suse-linux,arm-suse-linux,hppa-suse-linux,hppa64-suse-linux,i686-suse-linux,ia64-suse-linux,m68k-suse-linux,mips-suse-linux,powerpc-suse-linux,powerpc64-suse-linux,s390-suse-linux,s390x-suse-linux,sh4-suse-linux,sparc-suse-linux,sparc64-suse-linux,x86_64-suse-linux,powerpc-macos,powerpc-macos10,spu-elf
--enable-plugins --enable-gold --enable-shared
and gold configury patched to simply skip targets it doesn't know
(bah - --enable-targets is shared with all subdir configures but
the list of supported tagets differs ... that sucks).
icf_test.cpp is compiled like
g++ -DHAVE_CONFIG_H -I. -I../../../gold/testsuite -I..
-I../../../gold/testsuite -I../../../gold/testsuite/..
-I../../../gold/testsuite/../../include -I../../../gold/testsuite/../../elfcpp
-I.. -DLOCALEDIR="\"/usr/share/locale\"" -W -Wall-Werror
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fmerge-constants -fmessage-length=0
-O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables -g -Wno-error -O0 -c -ffunction-sections -g -o
icf_test.o ../../../gold/testsuite/icf_test.cc
g++ -W -Wall-Werror -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-fmerge-constants -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2
-fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wno-error
-o icf_test -Bgcctestdir/ -Wl,--icf=all icf_test.o
and g++ is 4.5.2 which is patched to add --build-id to the link command
(-v output):
/usr/lib64/gcc/x86_64-suse-linux/4.5/collect2 --build-id --eh-frame-hdr -m
elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o icf_test
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib64/crt1.o
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib64/crti.o
/usr/lib64/gcc/x86_64-suse-linux/4.5/crtbegin.o -Lgcctestdir
-L/usr/lib64/gcc/x86_64-suse-linux/4.5
-L/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64
-L/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/lib
-L/usr/lib64/gcc/x86_64-suse-linux/4.5/../../.. --icf=all icf_test.o -lstdc++
-lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/lib64/gcc/x86_64-suse-linux/4.5/crtend.o
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib64/crtn.o
which seems to be the problem(!) - with --build-id manually removed I get
39: 004004df21 FUNCGLOBAL DEFAULT 13 _Z9kept_funcv
40: 004004df21 FUNCGLOBAL DEFAULT 13 _Z11folded_funcv
is there any reason why you do not perform ICF when generating build-ids?
I can't think of any.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/12392] New: Many static link tests fail
http://sourceware.org/bugzilla/show_bug.cgi?id=12392 Summary: Many static link tests fail Product: binutils Version: 2.21 Status: NEW Severity: normal Priority: P2 Component: gold AssignedTo: i...@airs.com ReportedBy: rgue...@gcc.gnu.org One example, the errors are common: g++ -W -Wall-Werror -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fmerge-constants -O2 -g -o basic_static_test -Bgcctestdir/ -static basic_test.o gcctestdir/ld: /usr/lib/gcc/i586-suse-linux/4.5/../../../libc.a(errlist.o):(.debug_info+0x1c3): warning: `sys_errlist' is deprecated; use `strerror' or `strerror_r' instead gcctestdir/ld: /usr/lib/gcc/i586-suse-linux/4.5/../../../libc.a(errlist.o):(.debug_info+0x1f1): warning: `sys_nerr' is deprecated; use `strerror' or `strerror_r' instead gcctestdir/ld: /usr/lib/gcc/i586-suse-linux/4.5/../../../libc.a(elf-init.o): in function __libc_csu_irel:elf-init.c:94: error: undefined reference to '__rel_iplt_end' gcctestdir/ld: /usr/lib/gcc/i586-suse-linux/4.5/../../../libc.a(elf-init.o): in function __libc_csu_irel:elf-init.c:94: error: undefined reference to '__rel_iplt_start' gcctestdir/ld: /usr/lib/gcc/i586-suse-linux/4.5/../../../libc.a(elf-init.o): in function __libc_csu_irel:../sysdeps/i386/dl-irel.h:36: error: undefined reference to '__rel_iplt_start' gcctestdir/ld: /usr/lib/gcc/i586-suse-linux/4.5/../../../libc.a(elf-init.o): in function __libc_csu_irel:../sysdeps/i386/dl-irel.h:33: error: undefined reference to '__rel_iplt_start' gcctestdir/ld: /usr/lib/gcc/i586-suse-linux/4.5/../../../libc.a(elf-init.o): in function __libc_csu_irel:../sysdeps/i386/dl-irel.h:36: error: undefined reference to '__rel_iplt_start' collect2: ld returned 1 exit status make[5]: *** [basic_static_test] Error 1 The linker is invoked as ./gcctestdir/ld -m elf_i386 -static -o basic_static_test /usr/lib/gcc/i586-suse-linux/4.5/../../../crt1.o /usr/lib/gcc/i586-suse-linux/4.5/../../../crti.o /usr/lib/gcc/i586-suse-linux/4.5/crtbeginT.o -Lgcctestdir -L/usr/lib/gcc/i586-suse-linux/4.5 -L/usr/lib/gcc/i586-suse-linux/4.5/../../../../i586-suse-linux/lib -L/usr/lib/gcc/i586-suse-linux/4.5/../../.. basic_test.o -lstdc++ -lm --start-group -lgcc -lgcc_eh -lc --end-group /usr/lib/gcc/i586-suse-linux/4.5/crtend.o /usr/lib/gcc/i586-suse-linux/4.5/../../../crtn.o using GNU ld the link works fine. On x86_64-linux this works fine, but on i586-linux it breaks. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/12392] Many static link tests fail
http://sourceware.org/bugzilla/show_bug.cgi?id=12392 --- Comment #1 from Richard Guenther 2011-01-12 11:02:16 UTC --- Is there a way to easily extract all files used for the link? Most standard libraries are linker scripts and pull in stuff from somewhere. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/12392] Many static link tests fail
http://sourceware.org/bugzilla/show_bug.cgi?id=12392 Richard Guenther changed: What|Removed |Added Target||i?86-*-linux -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/12392] Many static link tests fail
http://sourceware.org/bugzilla/show_bug.cgi?id=12392 --- Comment #2 from Richard Guenther 2011-01-12 11:33:42 UTC --- Which means the fix for PR10893 isn't working? -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/12392] Many static link tests fail
http://sourceware.org/bugzilla/show_bug.cgi?id=12392 --- Comment #4 from Richard Guenther 2011-01-12 14:44:49 UTC --- (In reply to comment #3) > Passing the -t option to the linker will get you a complete list of all object > files and shared libraries that the linker includes in the link. > > The warning about sys_errlist being deprecated suggests that your system is > going to generate a warning on any static link. At least, I don't see > anything > in basic_static_test which would refer to errlist, so I think the reference > must be coming from libgcc or libc itself. Does the GNU linker give a warning > when linking with -static? No, the GNU linker doesn't give this warning. Maybe gold warns about the symbol definition? > The error about __rel_iplt_start and __rel_iplt_end not being defined is very > odd. The 32-bit x86 linker always defines those when linking with -static. I will produce a tarfile with the objects, anything else you want to know? -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/12392] Many static link tests fail
http://sourceware.org/bugzilla/show_bug.cgi?id=12392 --- Comment #5 from Richard Guenther 2011-01-12 14:51:10 UTC --- # g++ -W -Wall-Werror -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fmerge-constants -O2 -g -o basic_static_test -Bgcctestdir/ -static basic_test.o -Wl,-t /usr/lib/gcc/i586-suse-linux/4.5/../../../crt1.o /usr/lib/gcc/i586-suse-linux/4.5/../../../crti.o /usr/lib/gcc/i586-suse-linux/4.5/crtbeginT.o basic_test.o /usr/lib/gcc/i586-suse-linux/4.5/libstdc++.a(si_class_type_info.o) /usr/lib/gcc/i586-suse-linux/4.5/libstdc++.a(del_op.o) /usr/lib/gcc/i586-suse-linux/4.5/libstdc++.a(class_type_info.o) /usr/lib/gcc/i586-suse-linux/4.5/libstdc++.a(tinfo.o) /usr/lib/gcc/i586-suse-linux/4.5/../../../libc.a(libc-start.o) /usr/lib/gcc/i586-suse-linux/4.5/../../../libc.a(check_fds.o) ... /usr/lib/gcc/i586-suse-linux/4.5/libgcc_eh.a(unwind-dw2.o) /usr/lib/gcc/i586-suse-linux/4.5/libgcc_eh.a(unwind-dw2-fde-glibc.o) /usr/lib/gcc/i586-suse-linux/4.5/libgcc_eh.a(unwind-c.o) /usr/lib/gcc/i586-suse-linux/4.5/../../../libc.a(dl-iteratephdr.o) /usr/lib/gcc/i586-suse-linux/4.5/crtend.o /usr/lib/gcc/i586-suse-linux/4.5/../../../crtn.o ... files too large to attach. They will appear (at some point) at http://gcc.opensuse.org/gold-bug.tar.xz -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12726] New: cannot move location counter backwards, alignment related regression on 2.21 branch
http://sourceware.org/bugzilla/show_bug.cgi?id=12726 Summary: cannot move location counter backwards, alignment related regression on 2.21 branch Product: binutils Version: 2.21 Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassig...@sources.redhat.com ReportedBy: rgue...@gcc.gnu.org Created attachment 5702 --> http://sourceware.org/bugzilla/attachment.cgi?id=5702 testcase While the 2.21 release links the attached testcase just fine, the 2.21 branch taken at Apr 19th fails to link it with > ld -T romlayout32seg.lds code32seg.o -o rom32seg.o romlayout32seg.lds:66 cannot move location counter backwards (from 67b0 to 67a0) If one changes the linker script to add 0x4 more room for the sections (which corresponds to their alignment) like *(.rodata.__func__.10274) . = ( 0x6782 - code32seg_start ) ; *(.rodata.__func__.8035) . = ( 0x6796 - code32seg_start ) ; *(.rodata.__func__.8048) . = ( 0x67aa - code32seg_start ) ; *(.rodata.__func__.8075) . = ( 0x67c0 - code32seg_start ) ; *(.rodata.__func__.8115) then the link succeeds. This looks like a bogus alignment calculation as with the size of 0xe for the section 0x10 should be enough space to properly align the data. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12726] cannot move location counter backwards, alignment related regression on 2.21 branch
http://sourceware.org/bugzilla/show_bug.cgi?id=12726 Richard Guenther changed: What|Removed |Added Target||i?86-*-* --- Comment #1 from Richard Guenther 2011-05-03 10:54:15 UTC --- Similar issue happens on 64bit. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12726] cannot move location counter backwards, alignment related regression on 2.21 branch
http://sourceware.org/bugzilla/show_bug.cgi?id=12726 --- Comment #2 from Richard Guenther 2011-05-03 11:23:27 UTC --- Confirmed also with the current 2.21 branch head and also with 2010-12-04 Alan Modra * ldlang.c (lang_size_sections_1): Align lma using same alignment as for vma. reverted (that just looked maybe related). -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12801] New: ICE in bfd/elf64-x86-64.c line 2764 in elf64_x86_64_relocate_section
http://sourceware.org/bugzilla/show_bug.cgi?id=12801 Summary: ICE in bfd/elf64-x86-64.c line 2764 in elf64_x86_64_relocate_section Product: binutils Version: 2.21 Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassig...@sources.redhat.com ReportedBy: rgue...@gcc.gnu.org Current glibc git head fails to link with ld from the 2.21 branch > tar xjf ld-bug.tar.bz2 > cd ld-bug/ > ld -m elf_x86_64 -shared -o ./libc.so -e __libc_main -O1 -z defs > --version-script=./libc.map -soname=libc.so.6 -z combreloc -z relro > ./abi-note.o ./soinit.os --whole-archive ./libc_pic.a --no-whole-archive > ./sofini.os ./interp.os ./ld.so -v -T ./shlib.lds GNU ld (GNU Binutils; devel:gcc / openSUSE_11.1) 2.21.0.20110419-45 ld: BFD (GNU Binutils; devel:gcc / openSUSE_11.1) 2.21.0.20110419-45 internal error, aborting at ../../bfd/elf64-x86-64.c line 2764 in elf64_x86_64_relocate_section ld: Please report this bug. I suppose the testcase will be too large for bugzilla, you can fetch it from http://gcc.opensuse.org/ld-bug.tar.bz2 once it is synced there. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12801] ICE in bfd/elf64-x86-64.c line 2764 in elf64_x86_64_relocate_section
http://sourceware.org/bugzilla/show_bug.cgi?id=12801 Richard Guenther changed: What|Removed |Added Target||x86_64-unknown-linux-gnu --- Comment #1 from Richard Guenther 2011-05-24 09:51:15 UTC --- ICEs the same way with the 2.21 release. ld 2.16.91.0.5 doesn't grok the linker script. With GNU ld (GNU Binutils; SUSE Linux Enterprise 11) 2.20.0.20100122-0.7.9 it works fine, so it seems to be a regression in 2.21. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12801] ICE in bfd/elf64-x86-64.c line 2764 in elf64_x86_64_relocate_section
http://sourceware.org/bugzilla/show_bug.cgi?id=12801 Richard Guenther changed: What|Removed |Added Status|WAITING |NEW --- Comment #5 from Richard Guenther 2011-05-25 12:30:11 UTC --- Why should I? You can try yourself. I want a fix for 2.21.x, not for 2.22+. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12366] assertion failure with STT_GNU_IFUNC symbols on x86_64
http://sourceware.org/bugzilla/show_bug.cgi?id=12366 Richard Guenther changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Blocks||12801 -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12801] ICE in bfd/elf64-x86-64.c line 2764 in elf64_x86_64_relocate_section
http://sourceware.org/bugzilla/show_bug.cgi?id=12801 Richard Guenther changed: What|Removed |Added Depends on||12366 -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12801] ICE in bfd/elf64-x86-64.c line 2764 in elf64_x86_64_relocate_section
http://sourceware.org/bugzilla/show_bug.cgi?id=12801 Richard Guenther changed: What|Removed |Added Status|WAITING |NEW --- Comment #3 from Richard Guenther 2011-05-25 08:35:48 UTC --- I don't have mainline around. I have 2.20 around which works and 2.21 and the top of the 2.21 branch which both fail. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/12388] icf_test.sh and icf_safe_test.sh fail
http://sourceware.org/bugzilla/show_bug.cgi?id=12388 Richard Guenther changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Richard Guenther 2011-07-11 11:27:55 UTC --- The tests now work on the 2.21 branch. The only gold fail on x86_64 (with GCC 4.6.1) is PASS: exception_test /bin/sh: line 1: 9918 Aborted "$tst" > exception_static_test.lo g-t 2>&1 FAIL: exception_static_test and for i?86 I still get linker fails for them: g++ -W -Wall-Werror -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fmerge-const ants -O2 -g -Bgcctestdir/ -static -o exception_static_test exception_test_main. o exception_test_1.o exception_test_2.o -lz gcctestdir/ld: /usr/lib/gcc/i586-suse-linux/4.6/../../../libc.a(errlist.o):(.deb ug_info+0x1c3): warning: `sys_errlist' is deprecated; use `strerror' or `strerro r_r' instead gcctestdir/ld: /usr/lib/gcc/i586-suse-linux/4.6/../../../libc.a(errlist.o):(.deb ug_info+0x1f1): warning: `sys_nerr' is deprecated; use `strerror' or `strerror_r ' instead gcctestdir/ld: /usr/lib/gcc/i586-suse-linux/4.6/../../../libc.a(elf-init.o): in function __libc_csu_irel:elf-init.c:94: error: undefined reference to '__rel_ipl t_end' gcctestdir/ld: /usr/lib/gcc/i586-suse-linux/4.6/../../../libc.a(elf-init.o): in function __libc_csu_irel:elf-init.c:94: error: undefined reference to '__rel_ipl t_start' gcctestdir/ld: /usr/lib/gcc/i586-suse-linux/4.6/../../../libc.a(elf-init.o): in function __libc_csu_irel:../sysdeps/i386/dl-irel.h:36: error: undefined referenc e to '__rel_iplt_start' gcctestdir/ld: /usr/lib/gcc/i586-suse-linux/4.6/../../../libc.a(elf-init.o): in function __libc_csu_irel:../sysdeps/i386/dl-irel.h:33: error: undefined referenc e to '__rel_iplt_start' gcctestdir/ld: /usr/lib/gcc/i586-suse-linux/4.6/../../../libc.a(elf-init.o): in function __libc_csu_irel:../sysdeps/i386/dl-irel.h:36: error: undefined referenc e to '__rel_iplt_start' collect2: ld returned 1 exit status make[5]: *** [exception_static_test] Error 1 similar for tls_static_test and tls_static_pic_test. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/13141] New: Confusing error message with --no-copy-dt-needed-entries
http://sourceware.org/bugzilla/show_bug.cgi?id=13141
Bug #: 13141
Summary: Confusing error message with
--no-copy-dt-needed-entries
Product: binutils
Version: 2.21
Status: NEW
Severity: normal
Priority: P2
Component: binutils
AssignedTo: unassig...@sources.redhat.com
ReportedBy: rgue...@gcc.gnu.org
Classification: Unclassified
The error messages when linking a binary with a missing library and
--no-copy-dt-needed-entries (the new default) is confusing:
gcc -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector
-funwind-tables -fasynchronous-unwind-tables -g -DDATADIR='"/usr/share/bb/"'
-I/usr/include -pthread -D_REENTRANT -D SOUNDDIR=\"/usr/share/bb\" -o bb
autopilo.o backconv.o bb.o credits.o credits2.o ctrl87.o fk1.o fk2.o fk3.o
fk4.o formulas.o hh1.o hh2.o hh3.o hh4.o image.o julia.o kt1.o kt2.o kt3.o
kt4.o main.o messager.o ms1.o ms2.o ms3.o ms4.o print.o scene1.o scene2.o
scene3.o scene4.o scene5.o scene7.o scene8.o scene9.o tex.o textform.o timers.o
uncompfn.o zeb.o zoom.o -llzo2 -laa -L/usr/lib64 -lmikmod -ldl
/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/bin/ld:
credits.o: undefined reference to symbol 'sincos@@GLIBC_2.2.5'
/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/bin/ld:
note: 'sincos@@GLIBC_2.2.5' is defined in DSO /lib64/libm.so.6 so try adding it
to the linker command line
/lib64/libm.so.6: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[1]: *** [bb] Error 1
The last line,
/lib64/libm.so.6: could not read symbols: Invalid operation
should probably not appear.
Just for information, it's elf_link_add_object_symbols doing
/* A symbol from a library loaded via DT_NEEDED of some
other library is referenced by a regular object.
Add a DT_NEEDED entry for it. Issue an error if
--no-add-needed is used and the reference was not
a weak one. */
if (undef_bfd != NULL
&& (elf_dyn_lib_class (abfd) & DYN_NO_NEEDED) != 0)
{
(*_bfd_error_handler)
(_("%B: undefined reference to symbol '%s'"),
undef_bfd, name);
(*_bfd_error_handler)
(_("note: '%s' is defined in DSO %B so try adding it to the
linker command line"),
abfd, name);
bfd_set_error (bfd_error_invalid_operation);
goto error_free_vers;
and the caller, gld${EMULATION_NAME}_try_needed issueing
/* Add this file into the symbol table. */
if (! bfd_link_add_symbols (abfd, &link_info))
einfo ("%F%B: could not read symbols: %E\n", abfd);
we could guard the latter with bfd_get_error () != bfd_error_invalid_operation
or not set an error and guard it with bfd_get_error () != bfd_error_no_error.
Why is the bfd_set_error (bfd_error_invalid_operation) there in the first
place?
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/13141] Confusing error message with --no-copy-dt-needed-entries
http://sourceware.org/bugzilla/show_bug.cgi?id=13141 Richard Guenther changed: What|Removed |Added Component|binutils|ld -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12557] gcc & Firefox fail to build with -flto and --as-needed LDFLAGS
http://sourceware.org/bugzilla/show_bug.cgi?id=12557
Richard Guenther changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #31 from Richard Guenther 2011-09-02
10:36:33 UTC ---
Simple testcase
double x;
int main()
{
return x*x*x*x;
}
> gcc-4.6 -o t t.o -O -ffast-math -flto
> gcc-4.6 -o t t.o -flto
/tmp/ccIqK5i6.ltrans0.ltrans.o: In function `main':
ccIqK5i6.ltrans0.o:(.text+0x19): undefined reference to `pow'
collect2: ld returned 1 exit status
> gcc-4.6 -o t t.o -flto -lm
> gcc-4.6 -o t t.o -flto -Wl,--as-needed -lm
which works for me with the 2.21.1 release.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/32506] removed functions showing up in objdump listing and gdb
https://sourceware.org/bugzilla/show_bug.cgi?id=32506 --- Comment #4 from Richard Biener --- For targets where zero is a valid address a linker option to specify an alternate relocation target for targets within GCed sections might be a workaround, specifying an address that more likely doesn't clash with an actual object (say, --gced-section-reference-address=0x). Maybe such value can even be pre-configured on such targets. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32506] removed functions showing up in objdump listing and gdb
https://sourceware.org/bugzilla/show_bug.cgi?id=32506 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- It seems to be a design decision for --gc-sections to ignore uses in debug info relocations. The alternative would be to not GC sections that are still referenced from debug info or to remove debug info alltogether once any referenced section is removed (debug info after all is not "used"). The other alternative is to try produce multiple DWARF CUs from the compiler, one for each text section emitted. You can possibly "emulate" this by compiling each TU with LTO and link it with -flinker-output=nolto-rel -flto-partition=max and hack lto-wrapper (from GCC) to _not_ partially link the LTRANS objects but put them into an archive. That would get you -ffunction-sections by means of one object file per function (each with separate debug info). -- You are receiving this mail because: You are on the CC list for the bug.
