<div dir="ltr">Hi Sean<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 26, 2017 at 5:10 AM, Sean Silva <span dir="ltr"><<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><span class="m_7594468465333847554gmail-"><div></div></span>For that triple, Clang seems to be calling into GCC driver (/usr/bin/arm-none-eabi-gcc) f<wbr>or linking and GCC doesn't recognize -fuse-ld=lld (supposedly -fuse-ld=gold selects ld.gold, -fuse-ld=bfd selects ld.bfd and you would expect -fuse-lld=lld to select ld.lld, but it doesn't work like that apparently).<div><br></div><div>@Renato: Do you know why Clang is forwarding to GCC like this for linking? If we need to live with this arrangement for a long time we should definitely invest in teaching GCC about -fuse-ld=lld<br><div><br></div><div>@Davide: is there any chance you could revive that GCC patch to add support for LLD?</div><div><br></div><div>(though it does seem like we still fail H.J.'s test case in <a href="https://bugs.llvm.org//show_bug.cgi?id=28414" target="_blank">https://bugs.llvm.org//show<wbr>_bug.cgi?id=28414</a> has not yet been fixed. I further reduced it. Seems to be related to symbol versioning. We don't recognize that `.symver bar, foo@@VERS` is a definition of `foo`.</div><div>)</div><div><br></div></div><span class="m_7594468465333847554gmail-"><div><br></div></span><div>If you are building your own LLD, can you see if the attached patch fixes it for you? If not, can you add `--reproduce /tmp/repro.tar` to your link command line and upload repro.tar somewhere for us?</div></div></div></div></blockquote><div><br></div><div>Thanks! I applied that patch and it links with -flto now, but it looks like there are now some other problems. First, it seems to be dropping things that I try to KEEP in the linker script, even when I don't use --gc-sections, namely my interrupt vector table. Second, when using thin LTO, it starts trying to link symbols __aeabi_memclr4 and __aeabi_uidiv, which I don't think it should since I am using -ffreestanding -fno-builtins when compiling (with full lto or no lto, it does not try to link these symbols).<br><br></div><div>I just sent an email to register for a bugzilla account, I can report there with a minimally reproducible example for these problems.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>@Renato, do you know if there is any way for us to implement getBitcodeMachineKin<wbr>d in a sane way so that we don't fill in a long tail of cases of inferring EM_* from the triple? It seems that the EM_* choices are buried very deep in the backend, so it might not be feasible :(</div><span class="m_7594468465333847554gmail-"><div><br></div></span><div>What kind of issues have you been running into?</div><div><br></div><div>Linker scripts are certainly one area that we have been slowly filling in the long tail of compatibility, it would be great if you filed bugs with any issues you encounter! If the files are small enough and you can share them, it can be as simple as just adding `--reproduce /tmp/repro.tar` to your link command line (or setting LLD_REPRODUCE=/tmp/repro.tar in the environment) and attach repro.tar to a bug report whenever you encounter an issue (even if repro.tar is larger, you can try hosting on google drive / dropbox etc., compressing with xz also often helps). Or if it is a parsing problem just attaching the problematic linker script to the bug report might be enough.</div></div></div></div></blockquote><br></div><div class="gmail_quote">I haven't hit anything that looked like a bug, just features that aren't implemented, or that work slightly differently between ld linker scripts. I'd be happy to make additional feature requests for those on the bug tracker, too.<br></div><div class="gmail_quote"><div> <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div>Regarding objcopy, that is something that we have wanted to write for a long time (but it has never quite been a priority). As objcopy supports a bewildering set of different options, it would be useful for you to file a bug about what specific options/features you need. We don't really have a bugzilla component for objcopy yet, so you can just throw it under llvm-nm (another one of the binutils, close enough) in <a href="https://bugs.llvm.org/enter_bug.cgi?product=tools" target="_blank">https://bugs.llvm.org/enter<wbr>_bug.cgi?product=tools</a> </div></div></div></div></div></blockquote><div><br></div><div>Sounds good.<br><br></div><div>Thanks for the patch and the help.<br><br></div><div>Sean<br><br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>-- Sean Silva</div></div></div></div>
</blockquote></div><br></div></div></div>