[Bug binutils/28485] ar and objcopy stuck,failing on object name containing '/' inside an archive
https://sourceware.org/bugzilla/show_bug.cgi?id=28485 --- Comment #3 from Andrew Pullin --- Ultimately, the workaround for this was to use the llvm/clang version of objcopy to do the operation I needed to do to weaken symbols. Since the path handling is consistent within their ecosystem, it was able to deal with the '/'. So, this is probably not a bug at all, just two different teams' implementations of AR. And not that it is terribly important to this issue, but for a little elucidation of the case where this arose: This all came up when I was trying to use Rust FFI to include some Rust fuctions into a C codebase, targeting an embedded microcontroller target. There was a collision of libc builtins, and reimplementations in the core rust libraries/runtime. As far as I have seen, the C99 embedded world has not switched to clang/llvm yet (except Apple), but in various pieces of documentation and hacks to get Rust+C working, crossover into GNU tools does arise in a few places. Ultimately, I am able to use gnu arm-none-eabi-ld to link in the staticlib build by llvm+lld, after the localization step was done on the .a output from the Rust toolchain. https://github.com/rust-lang/compiler-builtins/issues/345 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28485] ar and objcopy stuck,failing on object name containing '/' inside an archive
https://sourceware.org/bugzilla/show_bug.cgi?id=28485 Alan Modra changed: What|Removed |Added Version|2.35.1 |2.35 -- You are receiving this mail because: You are on the CC list for the bug.
Re: ar and objcopy stuck, failing on object name containing '/' inside an archive?
Hi Nick, I filed a bug here: https://sourceware.org/bugzilla/show_bug.cgi?id=28485 Per one of the replies, it seems like this might not be a "bug", but simply a difference in definitions between binutils and llvm definitions of the archive format. It loos like the llvm format has allowances for paths in files which the Open Group spec does not. Without an extension in behavior definition (which would then go out-of-conformance with that spec), I don't think there is any way to resolve this. Ultimately, I used the llvm variant of objcopy and was able to accomplish what I needed to do wrt modifying objects in the archive. But that does "make sense", since the original archive was emitted by llvm tools. But the issue might come up in other places, as llvm and gcc try to coexist in software ecosystems. I am working in a sort-of special case here, with bare metal embedded on ARM, which (afaik) there is not an all-clang/llvm solution for yet. - Andrew On 11/17/21 8:13 AM, Nick Clifton wrote: Hi Andrew, [Sorry for taking such a long time to reply to your email] I am trying to localize some symbols in objects inside an archive. Ultimately, it seems like the tools are failing because the .a appears to contain an object with the name "bin/thumbv7em-none-eabihf.o". If you extract the object files, localize them one by one and then put them back, does the problem go away ? (In theory this should not make any difference at all, but you never know...) When I try to extract everything in the archive: arm-none-eabi-ar x librustlib.a it extracts all objects up to that problem object with the '/' in the name, but none after it. Is this a bug? Yes. :-) Either the extraction should complete with all of the files being retrieved or else an error message should be displayed and the exit status set to failure. Please could you file a bug report for this problem here: https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils If you could include a copy of the archive, or simple instructions on how to create a similar one, that would help a lot. Cheers Nick
Re: ar and objcopy stuck, failing on object name containing '/' inside an archive?
Hi Andrew, [Sorry for taking such a long time to reply to your email] I am trying to localize some symbols in objects inside an archive. Ultimately, it seems like the tools are failing because the .a appears to contain an object with the name "bin/thumbv7em-none-eabihf.o". If you extract the object files, localize them one by one and then put them back, does the problem go away ? (In theory this should not make any difference at all, but you never know...) When I try to extract everything in the archive: arm-none-eabi-ar x librustlib.a it extracts all objects up to that problem object with the '/' in the name, but none after it. Is this a bug? Yes. :-) Either the extraction should complete with all of the files being retrieved or else an error message should be displayed and the exit status set to failure. Please could you file a bug report for this problem here: https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils If you could include a copy of the archive, or simple instructions on how to create a similar one, that would help a lot. Cheers Nick
[Bug binutils/28485] ar and objcopy stuck,failing on object name containing '/' inside an archive
https://sourceware.org/bugzilla/show_bug.cgi?id=28485 --- Comment #2 from Alan Modra --- (In reply to Andrew Pullin from comment #1) > As far as I can tell, there is no defined behavior for how archive files > with a path containing a directory should behavior with the ar utility. https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ar.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28485] ar and objcopy stuck,failing on object name containing '/' inside an archive
https://sourceware.org/bugzilla/show_bug.cgi?id=28485 --- Comment #1 from Andrew Pullin --- This appears to originate from here: https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=binutils/ar.c;h=8885585ef7537450f0f0990a5eeea7eb16bcad8f;hb=refs/heads/master#l1157 As far as I can tell, there is no defined behavior for how archive files with a path containing a directory should behavior with the ar utility. afaik, `fopen()` has no facility for creating directories. Notably, if I do `mkdir bin` first, then the observed "No such file or directory" error will NOT be hit when using ar to extract, as now the pathname becomes valid. However: the issue remains with objcopy, since it apparently uses a temporary directory when doing an operation like `--localize-hidden`. Also of note: This appears to arise due to this archive file being created with `llvm-ar`, which does explicitely allow slashes in path name: https://releases.llvm.org/2.8/docs/CommandGuide/html/llvm-ar.html#:~:text=The%20path%20name%20is%20null%20terminated%20and%20may%20contain%20the%20slash%20(/)%20character. Using llvm-objcopy yields different behavior: the --localize-hidden operation succeeds without issue, despite the pathname containing a `/` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28485] New: ar and objcopy stuck,failing on object name containing '/' inside an archive
https://sourceware.org/bugzilla/show_bug.cgi?id=28485 Bug ID: 28485 Summary: ar and objcopy stuck,failing on object name containing '/' inside an archive Product: binutils Version: 2.35.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: pullin at berkeley dot edu Target Milestone: --- I am trying to localize some symbols in objects inside an archive. Ultimately, it seems like the tools are failing because the .a appears to contain an object with the name "bin/thumbv7em-none-eabihf.o". This all started from trying: arm-none-eabi-objcopy --localize-hidden librustlib.a So operations like: arm-none-eabi-objcopy -L __aeabi_dcmpgt librustlib.a result in the error: arm-none-eabi-objcopy: stsJ3ObR/bin/thumbv7em-none-eabihf.o: No such file or directory with apparently no change to the archive file. The symbol is definitely in there: arm-none-eabi-objdump -x librustlib.a gives compiler_builtins-2ff80b98fa64b741.compiler_builtins.6207f1bb-cgu.122.rcgu.o: file format elf32-littlearm rw-r--r-- 0/0 10176 Dec 31 16:00 1969 compiler_builtins-2ff80b98fa64b741.compiler_builtins.6207f1bb-cgu.122.rcgu.o architecture: armv7e-m, flags 0x0011: ... SYMBOL TABLE: ldf *ABS* compiler_builtins.6207f1bb-cgu.122 ld .text.__aeabi_dcmpgt .text.__aeabi_dcmpgt ... g F .text.__aeabi_dcmpgt 0078 .hidden __aeabi_dcmpgt So the symbol is there, flagged as a Function, .hidden, but still global. Checking the contents of the archive: arm-none-eabi-ar tv librustlib.a | grep thumb it does appear that something is there: rw-r--r-- 0/0 22732 Dec 31 16:00 1969 bin/thumbv7em-none-eabihf.o When I try to extract everything in the archive: arm-none-eabi-ar x librustlib.a it extracts all objects up to that problem object with the '/' in the name, but none after it. -- You are receiving this mail because: You are on the CC list for the bug.
ar and objcopy stuck, failing on object name containing '/' inside an archive?
Hi folks, I am having a little bit of trouble with ar and objcopy. Unsure if I am doing something that I should not expect the tools to do, or encountering a bug. I am trying to localize some symbols in objects inside an archive. Ultimately, it seems like the tools are failing because the .a appears to contain an object with the name "bin/thumbv7em-none-eabihf.o". This all started from trying: arm-none-eabi-objcopy --localize-hidden librustlib.a So operations like: arm-none-eabi-objcopy -L __aeabi_dcmpgt librustlib.a result in the error: arm-none-eabi-objcopy: stsJ3ObR/bin/thumbv7em-none-eabihf.o: No such file or directory with apparently no change to the archive file. The symbol is definitely in there: arm-none-eabi-objdump -x librustlib.a gives compiler_builtins-2ff80b98fa64b741.compiler_builtins.6207f1bb-cgu.122.rcgu.o: file format elf32-littlearm rw-r--r-- 0/0 10176 Dec 31 16:00 1969 compiler_builtins-2ff80b98fa64b741.compiler_builtins.6207f1bb-cgu.122.rcgu.o architecture: armv7e-m, flags 0x0011: ... SYMBOL TABLE: l df *ABS* compiler_builtins.6207f1bb-cgu.122 l d .text.__aeabi_dcmpgt .text.__aeabi_dcmpgt ... g F .text.__aeabi_dcmpgt 0078 .hidden __aeabi_dcmpgt So the symbol is there, flagged as a Function, .hidden, but still global. Checking the contents of the archive: arm-none-eabi-ar tv librustlib.a | grep thumb it does appear that something is there: rw-r--r-- 0/0 22732 Dec 31 16:00 1969 bin/thumbv7em-none-eabihf.o When I try to extract everything in the archive: arm-none-eabi-ar x librustlib.a it extracts all objects up to that problem object with the '/' in the name, but none after it. Is this a bug? This is actually part of a bigger effort on another issue of symbol collision at link time: https://github.com/rust-lang/compiler-builtins/issues/345 In short, both Rust and C export "builtins" for basic operations, e.g. IEEE 754 float operations here, which collide when trying to statically link the outputs together for an embedded target. So I am trying to localize all the symbols in the .a before linking, such that each of Rust and C will use their own impls of the builtins, to avoid collision. (I assume there is probably some more-correct way of resolving this collision, so any input here would also be great!) Thanks, Andrew
