[Bug binutils/27387] [readelf] Support -ggdb3 -gsplit-dwarf output
https://sourceware.org/bugzilla/show_bug.cgi?id=27387 --- Comment #11 from Tom de Vries --- Created attachment 13270 --> https://sourceware.org/bugzilla/attachment.cgi?id=13270&action=edit hello.o.gz -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27387] [readelf] Support -ggdb3 -gsplit-dwarf output
https://sourceware.org/bugzilla/show_bug.cgi?id=27387 --- Comment #10 from Tom de Vries --- Created attachment 13269 --> https://sourceware.org/bugzilla/attachment.cgi?id=13269&action=edit hello.s -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27128] nm -P portable output format regression
https://sourceware.org/bugzilla/show_bug.cgi?id=27128 Alan Modra changed: What|Removed |Added Status|REOPENED|ASSIGNED --- Comment #9 from Alan Modra --- I meant "pr25708 and commit 7e6e972f74a" -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27128] nm -P portable output format regression
https://sourceware.org/bugzilla/show_bug.cgi?id=27128 --- Comment #8 from Alan Modra --- Created attachment 13268 --> https://sourceware.org/bugzilla/attachment.cgi?id=13268&action=edit Add nm --without-symbol-versions There wasn't one to turn off symbol versions. After df2c87b58037 for pr20751 symbol versions for dynamic symbols were displayed by specifying the option --with-symbol-versions. In pr27128 and commit 7e6e972f74a you apparently decided that nm -D ought to display symbol versions by default. I agree. That makes more sense, because by default symbol versions are displayed in relocatable object files. Hmm, and by the look of pr26302 you did not notice nm already had an option to display symbol versions. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27268] mingw-w64 fails with dwarf5
https://sourceware.org/bugzilla/show_bug.cgi?id=27268 Hannes Domani changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=98860 --- Comment #3 from Hannes Domani --- This is the same issue as PR21459 was for the .debug_gdb_scripts section, any sections that are missing in the pe* linker scripts, get VMA 0x1, resulting in an invalid executable. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27407] Add --trace-symbols-from-file?
https://sourceware.org/bugzilla/show_bug.cgi?id=27407
--- Comment #2 from Fangrui Song ---
Yes, response files are accepted by many llvm-project tools. You reminded me
that we can compose tools, e.g.
ld.bfd @response.txt $(nm -Du usr/lib64/libc.so.6 | awk '{print
"-y"substr($0,20)}')
For object files, -D probably should be changed to -g.
There is some flexibility composing can provide: nm -u can be changed to
--defined-only to trace only defined symbols.
So it is unnecessary for ld to support such file tracing features.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/26659] x86_64 pe relocation truncated to fit: R_X86_64_PC32 against undefined symbol
https://sourceware.org/bugzilla/show_bug.cgi?id=26659 Hannes Domani changed: What|Removed |Added CC||ssbssa at sourceware dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27408] nm: Have a way to suppress 'no symbols'
https://sourceware.org/bugzilla/show_bug.cgi?id=27408 --- Comment #3 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Fangrui Song : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7fe1b1388ff80f10e932cde5d82d7268742ef336 commit 7fe1b1388ff80f10e932cde5d82d7268742ef336 Author: Fangrui Song Date: Fri Feb 26 09:25:45 2021 -0800 nm: Add --quiet to suppress "no symbols" diagnostic PR binutils/27408 * readelf.c (quiet): New option flag. (enum long_option_values): New enum to hold long option value. (long_options): Add --quiet. (usage): Mention --quiet. (display_rel_file): If quiet is enabled, suppress "no symbols". (main): Handle the new option. * NEWS: Mention --quiet. * docs/binutils.texi: Document --quiet. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27387] [readelf] Support -ggdb3 -gsplit-dwarf output
https://sourceware.org/bugzilla/show_bug.cgi?id=27387 Nick Clifton changed: What|Removed |Added Assignee|unassigned at sourceware dot org |nickc at redhat dot com Status|NEW |ASSIGNED --- Comment #9 from Nick Clifton --- (In reply to Tom de Vries from comment #8) Hi Tom, > .section.debug_macro.dwo,"e",@progbits > .Ldebug_macro0: > .value 0x4 # DWARF macro version number > -- > .section > .debug_macro.dwo,"G",@progbits,wm4.stdcpredef.h.19. > 006d14bbbe0dc07ba9b1ce3fdc8e40d3,comdat > .Ldebug_macro1: > .value 0x4 # DWARF macro version number > So it this an assembler bug then? Maybe. I suspect that the erroneous bytes that readelf is seeing are actually padding bytes at the end of .debug_macro.dwo sections. Hmmm, although this would not explain all of the mysterious .debug_macro.dwo sections. Please could you upload the hello.s file as well ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27411] [ARM] Wrong error message when assembler cannot honor width suffix ("lo register required")
https://sourceware.org/bugzilla/show_bug.cgi?id=27411 --- 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=fe0171d248e6d4cbc59c3101b9e74e18a9292294 commit fe0171d248e6d4cbc59c3101b9e74e18a9292294 Author: Nick Clifton Date: Fri Feb 26 16:37:30 2021 + Correct an error message in the ARM assembler. PR 27411 * config/tc-arm.c (do_t_add_sub): Correct error message. * testsuite/gas/arm/pr27411.s: New test. * testsuite/gas/arm/pr27411.d: New test driver. * testsuite/gas/arm/pr27411.l: Expected error output for new test. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27411] [ARM] Wrong error message when assembler cannot honor width suffix ("lo register required")
https://sourceware.org/bugzilla/show_bug.cgi?id=27411 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at redhat dot com Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- Hi Wojciech, Thanks for reporting this bug. The reason for the original error message is that the "add.n rN,#8" instruction is valid if rN is the stack pointer or pc, whereas "lsl.n sp, #8" is still invalid. Nevertheless I agree that the message is confusing and that using the same message as for lsl would be better, so I have checked in a small patch to do this, and to add a new test to the assembler testsuite. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27215] as: Error: non-constant .uleb128 is not supported on riscv64
https://sourceware.org/bugzilla/show_bug.cgi?id=27215 --- Comment #6 from Jim Wilson --- There is a problem if at least one label is in the text section. So yes, we could support this for debug info sections. On the compiler side, there is no way currently to tell the compiler that uleb128 is OK for debug section labels but not text section labels. All targets that do linker relaxation are broken with respect to uleb128 except RISC-V. The others just haven't noticed the problem yet. The problem is more noticeable for RISC-V than the other targets, because we do more linker relaxation than most other targets. See for instance https://sourceware.org/bugzilla/show_bug.cgi?id=22756#c2 for some other linker relaxation issues that are broken everywhere except RISC-V. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27408] nm: Have a way to suppress 'no symbols'
https://sourceware.org/bugzilla/show_bug.cgi?id=27408 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from Nick Clifton --- (In reply to Fangrui Song from comment #1) > Patch: https://sourceware.org/pipermail/binutils/2021-February/115340.html Patch approved - please apply. For some strange reason I cannot find your posts for this patch in my email queue, so I was unaware that you had asked for a review. So sorry for the delay and please go ahead and apply. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27407] Add --trace-symbols-from-file?
https://sourceware.org/bugzilla/show_bug.cgi?id=27407 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Hi Fangrui, Does lld support the @ command line option ? ld.bfd supports this and it allows a user to place as many command line options as they like into . So this is a more general solution to the problem and would work for options other than --trace-symbol as well. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27387] [readelf] Support -ggdb3 -gsplit-dwarf output
https://sourceware.org/bugzilla/show_bug.cgi?id=27387 --- Comment #8 from Tom de Vries --- (In reply to Nick Clifton from comment #7) > (In reply to Nick Clifton from comment #6) > > > Quick question: do you know where I can find the definition of the > > contents of a .debug_macro.dwo section in the DWARF standard ? > > Naturally as soon as I posted this question I found the answer. Section > 6.3.1. > Heh :) > But this does lead to the question - why are the version numbers 0 amd 1 > seen in some of the .debug_macro.dwo sections ? According to section 7.23 > paragraph 1 of the DWARF-5 spec, the version number should always be 5. Yeah, I see that too. If I do: ... $ gcc hello.c -ggdb3 -gsplit-dwarf -save-temps -dA ... and then grep: ... $ grep -A2 debug_macro.dwo hello.s ... I just get these type of entries: ... .section.debug_macro.dwo,"e",@progbits .Ldebug_macro0: .value 0x4 # DWARF macro version number -- .section .debug_macro.dwo,"G",@progbits,wm4.stdcpredef.h.19.006d14bbbe0dc07ba9b1ce3fdc8e40d3,comdat .Ldebug_macro1: .value 0x4 # DWARF macro version number -- ... So it this an assembler bug then? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27387] [readelf] Support -ggdb3 -gsplit-dwarf output
https://sourceware.org/bugzilla/show_bug.cgi?id=27387 --- Comment #7 from Nick Clifton --- (In reply to Nick Clifton from comment #6) > Quick question: do you know where I can find the definition of the > contents of a .debug_macro.dwo section in the DWARF standard ? Naturally as soon as I posted this question I found the answer. Section 6.3.1. But this does lead to the question - why are the version numbers 0 amd 1 seen in some of the .debug_macro.dwo sections ? According to section 7.23 paragraph 1 of the DWARF-5 spec, the version number should always be 5. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27387] [readelf] Support -ggdb3 -gsplit-dwarf output
https://sourceware.org/bugzilla/show_bug.cgi?id=27387 --- Comment #6 from Nick Clifton --- Hi Tom, > No problem :) , done. Thanks. Quick question: do you know where I can find the definition of the contents of a .debug_macro.dwo section in the DWARF standard ? I have looked and found various references to it, but no actual description of its contents. In particular I am trying to find out why readelf (and eu-readelf) complain about the version numbers in some of the headers inside the .debug_macro.dwo sections in the hello.dwo file. Of course it may be that the hello.dwo file is corrupt, but I would like to be certain before making an explicit complaint. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27128] nm -P portable output format regression
https://sourceware.org/bugzilla/show_bug.cgi?id=27128 --- Comment #7 from H.J. Lu --- (In reply to Alan Modra from comment #6) > > That said, pr25708 also had a request for a way to turn off reporting > versions, and at one stage nm had an option to conditionally display version > info. H.J., why was the version info made unconditional? What was the option name not to display symbol version? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27390] [readelf] Support DW_FORM_strx1 and DW_FORM_addrx
https://sourceware.org/bugzilla/show_bug.cgi?id=27390 Nick Clifton changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Nick Clifton --- Hi Tom, I have gone ahead and applied your patch. I am not sure why, but the problems with the references into the split dwarf file appear to have gone away. (Comment #4). Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27390] [readelf] Support DW_FORM_strx1 and DW_FORM_addrx
https://sourceware.org/bugzilla/show_bug.cgi?id=27390 --- Comment #5 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=32e4f96ceca798ad21f344e96667de9161c0b857 commit 32e4f96ceca798ad21f344e96667de9161c0b857 Author: Tom de Vries Date: Fri Feb 26 13:30:10 2021 + Add support for the split DWARF forms. PR 27390 * dwarf.c: (skip_attr_bytes): Add support for DW_FORM_str* and DW_FORM_addrx*. (read_and_display_attr_value): Likewise. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27128] nm -P portable output format regression
https://sourceware.org/bugzilla/show_bug.cgi?id=27128 --- Comment #6 from Alan Modra --- @@ and @ have different meanings in symbol definitions. sym@@ver specifies a definition of sym that satifies references to plain sym as well as sym@ver. sym@ver2 in a definition only satifies references to sym@ver2. If the tools of which you speak really need to match up symbol definitions to references then they would not have worked properly when multiple versions of a given symbol existed, prior to nm reporting versions. So I think your tools need updating, unless they are only expected to work in simple use cases. That said, pr25708 also had a request for a way to turn off reporting versions, and at one stage nm had an option to conditionally display version info. H.J., why was the version info made unconditional? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27128] nm -P portable output format regression
https://sourceware.org/bugzilla/show_bug.cgi?id=27128 Alan Modra 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 binutils/27387] [readelf] Support -ggdb3 -gsplit-dwarf output
https://sourceware.org/bugzilla/show_bug.cgi?id=27387 --- Comment #5 from Tom de Vries --- (In reply to Nick Clifton from comment #2) > Would you mind uploading the a.out and hello.dwo files please ? > > (I am not sure if the gcc that have installed here will produce > the same results as the version that you are using). No problem :) , done. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27387] [readelf] Support -ggdb3 -gsplit-dwarf output
https://sourceware.org/bugzilla/show_bug.cgi?id=27387 --- Comment #3 from Tom de Vries --- Created attachment 13266 --> https://sourceware.org/bugzilla/attachment.cgi?id=13266&action=edit a.out.gz -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27387] [readelf] Support -ggdb3 -gsplit-dwarf output
https://sourceware.org/bugzilla/show_bug.cgi?id=27387 --- Comment #4 from Tom de Vries --- Created attachment 13267 --> https://sourceware.org/bugzilla/attachment.cgi?id=13267&action=edit hello.dwo.gz -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27428] Error .eh_frame_hdr refers to overlapping FDEs
https://sourceware.org/bugzilla/show_bug.cgi?id=27428 Alan Modra changed: What|Removed |Added Target||i686-linux --- Comment #1 from Alan Modra --- What were you linking when you saw this error? A testcase would be useful. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27215] as: Error: non-constant .uleb128 is not supported on riscv64
https://sourceware.org/bugzilla/show_bug.cgi?id=27215
--- Comment #5 from Jakub Jelinek ---
Any reason why at least for now you can't add partial .{s,u}leb128 support?
I.e. support non-constant .{s,u}leb128 in .debug* sections as long as it refers
to .debug* section labels and not to code section?
I mean, the DWARF producers heavily rely on .debug* sections not being relaxed
in any way by the linker, they can have offsets computed etc. and it isn't a
normal code section.
I bet the relaxation you talk about applies to code sections, doesn't it?
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/27215] as: Error: non-constant .uleb128 is not supported on riscv64
https://sourceware.org/bugzilla/show_bug.cgi?id=27215 --- Comment #4 from Tom de Vries --- Cross-referencing gcc PR https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99090 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27215] as: Error: non-constant .uleb128 is not supported on riscv64
https://sourceware.org/bugzilla/show_bug.cgi?id=27215 Tom de Vries changed: What|Removed |Added CC||vries at gcc dot gnu.org --- Comment #3 from Tom de Vries --- Comment from dwz ml ( https://sourceware.org/pipermail/dwz/2021q1/000988.html ): ... > The construct seems like it is represented by a known constant at compile > time: > > .uleb128.Lexpr_end4 - .Lexpr_start3/* expression */ > .Lexpr_start3: > .byte0xf2 /* DW_OP_GNU_implicit_pointer */ > .4byte.Llabel2 > .sleb1280 > .Lexpr_end4: > > There isn't anything between the two labels that can have a variable > size. So it might be a good idea to file a bug report against > binutils as for not allowing this on riscv64. I believe the riscv people explain it by aggressive linker optimizations that make those not to work, but perhaps that applies to normal sections, but don't see how can that apply to .debug* sections... They shouldn't be doing any kind of aggressive linker relaxations on .debug*. ... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27387] [readelf] Support -ggdb3 -gsplit-dwarf output
https://sourceware.org/bugzilla/show_bug.cgi?id=27387 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from Nick Clifton --- Hi Tom, Would you mind uploading the a.out and hello.dwo files please ? (I am not sure if the gcc that have installed here will produce the same results as the version that you are using). Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27473] it's report error when using uftrace from binutils2.35.1
https://sourceware.org/bugzilla/show_bug.cgi?id=27473 Alan Modra changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Alan Modra --- uftrace is not part of binutils -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27456] Link failure due to the use of lstat in rename.c on MinGW
https://sourceware.org/bugzilla/show_bug.cgi?id=27456 Alan Modra changed: What|Removed |Added Target Milestone|--- |2.37 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #14 from Alan Modra --- Fixed -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27473] New: it's report error when using uftrace from binutils2.35.1
https://sourceware.org/bugzilla/show_bug.cgi?id=27473
Bug ID: 27473
Summary: it's report error when using uftrace from
binutils2.35.1
Product: binutils
Version: 2.35.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: wangmy at cn dot fujitsu.com
Target Milestone: ---
It's report error when using uftrace from binutils-2.35.1.
Is there any import changes from 2.35.1?
Here shows the problem while running uftrace on an ARM64el target board.(x86_64
and ARM32el are OK)
[test 1]
root # uftrace -a --force --no-pager ls
WARN: child terminated by signal: 7: Bus error
WARN: cannot open record data: /tmp/uftrace-live-r70C7c: No data available
[test2]
test.sh:
test="uftrace_report"
test_cpp="test.cpp"
touch $test_cpp
cat >> $test_cpp <
class A {
public:
A() {printf("A is created\n");}
~A() {printf("A is destroyed\n");}
};
int main() {
A a;
return 0;
}
EOF
g++ -pg $test_cpp
uftrace record a.out
uftrace report a.out
rm -f $test_cpp a.out
rm -rf uftrace.data
root # sh test.sh
WARN: child terminated by signal: 7: Bus error
WARN: cannot open record data: uftrace.data: No data available
--
You are receiving this mail because:
You are on the CC list for the bug.
