This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH Gold] Recognize clang-style crtbegin and crtend files
- From: Cary Coutant <ccoutant at gmail dot com>
- To: "augustine dot sterling at gmail dot com" <augustine dot sterling at gmail dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Tue, 7 Jan 2020 17:25:49 -0800
- Subject: Re: [PATCH Gold] Recognize clang-style crtbegin and crtend files
- References: <CAGSvup8i2X19GxpOG2=nBm+JZeFvJjAne8tfWZ0q4nGtXsfqiw@mail.gmail.com> <CAJimCsHjm4BdRCY15jBbCkm7uK0cqZ+UY-hRrEH-4FGxY=uMCw@mail.gmail.com> <CAGSvup-J+qWAGgffuhFBQUuzr1qQm_vYXBsJdPqwiXA--Yxkiw@mail.gmail.com>
> Enclosed is a patch that handles clang-style names completely
> separately, and also
> checks for the "-" before the target name.
+ if (*(base_name + match_len) != '.' &&
+ *(base_name + match_len) != '-')
+ return false;
Please write these as base_name[match_len].
But Fangrui Song's most recent message in this thread raised a red flag:
> We can use a looser rule which matches GNU ld more closely.
>
> % ld.bfd --verbose | grep -A12 ' .ctors '
> .ctors :
> {
> /* gcc uses crtbegin.o to find the start of
> the constructors, so we make sure it is
> first. Because this is a wildcard, it
> doesn't matter if the user does not
> actually link against crtbegin.o; the
> linker won't look for a file to match a
> wildcard. The wildcard also means that it
> doesn't matter which directory crtbegin.o
> is in. */
> KEEP (*crtbegin.o(.ctors))
> KEEP (*crtbegin?.o(.ctors))
>
> If divergence from other compiler-rt files (e.g.
> libclang_rt.asan-i386.a) is not a concern, clang_rt.i386.crtbegin.o
> should just work with GNU ld.
This seems to imply that the filename convention is not
clang_rt.crtbegin-<target>.o, but instead
clang_rt.<target>.crtbegin.o. I looked for a corresponding Gnu ld
patch but couldn't find one, so it does seem likely that you're using
the latter convention, which just happens to work with the existing
Gnu ld default script.
Can you clarify which of these two naming conventions you intend to
support? If it's the former, this patch is OK with the above change.
If the latter, I think you'll need to adjust this patch.
-cary