[Bug binutils/32459] objdump -R: dump SHT_RELR relocations?
https://sourceware.org/bugzilla/show_bug.cgi?id=32459 --- Comment #10 from Nick Clifton --- (In reply to H.J. Lu from comment #9) > Created attachment 15975 [details] > A patch Hi H.J. Well this is a nice idea, but it also raises the issue I pointed out in comment #1. Code like this makes the BFD library even more complicated than it already is, and all for a feature that is already available in the readelf program. Do we really need two different tools for displaying RELR relocations ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32741] readelf -r -D doesn't dump DT_RELR relocations
https://sourceware.org/bugzilla/show_bug.cgi?id=32741 Sam James changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=32459 CC||sam at gentoo dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32459] libbfd doesn't report RELR relocations
https://sourceware.org/bugzilla/show_bug.cgi?id=32459 H.J. Lu changed: What|Removed |Added Summary|objdump -R: dump SHT_RELR |libbfd doesn't report RELR |relocations?|relocations --- Comment #11 from H.J. Lu --- The BFD library provides: 1. bfd_get_dynamic_reloc_upper_bound to count dynamic relocations. 2. bfd_canonicalize_dynamic_reloc to retrieve dynamic reloctions. But they don't include RELR relocations. One symptom is that "objdump -R" doesn't display RELR relocations. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32459] libbfd doesn't report RELR relocations
https://sourceware.org/bugzilla/show_bug.cgi?id=32459 H.J. Lu changed: What|Removed |Added Target Milestone|--- |2.45 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32459] libbfd doesn't report RELR relocations
https://sourceware.org/bugzilla/show_bug.cgi?id=32459 --- Comment #12 from H.J. Lu --- (In reply to H.J. Lu from comment #11) > The BFD library provides: > > 1. bfd_get_dynamic_reloc_upper_bound to count dynamic relocations. > 2. bfd_canonicalize_dynamic_reloc to retrieve dynamic reloctions. > > But they don't include RELR relocations. One symptom is that > "objdump -R" doesn't display RELR relocations. A patch is posted at https://sourceware.org/pipermail/binutils/2025-February/139696.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32459] objdump -R: dump SHT_RELR relocations?
https://sourceware.org/bugzilla/show_bug.cgi?id=32459 Sam James changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=32741 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32745] The ld in binutils 2.44 produces a malfunctioning libadwaita library
https://sourceware.org/bugzilla/show_bug.cgi?id=32745 Sam James changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-02-26 Status|UNCONFIRMED |WAITING -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32745] The ld in binutils 2.44 produces a malfunctioning libadwaita library
https://sourceware.org/bugzilla/show_bug.cgi?id=32745 --- Comment #5 from Marc --- Created attachment 15981 --> https://sourceware.org/bugzilla/attachment.cgi?id=15981&action=edit Archive containing build of libadwaita with binutils 2.43.1 This archive contains a release and a debug build with all object files, binaries and log files. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32745] The ld in binutils 2.44 produces a malfunctioning libadwaita library
https://sourceware.org/bugzilla/show_bug.cgi?id=32745 --- Comment #7 from Marc --- (In reply to Sam James from comment #1) > Which binaries in the libadwaita package differ? Could you upload a bad and > good tarball, where one is built w/ binutils-2.43.1, and one is built w/ > binutils-2.44? I uploaded two archives containing all object files, binaries and log files. The object files are identical in each build, but the resulting binaries are different. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32745] The ld in binutils 2.44 produces a malfunctioning libadwaita library
https://sourceware.org/bugzilla/show_bug.cgi?id=32745 --- Comment #8 from Marc --- (In reply to Sam James from comment #2) > Also, does libadwaita's testsuite pass? Yes, the testsuite passes successfully. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32745] The ld in binutils 2.44 produces a malfunctioning libadwaita library
https://sourceware.org/bugzilla/show_bug.cgi?id=32745 Toolybird changed: What|Removed |Added CC||toolybird at tuta dot io --- Comment #4 from Toolybird --- Hi, Arch Linux bug wrangler here. I've just rebuilt libadwaita with binutils-2.44, installed it on a Gnome desktop.. and don't see any problems whatsoever. I suggest this report might be barking up the wrong tree.. and would encourage the reporter to jump into the Arch Linux support channels (Forum, IRC, etc) to seek some debugging assistance. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32745] The ld in binutils 2.44 produces a malfunctioning libadwaita library
https://sourceware.org/bugzilla/show_bug.cgi?id=32745 --- Comment #2 from Sam James --- Also, does libadwaita's testsuite pass? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32745] The ld in binutils 2.44 produces a malfunctioning libadwaita library
https://sourceware.org/bugzilla/show_bug.cgi?id=32745 --- Comment #3 from Sam James --- > they are not functional when executed. Do they crash on startup? Look wrong? Otherwise malfunction (how)? Can you give a backtrace if they crash? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/32746] New: ctf_member_info() cannot handle anonymous structs with cvr-quals
https://sourceware.org/bugzilla/show_bug.cgi?id=32746
Bug ID: 32746
Summary: ctf_member_info() cannot handle anonymous structs with
cvr-quals
Product: binutils
Version: 2.45 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libctf
Assignee: unassigned at sourceware dot org
Reporter: stephen.s.brennan at oracle dot com
Target Milestone: ---
The reproducer for this was using dtrace with libctf, with the following
minimal probe script:
fbt::do_wp_page:entry
{
this->owner = this->vmf->vma->vm_mm->owner;
}
Which gives the following error:
dtrace: failed to compile script tracewporig.d: line 3: vma is not a member of
struct vm_fault
The reason is that struct vm_fault is defined as so:
struct vm_fault {
const struct {
struct vm_area_struct *vma; /* Target VMA */
...
ctf_member_info() is supposed to be able to traverse the anonymous struct, but
due to the "const" added in here, it doesn't.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug libctf/32746] ctf_member_info() cannot handle anonymous structs with cvr-quals
https://sourceware.org/bugzilla/show_bug.cgi?id=32746
Nick Alcock changed:
What|Removed |Added
Assignee|unassigned at sourceware dot org |nick.alcock at oracle
dot com
Status|UNCONFIRMED |ASSIGNED
CC||nick.alcock at oracle dot com
Last reconfirmed||2025-02-25
Ever confirmed|0 |1
--- Comment #1 from Nick Alcock ---
Another reproducer (from the testsuite addition coming in the fix for this):
struct foo
{
int one;
const struct
{
int missing;
};
int two;
};
ctf_member_info() on struct foo will not see 'missing': nor will
ctf_member_next(), even with CTF_MN_RECURSE.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/32745] The ld in binutils 2.44 produces a malfunctioning libadwaita library
https://sourceware.org/bugzilla/show_bug.cgi?id=32745 Sam James changed: What|Removed |Added CC||sam at gentoo dot org --- Comment #1 from Sam James --- Which binaries in the libadwaita package differ? Could you upload a bad and good tarball, where one is built w/ binutils-2.43.1, and one is built w/ binutils-2.44? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32745] New: The ld in binutils 2.44 produces a malfunctioning libadwaita library
https://sourceware.org/bugzilla/show_bug.cgi?id=32745 Bug ID: 32745 Summary: The ld in binutils 2.44 produces a malfunctioning libadwaita library Product: binutils Version: 2.44 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: sourceware-bugzilla at hide dot mwcloud.eu Target Milestone: --- After updating to version 2.44 of the binutils software, ArchLinux encountered issues with the libadwaita library. While the library and demo binary can be successfully built, they are not functional when executed. This issue is specific to the library, as all binaries utilizing it encounter the same failure when run, not only the demo application. To illustrate the issue, I have prepared an example that can be found here: https://github.com/marcbull/archlinux-binutils. The issue was identified in ArchLinux and was traced back to a specific Docker image that had undergone several package updates.Preliminary analysis indicates a potential association with ld. The last working Docker image was archlinux/archlinux:base-devel-20250209.0.306672, and the first Docker image that exhibited this issue was archlinux/archlinux:base-devel-20250210.0.306967. If you build binutils 2.44 in ArchLinux and install it in /usr/local, and if you then remove all existing binutils binaries provided by the package, it will fail to build a functional libadwaita. However, if you remove all binaries except ld, it will build libadwaita as expected. -- You are receiving this mail because: You are on the CC list for the bug.
