[Bug gas/25539] fix-loongson3-llsc cannot produce `sync` when there are multi label at the same address
https://sourceware.org/bugzilla/show_bug.cgi?id=25539 --- Comment #1 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Chenghua Xu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=dec7b24be89fe0496f9442232bcbfcb16e030742 commit dec7b24be89fe0496f9442232bcbfcb16e030742 Author: YunQiang Su Date: Fri Feb 28 15:58:13 2020 +0800 MIPS/fix_loongson3_llsc: fix when target has multi labels When there is multi-labels on the same insn, the current code will take care about the last one. it may cause that no sync is added at the target. Here we scan all labels with same value of S_GET_VALUE(label_list->label) by label_list->next. 2020-02-28 YunQiang Su PR gas/25539 * config/tc-mips.c (fix_loongson3_llsc): Compare label value to handle multi-labels. (has_label_name): New. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25539] fix-loongson3-llsc cannot produce `sync` when there are multi label at the same address
https://sourceware.org/bugzilla/show_bug.cgi?id=25539 YunQiang Su changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from YunQiang Su --- This problem is fixed by https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=dec7b24be89fe0496f9442232bcbfcb16e030742 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/21464] relocation truncated to fit: R_OR1K_GOT16 on OpenRISC, when linking libQtGui.so.4.8.7
https://sourceware.org/bugzilla/show_bug.cgi?id=21464 Giulio Benetti changed: What|Removed |Added CC||giulio.benetti@micronovasrl ||.com --- Comment #3 from Giulio Benetti --- This issue still exists with version 2.31.1 when building protobuf on OpenRisc: /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.31.1 assertion fail elf32-or1k.c:1752 collect2: error: ld returned 1 exit status make[4]: *** [Makefile:2694: libprotobuf-lite.la] Error 1 make[4]: *** Waiting for unfinished jobs /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/crtbeginS.o: in function `deregister_tm_clones': crtstuff.c:(.text+0x48): relocation truncated to fit: R_OR1K_GOT16 against undefined symbol `_ITM_deregisterTMCloneTable' /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/crtbeginS.o: in function `register_tm_clones': crtstuff.c:(.text+0xd8): relocation truncated to fit: R_OR1K_GOT16 against undefined symbol `_ITM_registerTMCloneTable' /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/crtbeginS.o: in function `__do_global_dtors_aux': crtstuff.c:(.text+0x158): relocation truncated to fit: R_OR1K_GOT16 against symbol `__cxa_finalize' defined in .text section in /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/or1k-buildroot-linux-uclibc/sysroot/lib/libc.so.1 /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: crtstuff.c:(.text+0x1e0): relocation truncated to fit: R_OR1K_GOT16 against symbol `__deregister_frame_info@@GLIBC_2.0' defined in .text section in /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/lib/libgcc_s.so /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/crtbeginS.o: in function `frame_dummy': crtstuff.c:(.text+0x278): relocation truncated to fit: R_OR1K_GOT16 against symbol `__register_frame_info@@GLIBC_2.0' defined in .text section in /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/lib/libgcc_s.so /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: crtstuff.c:(.text+0x2c0): relocation truncated to fit: R_OR1K_GOT16 against undefined symbol `_Jv_RegisterClasses' /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: google/protobuf/stubs/.libs/bytestream.o: in function `google::protobuf::strings::CheckedArrayByteSink::CheckedArrayByteSink(char*, unsigned int)': bytestream.cc:(.text+0x3bc): relocation truncated to fit: R_OR1K_GOT16 against symbol `vtable for google::protobuf::strings::CheckedArrayByteSink' defined in .data.rel.ro._ZTVN6google8protobuf7strings20CheckedArrayByteSinkE[_ZTVN6google8protobuf7strings20CheckedArrayByteSinkE] section in google/protobuf/stubs/.libs/bytestream.o /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../
[Bug gas/25611] New: [DWARF-5] support for checksums in .file directives
https://sourceware.org/bugzilla/show_bug.cgi?id=25611 Bug ID: 25611 Summary: [DWARF-5] support for checksums in .file directives Product: binutils Version: 2.35 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: ndesaulniers at google dot com Target Milestone: --- I was playing around trying to enable -gdwarf-5 in the Linux kernel, and hit an issue where it looks like clang is emitting .file directives like: .file 1 "/home/nick/linux/init/do_mounts.c" md5 0x62e8a195aa9d4d8b466f84b7775ea4cd with GAS producing errors like: do_mounts.s:19: Error: junk at end of line, first unrecognized character is `m' A quick grep through the DWARF-5 spec [0] doesn't mention anything about assembly directives. The docs on .file directives also doesn't mention this. [1] I assume this is maybe an extension that Clang implemented? IIUC, it's used by debuggers to tell when/if a file has been modified. Is this something that can be implemented in GNU as? I'm happy to also pursue a command line flag in Clang to disable the emission of these checksums. See also [2]. [0] http://www.dwarfstd.org/doc/DWARF5.pdf [1] https://sourceware.org/binutils/docs/as/File.html#File [2] https://bugs.llvm.org/show_bug.cgi?id=45040 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25612] New: -gdwarf-{3,4,5} command line arguments
https://sourceware.org/bugzilla/show_bug.cgi?id=25612
Bug ID: 25612
Summary: -gdwarf-{3,4,5} command line arguments
Product: binutils
Version: 2.35 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: ndesaulniers at google dot com
Target Milestone: ---
Playing around with dwarf-5, I notices that GNU as has the command line flag
-gdwarf-2, but no equivalents for DWARF 3, 4, or 5. It looks like `gcc
-gwarf-5` will set the second value in the .debug_info section to the dwarf
version? I haven't put thought into what version should be preferred if BOTH
the command line version AND assembly specify differing versions.
The Linux kernel has a lot of out of line assembly, and I'm not sure it sets
the dwarf version correctly, though maybe that's something just to be fixed per
file than via global assembler flag.
Thoughts on implementing -gdwarf-{3,4,5} in GNU as? This would match the
behavior of `gcc -gdwarf-{3,4,5}` and `clang -gdwarf-{3,4,5}`.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/25611] [DWARF-5] support for checksums in .file directives
https://sourceware.org/bugzilla/show_bug.cgi?id=25611 --- Comment #1 from Nick Desaulniers --- Pawing more through the spec (previously linked), it looks like "1.4 Changes from Version 4 to Version 5" on pdf pg 26 kind of hints at this: 20 • Replace the line number program header format with a new format that 21 provides the ability to use an MD5 hash to validate the source file version in 22 use, allows pooling of directory and file name strings and makes provision 23 for vendor-defined extensions. Also add a string section specific to the line 24 number table (.debug_line_str) to properly support the common practice 25 of stripping all DWARF sections except for line number information. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25614] New: dwarf-5 allows for .file 0
https://sourceware.org/bugzilla/show_bug.cgi?id=25614 Bug ID: 25614 Summary: dwarf-5 allows for .file 0 Product: binutils Version: 2.35 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: ndesaulniers at google dot com Target Milestone: --- .file 0 "asdf" .section .debug_info,"",@progbits .long 3 .short 5 $ as x.s x.s: Assembler messages: x.s:1: Error: file number less than one It seems that dwarf-5 may have added support for `0` as a valid file number. Clang warns: $ clang x.s -c x.s:1:1: warning: file 0 not supported prior to DWARF-5 .file 0 "asdf" ^ $ clang x.s -c -gdwarf-5 I *think* section "2.14 Declaration Coordinates" pdf page 68 of [0] addresses this: "The value 0 indicates that no source file has been specified." See also [1]. [0] http://www.dwarfstd.org/doc/DWARF5.pdf [1] https://bugs.llvm.org/show_bug.cgi?id=45040 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25612] -gdwarf-{3,4,5} command line arguments
https://sourceware.org/bugzilla/show_bug.cgi?id=25612 --- Comment #1 from Nick Desaulniers --- See also: https://bugs.llvm.org/show_bug.cgi?id=45040 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25614] dwarf-5 allows for .file 0
https://sourceware.org/bugzilla/show_bug.cgi?id=25614 --- Comment #1 from Nick Desaulniers --- Also, documentation here would have to be updated. https://sourceware.org/binutils/docs/as/File.html#File -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25611] [DWARF-5] support for checksums in .file directives
https://sourceware.org/bugzilla/show_bug.cgi?id=25611 --- Comment #2 from Nick Desaulniers --- Also, documentation here would have to be updated. https://sourceware.org/binutils/docs/as/File.html#File -- You are receiving this mail because: You are on the CC list for the bug.
