[Bug ld/32003] Specifying --package-metadata might not be possible and is too fragile

2024-08-10 Thread bluca at debian dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=32003

--- Comment #28 from Luca Boccassi  ---
As user and owner of the spec, I am fine with any of those options. A slight
preference for a new command line (option A), as that means you don't need to
worry about version matching - if the new flag is there, then you can pass
encoded input, if it's not, then you know it only takes unencoded input. But
not a strong preference.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/32003] Specifying --package-metadata might not be possible and is too fragile

2024-08-10 Thread dilfridge at gentoo dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=32003

--- Comment #29 from Andreas K. Huettel  ---

> 
> Option A: Introduce a new --encoded-package-metadata parameter that takes
> the encoded string.
> 
> Option B: Extend --package-metadata to always decode the given string. As
> previously discussed, package names and version should not contain percent
> characters. So this change should not break backward compatibility.
> 

What are you going to do once you run into command line length limits
(which can be hidden in many places)?

(How much mystery data are we really talking about here?)

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/32003] Specifying --package-metadata might not be possible and is too fragile

2024-08-10 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=32003

--- Comment #30 from H.J. Lu  ---
(In reply to Benjamin Drung from comment #27)

> Option A: Introduce a new --encoded-package-metadata parameter that takes
> the encoded string.

This option isn't readable.

> Option B: Extend --package-metadata to always decode the given string. As
> previously discussed, package names and version should not contain percent
> characters. So this change should not break backward compatibility.

This is the readable option.

> Which of those proposals do you want to see implemented? My initial
> implementation is option 1A.

We should have a readable option.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/32067] ld crash in _bfd_elf_link_keep_memory when building statifier-1.7.4 with -Wl,--oformat,binary

2024-08-10 Thread cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=32067

--- Comment #4 from Sourceware Commits  ---
The master branch has been updated by H.J. Lu :

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=602f5cf7e3a82229d75998a5f6eb13753f828bb3

commit 602f5cf7e3a82229d75998a5f6eb13753f828bb3
Author: H.J. Lu 
Date:   Sat Aug 10 07:23:53 2024 -0700

ld: Add PR ld/32067 tests

Add PR ld/32067 tests with the compiler driver since the -plugin option
is needed to trigger this --oformat binary bug.

PR ld/32067
* testsuite/ld-i386/i386.exp: Run PR ld/32067 test.
* testsuite/ld-x86-64/x86-64.exp: Likewise.
* testsuite/ld-i386/start.s: Add .note.GNU-stack section.
* testsuite/ld-x86-64/pr32067.s: New file.

Signed-off-by: H.J. Lu 

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gold/32071] New: undefined weak hidden function symbols resolves to garbage

2024-08-10 Thread ishitatsuyuki at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=32071

Bug ID: 32071
   Summary: undefined weak hidden function symbols resolves to
garbage
   Product: binutils
   Version: 2.43
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: gold
  Assignee: ccoutant at gmail dot com
  Reporter: ishitatsuyuki at gmail dot com
CC: chris at smowton dot net, ian at airs dot com
  Target Milestone: ---

When there is no definition for a weak undef STT_FUNC symbol, the function's
address should resolve to absolute zero, not some random address.

In Bug 15435 gold was changed to accept weak undefs with STV_HIDDEN, however
when no definition is present it seems to resolve to some garbage address [1],
instead of zero. This is easily reproducible with the sample from the same bug.

---
extern void undefined () __attribute__((visibility("hidden")))
  __attribute__((weak));

int main ()
{
  if (&undefined != 0) return 1;
  return 0;
}
---

$ gcc main.c -fuse-ld=bfd && ./a.out; echo $?
0

$ gcc main.c -fuse-ld=gold && ./a.out; echo $?
1

$ gcc main.c -fuse-ld=lld && ./a.out; echo $?
0

$ gcc main.c -fuse-ld=mold && ./a.out; echo $?
0

[1]:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29986#note_2516917

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/32067] ld crash in _bfd_elf_link_keep_memory when building statifier-1.7.4 with -Wl,--oformat,binary

2024-08-10 Thread sam at gentoo dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=32067

--- Comment #5 from Sam James  ---
Thank you Alan and H.J.! I wasn't sure how to stop it getting there in the
first place.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/32067] ld crash in _bfd_elf_link_keep_memory when building statifier-1.7.4 with -Wl,--oformat,binary

2024-08-10 Thread amodra at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=32067

--- Comment #6 from Alan Modra  ---
HJ, when looking at the loop setting non_ir_ref_regular, I noticed the test of
info->strip in determining whether to look at debug sections' relocs.  That
seems wrong to me.  Should you allow a debug reference to a symbol to
potentially affect LTO output?

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/32067] ld crash in _bfd_elf_link_keep_memory when building statifier-1.7.4 with -Wl,--oformat,binary

2024-08-10 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=32067

--- Comment #7 from H.J. Lu  ---
(In reply to Alan Modra from comment #6)
> HJ, when looking at the loop setting non_ir_ref_regular, I noticed the test
> of info->strip in determining whether to look at debug sections' relocs. 
> That seems wrong to me.  Should you allow a debug reference to a symbol to
> potentially affect LTO output?

When debug symbols are stripped and are only referenced in debug sections,
they aren't needed for output.

-- 
You are receiving this mail because:
You are on the CC list for the bug.