[Bug ld/32003] New: Specifying --package-metadata might not be possible and is too fragile
https://sourceware.org/bugzilla/show_bug.cgi?id=32003
Bug ID: 32003
Summary: Specifying --package-metadata might not be possible
and is too fragile
Product: binutils
Version: 2.44 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: bdrung at posteo dot de
Target Milestone: ---
In Ubuntu we enabled setting ELF package metadata for the Debian package that
we build starting from Ubuntu 24.10 (oracular) on. Specifying the linker flag
--package-metadata is not possible in a robust way. All tried approaches are
either not working or too fragile:
1. The comma in the JSON value is used to split the -Wl parameter specified for
gcc:
```
$ echo "void main() { }" > test.c
$ gcc '-Wl,--package-metadata={"type":"deb","os":"ubuntu"}' test.c
/usr/bin/ld: cannot find "os":"ubuntu"}: No such file or directory
collect2: error: ld returned 1 exit status
```
2. The quotation marks in the JSON value are eaten by configure scripts and
Makefiles. Example:
```
$ echo "void main() { }" > test.c
$ printf 'test:\n\tgcc $(CFLAGS) test.c\n' > Makefile
$ env CFLAGS='-Wl,--package-metadata={"type":"deb"}' make
gcc -Wl,--package-metadata={"type":"deb"} test.c
/usr/bin/ld: warning: --package-metadata={type:deb} does not contain valid
JSON, ignoring: string or '}' expected near 'type'
```
3. Add `-specs=` to the gcc linker flags. Then this spec file could
construct the package metadata parameter. Example spec file:
```
$ cat /usr/share/dpkg/elf-package-metadata.specs
*link:
+
--package-metadata={\"type\":\"deb\",\"os\":\"%:getenv(DEB_BUILD_OS_RELEASE_ID
\",\"name\":\"%:getenv(DEB_SOURCE \",\"version\":\"%:getenv(DEB_VERSION
\",\"architecture\":\"%:getenv(DEB_HOST_ARCH \"}
```
Issue with that approach: It requires the spec file to be around and the
environment variables to be set. This will be the case during the package
build, but not at a later stage. See https://launchpad.net/bugs/2071468 for
examples where this breaks.
## Proposed solution
Add support for an `--escaped-package-metadata` parameter to the linkers that
takes a percent encoded (RFC 3986) parameter. Example:
```
-Wl,--encoded-package-metadata,%7B%22type%22:%22deb%22%2C%22os%22:%22ubuntu%22%2C%22name%22:%22dpkg%22%2C%22version%22:%221.22.6ubuntu15%22%2C%22architecture%22:%22amd64%22%7D
```
--
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
https://sourceware.org/bugzilla/show_bug.cgi?id=32003 --- Comment #1 from Benjamin Drung --- Proposed --encoded-package-metadata patches: * ld patch v4: https://sourceware.org/pipermail/binutils/2024-July/135769.html * gold patch v3: https://sourceware.org/pipermail/binutils/2024-July/135796.html -- You are receiving this mail because: You are on the CC list for the bug.
Issue 68198 in oss-fuzz: binutils:fuzz_windres: Null-dereference READ in ubsan_GetStackTrace
Updates: Labels: -deadline-approaching -restrict-view-commit Deadline-Exceeded Comment #4 on issue 68198 by sheriffbot: binutils:fuzz_windres: Null-dereference READ in ubsan_GetStackTrace https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=68198#c4 This bug has exceeded our disclosure deadline. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
[Bug binutils/32006] New: ld pulls symbols from wrong library
https://sourceware.org/bugzilla/show_bug.cgi?id=32006 Bug ID: 32006 Summary: ld pulls symbols from wrong library Product: binutils Version: 2.41 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: felix-glibc at fefe dot de Target Milestone: --- I'm not quite sure what is going on here. Basically, I'm linking a program like this: $ diet -v gcc -o t test.c -pthread -Wl,-Map,mapfile diet is a wrapper from dietlibc and it will transform the command line to this: $ gcc -nostdlib -static -L/opt/diet/lib-x86_64 /opt/diet/lib-x86_64/start.o -o t test.c -D_REENTRANT -lpthread -Wl,-Map,mapfile -isystem /opt/diet/include -D__dietlibc__ /opt/diet/lib-x86_64/libc.a -lgcc /opt/diet/lib-x86_64/crtend.o Now, there is a symbol called __stdio_init_file that is exported by fdglue2.o in libc.a and it is also exported from pthread_fdglue2.o in libpthread.a. My understanding is that ld should always satisfy references from the first library on the command line that has an export under that name (leaving trickery like weak symbols aside for now). Here's the load list from the mapfile: LOAD /opt/diet/lib-x86_64/start.o LOAD /tmp/ccnyXICz.o LOAD /opt/diet/lib-x86_64/libpthread.a LOAD /opt/diet/lib-x86_64/libc.a LOAD /usr/lib64/gcc/x86_64-pc-linux-gnu/14.1.0/libgcc.a LOAD /opt/diet/lib-x86_64/crtend.o libpthread.a is named first, then libc.a. Here's what nm says about libpthread.a: pthread_fdglue2.o: T __stdio_init_file U __stdio_init_file_nothreads Here's what nm says about libc.a: fdglue2.o: U _GLOBAL_OFFSET_TABLE_ U __errno_location U __libc_close U __stdio_atexit U __stdio_flushall W __stdio_init_file T __stdio_init_file_nothreads U __stdio_root U atexit U free U fstat U malloc Making __stdio_init_file weak is my current attempt to fix the situation but it is not helping. So both libraries export __stdio_init_file and libpthread.a is named first, yet ld takes the one from libc instead: /opt/diet/lib-x86_64/libc.a(fdglue2.o) /opt/diet/lib-x86_64/libc.a(fopen.o) (__stdio_init_file) What the hell is going on? Is this a bug in binutils ld? For good measure I tried -fuse-ld=gold (same behavior) and -fuse-ld=lld (pulls in pthread_fdglue2.o) and -fuse-ld=mold (also pulls in pthread_fdglue2.o). Have I been relying on undefined behaviour for over a decade? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30697] ppc32 mix of local-dynamic and global-dynamic TLS
https://sourceware.org/bugzilla/show_bug.cgi?id=30697 Sam James changed: What|Removed |Added See Also||https://bugs.gentoo.org/sho ||w_bug.cgi?id=909544, ||https://github.com/python/c ||python/issues/106428 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31953] Show PE objdump -P versions in human readable form
https://sourceware.org/bugzilla/show_bug.cgi?id=31953 --- Comment #5 from Nick Clifton --- Sorry - I am taking a look now... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31998] Linking with -fpic on sparc64 fails with: relocation truncated to fit: R_SPARC_GOT13
https://sourceware.org/bugzilla/show_bug.cgi?id=31998 --- Comment #2 from Sam James --- https://github.com/swig/swig/blob/9ef15fd93f3da0f16a7942cce0111e5e9b9eb481/configure.ac#L233 We should try swap it. -- 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
https://sourceware.org/bugzilla/show_bug.cgi?id=32003 H.J. Lu changed: What|Removed |Added CC||bluca at debian dot org -- 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
https://sourceware.org/bugzilla/show_bug.cgi?id=32003
--- Comment #2 from H.J. Lu ---
(In reply to Benjamin Drung from comment #0)
> In Ubuntu we enabled setting ELF package metadata for the Debian package
> that we build starting from Ubuntu 24.10 (oracular) on. Specifying the
> linker flag --package-metadata is not possible in a robust way. All tried
> approaches are either not working or too fragile:
>
> 1. The comma in the JSON value is used to split the -Wl parameter specified
> for gcc:
>
> ```
> $ echo "void main() { }" > test.c
> $ gcc '-Wl,--package-metadata={"type":"deb","os":"ubuntu"}' test.c
> /usr/bin/ld: cannot find "os":"ubuntu"}: No such file or directory
> collect2: error: ld returned 1 exit status
> ```
This is a real issue.
> 2. The quotation marks in the JSON value are eaten by configure scripts and
> Makefiles. Example:
>
> ```
> $ echo "void main() { }" > test.c
> $ printf 'test:\n\tgcc $(CFLAGS) test.c\n' > Makefile
> $ env CFLAGS='-Wl,--package-metadata={"type":"deb"}' make
> gcc -Wl,--package-metadata={"type":"deb"} test.c
> /usr/bin/ld: warning: --package-metadata={type:deb} does not contain valid
> JSON, ignoring: string or '}' expected near 'type'
> ```
The linker testcase has
"--package-metadata='{\"foo\":\"bar\"}'"
which is how this option should be used.
> 3. Add `-specs=` to the gcc linker flags. Then this spec file
> could construct the package metadata parameter. Example spec file:
>
> ```
> $ cat /usr/share/dpkg/elf-package-metadata.specs
> *link:
> +
> --package-metadata={\"type\":\"deb\",\"os\":\"%:
> getenv(DEB_BUILD_OS_RELEASE_ID \",\"name\":\"%:getenv(DEB_SOURCE
> \",\"version\":\"%:getenv(DEB_VERSION
> \",\"architecture\":\"%:getenv(DEB_HOST_ARCH \"}
> ```
>
> Issue with that approach: It requires the spec file to be around and the
> environment variables to be set. This will be the case during the package
> build, but not at a later stage. See https://launchpad.net/bugs/2071468 for
> examples where this breaks.
>
> ## Proposed solution
>
> Add support for an `--escaped-package-metadata` parameter to the linkers
> that takes a percent encoded (RFC 3986) parameter. Example:
> ```
> -Wl,--encoded-package-metadata,%7B%22type%22:%22deb%22%2C%22os%22:
> %22ubuntu%22%2C%22name%22:%22dpkg%22%2C%22version%22:%221.22.
> 6ubuntu15%22%2C%22architecture%22:%22amd64%22%7D
> ```
It is very much unreadable. The main issue is that compiler drivers eat
comma. Can we update linker to support an escape for comma which won't be
eaten by compiler drivers?
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/32006] ld pulls symbols from wrong library
https://sourceware.org/bugzilla/show_bug.cgi?id=32006 H.J. Lu changed: What|Removed |Added Resolution|--- |NOTABUG Status|UNCONFIRMED |RESOLVED --- Comment #1 from H.J. Lu --- (In reply to Felix von Leitner from comment #0) > I'm not quite sure what is going on here. > Basically, I'm linking a program like this: > > $ diet -v gcc -o t test.c -pthread -Wl,-Map,mapfile > > diet is a wrapper from dietlibc and it will transform the command line to > this: > > $ gcc -nostdlib -static -L/opt/diet/lib-x86_64 > /opt/diet/lib-x86_64/start.o -o t test.c -D_REENTRANT -lpthread > -Wl,-Map,mapfile -isystem /opt/diet/include -D__dietlibc__ > /opt/diet/lib-x86_64/libc.a -lgcc /opt/diet/lib-x86_64/crtend.o > > Now, there is a symbol called __stdio_init_file that is exported by > fdglue2.o in libc.a and it is also exported from pthread_fdglue2.o in > libpthread.a. This is expected. Please add -lpthread after libc.a. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31998] Linking with -fpic on sparc64 fails with: relocation truncated to fit: R_SPARC_GOT13
https://sourceware.org/bugzilla/show_bug.cgi?id=31998 matoro changed: What|Removed |Added Resolution|--- |INVALID URL||https://github.com/swig/swi ||g/pull/2969 Status|WAITING |RESOLVED --- Comment #3 from matoro --- Thanks, my apologies! I've opened a request to fix this with upstream swig at https://github.com/swig/swig/pull/2969 -- 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
https://sourceware.org/bugzilla/show_bug.cgi?id=32003 --- Comment #3 from H.J. Lu --- (In reply to H.J. Lu from comment #2) > It is very much unreadable. The main issue is that compiler drivers eat > comma. Can we update linker to support an escape for comma which won't be > eaten by compiler drivers? One possibility is to treat "\comma" as ','. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32006] ld pulls symbols from wrong library
https://sourceware.org/bugzilla/show_bug.cgi?id=32006 --- Comment #2 from Alan Modra --- Standard unix linkers extract an object from an archive if the object satisifies an undefined symbol reference in objects seen before the archive is searched. Ordering on the command line matters. -- You are receiving this mail because: You are on the CC list for the bug.
