[Bug gprofng/30679] gprofng man pages improvements
https://sourceware.org/bugzilla/show_bug.cgi?id=30679 Ruud van der Pas changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Ruud van der Pas --- The updates are upstream now. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31096] nm for mips32 (native or cross-compiled) shows 32bit addresses as sign-extended 64bit addresses
https://sourceware.org/bugzilla/show_bug.cgi?id=31096 Alan Modra changed: What|Removed |Added Assignee|nickc at redhat dot com|amodra at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/31109] gprofng not built and installed in a combined binutils+gcc build
https://sourceware.org/bugzilla/show_bug.cgi?id=31109 --- Comment #6 from Vladimir Mezentsev --- I removed only compiler errors to continue my build. Like this: % diff $old_binutils/libctf/ctf-hash.c libctf/ctf-hash.c 168,169c168,169 < else < dynhash = malloc (offsetof (ctf_dynhash_t, key_free)); --- > elsedynhash = malloc (sizeof (ctf_dynhash_t)); > 222c222 < *slot = malloc (offsetof (ctf_helem_t, owner)); --- > *slot = malloc (sizeof (ctf_helem_t)); The correct fix is needed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31106] strip --strip-debug breaks relocations
https://sourceware.org/bugzilla/show_bug.cgi?id=31106 --- Comment #6 from Stas Sergeev --- (In reply to Nick Clifton from comment #4) > (Incidentally the symbols have very strange > looking names. Is this deliberate ?) This is a so-called "RELC encoding". I've looked into binutils source to find that it even exists. :) Now my modified nasm generates such symbols. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31106] strip --strip-debug breaks relocations
https://sourceware.org/bugzilla/show_bug.cgi?id=31106 --- Comment #5 from Nick Clifton --- Addendum: It may not be the effect of stripping that causes this behaviour. Just copying the file using objcopy also shows the same effect: $ objcopy fdppkrnl.35.10.elf test.elf $ readelf -r test.elf | grep s8 2344 00026714 R_386_16 0010 >>:s8:_PGROUP~:#0[...] $ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31106] strip --strip-debug breaks relocations
https://sourceware.org/bugzilla/show_bug.cgi?id=31106 Nick Clifton changed: What|Removed |Added Assignee|unassigned at sourceware dot org |nickc at redhat dot com Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-12-04 Ever confirmed|0 |1 --- Comment #4 from Nick Clifton --- (In reply to Stas Sergeev from comment #3) > I have re-uploaded the file now > (haven't checked if the first one > was alredy stripped, but likely so) Thank you. This second version contains all the relocs, and strip does indeed behave as you described. Interestingly strip is not actually removing the relocations, but instead it is changing them, removing the references to the symbols. (Incidentally the symbols have very strange looking names. Is this deliberate ?) Anyway I am investigating to see if I can find out what strip thinks it is doing. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31106] strip --strip-debug breaks relocations
https://sourceware.org/bugzilla/show_bug.cgi?id=31106 --- Comment #3 from Stas Sergeev --- (In reply to Nick Clifton from comment #1) > Is it possible that you uploaded the stripped file ? Thank you. I have re-uploaded the file now (haven't checked if the first one was alredy stripped, but likely so) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31106] strip --strip-debug breaks relocations
https://sourceware.org/bugzilla/show_bug.cgi?id=31106 Stas Sergeev changed: What|Removed |Added Attachment #15232|0 |1 is obsolete|| --- Comment #2 from Stas Sergeev --- Created attachment 15235 --> https://sourceware.org/bugzilla/attachment.cgi?id=15235&action=edit test case Re-attaching. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31106] strip --strip-debug breaks relocations
https://sourceware.org/bugzilla/show_bug.cgi?id=31106 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- (In reply to Stas Sergeev from comment #0) Hi Stas, > Created attachment 15232 [details] > $ readelf -r fdppkrnl.35.10.elf | grep ':s8:' | wc -l > 65 Err, are you sure about this first count ? For me I only see one reloc against s8 in the original file: $ readelf -r fdppkrnl.35.10.elf | grep ':s8:' | wc -l 1 Is it possible that you uploaded the stripped file ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31096] nm for mips32 (native or cross-compiled) shows 32bit addresses as sign-extended 64bit addresses
https://sourceware.org/bugzilla/show_bug.cgi?id=31096 Nicolas Schier changed: What|Removed |Added CC||n.schier at avm dot de --- Comment #4 from Nicolas Schier --- Created attachment 15234 --> https://sourceware.org/bugzilla/attachment.cgi?id=15234&action=edit nm: Enforce 32-bit width limit when printing 32-bit values Patch is sent to binut...@sourceware.org: https://sourceware.org/pipermail/binutils/2023-December/130966.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31096] nm for mips32 (native or cross-compiled) shows 32bit addresses as sign-extended 64bit addresses
https://sourceware.org/bugzilla/show_bug.cgi?id=31096 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at sourceware dot org |nickc at redhat dot com Ever confirmed|0 |1 Last reconfirmed||2023-12-04 --- Comment #3 from Nick Clifton --- (In reply to Nicolas Schier from comment #2) > thanks for the insights and explanations, I am still a bit bewildered of > "signed address space" and its implications. Agreed. I have always felt that it was a strange choice by the MIPS designers. > Am I still missing some point? Is it really intended that `nm` shows 64-bit > addresses for mips32 targets? No - you are right, this is a bug. > If not, I plan to forward the patch to binut...@sourceware.org. Please do. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31096] nm for mips32 (native or cross-compiled) shows 32bit addresses as sign-extended 64bit addresses
https://sourceware.org/bugzilla/show_bug.cgi?id=31096
--- Comment #2 from Nicolas Schier ---
Hi Nick,
(In reply to Nick Clifton from comment #1)
> Hi Nicolas,
>
> This is actually expected behaviour.
>
> The MIPS architecture uses a signed address space, and tools configured to
> support the MIPS are aware of this. Hence the mips-linux-gnu-nm tool
> displays a signed address. Some tools however can be used on architectures
> for which they were not configured. Nm is one of these tools. So if you
> use x86_64-linux-gnu-nm on a MIPS binary, it will be able to display the
> symbols, but it will display their addresses as unsigned values, since that
> is how the x86_64 architecture treats its addresses.
>
> Basically if you want to discover information about MIPS binaries, use
> tools that are configured to support the MIPS architecture.
thanks for the insights and explanations, I am still a bit bewildered of
"signed address space" and its implications. The most irritating thing for me
is still that a mip32-native `nm` shows addresses of a mips32-native binary as
64-bit addresses, while mips32-native `objdump` shows 32-bit addresses:
$ objdump -t ../my-mips32-binary
../my-mips32-binary: file format elf32-tradlittlemips
SYMBOL TABLE:
8000 ld .note.gnu.build-id .note.gnu.build-id
8030 ld .text .text
[...]
ldf *ABS* test.c
8030 g F .text 0024 test
$ nm ../my-mips32-binary
8030 T test
For my local work, a simple patch such as:
diff --git a/binutils/nm.c b/binutils/nm.c
index e4c8036df1b..7e42ce8f469 100644
--- a/binutils/nm.c
+++ b/binutils/nm.c
@@ -1821,6 +1821,9 @@ print_value (bfd *abfd ATTRIBUTE_UNUSED, bfd_vma val)
switch (print_width)
{
case 32:
+ printf (print_format_string, 0x & (uint64_t) val);
+ break;
+
case 64:
printf (print_format_string, (uint64_t) val);
break;
would be sufficient to get the output that I expect:
$ binutils/nm-new ../mips32-test
8030 T test
here, `nm-new` is a mips32-native `nm`. A native mips64el build of `nm`
shows this:
$ binutils/nm-new /tmp/mips64el-test
8030 T test
$ binutils/nm-new /tmp/mips32-test
8030 T test
which is exactly what I had originally expected.
Am I still missing some point? Is it really intended that `nm` shows 64-bit
addresses for mips32 targets?
If not, I plan to forward the patch to binut...@sourceware.org.
Kind regards,
Nicolas
--
You are receiving this mail because:
You are on the CC list for the bug.
