[Bug ld/26806] Suspected linker bug with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=26806 --- Comment #8 from Alan Modra --- Created attachment 12931 --> https://sourceware.org/bugzilla/attachment.cgi?id=12931&action=edit patch under test This should do what I intended for git commit 1e3b96fd6cf. Please show it to be broken it if you can! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26806] Suspected linker bug with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=26806 --- Comment #7 from H.J. Lu --- (In reply to Alan Modra from comment #6) > (In reply to H.J. Lu from comment #1) > > This regression was introduced on purpose by > That's not exactly true. The as-needed library was supposed to marked > needed by an IR reference, but it is entirely accidental that references > from undefined IR symbols result in dynamic symbols. Definitely a bug. It is the same thing underneath. An undefined IR symbol leads to dynamic undefined symbol which is satisfied by a needed library, -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26815] Unnecessary error on linking STV_PROTECTED library: relocation R_X86_64_PC32 against protected symbol `f' can not be used when making a shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=26815
--- Comment #6 from Thiago Macieira ---
A bit more testing shows that we'd need a compiler update too, to tell the
compiler that a variable should be accessed via the GOT regardless (equiv. to
Windows __declspec(dllimport)). We can accomplish that by always compiling
everything with -fPIC, though.
lib.c:
long variable = 0;
void *addr()
{
++variable;
return &variable;
}
main.c:
#include
void *addr(void);
extern long variable;
__auto_type ptr2 = &variable;
int main()
{
variable++;
printf("addr() = %p, &variable = %p\n", addr(), ptr2);
}
$ gcc -O2 -shared -fPIC -fvisibility=protected -fuse-ld=gold -o lib.so lib.c
Now the error comes from Gold:
$ gcc -O2 -pie -fPIE -fuse-ld=gold main.c ./lib.so
/usr/bin/ld.gold: error: /tmp/ccUGJmAG.o: cannot make copy relocation for
protected symbol 'variable', defined in ./lib.so
collect2: error: ld returned 1 exit status
ld.bfd can link it:
$ gcc -O2 -pie -fPIE main.c ./lib.so
When run, this particular example appears to work but the variable was actually
copy-relocated:
$ ./a.out
addr() = 0x8050, &variable = 0x8050
When linking the library with ld.bfd instead:
# gcc -O2 -shared -fPIC -fvisibility=protected
-Wl,--dynamic-list,empty.dynlist -o lib.so lib.c
Then we get a mismatch:
$ ./a.out
addr() = 0x7ffa8cabc028, &variable = 0x556094d36050
All these problems go away when the main application is compiled with -fPIC.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/26815] Unnecessary error on linking STV_PROTECTED library: relocation R_X86_64_PC32 against protected symbol `f' can not be used when making a shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=26815 --- Comment #5 from H.J. Lu --- (In reply to Thiago Macieira from comment #4) > (In reply to H.J. Lu from comment #3) > > GOT relocation is needed for function pointer comparison. > > > > > Either way, the fact that gold and ld.bfd behave different is a problem. > > > And > > > so is the fact that passing an empty --dynamic-list file causes it to > > > work. > > > > An empty --dynamic-list file is the same as -Bsymbolic. > > I see. > > Then this is an incompatibility between compiler and linker: the compiler > sees a protected symbol and emits a relocation assuming it doesn't need > indirect access via the GOT to do a pointer comparison, but ld.bfd says it > should. > > Anyway, this is what I am asking to change: when a symbol is protected, the > compiler optimisation should be allowed and pointer comparison still works > provided ALL users use the GOT too. That includes the executable. This is an ABI change. We have 2 choices 1. Extend GNU_PROPERTY_NO_COPY_ON_PROTECTED to cover protected function pointers. We can rename it to GNU_PROPERTY_LOCAL_PROTECTED, Or 2. Add a new property for protected function pointers. Please raise the issue at https://gitlab.com/x86-psABIs/Linux-ABI This will require support in GCC, linker and ld.so. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26806] Suspected linker bug with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=26806 Alan Modra changed: What|Removed |Added Status|REOPENED|ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26806] Suspected linker bug with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=26806 Alan Modra changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|REOPENED Assignee|unassigned at sourceware dot org |amodra at gmail dot com --- Comment #6 from Alan Modra --- (In reply to H.J. Lu from comment #1) > This regression was introduced on purpose by That's not exactly true. The as-needed library was supposed to marked needed by an IR reference, but it is entirely accidental that references from undefined IR symbols result in dynamic symbols. Definitely a bug. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26815] Unnecessary error on linking STV_PROTECTED library: relocation R_X86_64_PC32 against protected symbol `f' can not be used when making a shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=26815 --- Comment #4 from Thiago Macieira --- (In reply to H.J. Lu from comment #3) > GOT relocation is needed for function pointer comparison. > > > Either way, the fact that gold and ld.bfd behave different is a problem. And > > so is the fact that passing an empty --dynamic-list file causes it to work. > > An empty --dynamic-list file is the same as -Bsymbolic. I see. Then this is an incompatibility between compiler and linker: the compiler sees a protected symbol and emits a relocation assuming it doesn't need indirect access via the GOT to do a pointer comparison, but ld.bfd says it should. Anyway, this is what I am asking to change: when a symbol is protected, the compiler optimisation should be allowed and pointer comparison still works provided ALL users use the GOT too. That includes the executable. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26806] Suspected linker bug with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=26806 --- Comment #5 from H.J. Lu --- (In reply to Alan Modra from comment #4) > > So this whole thing is a bit of a mess. Reverting my patches and applying > HJ's might work as a quick solution, but do please check out Jeff's testcase. Jeff's testcase fails with commit 865bfec6bc0d5fd97ea876d8e4e77197653f3823 Author: H.J. Lu Date: Mon Sep 7 07:54:43 2020 -0700 Revert "Allow plugin syms to mark as-needed shared libs needed" This reverts commit 1e3b96fd6cf0c7d018083994ad951ccf92aba582. and passes with my patch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26806] Suspected linker bug with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=26806 Alan Modra changed: What|Removed |Added CC||law at redhat dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26806] Suspected linker bug with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=26806 --- Comment #4 from Alan Modra --- (In reply to Nick Clifton from comment #2) > I am hoping that Alan will review the patch, but just FYI it is working for > me in rawhide. There is an email thread on that subject. I committed a couple of patches, a896df97b95 and 1e3b96fd6cf that changed --as-needed behaviour, because I fairly strongly believed we can't get all the corner cases correct in the linker. I continue to think that too. We need to inform LTO of shared library symbols before recompilation, but with --as-needed those symbols might not actually be available in the final executable. They are of course if the recompiled object references something to make the as-needed library needed. But what if LTO makes decisions based on a set of symbols that is different to that in the final executable, due to an as-needed library being dropped? Can you say with any certainty that this will never happen? Those two patches of mine make https://sourceware.org/pipermail/binutils/2020-September/113227.html superfluous. I didn't forsee we would have anything like the redhat bugzilla. :-( Note that the comment in the log for a896df97b95 about duplicated copies of variables isn't completely correct. A duplicate being present doesn't necessarily cause a problem: the duplicates need to be used to actually cause a problem. That probably wan't happening in the libbfd.so case, but Jeff Law posted about a case where duplicates did occur *and* were used. https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555899.html So this whole thing is a bit of a mess. Reverting my patches and applying HJ's might work as a quick solution, but do please check out Jeff's testcase. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26815] Unnecessary error on linking STV_PROTECTED library: relocation R_X86_64_PC32 against protected symbol `f' can not be used when making a shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=26815 --- Comment #3 from H.J. Lu --- (In reply to Thiago Macieira from comment #2) > (In reply to H.J. Lu from comment #1) > > You can override it with linker options: > > > > -Bsymbolic Bind global references locally > > -Bsymbolic-functionsBind global function references locally > > Those options shouldn't be needed. The protected visibility already implies > them. > GOT relocation is needed for function pointer comparison. > Either way, the fact that gold and ld.bfd behave different is a problem. And > so is the fact that passing an empty --dynamic-list file causes it to work. An empty --dynamic-list file is the same as -Bsymbolic. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26815] Unnecessary error on linking STV_PROTECTED library: relocation R_X86_64_PC32 against protected symbol `f' can not be used when making a shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=26815 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-10-30 Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- Protected function pointer should be treated as normal symbol: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520 You can override it with linker options: -Bsymbolic Bind global references locally -Bsymbolic-functionsBind global function references locally -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26815] Unnecessary error on linking STV_PROTECTED library: relocation R_X86_64_PC32 against protected symbol `f' can not be used when making a shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=26815 --- Comment #2 from Thiago Macieira --- (In reply to H.J. Lu from comment #1) > You can override it with linker options: > > -Bsymbolic Bind global references locally > -Bsymbolic-functionsBind global function references locally Those options shouldn't be needed. The protected visibility already implies them. Either way, the fact that gold and ld.bfd behave different is a problem. And so is the fact that passing an empty --dynamic-list file causes it to work. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26815] Unnecessary error on linking STV_PROTECTED library: relocation R_X86_64_PC32 against protected symbol `f' can not be used when making a shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=26815 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26815] New: Unnecessary error on linking STV_PROTECTED library: relocation R_X86_64_PC32 against protected symbol `f' can not be used when making a shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=26815
Bug ID: 26815
Summary: Unnecessary error on linking STV_PROTECTED library:
relocation R_X86_64_PC32 against protected symbol `f'
can not be used when making a shared object
Product: binutils
Version: 2.35.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: thiago at kde dot org
Target Milestone: ---
Using ld.bfd:
$ cat test.c
void f() {}
void *g() { return &f; }
$ gcc -fPIC -o /tmp/a.so -shared -fvisibility=protected test.c
/usr/bin/ld: /tmp/ccbS1isF.o: relocation R_X86_64_PC32 against protected symbol
`f' can not be used when making a shared object
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
$ ld --version
GNU ld (GNU Binutils) 2.35.1.20190203
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
But it works with gold:
$ gcc -fuse-ld=gold -fPIC -o /tmp/a.so -shared -fvisibility=protected test.c
[no error]
It similarly works with ld.bfd if you pass a dummy dynamic list:
$ cat /tmp/empty.dynlist
{
this_symbol_doesnt_exist;
};
$ gcc -Wl,--dynamic-list,/tmp/empty.dynlist -fPIC -o /tmp/a.so -shared
-fvisibility=protected test.c
[no error]
The library looks fine otherwise (using -nostdlib for output brevity):
$ gcc -nostdlib -Wl,--dynamic-list,/tmp/empty.dynlist -fPIC -o /tmp/a.so
-shared -fvisibility=protected test.c
$ readelf -Ds /tmp/a.so
Symbol table for image contains 3 entries:
Num:Value Size TypeBind Vis Ndx Name
0: 0 NOTYPE LOCAL DEFAULT UND
1: 1001 8 FUNCGLOBAL PROTECTED6 g
2: 1000 1 FUNCGLOBAL PROTECTED6 f
$ readelf -r /tmp/a.so
There are no relocations in this file.
$ objdump -d /tmp/a.so
/tmp/a.so: file format elf64-x86-64
Disassembly of section .text:
1000 :
1000: c3 retq
1001 :
1001: 48 8d 05 f8 ff ff fflea-0x8(%rip),%rax# 1000
1008: c3 retq
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/26809] nm-new : heap-buffer-overflow in bfd_getl_signed_64
https://sourceware.org/bugzilla/show_bug.cgi?id=26809 Nick Clifton changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Nick Clifton --- Hi Wu, Thanks for reporting this bug. The problem was in the code to handle secondary relocs, which was assuming that any given target only used either REL or RELA type relocations. This of course is not true for all targets, and your testcase revealed one such scenario. I have checked in a patch to remove this assumption, and now the test file is processed without any problems. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26809] nm-new : heap-buffer-overflow in bfd_getl_signed_64
https://sourceware.org/bugzilla/show_bug.cgi?id=26809 --- Comment #2 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=8ee54925b48985e8e7102221e698bf50b800dd81 commit 8ee54925b48985e8e7102221e698bf50b800dd81 Author: Nick Clifton Date: Thu Oct 29 20:13:00 2020 + Fix an illegal memory access problem when processing secondary relocs for architectures which support both REL and RELA relocs. PR 26809 * elf.c (_bfd_elf_slurp_secondary_reloc_section): Use the correct sized reloc reading function. (_bfd_elf_write_secondary_reloc_section): Use the correct sized reloc writing function. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26803] c++filt fails to demangle a C++ symbol
https://sourceware.org/bugzilla/show_bug.cgi?id=26803 yuri at tsoft dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |NOTABUG --- Comment #2 from yuri at tsoft dot com --- The symbol in question is truncated, it had the dollar sign and more characters in the end. In its complete form binutils does demangle it correctly. It resulted from the C++ lambda function. Sorry for the disturbance! Yuri -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26809] nm-new : heap-buffer-overflow in bfd_getl_signed_64
https://sourceware.org/bugzilla/show_bug.cgi?id=26809 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2020-10-29 --- Comment #1 from Nick Clifton --- testing a patch now -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26809] nm-new : heap-buffer-overflow in bfd_getl_signed_64
https://sourceware.org/bugzilla/show_bug.cgi?id=26809 Nick Clifton changed: What|Removed |Added Assignee|unassigned at sourceware dot org |nickc at redhat dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26806] Suspected linker bug with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=26806 --- Comment #3 from H.J. Lu --- The patch was posted at https://sourceware.org/pipermail/binutils/2020-September/113227.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26808] [2.36 Regression] readelf: Warning: DIE at offset 0x232 refers to abbreviation number 77 which does not exist
https://sourceware.org/bugzilla/show_bug.cgi?id=26808 --- Comment #12 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=76868f3606fb9de04f49c441c1e3cdd3e943a34d commit 76868f3606fb9de04f49c441c1e3cdd3e943a34d Author: H.J. Lu Date: Thu Oct 29 09:19:25 2020 -0700 dwarf: Also match abbrev base when searching abbrev list A .debug_abbrev section can have multiple CUs. When caching abbrev list, we need to check abbrev base to support multiple CUs. PR binutils/26808 * dwarf.c (abbrev_list): Add abbrev_base. (new_abbrev_list): Add an abbrev_base argument and record it. (find_abbrev_list_by_abbrev_offset): Add an abbrev_base argument and match it. (process_debug_info): Pass abbrev_base to new_abbrev_list and find_abbrev_list_by_abbrev_offset. (display_debug_abbrev): Pass 0 abbrev_base to new_abbrev_list and find_abbrev_list_by_abbrev_offset. * testsuite/binutils-all/x86-64/pr26808.dump: New file. * testsuite/binutils-all/x86-64/pr26808.dwp.bz2: Likewise. * testsuite/binutils-all/x86-64/x86-64.exp: Run PR binutils/26808 test. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26808] [2.36 Regression] readelf: Warning: DIE at offset 0x232 refers to abbreviation number 77 which does not exist
https://sourceware.org/bugzilla/show_bug.cgi?id=26808 --- Comment #11 from Mark Wielaard --- (In reply to H.J. Lu from comment #10) > A patch is posted at > > https://sourceware.org/pipermail/binutils/2020-October/113938.html Thanks. I get what is going on now. This isn't a normal .dwo file, it is one processed with dwp. In that case you do indeed need to take the offsets from the .debug_cu_index into account. eu-readelf also doesn't do that. I filed a bug for that: https://sourceware.org/bugzilla/show_bug.cgi?id=26812 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26806] Suspected linker bug with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=26806 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from Nick Clifton --- (In reply to H.J. Lu from comment #1) I am hoping that Alan will review the patch, but just FYI it is working for me in rawhide. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26808] [2.36 Regression] readelf: Warning: DIE at offset 0x232 refers to abbreviation number 77 which does not exist
https://sourceware.org/bugzilla/show_bug.cgi?id=26808 H.J. Lu changed: What|Removed |Added Target Milestone|--- |2.36 --- Comment #10 from H.J. Lu --- A patch is posted at https://sourceware.org/pipermail/binutils/2020-October/113938.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26808] [2.36 Regression] readelf: Warning: DIE at offset 0x232 refers to abbreviation number 77 which does not exist
https://sourceware.org/bugzilla/show_bug.cgi?id=26808
--- Comment #9 from H.J. Lu ---
It has multiple CUs:
Compilation Unit @ offset 0x0:
Compilation Unit @ offset 0x17c:
Compilation Unit @ offset 0x72f:
Compilation Unit @ offset 0x7fe:
Compilation Unit @ offset 0x0:
Compilation Unit @ offset 0xfb:
Compilation Unit @ offset 0x1f0:
But this mixes offsets from different CUs:
list = find_abbrev_list_by_abbrev_offset (compunit.cu_abbrev_offset);
if (list == NULL)
{
unsigned char * next;
list = new_abbrev_list (compunit.cu_abbrev_offset);
next = process_abbrev_set
(((unsigned char *) debug_displays [abbrev_sec].section.start
+ abbrev_base + compunit.cu_abbrev_offset),
((unsigned char *) debug_displays [abbrev_sec].section.start
+ abbrev_base + abbrev_size),
list);
list->start_of_next_abbrevs = next;
}
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/26808] [2.36 Regression] readelf: Warning: DIE at offset 0x232 refers to abbreviation number 77 which does not exist
https://sourceware.org/bugzilla/show_bug.cgi?id=26808 --- Comment #8 from H.J. Lu --- DWO sections have 2 parts: Section contributions: .debug_abbrev.dwo: 0x0 0x154 .debug_line.dwo: 0x0 0x40 .debug_loc.dwo: 0x0 0x0 .debug_str_offsets.dwo: 0x0 0x14 and Section contributions: .debug_abbrev.dwo: 0x154 0x21d .debug_line.dwo: 0x40 0x3d .debug_loc.dwo: 0x0 0x0 .debug_str_offsets.dwo: 0x14 0x44 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26808] [2.36 Regression] readelf: Warning: DIE at offset 0x232 refers to abbreviation number 77 which does not exist
https://sourceware.org/bugzilla/show_bug.cgi?id=26808 --- Comment #7 from H.J. Lu --- DWO processing is broken. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26808] [2.36 Regression] readelf: Warning: DIE at offset 0x232 refers to abbreviation number 77 which does not exist
https://sourceware.org/bugzilla/show_bug.cgi?id=26808 H.J. Lu changed: What|Removed |Added Status|WAITING |NEW -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26808] [2.36 Regression] readelf: Warning: DIE at offset 0x232 refers to abbreviation number 77 which does not exist
https://sourceware.org/bugzilla/show_bug.cgi?id=26808 --- Comment #6 from H.J. Lu --- (In reply to H.J. Lu from comment #5) > Before the commit, process_abbrev_section is call twice with different > start and end. The result from the fist one is dropped. The first call is for the .debug_info.dwo section. The second call is for: Section contributions: .debug_abbrev.dwo: 0x154 0x21d .debug_line.dwo: 0x40 0x3d .debug_loc.dwo: 0x0 0x0 .debug_str_offsets.dwo: 0x14 0x44 After the commit, the second scan was dropped. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26808] [2.36 Regression] readelf: Warning: DIE at offset 0x232 refers to abbreviation number 77 which does not exist
https://sourceware.org/bugzilla/show_bug.cgi?id=26808 --- Comment #5 from H.J. Lu --- Before the commit, process_abbrev_section is call twice with different start and end. The result from the fist one is dropped. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26808] [2.36 Regression] readelf: Warning: DIE at offset 0x232 refers to abbreviation number 77 which does not exist
https://sourceware.org/bugzilla/show_bug.cgi?id=26808 --- Comment #4 from H.J. Lu --- (In reply to Mark Wielaard from comment #3) > (In reply to Nick Clifton from comment #1) > > Hmm, I think that maybe the test file is corrupt. The elfutils version of > > readelf appears to support this: > > > > % eu-readelf -w dwp_test_1.dwp > /dev/null > > [..various warnings and errors and then...] > > eu-readelf: cannot get tag of DIE at offset [232] in section > > '.debug_info.dwo': invalid DWARF > > > > Is it possible that the test, or gold itself, is broken ? > > It seems broken indeed, but it is hard to tell what is going on without the > main file that contains the skeleton DIEs [the various warnings and errors > are about trying to parse the .dwo without the main .debug DIEs]. How was > this file generated? This is the part of gold tests in binutils. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26808] [2.36 Regression] readelf: Warning: DIE at offset 0x232 refers to abbreviation number 77 which does not exist
https://sourceware.org/bugzilla/show_bug.cgi?id=26808 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #3 from Mark Wielaard --- (In reply to Nick Clifton from comment #1) > Hmm, I think that maybe the test file is corrupt. The elfutils version of > readelf appears to support this: > > % eu-readelf -w dwp_test_1.dwp > /dev/null > [..various warnings and errors and then...] > eu-readelf: cannot get tag of DIE at offset [232] in section > '.debug_info.dwo': invalid DWARF > > Is it possible that the test, or gold itself, is broken ? It seems broken indeed, but it is hard to tell what is going on without the main file that contains the skeleton DIEs [the various warnings and errors are about trying to parse the .dwo without the main .debug DIEs]. How was this file generated? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26808] [2.36 Regression] readelf: Warning: DIE at offset 0x232 refers to abbreviation number 77 which does not exist
https://sourceware.org/bugzilla/show_bug.cgi?id=26808 --- Comment #2 from H.J. Lu --- process_abbrev_set is changed from - <1><209>: Abbrev Number: 13 (DW_TAG_class_type) <<< Before the commit + <1><209>: Abbrev Number: 13 (DW_TAG_subprogram) <<< After the commit -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26808] [2.36 Regression] readelf: Warning: DIE at offset 0x232 refers to abbreviation number 77 which does not exist
https://sourceware.org/bugzilla/show_bug.cgi?id=26808 Nick Clifton changed: What|Removed |Added Status|NEW |WAITING --- Comment #1 from Nick Clifton --- Hmm, I think that maybe the test file is corrupt. The elfutils version of readelf appears to support this: % eu-readelf -w dwp_test_1.dwp > /dev/null [..various warnings and errors and then...] eu-readelf: cannot get tag of DIE at offset [232] in section '.debug_info.dwo': invalid DWARF Is it possible that the test, or gold itself, is broken ? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26809] New: nm-new : heap-buffer-overflow in bfd_getl_signed_64
https://sourceware.org/bugzilla/show_bug.cgi?id=26809 Bug ID: 26809 Summary: nm-new : heap-buffer-overflow in bfd_getl_signed_64 Product: binutils Version: 2.36 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: zodf0055980 at gmail dot com Target Milestone: --- Created attachment 12928 --> https://sourceware.org/bugzilla/attachment.cgi?id=12928&action=edit file that reproduces this problem OS : ubuntu 18.04.3 kernel : gnu/linux 5.4.0-52-generic CPU : Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz compiler : gcc version 7.5.0 Steps to Reproduce : download the sample from attachment ~/binutils-ASAN/binutils/nm-new -D --synthetic ./sample /home/yuan/binutils-ASAN/binutils/nm-new: ./sample(.rela.plt): relocation 0 has invalid symbol index 6 /home/yuan/binutils-ASAN/binutils/nm-new: ./sample: unsupported relocation type 0xf8 = ==1587==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60400247 at pc 0x5635ebbcfbd8 bp 0x7ffeb201d870 sp 0x7ffeb201d860 READ of size 1 at 0x60400247 thread T0 #0 0x5635ebbcfbd7 in bfd_getl_signed_64 /home/yuan/binutils-ASAN/bfd/libbfd.c:752 #1 0x5635ebc82b61 in bfd_elf64_swap_reloca_in /home/yuan/binutils-ASAN/bfd/elfcode.h:432 #2 0x5635ebd3597a in _bfd_elf_slurp_secondary_reloc_section /home/yuan/binutils-ASAN/bfd/elf.c:12635 #3 0x5635ebc8c95f in bfd_elf64_slurp_reloc_table /home/yuan/binutils-ASAN/bfd/elfcode.h:1606 #4 0x5635ebd08299 in _bfd_elf_canonicalize_dynamic_reloc /home/yuan/binutils-ASAN/bfd/elf.c:8654 #5 0x5635ebc72dbc in _bfd_x86_elf_get_synthetic_symtab /home/yuan/binutils-ASAN/bfd/elfxx-x86.c:2111 #6 0x5635ebc2fa6b in elf_x86_64_get_synthetic_symtab /home/yuan/binutils-ASAN/bfd/elf64-x86-64.c:4918 #7 0x5635ebb7b0e3 in display_rel_file /home/yuan/binutils-ASAN/binutils/nm.c:1161 #8 0x5635ebb7db8b in display_file /home/yuan/binutils-ASAN/binutils/nm.c:1381 #9 0x5635ebb72d73 in main /home/yuan/binutils-ASAN/binutils/nm.c:1865 #10 0x7f7846ed8b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96) #11 0x5635ebb74ed9 in _start (/home/yuan/binutils-ASAN/binutils/nm-new+0xaced9) 0x60400247 is located 7 bytes to the right of 48-byte region [0x60400210,0x60400240) allocated by thread T0 here: #0 0x7f784758ab40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) #1 0x5635ebbcc9a7 in bfd_malloc /home/yuan/binutils-ASAN/bfd/libbfd.c:275 SUMMARY: AddressSanitizer: heap-buffer-overflow /home/yuan/binutils-ASAN/bfd/libbfd.c:752 in bfd_getl_signed_64 Shadow bytes around the buggy address: 0x0c087fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c087fff8000: fa fa 00 00 00 00 01 fa fa fa fd fd fd fd fd fd 0x0c087fff8010: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fd 0x0c087fff8020: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fa 0x0c087fff8030: fa fa fd fd fd fd fd fa fa fa 00 00 00 00 00 00 =>0x0c087fff8040: fa fa 00 00 00 00 00 00[fa]fa fd fd fd fd fd fd 0x0c087fff8050: fa fa 00 00 00 00 00 03 fa fa 00 00 00 00 00 fa 0x0c087fff8060: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fd 0x0c087fff8070: fa fa fd fd fd fd fd fa fa fa fa fa fa fa fa fa 0x0c087fff8080: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c087fff8090: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb ==1587==ABORTING -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26808] New: [2.36 Regression] readelf: Warning: DIE at offset 0x232 refers to abbreviation number 77 which does not exist
https://sourceware.org/bugzilla/show_bug.cgi?id=26808 Bug ID: 26808 Summary: [2.36 Regression] readelf: Warning: DIE at offset 0x232 refers to abbreviation number 77 which does not exist Product: binutils Version: 2.36 (HEAD) Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: hjl.tools at gmail dot com CC: nickc at redhat dot com Target Milestone: --- Created attachment 12927 --> https://sourceware.org/bugzilla/attachment.cgi?id=12927&action=edit A testcase On Fedora 33/x86-64, commit bcd213b2cfbca2df53fb7e5d187fd67ea8eb7185 Author: Nick Clifton Date: Tue Oct 27 16:17:13 2020 + Fix the decoding of DW_FORM_ref_addr DWARF attribute. caused the gold test failure: [hjl@gnu-cfl-2 testsuite]$ ../../binutils/readelf -wi dwp_test_1.dwp > /dev/null readelf: Warning: DIE at offset 0x232 refers to abbreviation number 77 which does not exist [hjl@gnu-cfl-2 testsuite]$ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26806] Suspected linker bug with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=26806 H.J. Lu changed: What|Removed |Added CC||amodra at gmail dot com Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from H.J. Lu --- This regression was introduced on purpose by commit 1e3b96fd6cf0c7d018083994ad951ccf92aba582 (HEAD) Author: Alan Modra Date: Fri Sep 4 13:54:21 2020 +0930 Allow plugin syms to mark as-needed shared libs needed We must tell LTO about symbols in all shared libraries loaded. That means we can't load extra shared libraries after LTO recompilation, at least, not those that affect the set of symbols that LTO cares about, the IR symbols. This change will likely result in complaints about --as-needed libraries being loaded unnecessarily, but being correct is more important than being optimal. One of the PR15146 tests regresses, and while that could be hidden by disabling the missing dso message by making it conditional on h->root.non_ir_ref_regular, that would just be sweeping a problem under the rug. users/hjl/pr26530/master branch at https://gitlab.com/x86-binutils/binutils-gdb/-/commits/users/hjl/pr26530/master contains patches which fix PR ld/26530 without this regression. *** This bug has been marked as a duplicate of bug 15146 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/15146] Reference from dummy plugin symbol isn't removed
https://sourceware.org/bugzilla/show_bug.cgi?id=15146 H.J. Lu changed: What|Removed |Added CC||jakub at redhat dot com --- Comment #7 from H.J. Lu --- *** Bug 26806 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26805] objcopy : global-buffer-overflow in objcopy.c:1274
https://sourceware.org/bugzilla/show_bug.cgi?id=26805 Nick Clifton changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Nick Clifton --- Hi Wu, Thanks for reporting this bug. The problem was the is_dwo_section() function in the objcopy sources, which assumed that all section names were at least four characters long. I have checked in a small patch to remove this assumption, and now your test case passes without triggering any sanitization errors. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26805] objcopy : global-buffer-overflow in objcopy.c:1274
https://sourceware.org/bugzilla/show_bug.cgi?id=26805 --- Comment #1 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=00c19b8e7879b5e256e7852bdac667466d7a42c2 commit 00c19b8e7879b5e256e7852bdac667466d7a42c2 Author: Nick Clifton Date: Thu Oct 29 11:17:39 2020 + Fix a potential illegal memory access by objcopy when extracting dwo sections. PR 26805 * objcopy.c (is_dwo_section): Check for missing or short section names. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26805] objcopy : global-buffer-overflow in objcopy.c:1274
https://sourceware.org/bugzilla/show_bug.cgi?id=26805 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED CC||nickc at redhat dot com Last reconfirmed||2020-10-29 Ever confirmed|0 |1 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26803] c++filt fails to demangle a C++ symbol
https://sourceware.org/bugzilla/show_bug.cgi?id=26803 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Hi Yuri, What is the expected demangling of this symbol ? How was the symbol constructed ? Does the problem persist if you use the latest version of the binutils ? The demangling of C++ symbols is performed by the libiberty library. The sources for this library are included as part of the binutils, but they are actually maintained by the GCC project. So this bug really needs to be reported there rather than here. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26806] Suspected linker bug with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=26806 Jakub Jelinek changed: What|Removed |Added CC||hjl.tools at gmail dot com, ||hubicka at gcc dot gnu.org, ||nickc at sourceware dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26806] New: Suspected linker bug with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=26806
Bug ID: 26806
Summary: Suspected linker bug with LTO
Product: binutils
Version: 2.35
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: jakub at redhat dot com
Target Milestone: ---
#include
int foo (int x) { if (__builtin_constant_p (x)) return getpid (); return 0; }
compiled with
gcc -shared -fpic -O2 -flto -o testpid.so testpid.c
nm testpid.so | grep getpid; nm -D testpid.so | grep getpid
shows getpid@@GLIBC_2.2.5 in both symbol tables when linked with binutils 2.35
and none when linked with binutils 2.31.1.
As the ltrans assembly file lto1 emits doesn't contain any references to
getpid,
i.e. getpid as undefined symbol is there before IPA optimizations and later
optimized away, it doesn't seem like a GCC bug (unless it is a linker plugin
bug, but then, the same linker plugin works fine against older linker).
https://bugzilla.redhat.com/show_bug.cgi?id=1889763
contains another testcase (even more important one, where because of this the
link is rejected, as the symbol kept in symbol table that really shouldn't be
there gets an linker error (__open*_missing_mode).
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/26805] New: objcopy : global-buffer-overflow in objcopy.c:1274
https://sourceware.org/bugzilla/show_bug.cgi?id=26805 Bug ID: 26805 Summary: objcopy : global-buffer-overflow in objcopy.c:1274 Product: binutils Version: 2.36 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: zodf0055980 at gmail dot com Target Milestone: --- Created attachment 12926 --> https://sourceware.org/bugzilla/attachment.cgi?id=12926&action=edit file that reproduces this problem OS : ubuntu 18.04.3 kernel : gnu/linux 5.4.0-52-generic CPU : Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz compiler : gcc version 7.5.0 Steps to Reproduce : download the sample from attachment ~/binutils-ASAN/binutils/objcopy -I elf32-i386 --extract-dwo ./sample /dev/null ASan trace: = ==13087==ERROR: AddressSanitizer: global-buffer-overflow on address 0x5606d020369c at pc 0x7f30d2c91a69 bp 0x7ffc6df9eba0 sp 0x7ffc6df9e348 READ of size 1 at 0x5606d020369c thread T0 #0 0x7f30d2c91a68 (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x5aa68) #1 0x5606cfb81813 in is_dwo_section /home/yuan/binutils-ASAN/binutils/objcopy.c:1274 #2 0x5606cfb81813 in is_strip_section_1 /home/yuan/binutils-ASAN/binutils/objcopy.c:1371 #3 0x5606cfb81813 in is_strip_section /home/yuan/binutils-ASAN/binutils/objcopy.c:1381 #4 0x5606cfb86b5c in setup_section /home/yuan/binutils-ASAN/binutils/objcopy.c:3985 #5 0x5606cfc8d1cb in bfd_map_over_sections /home/yuan/binutils-ASAN/bfd/section.c:1379 #6 0x5606cfb8ae5d in copy_object /home/yuan/binutils-ASAN/binutils/objcopy.c:2826 #7 0x5606cfb9b51b in copy_file /home/yuan/binutils-ASAN/binutils/objcopy.c:3838 #8 0x5606cfb6fd84 in copy_main /home/yuan/binutils-ASAN/binutils/objcopy.c:5899 #9 0x5606cfb6fd84 in main /home/yuan/binutils-ASAN/binutils/objcopy.c:6025 #10 0x7f30d2663b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96) #11 0x5606cfb7b4d9 in _start (/home/yuan/binutils-ASAN/binutils/objcopy+0xc14d9) 0x5606d020369c is located 54 bytes to the right of global variable '*.LC24' defined in 'elf.c' (0x5606d0203660) of size 6 '*.LC24' is ascii string '.rela' 0x5606d020369c is located 4 bytes to the left of global variable '*.LC26' defined in 'elf.c' (0x5606d02036a0) of size 1 '*.LC26' is ascii string '' SUMMARY: AddressSanitizer: global-buffer-overflow (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x5aa68) Shadow bytes around the buggy address: 0x0ac15a038680: 06 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9 0x0ac15a038690: 06 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 05 f9 0x0ac15a0386a0: f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 0x0ac15a0386b0: 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 07 f9 f9 f9 0x0ac15a0386c0: f9 f9 f9 f9 05 f9 f9 f9 f9 f9 f9 f9 06 f9 f9 f9 =>0x0ac15a0386d0: f9 f9 f9[f9]01 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 0x0ac15a0386e0: f9 f9 f9 f9 00 04 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 0x0ac15a0386f0: f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9 05 f9 f9 f9 0x0ac15a038700: f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 0x0ac15a038710: f9 f9 f9 f9 00 00 00 00 00 00 00 03 f9 f9 f9 f9 0x0ac15a038720: 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 00 02 f9 f9 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb ==13087==ABORTING len in is_dwo_section() is 0, so name + len - 4 is overflow. -- You are receiving this mail because: You are on the CC list for the bug.
