[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||hjl.tools at gmail dot com -- 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 #6 from Sourceware Commits --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=91b999864f9831287f2ea6f960e8fa98e7b13ee9 commit 91b999864f9831287f2ea6f960e8fa98e7b13ee9 Author: Pali Roh?r Date: Tue Jul 23 08:52:21 2024 +0100 Improve objdump's display of PE header information. PR 31953 -- 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 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Nick Clifton --- Hi Pali, The patches are fine. I have gone ahead and checked them in. Thanks very much for solving this issue. Cheers Nick -- 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
Felix von Leitner changed:
What|Removed |Added
Resolution|NOTABUG |---
Status|RESOLVED|UNCONFIRMED
--- Comment #3 from Felix von Leitner ---
Sorry for still pestering you about this, but let's examine the problem more
closely.
$ cat a.c
extern int a();
extern int b(); extern int b_dep();
int main() {
a();
b();
}
$ cat a_first.c
int a() { return 0; }
__asm(".section .gnu.warning.a\n.string \"a from a_first\"\n.previous");
$ cat a_second.c
int a() { return 1; }
__asm(".section .gnu.warning.a\n.string \"a from a_second\"\n.previous");
$ cat b_first.c
extern int b_dep();
int b() { return b_dep(); }
$ cat b_dep_first.c
int b_dep() { return 0; }
__asm(".section .gnu.warning.b_dep\n.string \"b_dep from
b_dep_first\"\n.previous");
$ cat b_dep_second.c
int b_dep() { return 1; }
__asm(".section .gnu.warning.b_dep\n.string \"b_dep from
b_dep_second\"\n.previous");
$ gcc -c *.c
$ ar cru first.a a_first.o b_first.o b_dep_first.o
$ ar cru second.a a_second.o b_dep_second.o
$
Remember, I want one library to reliably overrule the other one.
This setup exercises two scenarios. Scenario 1: I call a() that is in first.a
and second.a. Second, I call b() that is in first.a but calls b_dep() that is
in both libraries.
I need a way to make sure one library always wins.
I added some linker warnings so we can see which object was pulled in.
Let's see what happens:
$ gcc -o a a.c first.a second.a
a.c:(.text+0xa): warning: a from a_first
b_first.c:(.text+0xa): warning: b_dep from b_dep_first
$
Please explain that to me. You just told me to put libpthread.a AFTER libc.a so
that it overrules it.
But it gets wilder:
$ gcc -o a a.c second.a first.a
a.c:(.text+0xa): warning: a from a_second
b_first.c:(.text+0xa): warning: b_dep from b_dep_first
$
As you can see, when I switch the libraries the first one does NOT reliably
win. Now it wins if I reference the symbol from the main program, but not if
the symbol is referenced by something from inside the library.
Please advise how I can get the effect I need. I hope you don't expect me to do
preprocessor trickery to name symbols differently. The goal was to implement a
libpthread.a. That should work even if you don't have the source code for parts
of the program you are trying to link.
--
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 Jan Beulich changed: What|Removed |Added CC||jbeulich at suse dot com --- Comment #4 from Jan Beulich --- (In reply to H.J. Lu from comment #3) > One possibility is to treat "\comma" as ','. Yet introducing another escape character would come with further complexity. It also looks to me as if the %-encoding of double-quotes dominated that of commas in the example provided. I'm inclined to suggest to extend the %-encoding scheme instead; that way what's going to be in 2.43 is not at risk of subtle breakage when support further escaping sequences is added. All that needs to be made sure is for existing escaping sequences to retain their original meaning. What the best scheme here would be is likely better determined by people who make active use of the feature (knowing what set of characters it is that frequently would need escaping one way or the other). I'd be inclined to borrow naming e.g. from HTML's Named Character References, and then use, say, "%[comma]" or "%comma;" to have proper delimiting on both ends. -- 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 Reto Schneider changed: What|Removed |Added CC||c...@reto-schneider.ch -- 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 #5 from H.J. Lu --- I am against the proposed solution. The solution should be as close to the normal JSON syntax as possible and linker tests should cover +90% of use cases. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32014] New: RISC-V: -flto causes .riscv.attributes section to ignore specified extensions
https://sourceware.org/bugzilla/show_bug.cgi?id=32014
Bug ID: 32014
Summary: RISC-V: -flto causes .riscv.attributes section to
ignore specified extensions
Product: binutils
Version: 2.44 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: patrick at rivosinc dot com
Target Milestone: ---
Created attachment 15640
--> https://sourceware.org/bugzilla/attachment.cgi?id=15640&action=edit
Temp files/command outputs
func.c:
extern short a;
void test() { a = a < 0 ? a : 0; }
driver.c:
short a;
void test();
int main() { test(); }
Commands:
> /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/riscv64-unknown-linux-gnu-gcc
> -march=rv64g_zbkb -O3 -flto -c func.c -o func.o -v > func-flto-log.txt 2>&1
> /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/riscv64-unknown-linux-gnu-gcc
> -O3 -flto -c driver.c -o driver.o -v > driver-flto-log.txt 2>&1
> /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/riscv64-unknown-linux-gnu-gcc
> driver.o func.o -o user-config.out -v -save-temps > flto-together-log.txt
> 2>&1
> /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/riscv64-unknown-linux-gnu-readelf
> -a user-config.out > user-config-dump.txt
...
Tag_RISCV_arch:
"rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_v1p0_zicsr2p0_zifencei2p0_zmmul1p0_zaamo1p0_zalrsc1p0_zca1p0_zcd1p0_zve32f1p0_zve32x1p0_zve64d1p0_zve64f1p0_zve64x1p0_zvl128b1p0_zvl32b1p0_zvl64b1p0"
^ This arch string is missing zbkb.
With func-no-lto.o:
> /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/riscv64-unknown-linux-gnu-gcc
> -march=rv64g_zbkb -O3 -c func.c -o func-no-lto.o -v > func-no-flto-log.txt
> 2>&1
> /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/riscv64-unknown-linux-gnu-gcc
> driver.o func-no-lto.o -o user-config-mixed.out -v -save-temps >
> flto-mixed-log.txt 2>&1
> /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/riscv64-unknown-linux-gnu-readelf
> -a user-config-mixed.out > user-config-mixed-dump.txt
...
Tag_RISCV_arch:
"rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_v1p0_zicsr2p0_zifencei2p0_zmmul1p0_zaamo1p0_zalrsc1p0_zca1p0_zcd1p0_zbkb1p0_zve32f1p0_zve32x1p0_zve64d1p0_zve64f1p0_zve64x1p0_zvl128b1p0_zvl32b1p0_zvl64b1p0"
This can also be shown with extensions that modify generated code (eg.
xtheadbb) but I thought it'd be better to use an example without vendor
extensions.
>From poking around the lto/non-lto'd object files there isn't anything
immediately obvious that's causing this issue. func.o and func-no-lto.o both
have the correct .riscv.attribute ISA string.
AFAICT the only difference between the verbose gcc logs are which files get
passed into lto-wrapper.
Tested using binutils a606ff9b090, GCC tip-of-tree (a3f03891065).
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/32014] RISC-V: -flto causes .riscv.attributes section to ignore specified extensions
https://sourceware.org/bugzilla/show_bug.cgi?id=32014 Patrick O'Neill changed: What|Removed |Added Target||riscv*-*-* CC||nelsonc1225 at sourceware 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 #6 from Benjamin Drung ---
(In reply to H.J. Lu from comment #2)
> > 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.
That linker testcase snippet is evaluated to:
--package-metadata='{"foo":"bar"}'
Passing that to a shell or makefile works, because the singe quotes protect the
JSON content inside. But this escaping protects this snippet from evaluating
only once. The problem is that the linker flag can be passed around and
evaluated multiple times. This will happen easily during Debian package build,
where debian/rules is a Makefile that calls the project build system (that can
use makefiles as well).
Simple example that shows the problem:
```
$ cat example.c
#include
void main() {
printf("Hello world!");
}
$ cat Makefile2
all: example
%: %.c
gcc $(LDFLAGS) -o $@ $<
.PHONY: all
$ cat Makefile
all:
make -f Makefile2 all LDFLAGS=$(LDFLAGS)
.PHONY: all
$ LANG=C make LDFLAGS="-Wl,--package-metadata='{\"foo\":\"bar\"}'"
make -f Makefile2 all LDFLAGS=-Wl,--package-metadata='{"foo":"bar"}'
make[1]: Entering directory 'makefile2'
gcc -Wl,--package-metadata={"foo":"bar"} -o example example.c
/usr/bin/ld: warning: --package-metadata={foo:bar} does not contain valid JSON,
ignoring: string or '}' expected near 'foo'
make[1]: Leaving directory 'makefile2'
```
I am very confident to find a real world Debian package that will resemble this
example. There is no way to programmatically determine how many times the
linker flag needs to be escaped for each individual Debian package build.
Fixing those cases by quoting will be a lot of work and might not cover all
cases (i.e. it will be a fragile approach).
> > ## 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?
The encoding is flexible and you could just encode the characters that are
problematic in your case:
-Wl,--encoded-package-metadata,{"type":"deb"%2C"os":"ubuntu"%2C"name":"dpkg"%2C"version":"1.22.6ubuntu15"%2C"architecture":"amd64"}
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/31728] dlltool generates incorrect hints in import libraries
https://sourceware.org/bugzilla/show_bug.cgi?id=31728 --- Comment #15 from Pali Rohár --- Hello Nick, have you looked at those test cases? -- 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 Thomas Jahns changed: What|Removed |Added CC||jahns at dkrz dot de --- Comment #4 from Thomas Jahns --- My understanding is that __stdio_init_file should be in an object file separate from the one using it in libc.a because static linkage means no late binding of symbols will occur. -- 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 #5 from Felix von Leitner --- (In reply to Thomas Jahns from comment #4) > My understanding is that __stdio_init_file should be in an object file > separate from the one using it in libc.a because static linkage means no > late binding of symbols will occur. I'm not sure what you are trying to say. a) It is in a different object file. b) Nobody is talking about late binding here. It is precisedly in a different object file so that the linker can replace that object file with the one from libpthread. That's why it is its own function to begin with. -- 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 #7 from H.J. Lu ---
(In reply to Benjamin Drung from comment #6)
> The encoding is flexible and you could just encode the characters that are
> problematic in your case:
>
> -Wl,--encoded-package-metadata,{"type":"deb"%2C"os":"ubuntu"%2C"name":
> "dpkg"%2C"version":"1.22.6ubuntu15"%2C"architecture":"amd64"}
Doesn't this have the same issue with '"'?
--
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 #6 from H.J. Lu --- (In reply to Felix von Leitner from comment #3) > Please explain that to me. You just told me to put libpthread.a AFTER libc.a > so that it overrules it. What I meant was to use -lpthread ... libc.a ... -lpthreadd -- 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 #7 from Thomas Jahns --- What I meant was that I think static resolution of symbols from the same object file is different from lookups in other files. Also the documentation of option --start-group option suggests that symbols should be resolved strictly left to right, unless that option is used, i.e. $ 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__ -Wl,--start-group /opt/diet/lib-x86_64/libc.a -lgcc -Wl,--end-group /opt/diet/lib-x86_64/crtend.o should provide the expected behaviour. -- 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 #8 from Thomas Jahns --- Sorry, my fault, misplaced the group flags, should be: $ gcc -nostdlib -static -L/opt/diet/lib-x86_64 /opt/diet/lib-x86_64/start.o -o t test.c -D_REENTRANT -Wl,--start-group -lpthread -Wl,-Map,mapfile -isystem /opt/diet/include -D__dietlibc__ /opt/diet/lib-x86_64/libc.a -Wl,--end-group -lgcc /opt/diet/lib-x86_64/crtend.o -- 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 #8 from Benjamin Drung ---
(In reply to H.J. Lu from comment #7)
> (In reply to Benjamin Drung from comment #6)
>
> > The encoding is flexible and you could just encode the characters that are
> > problematic in your case:
> >
> > -Wl,--encoded-package-metadata,{"type":"deb"%2C"os":"ubuntu"%2C"name":
> > "dpkg"%2C"version":"1.22.6ubuntu15"%2C"architecture":"amd64"}
>
> Doesn't this have the same issue with '"'?
Yes, this example parameter needs to be quoted in case it is used in shell (or
multiple times quoted in case it is parsed multiple times). I just wanted to
make the point that the percent-encoding can be used sparsely to only encode
the characters that are problematic in the specific use-case. So in case you
control the whole build pipeline, you can quote just the comma. If you want to
pass this flag into a random projects, you can encode the quotation marks as
well.
--
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 Last reconfirmed||2024-07-23 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #9 from H.J. Lu --- --package-metadata doesn't work with shell, compiler driver nor make. The new solution should support for JSON codes with shell, compiler driver and make. It should be human readable. For non-working --package-metadata, we should either remove it or fix it. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/32016] New: ld.gold error unsupported -mbss-plt code
https://sourceware.org/bugzilla/show_bug.cgi?id=32016 Bug ID: 32016 Summary: ld.gold error unsupported -mbss-plt code Product: binutils Version: 2.40 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: judge.packham+glibc at gmail dot com CC: ian at airs dot com Target Milestone: --- I'm experimenting with adding ld.gold as an option to our toolchains but I'm hitting an error. This happens to be from the lxcfs package which tries to use ld.gold if it's available. This only seems to affect our powerpc 32 builds. Other architectures seem fine. I've tried with and without -mbss-plt in $CFLAGS. I'm not sure if this is a compiler issue, linker issue or just a problem with the flags we are passing The error is $ powerpc-e500mc-linux-gnu-gcc -o liblxcfs.so liblxcfs.so.p/src_bindings.c.o liblxcfs.so.p/src_cgroups_cgfsng.c.o liblxcfs.so.p/src_cgroups_cgroup.c.o liblxcfs.so.p/src_cgroups_cgroup2_devices.c.o liblxcfs.so.p/src_cgroups_cgroup_utils.c.o liblxcfs.so.p/src_cgroup_fuse.c.o liblxcfs.so.p/src_cpuset_parse.c.o liblxcfs.so.p/src_lxcfs.c.o liblxcfs.so.p/src_proc_cpuview.c.o liblxcfs.so.p/src_proc_fuse.c.o liblxcfs.so.p/src_proc_loadavg.c.o liblxcfs.so.p/src_sysfs_fuse.c.o liblxcfs.so.p/src_utils.c.o -Wl,--as-needed -Wl,--allow-shlib-undefined -shared -fPIC -Wl,--gc-sections -Wl,-z,relro -Wl,-z,now -Wl,-fuse-ld=gold --sysroot=/usr/src/output/ppc_e500mc/lxcfs/staging -pthread -Wl,--start-group /usr/src/output/ppc_e500mc/lxcfs/staging/usr/lib/libfuse3.so -lpthread -Wl,--end-group /usr/bin/../lib/gcc/powerpc-e500mc-linux-gnu/13.2.0/../../../../powerpc-e500mc-linux-gnu/bin/ld.gold: error: /usr/bin/../lib/gcc/powerpc-e500mc-linux-gnu/13.2.0/crtbeginS.o: unsupported -mbss-plt code /usr/bin/../lib/gcc/powerpc-e500mc-linux-gnu/13.2.0/../../../../powerpc-e500mc-linux-gnu/bin/ld.gold: error: /usr/bin/../lib/gcc/powerpc-e500mc-linux-gnu/13.2.0/crtbeginS.o: unsupported -mbss-plt code /usr/bin/../lib/gcc/powerpc-e500mc-linux-gnu/13.2.0/../../../../powerpc-e500mc-linux-gnu/bin/ld.gold: error: /usr/bin/../lib/gcc/powerpc-e500mc-linux-gnu/13.2.0/crtbeginS.o: unsupported -mbss-plt code /usr/bin/../lib/gcc/powerpc-e500mc-linux-gnu/13.2.0/../../../../powerpc-e500mc-linux-gnu/bin/ld.gold: error: liblxcfs.so.p/src_bindings.c.o: unsupported -mbss-plt code ... I don't really understand what ld.gold is complaining about. My options right now are to not build that package for powerpc 32 or to not have ld.gold available for powerpc 32. Both of those options aren't too terrible but if it were a case of simply passing the right arguments then having ld.gold available would be nicer. -- 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 #10 from Luca Boccassi --- (In reply to H.J. Lu from comment #9) > For non-working --package-metadata, we should either remove it or fix it. Sorry, but this is absolutely wrong, as the existing option works just fine. I do not mind if you add other options, but the existing one cannot be removed, as it is in active use in production, and it will remain in active use in production for the foreseeable future - I have no intention nor plan of stopping its use, even if there are alternatives. It works just fine either directly with some escaping, or indirectly via a spec file. Again, no problem with adding alternative options if you want to have them, absolutely fine to do so, but just not at the expense of the current one. -- 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 #11 from Benjamin Drung ---
(In reply to H.J. Lu from comment #9)
> It should be human readable.
What do you recommend? IMO percent-escaping is readable enough and increases
the size of the already long string not too much.
The encoding of the JSON
{"type":"deb","os":"ubuntu","name":"dpkg","version":"1.22.6ubuntu15","architecture":"amd64"}
would be:
-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
At first it might look confusing, but the relevant strings can be seen on a
second look: "type", "deb", "os", "ubuntu", "name", "dpkg", "version",
"1.22.6ubuntu15", "architecture", "amd64". Only the beginning of the version
number is harder to see.
There are multiple tools that can encode/decode it. For example Python's
urllib.parse.unquote and urllib.parse.quote.
I am open for better encodings. I am open for making --package-metadata
percent-decode the value instead of adding a new parameter. Percents are
relative safe encoding option. The Debian package name and the Debian version
are not allowed to contain percents. The os, type, and architecture will not
have percents in them.
--
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 #12 from H.J. Lu ---
(In reply to Benjamin Drung from comment #11)
> (In reply to H.J. Lu from comment #9)
> > It should be human readable.
>
> What do you recommend? IMO percent-escaping is readable enough and increases
> the size of the already long string not too much.
>
> The encoding of the JSON
> {"type":"deb","os":"ubuntu","name":"dpkg","version":"1.22.6ubuntu15",
> "architecture":"amd64"} would be:
>
> -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
>
> At first it might look confusing, but the relevant strings can be seen on a
> second look: "type", "deb", "os", "ubuntu", "name", "dpkg", "version",
> "1.22.6ubuntu15", "architecture", "amd64". Only the beginning of the version
> number is harder to see.
>
> There are multiple tools that can encode/decode it. For example Python's
> urllib.parse.unquote and urllib.parse.quote.
>
> I am open for better encodings. I am open for making --package-metadata
> percent-decode the value instead of adding a new parameter. Percents are
> relative safe encoding option. The Debian package name and the Debian
> version are not allowed to contain percents. The os, type, and architecture
> will not have percents in the
%22 isn't human readable. Do we need to escape { and }? We need to escape "
and ,. Should $ be supported in JSON code? Will "%[string]" escape work?
--
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 #13 from Benjamin Drung ---
(In reply to H.J. Lu from comment #12)
> (In reply to Benjamin Drung from comment #11)
> > (In reply to H.J. Lu from comment #9)
> > > It should be human readable.
> >
> > What do you recommend? IMO percent-escaping is readable enough and increases
> > the size of the already long string not too much.
> >
> > The encoding of the JSON
> > {"type":"deb","os":"ubuntu","name":"dpkg","version":"1.22.6ubuntu15",
> > "architecture":"amd64"} would be:
> >
> > -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
> >
> > At first it might look confusing, but the relevant strings can be seen on a
> > second look: "type", "deb", "os", "ubuntu", "name", "dpkg", "version",
> > "1.22.6ubuntu15", "architecture", "amd64". Only the beginning of the version
> > number is harder to see.
> >
> > There are multiple tools that can encode/decode it. For example Python's
> > urllib.parse.unquote and urllib.parse.quote.
> >
> > I am open for better encodings. I am open for making --package-metadata
> > percent-decode the value instead of adding a new parameter. Percents are
> > relative safe encoding option. The Debian package name and the Debian
> > version are not allowed to contain percents. The os, type, and architecture
> > will not have percents in the
>
> %22 isn't human readable. Do we need to escape { and }?
Maybe escaping { and } is not needed.
> We need to escape " and ,.
Those two are definitively needed to be escaped.
> Should $ be supported in JSON code?
$ needs to be escaped for shells. Theoretically $ might be part of a string.
> Will "%[string]" escape work?
Like this?
-Wl,--encoded-package-metadata={%[quot]type%[quot]:%[quot]deb%[quot]%[comma]%[quot]os%[quot]:%[quot]ubuntu%[quot]%[comma]%[quot]name%[quot]:%[quot]dpkg%[quot]%[comma]%[quot]version%[quot]:%[quot]1.22.6ubuntu15%[quot]%[comma]%[quot]architecture%[quot]:%[quot]amd64%[quot]}
This might work, but it is much longer. IMO on a scale from human readable to
random character this is insignificantly more readable. A longer parameter
makes it harder to find the relevant log output (in case of problems unrelated
to the package metadata) and the log files will be bigger. Debian package tend
to print all calls with all compiler parameters.
--
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 #14 from H.J. Lu ---
(In reply to Benjamin Drung from comment #13)
> > Will "%[string]" escape work?
>
> Like this?
>
> -Wl,--encoded-package-metadata={%[quot]type%[quot]:
> %[quot]deb%[quot]%[comma]%[quot]os%[quot]:
> %[quot]ubuntu%[quot]%[comma]%[quot]name%[quot]:
> %[quot]dpkg%[quot]%[comma]%[quot]version%[quot]:%[quot]1.22.
> 6ubuntu15%[quot]%[comma]%[quot]architecture%[quot]:%[quot]amd64%[quot]}
It should be %[quote]". Will adding support for "%[string]" to existing
--package-metadata option break anything?
> This might work, but it is much longer. IMO on a scale from human readable
> to random character this is insignificantly more readable. A longer
> parameter makes it harder to find the relevant log output (in case of
> problems unrelated to the package metadata) and the log files will be
Is this a real problem? "grep" should work.
> bigger. Debian package tend to print all calls with all compiler parameters.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/32017] New: Linker failed to check invalid TLS sequence
https://sourceware.org/bugzilla/show_bug.cgi?id=32017 Bug ID: 32017 Summary: Linker failed to check invalid TLS sequence Product: binutils Version: 2.44 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: hjl.tools at gmail dot com Target Milestone: --- Target: x86-64 [hjl@gnu-tgl-3 tmp]$ cat tlsie5.s .text .globl _start _start: xorq%rax, foo@GOTTPOFF(%rip), %rax movq(%rax), %rax .globl foo .section.tdata,"awT",@progbits .align 4 .type foo, @object .size foo, 4 foo: .long 100 [hjl@gnu-tgl-3 tmp]$ gcc -c tlsie5.s [hjl@gnu-tgl-3 tmp]$ ld tlsie5.o [hjl@gnu-tgl-3 tmp]$ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32001] Untranslated part in error message of elfxx-riscv.c:2466
https://sourceware.org/bugzilla/show_bug.cgi?id=32001
Nelson Chu changed:
What|Removed |Added
CC||nelsonc1225 at sourceware dot
org
--- Comment #1 from Nelson Chu ---
Since the riscv_update_subset1 is shared by .option arch and
riscv_implicit_subsets table, the previous one is for normal users, and the
later one is for developers.
When developing, I added the following wrong code,
diff --git a/bfd/elfxx-riscv.c b/bfd/elfxx-riscv.c
index b3adbed1913..2e9e42c4b62 100644
--- a/bfd/elfxx-riscv.c
+++ b/bfd/elfxx-riscv.c
@@ -1269,6 +1269,7 @@ static struct riscv_implicit_subset
riscv_implicit_subsets[] =
{"svade", "+zicsr", check_implicit_always},
{"svadu", "+zicsr", check_implicit_always},
{"svbare", "+zicsr", check_implicit_always},
+ {"i", "+unknown_implicit", check_implicit_always},
{NULL, NULL, NULL}
};
When user added the wrong user assembly,
% cat tmp.s
.option arch, +unknown_arch
%
~/work/build-upstream/build-elf64-upstream/build-install/bin/riscv64-unknown-elf-as
tmp.s -o tmp.o
Assembler messages:
Error: internal: unknown ISA extension `unknown_implicit' in
riscv_implicit_subsets `+unknown_implicit'
tmp.s:1: Error: unknown ISA extension `unknown_arch' in .option arch
`+unknown_arch'
The two errors seems reasonable to me, so what error messages that you think
should be correct? Thanks.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/31969] [RISCV] -static -pie produces GOT dependent code
https://sourceware.org/bugzilla/show_bug.cgi?id=31969 Nelson Chu changed: What|Removed |Added CC||nelsonc1225 at sourceware dot org --- Comment #1 from Nelson Chu --- Since we don't have the relaxation for got, we still use auipc+lw to get the _vector_table from the got entry, but linker needs to fill the static value into there. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32018] New: Compilation of binutils 2.43 for riscv64-unknown-linux-gnu failed on CentOS 6
https://sourceware.org/bugzilla/show_bug.cgi?id=32018 Bug ID: 32018 Summary: Compilation of binutils 2.43 for riscv64-unknown-linux-gnu failed on CentOS 6 Product: binutils Version: 2.43 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: bigmagicreadsun at gmail dot com Target Milestone: --- Fetch the source code from the latest branch of binutils and configure it with the following options: ../configure --prefix=/home/tools --target=riscv64-unknown-linux-gnu --disable-nls --disable-werror --enable-new-dtags --disable-gdb --disable-sim --disable-libdecnumber --disable-readline When running make to compile, the following error occurs: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../../gprofng/libcollector -U_ASM -I.. -I../../../gprofng/libcollector -I../../../gprofng/libcollector/../common -I../../../gprofng/libcollector/../src -I../../../gprofng/libcollector/../../include -I../../bfd -I../../../gprofng/libcollector/../.. -Wall -Wno-nonnull-compare -g -O2 -MT libgp_collector_la-hwprofile.lo -MD -MP -MF .deps/libgp_collector_la-hwprofile.Tpo -c ../../../gprofng/libcollector/hwprofile.c -fPIC -DPIC -o .libs/libgp_collector_la-hwprofile.o In file included from /usr/include/string.h:637, from ../../../gprofng/libcollector/../common/hwcdrv.h:37, from ../../../gprofng/libcollector/hwprofile.c:35: ../../../gprofng/libcollector/hwprofile.c: In function ‘open_experiment’: ../../../gprofng/libcollector/hwprofile.c:219:27: error: expected identifier before ‘(’ token params = CALL_UTIL (strchr)(params, ';'); ^~ ../../../gprofng/libcollector/hwprofile.c:219:16: note: in expansion of macro ‘CALL_UTIL’ params = CALL_UTIL (strchr)(params, ';'); ^ ../../../gprofng/libcollector/hwprofile.c:225:24: error: expected identifier before ‘(’ token char *s = CALL_UTIL (strchr)(params, (int) ';'); ^~ ../../../gprofng/libcollector/hwprofile.c:225:13: note: in expansion of macro ‘CALL_UTIL’ char *s = CALL_UTIL (strchr)(params, (int) ';'); ^ make[5]: *** [Makefile:715: libgp_collector_la-hwprofile.lo] Error 1 make[5]: Leaving directory '/home/riscv-gnu-toolchain-upstream/binutils/build/gprofng/libcollector' make[4]: *** [Makefile:478: all] Error 2 make[4]: Leaving directory '/home/riscv-gnu-toolchain-upstream/binutils/build/gprofng/libcollector' make[3]: *** [Makefile:472: all-recursive] Error 1 make[3]: Leaving directory '/home/riscv-gnu-toolchain-upstream/binutils/build/gprofng' make[2]: *** [Makefile:404: all] Error 2 make[2]: Leaving directory '/home/riscv-gnu-toolchain-upstream/binutils/build/gprofng' make[1]: *** [Makefile:7319: all-gprofng] Error 2 make[1]: Leaving directory '/home/riscv-gnu-toolchain-upstream/binutils/build' make: *** [Makefile:1028: all] Error 2 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32018] Compilation of binutils 2.43 for riscv64-unknown-linux-gnu failed on CentOS 6
https://sourceware.org/bugzilla/show_bug.cgi?id=32018 --- Comment #1 from bigmagicreadsun --- I am currently using the Docker version of CentOS 6. The GCC version is gcc version 8.3.1 20190311 (Red Hat 8.3.1-3) (GCC) and GLIBC version is (GNU libc) 2.12 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32001] Untranslated part in error message of elfxx-riscv.c:2466
https://sourceware.org/bugzilla/show_bug.cgi?id=32001
--- Comment #2 from Frederic Marchal ---
Both messages are:
Error: internal: unknown ISA extension `unknown_implicit' in
riscv_implicit_subsets
Error: unknown ISA extension `unknown_arch' in .option arch
Try to display the first message in a foreign language. You'll see that
"internal:" is NOT translated.
I suspect a proper patch would be
const char *errmsg_internal = explicit_subset == NULL ? "" : _("internal: ");
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/32001] Untranslated part in error message of elfxx-riscv.c:2466
https://sourceware.org/bugzilla/show_bug.cgi?id=32001 --- Comment #3 from Sourceware Commits --- The master branch has been updated by Nelson Chu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=91a84aaf9a1c72d3b56c8cbc55d32327cdcfb8ce commit 91a84aaf9a1c72d3b56c8cbc55d32327cdcfb8ce Author: Nelson Chu Date: Wed Jul 24 13:03:48 2024 +0800 RISC-V: PR32001, Untranslated "internal:" prefix for error message. bfd/ PR 32001 * elfxx-riscv.c (riscv_update_subset1): Fixed the untranslated "internal:" prefix for error message. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32017] Linker failed to check invalid TLS sequence
https://sourceware.org/bugzilla/show_bug.cgi?id=32017 Sam James changed: What|Removed |Added CC||sam at gentoo dot org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=116043, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=103275, ||https://sourceware.org/bugz ||illa/show_bug.cgi?id=28595 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28595] glibc-2.34 build fails with linker error (TLS transition from R_386_TLS_GOTIE to R_386_TLS_LE_32 against `__libc_tsd_CTYPE_B' at 0xf4 in section `.text' failed)
https://sourceware.org/bugzilla/show_bug.cgi?id=28595 Sam James changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=32017 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32017] Linker failed to check invalid TLS sequence
https://sourceware.org/bugzilla/show_bug.cgi?id=32017 --- Comment #1 from Sam James --- Thanks. For the improved message on already-diagnosed conditions, I was going to file a bug today, and you beat me with a patch :) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/32018] Compilation of binutils 2.43 for riscv64-unknown-linux-gnu failed on CentOS 6
https://sourceware.org/bugzilla/show_bug.cgi?id=32018 Sam James changed: What|Removed |Added CC||sam at gentoo dot org Assignee|unassigned at sourceware dot org |vladimir.mezentsev at oracle dot c ||om Component|binutils|gprofng -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/32018] Compilation of binutils 2.43 for riscv64-unknown-linux-gnu failed on CentOS 6
https://sourceware.org/bugzilla/show_bug.cgi?id=32018 Sam James changed: What|Removed |Added CC|sam at gentoo 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 #15 from Jan Beulich ---
(In reply to Benjamin Drung from comment #6)
> That linker testcase snippet is evaluated to:
>
> --package-metadata='{"foo":"bar"}'
>
> Passing that to a shell or makefile works, because the singe quotes protect
> the JSON content inside. But this escaping protects this snippet from
> evaluating only once. The problem is that the linker flag can be passed
> around and evaluated multiple times. This will happen easily during Debian
> package build, where debian/rules is a Makefile that calls the project build
> system (that can use makefiles as well).
That, however, is a problem of the build system. Passing around potentially
quoted strings needs special care, to retain quotation. The issue isn't unique
to Debian; see e.g. the Linux kernel's "escsq" and its uses (and how it further
protects e.g. # and $$).
Imo it's just the commas which are the main problem here, as -Wl,... in the
compiler has - afaik - no way of escaping them.
--
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 #16 from Jan Beulich --- (In reply to H.J. Lu from comment #14) > It should be %[quote]". Will adding support for "%[string]" to existing > --package-metadata option break anything? You won't know until someone reports a problem. We simply don't know what people might be using. -- 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 #17 from H.J. Lu --- (In reply to Jan Beulich from comment #16) > (In reply to H.J. Lu from comment #14) > > It should be %[quote]". Will adding support for "%[string]" to existing > > --package-metadata option break anything? > > You won't know until someone reports a problem. We simply don't know what > people might be using. It is a new option and only supports very limited JSON code. Can Debian people provide feedbacks on adding "%[string]" to existing --package-metadata option? -- 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 #18 from H.J. Lu ---
(In reply to Jan Beulich from comment #15)
> (In reply to Benjamin Drung from comment #6)
> > That linker testcase snippet is evaluated to:
> >
> > --package-metadata='{"foo":"bar"}'
> >
> > Passing that to a shell or makefile works, because the singe quotes protect
> > the JSON content inside. But this escaping protects this snippet from
> > evaluating only once. The problem is that the linker flag can be passed
> > around and evaluated multiple times. This will happen easily during Debian
> > package build, where debian/rules is a Makefile that calls the project build
> > system (that can use makefiles as well).
>
> That, however, is a problem of the build system. Passing around potentially
> quoted strings needs special care, to retain quotation. The issue isn't
> unique to Debian; see e.g. the Linux kernel's "escsq" and its uses (and how
> it further protects e.g. # and $$).
>
> Imo it's just the commas which are the main problem here, as -Wl,... in the
> compiler has - afaik - no way of escaping them.
'"' may be an issue for make as in comment #6.
--
You are receiving this mail because:
You are on the CC list for the bug.
