[Bug binutils/32211] 2.41 and later don't seem to honor the `-z` flag
https://sourceware.org/bugzilla/show_bug.cgi?id=32211 --- Comment #17 from Dan McDonald --- (In reply to Nick Clifton from comment #16) > Hi Dan, > > (In reply to Dan McDonald from comment #15) > > 1.) Thank you for confirming there was a doc update and I should've RTFM > > more carefully. There's a philosophical argument about surprising chnages, > > but given the next item I'm not going to raise a stink. > > Thanks. I am sorry that this change caused you so much hassle. At the time > it seemed rather obvious - bss sections do not contain anything (on disk) so > disassembling them could not produce any useful information. In hindsight > of course this assumption was wrong. This all falls out of the (very old version in SmartOS's case) Node.js automatic generation of debugging symbols for itself, and tools like DTrace. > I was wondering however - exactly what is it that your testsuite is checking > for ? > Maybe there is way to conduct the test without relying on objdump to > disassemble .bss sections... SmartOS uses a (very old) version of Node.js. Its debugging support uses objdump to turn internal state values into a header file for debugging tools like DTrace and mdb_v8. I'm stuck with a very old version because Node apparently didn't value interface stability (and introduced so many breaking changes it forced a version freeze upon SmartOS & friends), but that's a history I'm not familiar with (having not been in SmartOS-land in its early days). illumos (the still-open successor of OpenSolaris) and its distributions have a strong interface stability-and-documentation culture, which can sometimes be annoying to folks, but has proven to be robust well after Oracle re-closed the barn door. > > This was educational. Thank you for your time & patience. > > And thank you for taking the time to report this problem and then persist in > helping me to understand the real issue. Persistence until resolution is also a trait of illumos culture. Thank you for understanding. I think we're good now, and it looks like this is closed so it looks like you think we're good now too. Thank you! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32211] 2.41 and later don't seem to honor the `-z` flag
https://sourceware.org/bugzilla/show_bug.cgi?id=32211 Nick Clifton changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |NOTABUG --- Comment #16 from Nick Clifton --- Hi Dan, (In reply to Dan McDonald from comment #15) > 1.) Thank you for confirming there was a doc update and I should've RTFM > more carefully. There's a philosophical argument about surprising chnages, > but given the next item I'm not going to raise a stink. Thanks. I am sorry that this change caused you so much hassle. At the time it seemed rather obvious - bss sections do not contain anything (on disk) so disassembling them could not produce any useful information. In hindsight of course this assumption was wrong. > 2.) My use of the `-fno-zero-initialized-in-bss` compiler/gcc flag cured > what ailed me. Hooray. I was wondering however - exactly what is it that your testsuite is checking for ? Maybe there is way to conduct the test without relying on objdump to disassemble .bss sections... > This was educational. Thank you for your time & patience. And thank you for taking the time to report this problem and then persist in helping me to understand the real issue. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32211] 2.41 and later don't seem to honor the `-z` flag
https://sourceware.org/bugzilla/show_bug.cgi?id=32211
--- Comment #14 from Nick Clifton ---
(In reply to Dan McDonald from comment #13)
> Did this change in 2.41 include updates in the man page or other user
> documentation? If so, sorry for missing it.
Yes. It includes this change to the binutils/doc/binutils.texi file
which gets translated into man pages as well as an info file:
@item -D
@itemx --disassemble-all
-Like @option{-d}, but disassemble the contents of all sections, not just
-those expected to contain instructions.
+Like @option{-d}, but disassemble the contents of all non-empty
+non-bss sections, not just those expected to contain instructions.
+@option{-j} may be used to select specific sections.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/32211] 2.41 and later don't seem to honor the `-z` flag
https://sourceware.org/bugzilla/show_bug.cgi?id=32211 --- Comment #15 from Dan McDonald --- 1.) Thank you for confirming there was a doc update and I should've RTFM more carefully. There's a philosophical argument about surprising chnages, but given the next item I'm not going to raise a stink. 2.) My use of the `-fno-zero-initialized-in-bss` compiler/gcc flag cured what ailed me. This was educational. Thank you for your time & patience. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32211] 2.41 and later don't seem to honor the `-z` flag
https://sourceware.org/bugzilla/show_bug.cgi?id=32211 --- Comment #13 from Dan McDonald --- (In reply to Nick Clifton from comment #12) > Hi Dan, > > I do not know if it will help, but you can work around the problem by using > the -j option to explicitly request the disassembly of the sections that > matter, eg: > > objdump -Dz 23.4-strap-libv8_base.a -j .bss.v8dbg_SmiTag -j > .data.v8dbg_SmiTagMask > This workaround will not help as there are (lemme check) 85 symbols that get dropped generating a .h file because of this. The big .a file is fed into a pipeline that wants all of the zeroed data sections (which get marked as .bss) and the non-zeroed ones (that get marked as .data). I am going to enable `-fno-zero-initialized-in-bss` and see if that helps my situation, and will report here with an update. Did this change in 2.41 include updates in the man page or other user documentation? If so, sorry for missing it. If not, that may be misleading to folks beyond me. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32211] 2.41 and later don't seem to honor the `-z` flag
https://sourceware.org/bugzilla/show_bug.cgi?id=32211 --- Comment #12 from Nick Clifton --- Hi Dan, Sorry, you are right, I was wrong. And now that I understand the problem I have been able to track down the exact commit that causes this issue: 0a3137ce4c4b Which states: There is some inconsistency between the behaviour of objdump -D and objdump -s, both supposedly operating on all sections by default. objdump -s ignores bss sections, while objdump -D dissassembles the zeros. Fix this by making objdump -D ignore bss sections too. I do not know if it will help, but you can work around the problem by using the -j option to explicitly request the disassembly of the sections that matter, eg: objdump -Dz 23.4-strap-libv8_base.a -j .bss.v8dbg_SmiTag -j .data.v8dbg_SmiTagMask Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32211] 2.41 and later don't seem to honor the `-z` flag
https://sourceware.org/bugzilla/show_bug.cgi?id=32211 --- Comment #10 from Dan McDonald --- Created attachment 15718 --> https://sourceware.org/bugzilla/attachment.cgi?id=15718&action=edit Small C program that could compile an object with the same properties as the big .a files. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32211] 2.41 and later don't seem to honor the `-z` flag
https://sourceware.org/bugzilla/show_bug.cgi?id=32211 --- Comment #11 from Dan McDonald --- Created attachment 15719 --> https://sourceware.org/bugzilla/attachment.cgi?id=15719&action=edit a.out from the C program, compiled on Ubuntu 22 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32211] 2.41 and later don't seem to honor the `-z` flag
https://sourceware.org/bugzilla/show_bug.cgi?id=32211 --- Comment #9 from Dan McDonald --- Adding a tiny C program and an a.out it generated on the Ubuntu 22 box I've been using to further demonstrate on a smaller level. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32211] 2.41 and later don't seem to honor the `-z` flag
https://sourceware.org/bugzilla/show_bug.cgi?id=32211 --- Comment #8 from Dan McDonald --- Nope. -w was intentional. it's the v8dbg_SmiTag symbol that's getting set to 0 and getting ignored. The v8dbg_SmiTagMask is set to 0x1 and is not. Something changed between 2.40 and 2.41 as far as I can tell; perhaps you should inspect diffs between those two releases to see what happened. I save the entire output on the large .a files, and here's what I see on 2.40 and earlier... Disassembly of section .data.v8dbg_SmiTagMask: : 0: 01 00 add%eax,(%eax) 2: 00 00 add%al,(%eax) Disassembly of section .bss.v8dbg_SmiTag: : 0: 00 00 add%al,(%eax) 2: 00 00 add%al,(%eax) Disassembly of section .data.v8dbg_HeapObjectTagMask: : 0: 03 00 add(%eax),%eax 2: 00 00 add%al,(%eax) And here's what I see on 2.41 and later... Disassembly of section .data.v8dbg_SmiTagMask: : 0: 01 00 add%eax,(%eax) 2: 00 00 add%al,(%eax) Disassembly of section .data.v8dbg_HeapObjectTagMask: : 0: 03 00 add(%eax),%eax 2: 00 00 add%al,(%eax) v8dbg_SmiTagMask is getting dropped, and so are all other values set to 0. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32211] 2.41 and later don't seem to honor the `-z` flag
https://sourceware.org/bugzilla/show_bug.cgi?id=32211 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #7 from Nick Clifton --- Hi Dan, (In reply to Dan McDonald from comment #3) > Run it on the provided sample files. There appears to be a problem with one of the grep command line options that you are using... I tried running one of the commands by hand and it failed, just as you are reporting: $ objdump -z -D 23.4-strap-libv8_base.a | grep -qw v8dbg_SmiTag $ echo $? 1 So I tried removing the options from grep to see if it found anything: $ objdump -z -D 23.4-strap-libv8_base.a | grep v8dbg_SmiTag Disassembly of section .data.v8dbg_SmiTagMask: : $ echo $? 0 The most likely culprit was the word option, so I restored that: $ objdump -z -D 23.4-strap-libv8_base.a | grep -w v8dbg_SmiTag $ echo $? 1 And just to confirm, if you have -q without -w, the test does still work: $ objdump -z -D 23.4-strap-libv8_base.a | grep -q v8dbg_SmiTag $ echo $? 0 > Also, is it possible that the combination of "-z -D" might be the problem? It is very unlikely. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32211] 2.41 and later don't seem to honor the `-z` flag
https://sourceware.org/bugzilla/show_bug.cgi?id=32211 --- Comment #6 from Dan McDonald --- root@ubuntu-22:~# cat x.s .text foo: .zero 10 mov %eax, %ebx root@ubuntu-22:~# gcc -c x.s root@ubuntu-22:~# file x.o x.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped root@ubuntu-22:~# objdump --version GNU objdump (GNU Binutils for Ubuntu) 2.38 Copyright (C) 2022 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) any later version. This program has absolutely no warranty. root@ubuntu-22:~# objdump -z -D x.o x.o: file format elf64-x86-64 Disassembly of section .text: : 0: 00 00 add%al,(%rax) 2: 00 00 add%al,(%rax) 4: 00 00 add%al,(%rax) 6: 00 00 add%al,(%rax) 8: 00 00 add%al,(%rax) a: 89 c3 mov%eax,%ebx root@ubuntu-22:~# as -mx86-used-note=no -o x2.o x.s root@ubuntu-22:~# objdump -z -D x2.o x2.o: file format elf64-x86-64 Disassembly of section .text: : 0: 00 00 add%al,(%rax) 2: 00 00 add%al,(%rax) 4: 00 00 add%al,(%rax) 6: 00 00 add%al,(%rax) 8: 00 00 add%al,(%rax) a: 89 c3 mov%eax,%ebx root@ubuntu-22:~# -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32211] 2.41 and later don't seem to honor the `-z` flag
https://sourceware.org/bugzilla/show_bug.cgi?id=32211 H.J. Lu changed: What|Removed |Added Status|NEW |WAITING --- Comment #5 from H.J. Lu --- Which version of binutils's objdump -z -D dumps a .bss section? Please show the output of such objdump -z -D on x.o. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32211] 2.41 and later don't seem to honor the `-z` flag
https://sourceware.org/bugzilla/show_bug.cgi?id=32211 H.J. Lu changed: What|Removed |Added Status|WAITING |NEW --- Comment #4 from H.J. Lu --- [hjl@gnu-tgl-3 tmp]$ cat x.s .bss foo: .zero 10 [hjl@gnu-tgl-3 tmp]$ as -mx86-used-note=no -o x.o x.s [hjl@gnu-tgl-3 tmp]$ objdump -z -D x.o x.o: file format elf64-x86-64 [hjl@gnu-tgl-3 tmp]$ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32211] 2.41 and later don't seem to honor the `-z` flag
https://sourceware.org/bugzilla/show_bug.cgi?id=32211 --- Comment #3 from Dan McDonald --- Run it on the provided sample files. Also, is it possible that the combination of "-z -D" might be the problem? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32211] 2.41 and later don't seem to honor the `-z` flag
https://sourceware.org/bugzilla/show_bug.cgi?id=32211 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2024-09-25 --- Comment #2 from H.J. Lu --- "objdump -z" works for me on Linux/x86: [hjl@gnu-tgl-3 tmp]$ cat x.s .text foo: .zero 10 mov %eax, %ebx [hjl@gnu-tgl-3 tmp]$ gcc -c x.s [hjl@gnu-tgl-3 tmp]$ objdump -dw x.o x.o: file format elf64-x86-64 Disassembly of section .text: : ... 8: 00 00 add%al,(%rax) a: 89 c3 mov%eax,%ebx [hjl@gnu-tgl-3 tmp]$ objdump -z -dw x.o x.o: file format elf64-x86-64 Disassembly of section .text: : 0: 00 00 add%al,(%rax) 2: 00 00 add%al,(%rax) 4: 00 00 add%al,(%rax) 6: 00 00 add%al,(%rax) 8: 00 00 add%al,(%rax) a: 89 c3 mov%eax,%ebx [hjl@gnu-tgl-3 tmp]$ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32211] 2.41 and later don't seem to honor the `-z` flag
https://sourceware.org/bugzilla/show_bug.cgi?id=32211 Dan McDonald changed: What|Removed |Added CC||danmcd at mnx dot io -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32211] 2.41 and later don't seem to honor the `-z` flag
https://sourceware.org/bugzilla/show_bug.cgi?id=32211 Dan McDonald changed: What|Removed |Added Summary|2.41 and later doesn't seem |2.41 and later don't seem |to honor the `-z` flag |to honor the `-z` flag -- You are receiving this mail because: You are on the CC list for the bug.
