[Bug ld/20828] [MIPS] produces invalid dynamic symbol table when --gc-sections is used since PR ld/13177 fix
https://sourceware.org/bugzilla/show_bug.cgi?id=20828 --- Comment #14 from John Paul Adrian Glaubitz --- Hi Maciej! (In reply to Maciej W. Rozycki from comment #12) > There's been no further feedback from other people and myself I haven't > made up my mind about this bug yet, so if you are blocked with your > work, then for the time being please use one of the proposals posted > here as a temporary workaround. The problem with this approach is that our toolchain maintainers are unwilling to merge a patch which has not been fully approved upstream for a supported target architecture. This means, the binutils package in Debian is still broken on all MIPS targets (mips32 big-endian, mips32 little-endian, mips64 little-endian) in Debian and if the issue is not resolved within the near future, the upcoming Debian Stretch release may be shipped without any official support for MIPS [1]. So, from the Debian point-of-view, fixing this bug has urgent priority unless we want to waive for MIPS support. Thanks, Adrian > [1] https://release.debian.org/stretch/arch_qualify.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
ld: once multiple symbol definitions are allowed, both definitions end up in the executable
Hello, Could please someone advice is it a bug or a feature when we get both bodies of the functions with the same name in the executable once multiple symbol definitions are allowed? Here is the example showing the behavior: $ cat main.c int f() {return 6;} int main() { return f();} $ cat a.c int f() {return 4;} $ gcc -c a.c main.c $ gcc -Wl,--allow-multiple-definition a.o main.o # From objdump we can see that the bodies of both functions "f" end up in the executable: $ objdump -d a.out 004004f6 : 4004f6:55 push %rbp 4004f7:48 89 e5 mov%rsp,%rbp 4004fa:b8 04 00 00 00 mov$0x4,%eax 4004ff:5d pop%rbp 400500:c3 retq 400501:55 push %rbp 400502:48 89 e5 mov%rsp,%rbp 400505:b8 06 00 00 00 mov$0x6,%eax 40050a:5d pop%rbp 40050b:c3 retq # The behavior is more or less as specified in the documentation with only the first definition executed: $ ./a.out $ echo $? 4 $ In my (more complex) setup I saw issues coming from this behavior since not only we get the second definition but the relocations needed by it. Just in case some more information on my setup (though the behavior is the same on one more Linux host and the issue looks to be there on more recent ld also): $ gcc --version gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6) $ ld --version GNU ld version 2.25-9.fc22 Best regards, Pavel ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/20876] objdump is not aware about the build ID method to find detached debug info
https://sourceware.org/bugzilla/show_bug.cgi?id=20876 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #3 from Mark Wielaard --- Just a note that elfutils searches only the (global?) absolute debuginfo paths directly. So given the default of "":.debug:/usr/lib/debug", it skips the "" relative cwd and the ".debug" postfix, but only tries /usr/lib/debug/.build-id/xx/.debug So the search strategy of elfutils for a separate .debug file given a build-id xx and a list of debuginfo search paths is to take the absolute paths (starting with '/') and trying /path/.build-id/xx/.debug. Where the default list of (absolute) debuginfo search paths is just "/usr/lib/debug". It then takes the canonicalize_file_name assuming it might be a symlink and the user might find the resolved name more interesting. As a sanity check elfutils also only allows build-ids that are at a minimum 4 and at a maximum 64 hex characters long. It does normally also verify that the found file does contain the build-id it should and reject the file if it doesn't. -- 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/13442] gold screws up exception handling with --incremental flag
https://sourceware.org/bugzilla/show_bug.cgi?id=13442 Matt Godbolt changed: What|Removed |Added CC||matt at godbolt dot org --- Comment #10 from Matt Godbolt --- On a whim I tried incremental linking on our existing large codebase and hit this exact same problem. This happens with Ubuntu 14.04's default g++ 4.8.4 and gold 1.11 (binutils 2.24) reproduced using Samuel's steps (adding -fuse-ld=gold). It also happens with a custom-built GCC 6.3.0 with an in-tree build of gold (binutils 2.26, gold 1.11) - though in order to get around the plugin support built into this build the repro case needs -fno-lto too. -- 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/20828] [MIPS] produces invalid dynamic symbol table when --gc-sections is used since PR ld/13177 fix
https://sourceware.org/bugzilla/show_bug.cgi?id=20828 Maciej W. Rozycki changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #15 from Maciej W. Rozycki --- I can't comment on individual distribution policies here, this is not the right place to discuss them. As per the milestone set this will be fixed with 2.28. If this does not satisfy your distribution's requirements, then you have several options to choose from, including but possibly not limited to these: 1. Propose a change suitable for inclusion with our sources; I have outlined one earlier on although there may be other acceptable ways to do it too. 2. Temporarily use one of the quick fixes proposed here. 3. Work the problem around by disabling linker GC. It is then up to individual distribution's maintainers to decide which of these options suits them best; in particular submitting a change that can be accepted right away is always welcome and guarantees quick processing. NB while I'll implement the missing dynsym ordering case for the MIPS backend so that it follows the ELF gABI even if weird output is somehow produced by the generic BFD ELF linker I maintain that dropping symbols that have been GC-ed (but not other forced local ones) is the right solution. -- 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/21038] New: Incorrect unwind info for BND PLT
https://sourceware.org/bugzilla/show_bug.cgi?id=21038 Bug ID: 21038 Summary: Incorrect unwind info for BND PLT Product: binutils Version: 2.29 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: hjl.tools at gmail dot com Target Milestone: --- Target: x86-64 [hjl@gnu-6 mpx-6]$ cat y.S .text .globl foo .type foo, @function foo: .cfi_startproc callfunc@plt .cfi_endproc [hjl@gnu-6 mpx-6]$ make LD=ld gcc -B./-c -o y.o y.S ld -z bndplt -shared -o y.so y.o ./objdump -Wf -dw y.so y.so: file format elf64-x86-64 Contents of the .eh_frame section: 0014 CIE Version: 1 Augmentation: "zR" Code alignment factor: 1 Data alignment factor: -8 Return address column: 16 Augmentation data: 1b DW_CFA_def_cfa: r7 (rsp) ofs 8 DW_CFA_offset: r16 (rip) at cfa-8 DW_CFA_nop DW_CFA_nop 0018 0014 001c FDE cie= pc=0248..024d DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop 0030 0024 0034 FDE cie= pc=0220..0240 DW_CFA_def_cfa_offset: 16 DW_CFA_advance_loc: 6 to 0226 DW_CFA_def_cfa_offset: 24 DW_CFA_advance_loc: 10 to 0230 DW_CFA_def_cfa_expression (DW_OP_breg7 (rsp): 8; DW_OP_breg16 (rip): 0; DW_OP_lit15; DW_OP_and; DW_OP_lit11; DW_OP_ge; DW_OP_lit3; DW_OP_shl; DW_OP_plus) DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop Disassembly of section .plt: 0220 <.plt>: 220: ff 35 e2 0d 20 00 pushq 0x200de2(%rip)# 201008 <_GLOBAL_OFFSET_TABLE_+0x8> 226: f2 ff 25 e3 0d 20 00bnd jmpq *0x200de3(%rip)# 201010 <_GLOBAL_OFFSET_TABLE_+0x10> 22d: 0f 1f 00nopl (%rax) 230: 68 00 00 00 00 pushq $0x0 235: f2 e9 e5 ff ff ff bnd jmpq 220 <.plt> 23b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) Disassembly of section .plt.bnd: 0240 : 240: f2 ff 25 d1 0d 20 00bnd jmpq *0x200dd1(%rip)# 201018 247: 90 nop Disassembly of section .text: 0248 : 248: e8 f3 ff ff ff callq 240 [hjl@gnu-6 mpx-6]$ Since the BND PLT has 230: 68 00 00 00 00 pushq $0x0 235: f2 e9 e5 ff ff ff bnd jmpq 220 <.plt> 23b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) instead of 230: ff 25 e2 0d 20 00 jmpq *0x200de2(%rip)# 201018 236: 68 00 00 00 00 pushq $0x0 23b: e9 e0 ff ff ff jmpq 220 <.plt> Its unwind info should be DW_CFA_def_cfa_expression (DW_OP_breg7 (rsp): 8; DW_OP_breg16 (rip): 0; DW_OP_lit15; DW_OP_and; DW_OP_lit5; DW_OP_ge; DW_OP_lit3; DW_OP_shl; DW_OP_plus) -- 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/20876] objdump is not aware about the build ID method to find detached debug info
https://sourceware.org/bugzilla/show_bug.cgi?id=20876 Nick Clifton changed: What|Removed |Added Attachment #9746|0 |1 is obsolete|| --- Comment #4 from Nick Clifton --- Created attachment 9748 --> https://sourceware.org/bugzilla/attachment.cgi?id=9748&action=edit Proposed patch Hi Matthias, OK, here is a revised patch. Please let me know what you think. I have not added build-id verification as I am lazy, but that can be done if you are happy with the rest of the patch. More controversially however, I have not restricted the path generation to absolute paths. The reason is basically testing. If the build-id based debug info files *have* to be installed into admin controlled parts of the file system then it is not going to be possible to test the feature as an ordinary user. (See the addition to objdump.exp in the updated patch for an example of how I envisage testing the feature currently). Is it such a bad thing to be able to load locally stored build-id based debug info files ? It makes testing possible, and I imagine that it would be quite useful in development too. If the user wants to debug a built, but not installed, application (which uses build-id based separate debug files), then all that they need to do is to make sure that the files are in the correct .build-id/NN directories and away they go. Cheers Nick -- 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/21038] Incorrect unwind info for BND PLT
https://sourceware.org/bugzilla/show_bug.cgi?id=21038 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |2.29 --- Comment #2 from H.J. Lu --- Fixed. -- 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/21038] Incorrect unwind info for BND PLT
https://sourceware.org/bugzilla/show_bug.cgi?id=21038 --- Comment #1 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=9e65917652e994b0864b344bfa47014155d93100 commit 9e65917652e994b0864b344bfa47014155d93100 Author: H.J. Lu Date: Wed Jan 11 09:16:44 2017 -0800 x86-64: Correct unwind info for the BND PLT Since the BND PLT has 230: 68 00 00 00 00 pushq $0x0 235: f2 e9 e5 ff ff ff bnd jmpq 220 <.plt> 23b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) instead of 230: ff 25 e2 0d 20 00 jmpq *0x200de2(%rip)# 201018 236: 68 00 00 00 00 pushq $0x0 23b: e9 e0 ff ff ff jmpq 220 <.plt> its unwind info should be DW_CFA_def_cfa_expression (DW_OP_breg7 (rsp): 8; DW_OP_breg16 (rip): 0; DW_OP_lit15; DW_OP_and; DW_OP_lit5; DW_OP_ge; DW_OP_lit3; DW_OP_shl; DW_OP_plus) bfd/ PR ld/21038 * elf64-x86-64.c (elf_x86_64_eh_frame_bnd_plt): New. (elf_x86_64_bnd_arch_bed): Use elf_x86_64_eh_frame_bnd_plt and elf_x86_64_eh_frame_plt_got. (elf_x86_64_size_dynamic_sections): Get unwind info from elf_x86_64_bnd_arch_bed for the BND PLT. ld/ PR ld/21038 * testsuite/ld-x86-64/pr21038a.d: New file. * testsuite/ld-x86-64/pr21038a.s: Likewise. * testsuite/ld-x86-64/pr21038b.d: Likewise. * testsuite/ld-x86-64/pr21038b.s: Likewise. * testsuite/ld-x86-64/x86-64.exp: Run pr21038a and pr21038b. -- 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/21039] New: Tests fail on i386-linux
https://sourceware.org/bugzilla/show_bug.cgi?id=21039 Bug ID: 21039 Summary: Tests fail on i386-linux Product: binutils Version: 2.29 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: hjl.tools at gmail dot com CC: ian at airs dot com Target Milestone: --- Target: i386 On Linux/i386, I got FAIL: script_test_13.sh FAIL: script_test_15a.sh FAIL: script_test_15b.sh FAIL: script_test_15c.sh FAIL: script_test_13.sh (exit: 1) = Expected pattern was not found: \.rela\.dyn[[:space:]]\+RELA[[:space:]]\+0\+1\b Actual output below: There are 20 section headers, starting at offset 0x257c: Section Headers: [Nr] Name TypeAddr OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .text PROGBITS 001000 00 00 AX 0 0 1 [ 2] .dynsym DYNSYM 001000 30 10 A 3 1 4 [ 3] .dynstr STRTAB 0030 001030 06 00 A 0 0 1 [ 4] .hash HASH0038 001038 18 04 A 2 0 4 [ 5] .data PROGBITS0050 001050 00 00 WA 0 0 1 [ 6] .data.rel PROGBITS0050 001050 04 00 WA 0 0 4 [ 7] .dynamic DYNAMIC 0054 001054 70 08 WA 3 0 4 [ 8] .rel.dyn REL 0001 002000 08 08 A 2 0 4 [ 9] .bss NOBITS 00010229 002229 00 00 WA 0 0 1 [10] .debug_abbrev PROGBITS 002229 48 00 0 0 1 [11] .debug_info PROGBITS 002271 4b 00 0 0 1 [12] .debug_line PROGBITS 0022bc 76 00 0 0 1 [13] .debug_pubnames PROGBITS 002332 19 00 0 0 1 [14] .debug_strPROGBITS 00234b 99 01 MS 0 0 1 [15] .comment PROGBITS 0023e4 49 01 MS 0 0 1 [16] .note.gnu.gold-version NOTE 002430 1c 00 0 0 4 [17] .symtab SYMTAB 00244c 50 10 18 3 4 [18] .strtab STRTAB 00249c 20 00 0 0 1 [19] .shstrtab STRTAB 0024bc bf 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), I (info), L (link order), O (extra OS processing required), G (group), T (TLS), C (compressed), x (unknown), o (OS specific), E (exclude), p (processor specific) -- 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/21040] New: Gold fails with GCC 4.2
https://sourceware.org/bugzilla/show_bug.cgi?id=21040 Bug ID: 21040 Summary: Gold fails with GCC 4.2 Product: binutils Version: 2.29 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: hjl.tools at gmail dot com CC: ian at airs dot com Target Milestone: --- With GCC 4.2, I got gold/x86_64.cc:481: error: using ‘typename’ outside of template ... gold/powerpc.cc:2013: warning: comparison is always false due to limited range of data type ... gold/testsuite/copy_test_relro_1.cc:24: warning: ‘p’ initialized and declared ‘extern’ -- 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/21039] Tests fail on i386-linux
https://sourceware.org/bugzilla/show_bug.cgi?id=21039 --- Comment #1 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Cary Coutant : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=1fa5f68bf38fc29f173990614db70fed1b66c0e0 commit 1fa5f68bf38fc29f173990614db70fed1b66c0e0 Author: Cary Coutant Date: Wed Jan 11 11:26:26 2017 -0800 Fix test cases to work for i386. gold/ PR gold/21039 * testsuite/script_test_13.sh: Adjust patterns to work for i386. * testsuite/script_test_15a.sh: Likewise. * testsuite/script_test_15b.sh: Likewise. * testsuite/script_test_15c.sh: Likewise. -- 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/21039] Tests fail on i386-linux
https://sourceware.org/bugzilla/show_bug.cgi?id=21039 --- Comment #2 from cvs-commit at gcc dot gnu.org --- The binutils-2_28-branch branch has been updated by Cary Coutant : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a513f8bec2a8be13196960372b477231af8f76a2 commit a513f8bec2a8be13196960372b477231af8f76a2 Author: Cary Coutant Date: Wed Jan 11 11:26:26 2017 -0800 Fix test cases to work for i386. gold/ PR gold/21039 * testsuite/script_test_13.sh: Adjust patterns to work for i386. * testsuite/script_test_15a.sh: Likewise. * testsuite/script_test_15b.sh: Likewise. * testsuite/script_test_15c.sh: Likewise. -- 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/21039] Tests fail on i386-linux
https://sourceware.org/bugzilla/show_bug.cgi?id=21039 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Cary Coutant --- Fixed on trunk and binutils-2_28-branch. -- 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/20876] objdump is not aware about the build ID method to find detached debug info
https://sourceware.org/bugzilla/show_bug.cgi?id=20876 --- Comment #5 from Matthias Klose --- no, still doesn't strip the dirname, and one location is search twice. open("/usr/lib/debug/bin/.build-id/1b/1d2d0a5c825e50e07e80595427894ef0af116b.debug", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/debug/usr/bin/.build-id/1b/1d2d0a5c825e50e07e80595427894ef0af116b.debug", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/debug/bin/.build-id/1b/1d2d0a5c825e50e07e80595427894ef0af116b.debug", O_RDONLY) = -1 ENOENT (No such file or directory) -- 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/21040] Gold fails with GCC 4.2
https://sourceware.org/bugzilla/show_bug.cgi?id=21040 --- Comment #3 from cvs-commit at gcc dot gnu.org --- The binutils-2_28-branch branch has been updated by Cary Coutant : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=930624ccb207a0e1bb16500a4d812e9671fb78de commit 930624ccb207a0e1bb16500a4d812e9671fb78de Author: Cary Coutant Date: Wed Jan 11 11:47:27 2017 -0800 Fix compile errors with GCC 4.2. gold/ PR gold/21040 * x86_64.cc (Output_data_plt_x86_64_bnd::do_fill_first_plt_entry): Remove unnecessary 'typename' keyword. (Output_data_plt_x86_64_bnd::do_fill_plt_entry): Likewise. (Output_data_plt_x86_64_bnd::do_fill_tlsdesc_entry): Likewise. (Output_data_plt_x86_64_bnd::fill_aplt_entry): Likewise. * testsuite/copy_test_relro_1.cc (p, b, c, q): Add separate extern declarations. -- 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/21040] Gold fails with GCC 4.2
https://sourceware.org/bugzilla/show_bug.cgi?id=21040 Cary Coutant changed: What|Removed |Added CC||amodra at gmail 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
Re: ld: once multiple symbol definitions are allowed, both definitions end up in the executable
On 01/11/2017 01:49 AM, Pavel Shishpor wrote: Could please someone advice is it a bug or a feature when we get both bodies of the functions with the same name in the executable once multiple symbol definitions are allowed? Here is the example showing the behavior: The only thing that the --allow-multiple-definitions option does is disable the error message that you would normally get. It doesn't change how the linker output is created. So yes, you will end up with both definitions in the output. It is best to avoid getting multiple definitions in the first place. If you want the linker to discard unused functions, then each function must be in its own section via gcc -ffunction-sections and then use the linker --gc-sections option. However, this may cause problems of its own, e.g. debug functions may disappear because they appear unused, it won't work for libraries where most functions are meant to be used by an application it is linked with, etc. Or alternatively, you can try making it a COMDAT function, then duplicates get dropped automatically. For your example, the duplicate f function is in the same text section as the main function, which can't be deleted. The assembler may resolve intra-section references itself. Which means editing the text section to remove the f function may break other things in the same section, which is unsafe, and hence the linker can't do it. Thus the requirement that we can only delete functions that are in their own section. Jim ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/21040] Gold fails with GCC 4.2
https://sourceware.org/bugzilla/show_bug.cgi?id=21040 --- Comment #1 from Cary Coutant --- > gold/powerpc.cc:2013: warning: comparison is always false due to limited > range of data type Alan, I'll leave this one to you. Not sure whether you want to cast addr to uint64_t or not. -- 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/21040] Gold fails with GCC 4.2
https://sourceware.org/bugzilla/show_bug.cgi?id=21040 --- Comment #2 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Cary Coutant : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=976e204b369fd01f9d35d87ea2cd07707c3a40cf commit 976e204b369fd01f9d35d87ea2cd07707c3a40cf Author: Cary Coutant Date: Wed Jan 11 11:47:27 2017 -0800 Fix compile errors with GCC 4.2. gold/ PR gold/21040 * x86_64.cc (Output_data_plt_x86_64_bnd::do_fill_first_plt_entry): Remove unnecessary 'typename' keyword. (Output_data_plt_x86_64_bnd::do_fill_plt_entry): Likewise. (Output_data_plt_x86_64_bnd::do_fill_tlsdesc_entry): Likewise. (Output_data_plt_x86_64_bnd::fill_aplt_entry): Likewise. * testsuite/copy_test_relro_1.cc (p, b, c, q): Add separate extern declarations. -- 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/20876] objdump is not aware about the build ID method to find detached debug info
https://sourceware.org/bugzilla/show_bug.cgi?id=20876 --- Comment #6 from Matthias Klose --- applying this on top of your patch works for me. The global debug directory doesn't have the dirname of the original file, so don't append `canon_dir'. Not sure if that needs to be stripped from the tests with EXTRA_DEBUG_ROOT1 and EXTRA_DEBUG_ROOT2 prefixes as well? --- bfd/opncls.c~ 2017-01-11 20:29:07.061189932 +0100 +++ bfd/opncls.c2017-01-11 21:39:51.211288793 +0100 @@ -1481,11 +1481,8 @@ /* Then try in the global debugfile directory. */ strcpy (debugfile, debug_file_directory); dirlen = strlen (debug_file_directory) - 1; - if (dirlen > 0 - && debug_file_directory[dirlen] != '/' - && canon_dir[0] != '/') + if (dirlen > 0 && debug_file_directory[dirlen] != '/') strcat (debugfile, "/"); - strcat (debugfile, canon_dir); strcat (debugfile, base); if (check_func (debugfile, crc32)) -- 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/21040] Gold fails with GCC 4.2
https://sourceware.org/bugzilla/show_bug.cgi?id=21040 --- Comment #5 from cvs-commit at gcc dot gnu.org --- The binutils-2_28-branch branch has been updated by Cary Coutant : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c5cb17ebcfe6d375a7b85dd6014306b1ef473a2f commit c5cb17ebcfe6d375a7b85dd6014306b1ef473a2f Author: Cary Coutant Date: Wed Jan 11 13:42:24 2017 -0800 Fix more compile errors with GCC 4.2. gold/ PR gold/21040 * x86_64.cc (Output_data_plt_x86_64_bnd::do_fill_first_plt_entry): Remove unnecessary 'typename' keyword. (Output_data_plt_x86_64_bnd::do_fill_plt_entry): Likewise. (Output_data_plt_x86_64_bnd::fill_aplt_entry): Likewise. (Output_data_plt_x86_64_bnd::do_fill_tlsdesc_entry): Likewise. (Output_data_plt_x86_64_bnd::do_write): Likewise. -- 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/21040] Gold fails with GCC 4.2
https://sourceware.org/bugzilla/show_bug.cgi?id=21040 --- Comment #4 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Cary Coutant : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=6624f3a142811450fab7eed1f406c4a030c3c9be commit 6624f3a142811450fab7eed1f406c4a030c3c9be Author: Cary Coutant Date: Wed Jan 11 13:42:24 2017 -0800 Fix more compile errors with GCC 4.2. gold/ PR gold/21040 * x86_64.cc (Output_data_plt_x86_64_bnd::do_fill_first_plt_entry): Remove unnecessary 'typename' keyword. (Output_data_plt_x86_64_bnd::do_fill_plt_entry): Likewise. (Output_data_plt_x86_64_bnd::fill_aplt_entry): Likewise. (Output_data_plt_x86_64_bnd::do_fill_tlsdesc_entry): Likewise. (Output_data_plt_x86_64_bnd::do_write): Likewise. -- 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