| Summary: | [ld] Search for input files relative to the current linker script | ||
|---|---|---|---|
| Product: | binutils | Reporter: | Fangrui Song <maskray> |
| Component: | ld | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | amodra, nickc |
| Priority: | P2 | ||
| Version: | 2.35 | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | ||
| Project(s) to access: | ssh public key: | ||
|
Description
Fangrui Song
2020-04-09 04:17:50 UTC
I made some investigations. Notation: CWD => current working directory For a relative pathname (not absolute path or -l) in INPUT() or GROUP(): * GNU ld searches in CWD then in -L * gold searches in the parent directory of the current linker script then in -L. It does not fall back to CWD. I am going to change the search order of lld * the parent directory of the current linker script * next in CWD * then in -L. https://reviews.llvm.org/D77779 libstdc++.a currently includes object files from libsupc++. It could use a linker script as an alternative if GNU ld had this feature... Though there is probably no point to do this For libc++.a, it probably makes more sense because several C++ ABI libraries can be plugged in. Hi Fangrui,
> gold a.o p/libm.a
>
> gold can find p/libm.a.1 even if -L p is not specified.
A couple of questions:
1. Does the extra search path persist beyond the end of the linker
script ? For example, using your sample script:
% ld p/libm.a foo.o
Should the linker load p/foo.o ? (If it exists, of course).
2. Is this feature restricted to libraries, or should it also affect
object files ? For example:
% cat p/libm.a
INPUT(libm.a.1)
INPUT(foo.o)
% ld p/libm.a
Is this expected to load p/foo.o ?
Cheers
Nick
(In reply to Nick Clifton from comment #2) > Hi Fangrui, > > > gold a.o p/libm.a > > > > gold can find p/libm.a.1 even if -L p is not specified. > > A couple of questions: > > 1. Does the extra search path persist beyond the end of the linker > script ? For example, using your sample script: > > % ld p/libm.a foo.o > > Should the linker load p/foo.o ? (If it exists, of course). No. I think we should make the intuitive choice: the extra search path is local to the linker script. > 2. Is this feature restricted to libraries, or should it also affect > object files ? For example: > > % cat p/libm.a > INPUT(libm.a.1) > INPUT(foo.o) > > % ld p/libm.a > > Is this expected to load p/foo.o ? > > Cheers > Nick p/foo.o will be loaded. The extra search rule should apply to any relative pathname (my observation of the gold behavior). They can be: libm.a.1 , foo.o , foo.so , relative/foo.so , etc The -l form does not apply. I hope the rules above are all intuitive and likely what users expect... For me, I did feel strange when I first noticed that INPUT() and GROUP() do not search for the "local files" but I did not think hard about the rule. Proposed patch: https://sourceware.org/pipermail/binutils/2020-April/110743.html The master branch has been updated by Nick Clifton <nickc@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=161719466ac9ea5f186514312f6bce842181804f commit 161719466ac9ea5f186514312f6bce842181804f Author: Fangrui Song <maskray@google.com> Date: Wed Apr 22 16:20:02 2020 +0100 For relative paths in INPUT() and GROUP(), search the directory of the current linker script before searching other paths. PR ld/25806 * ldlang.h (struct lang_input_statement_struct): Add extra_search_path. * ldlang.c (current_input_file): New. (ldirname): New. (new_afile): Add from_filename parameter. Set extra_search_path. (lang_add_input_file): Pass current_input_file to new_afile. (load_symbols): Set current_input_file. Patch applied. Note - testsuite patch may follow. |