[cfe-dev] Feedback on feature (and status of lld linker script support?)

[David Blaikie via cfe-dev]

+Fangrui Song <maskray at google.com> for general LLD stuff
+Jez Ng <jezng at fb.com> for ld64.lld stuff
+Reid Kleckner <rnk at google.com> for discussion around section/symbol
reduction

I'm guessing it'll be best to keep each issue in a separate thread - and
the previous thread on llvm-dev (
https://groups.google.com/g/llvm-dev/c/YzHbrfTxLCY/m/ssYtlxIdAwAJ )

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

On Sun, Nov 28, 2021 at 7:53 AM Christopher Friedt via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Hi all,
>
> I emailed the llvm mailing list but have not heard any response yet,
> but maybe I was sent to the wrong list. Hopefully this is the right
> one.
>
> TLDR:
> 1) Is anyone available to provide some quick feedback on a feature [1]
> before I submit it?
> 2) What is the status of linker script support for LLD on macOS?
>
> I'm a bit of a newcomer to clang / llvm development and I'm working on
> a feature that I hope will improve the experience on macOS for
> applications that rely on custom section placement. Specifically, it
> addresses this type of error:
>
> error: argument to 'section' attribute is not valid for this target:
> mach-o section specifier requires a section whose length is between 1
> and 16 characters
>
> The solution I've put together in [1] simply hashes long section names
> to fit into N (16) characters. The approach is SHA256 -> base64 ->
> truncate to N which is already somewhat common in various runtimes on
> macOS.
>
> I've added two options:
> * -fhash-section-names=N
>   * hashes section names when they are > N characters
> * -fhashed-section-names=outputfile
>   * outputs a mapping of all section names to the hash value in tabbed
> CSV format
>   * each line is of the form: (section)\t(hash)
>   * would be nice to reuse any artifact file names if "outputfile" is ""
>   * e.g. build/foo.o => build/foo.sn, build/foo.exe => foo.sn,
> build/foo => foo.sn
>
> The above changes allow one to use linker-generated symbols to iterate
> over all elements placed into a particular section. It is working
> quite well for local "native_posix_64" builds of Zephyr so far. Zephyr
> uses (long) custom section names extensively. Otherwise the section
> name size limitation of macOS is a showstopper.
>
> Does anyone have any quick feedback before I submit this patch to the
> mailing list?
>
> The second question I had was about LLD support for GNU style linker
> scripts on macOS. I'm currently getting this error:
>
> ld64.lld: error: zephyr/linker_zephyr_pre0.cmd: unhandled file type
>
> Is there an option I can provide to LLD that would provide more
> information about the error? Currently I'm using "-Wl,-flat_namespace,
> -Wl,-undefined,warning" just to make it link, but there are several
> symbols defined in the linker script that are required for the
> application to run properly. Supporting GNU style linker scripts would
> be immensely helpful in this case, so I'd like to make that work if at
> all possible. Would be happy to patch LLD as well.
>
> Thanks,
>
> C
>
> [1]
> https://github.com/llvm/llvm-project/compare/main...cfriedt:fhash-long-section-names
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20211129/cdf8d915/attachment.html>