[llvm-dev] [cfe-dev] Feedback on feature (and status of lld linker script support?)
Peter Smith via llvm-dev
llvm-dev at lists.llvm.org
Tue Nov 30 01:54:55 PST 2021
> Almost as critical, imho, is supporting GNU linker scripts with LLD
> for macOS. What are the main limiting factors right now preventing
> ld64.lld from borrowing most of the GNU linker script support from
> ld.lld? Or is that a conversation for a different mailing list?
The code to parse linker scripts could be borrowed from the ELF ld.lld but that would only be one small piece of the puzzle. AFAIK the GNU linker doesn't support Mach-O so there would have to be a mapping worked out from GNU linker scripts to Mach-O. This is possible but a lot of work and experimentation will be needed to work out what makes sense. For example something like PHDRS is unlikely to cross over from ELF. Then there's the complexity of what linker scripts can do to the linker code. A lot of corner case code has to be written to account for what can be written in a linker script.
Given the lack of precedent in Mach-O for linker scripts it may be better to look at what specific needs there are and try to look at alternative ways of supporting them rather than adopting GNU linker scripts. For example are scripts needed for linker defined symbols? section/atom ordering within a section?
Peter
> -----Original Message-----
> From: cfe-dev <cfe-dev-bounces at lists.llvm.org> On Behalf Of Shoaib
> Meenai via cfe-dev
> Sent: 30 November 2021 05:59
> To: Christopher Friedt <chrisfriedt at gmail.com>; David Blaikie
> <dblaikie at gmail.com>
> Cc: llvm-dev at lists.llvm.org; Jez Ng <jezng at fb.com>
> Subject: Re: [cfe-dev] Feedback on feature (and status of lld linker script
> support?)
>
> For ld64.lld, we're aiming to be compatible with ld64 (the standard platform
> linker for Apple). ld64 doesn't support linker scripts, and we had no plans of
> supporting them either.
>
> I'd be super reluctant to add support for linker scripts unless there's a very
> compelling use case for them. They add a lot of complication to the linker,
> and my understanding is that many aspects of them are ill-defined (bfd, gold,
> and LLD might do different things for the same input linker script). There's
> also no precedent of linker script support for Apple platforms that I'm aware
> of.
>
> (llvm-dev is the right mailing list for LLD discussions, so I moved this to llvm-
> dev and BCC'd cfe-dev.)
>
> On 11/29/21, 8:04 PM, "cfe-dev on behalf of Christopher Friedt via cfe-dev"
> <cfe-dev-bounces at lists.llvm.org on behalf of cfe-dev at lists.llvm.org> wrote:
>
> On Mon, Nov 29, 2021 at 3:33 PM David Blaikie <dblaikie at gmail.com>
> wrote:
> > The section name hashing might be more of a clang feature than an LLVM
> one - if it's specifically for user-specified sections, etc. It could have some
> overlap with some symbol name length issues I've been considering for a
> while with somewhat similar strategies (hash, but then have a lookup table).
> I'm not sure who's going to be best to actually make the final call on whether
> what you're proposing is suitable for Clang/LLVM
>
> Good to know that I'm not the only one thinking about this stuff,
> hehe. I was planning on using it for user-specified sections, yea.
>
> Hopefully this or something like it could be upstreamed. It's not
> ideal because it's only hiding the root problem (the Mach-O spec) but
> at least it's a short term solution.
>
> Almost as critical, imho, is supporting GNU linker scripts with LLD
> for macOS. What are the main limiting factors right now preventing
> ld64.lld from borrowing most of the GNU linker script support from
> ld.lld? Or is that a conversation for a different mailing list?
>
> Thanks for your response,
>
> C
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
More information about the llvm-dev
mailing list