[Bug ld/30590] Section matching broken by prefix tree change (b1eecf6f66a4a642)
https://sourceware.org/bugzilla/show_bug.cgi?id=30590 --- Comment #6 from Andrew Oates --- Thank you for the detailed explanation and quick fix! Agreed, relying on this behavior (undocumented, subtle) is suboptimal --- I'll update my linker scripts to be explicit on archive and path matching, that is a much better approach. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30590] Section matching broken by prefix tree change (b1eecf6f66a4a642)
https://sourceware.org/bugzilla/show_bug.cgi?id=30590 Michael Matz changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Michael Matz --- Fixed with the commit above. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30590] Section matching broken by prefix tree change (b1eecf6f66a4a642)
https://sourceware.org/bugzilla/show_bug.cgi?id=30590 --- Comment #4 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Michael Matz : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=edc1244e9b864daf7b3905fdcbe15407b6aa79e4 commit edc1244e9b864daf7b3905fdcbe15407b6aa79e4 Author: Michael Matz Date: Mon Jun 26 17:11:31 2023 +0200 section-match: Check parent archive name as well rewriting the section matching routines lost a special case of matching: section statements of the form NAME(section-glob) normally match against NAME being an object file, but like in the exclude list we happened to accept archive names as NAME (undocumented). The documented way to specify (all) archive members is by using e.g. lib.a:(section-glob) (that does work also with the prefix tree matcher). But I intended to not actually change behaviour with the prefix tree implementation. So, let's also implement checking against archive names with a similar FIXME comment we already have in walk_wild_file_in_exclude_list. PR 30590 ld/ * ldlang.c (walk_wild_section_match): Also look at archive parents for a name match. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30590] Section matching broken by prefix tree change (b1eecf6f66a4a642)
https://sourceware.org/bugzilla/show_bug.cgi?id=30590 --- Comment #3 from Michael Matz --- When you move the libs into a subdir (and accordingly don't have them in the current dir anymore!) then your "lib1.a(*)" should have given you an error, with old ld, with new ld and with patch: % ls -l lib* subdir/lib* -rw-r--r-- 1 matz suse 3028 Jun 26 15:02 lib1.a.away -rw-r--r-- 1 matz suse 1422 Jun 26 15:02 lib2.a.away -rw-r--r-- 1 matz suse 3028 Jun 26 15:02 subdir/lib1.a -rw-r--r-- 1 matz suse 1422 Jun 26 15:02 subdir/lib2.a % grep lib1 linker.ld lib1.a(*) % ld -Map bla.map -o out.bin -T linker.ld subdir/lib1.a subdir/lib2.a ld: cannot find lib1.a: No such file or directory (this is with an oldish system linker, i.e. before the prefix tree change). The thing is the following: with a bare-word filename part in the section statement (i.e. no colons and no wildcards), the named "thing" is loaded in a special mode: as if named on command line, but with searching in search paths. E.g. adding '-L subdir' above would make the error message go away (but doing that would still not make just mentioning "lib1.a" on the cmdline work). If you name the bare-word part also on the command line, then the thing might be loaded twice. It's usually not, because obvious duplicates, based on filenames are not loaded twice, but with enough work you could make ld do that, and get e.g. duplicate symbol definitions. As the above are archives it's even harder, but if they are for instance normal .o files you can easily run into that: % ln test1.o subdir/test1.o % egrep 'lib|test' linker.ld test1.o(*) test2.o(*) % ld -Map bla.map -o out.bin -T linker.ld subdir/test1.o subdir/lib1.a subdir/lib2.a ld: subdir/test1.o: in function `func1': test1.c:(.text+0x0): multiple definition of `func1'; test1.o:test1.c:(.text+0x0): first defined here Compare with: % egrep 'lib|test' linker.ld test*.o(*) % ld -Map bla.map -o out.bin -T linker.ld subdir/test1.o subdir/lib1.a subdir/lib2.a % # worked I.e. non-bare-word parts don't actively load anything, they only match against things that are otherwise loaded (per cmdline, INPUT statements or the above form of bare-word pseudo-INPUT statements). So, if your 'lib1.a(*)' statement worked also when lib1.a was in a subdir, that was because it somehow was loaded without error, either because of a searchpath (-L) or because a file named lib1.a was still in the current dir, in which case that probably wasn't the intention. If the latter then it wasn't really matching against the subdir/lib1.a, but rather against ./lib1.a which may or may not have been the same file. It's all mightily confusing, I agree. But parts of all this is historic baggage, and parts of this is even documented (e.g. that bare-words are loading stuff), so we can't easily remove that behaviour. IMHO it's best to avoid bare-word section "matchers" (certainly with archives) and just name all to-be-loaded things either on the cmdline or in explicit INPUT statements. Otherwise there's always the danger to run into confusions in mildly complex directory layout situations. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30590] Section matching broken by prefix tree change (b1eecf6f66a4a642)
https://sourceware.org/bugzilla/show_bug.cgi?id=30590 --- Comment #2 from Andrew Oates --- Thanks! I have tested the linked patch and confirmed it fixes building with my original linker script and my testcase. One of the reasons I didn't realize the archive syntax was the right approach is that path matching behavior seems to be different between the undocumented form I've been using, and the proper archive form --- again, I don't totally understand the nuance, but in the testcase, if I move lib1.a into a subdirectory, "lib.a(*)" matches (pre 2.39, and with this patch), while "lib1.a:(*)" and "lib1.a:*(*)" _don't_ match (but "*/lib1.a:(*)" and variants do). That is surprising to me, but AFAICT is unrelated to this issue. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30590] Section matching broken by prefix tree change (b1eecf6f66a4a642)
https://sourceware.org/bugzilla/show_bug.cgi?id=30590 Michael Matz changed: What|Removed |Added Assignee|unassigned at sourceware dot org |matz at suse dot de Last reconfirmed||2023-06-27 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30590] Section matching broken by prefix tree change (b1eecf6f66a4a642)
https://sourceware.org/bugzilla/show_bug.cgi?id=30590 Michael Matz changed: What|Removed |Added CC||matz at suse dot de --- Comment #1 from Michael Matz --- The patch I posted at https://sourceware.org/pipermail/binutils/2023-June/128002.html should fix this (but please test on your full example). A note for the future: if you want to name archives in the file-part of section globs, then the documented forms are (and I'll cite): You can also specify files within archives by writing a pattern matching the archive, a colon, then the pattern matching the file, with no whitespace around the colon. 'archive:file' matches file within archive 'archive:' matches the whole archive ':file' matches file but not one in an archive Either one or both of 'archive' and 'file' can contain shell wildcards. That it worked formerly with just "lib1.a(*)" is an undocumented behaviour that got lost with my prefix-tree matching (and is reinstated with above patch). The above forms would have worked. -- You are receiving this mail because: You are on the CC list for the bug.
