<div dir="ltr"><div class="gmail_extra">On Thu, Jan 7, 2016 at 7:03 AM, Arseny Kapoulkine via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">In the process of migrating from old lld ELF linker to new (previously ELF2) I noticed the interface lost several important features (ordered by importance for my use case):<div><br></div><div><div>1. Detecting errors in the first place. New linker seems to call exit(1) for any error.</div></div><div><br></div><div>2. Reporting messages to non-stderr outputs. Previously all link functions had a raw_ostream argument so it was possible to delay the error output, aggregate it for multiple linked files, output via a different format, etc.</div><div><br></div><div>3. Linking multiple outputs in parallel (useful for test drivers) in a single process. Not really an interface issue but there are at least two global pointers (Config & Driver) that refer to stack variables and are used in various places in the code.</div><div><br></div><div>All of this seems to indicate a departure from the linker being useable as a library. To maintain the previous behavior you'd have to use a linker binary & popen.</div><div><br></div><div>Is this a conscious design decision or a temporary limitation?</div></div></blockquote><div><br></div><div>That the new ELF and COFF linkers are designed as commands instead of libraries is very much an intended design change.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>If it's a limitation, how would one go about fixing this? I'm not too familiar with the idiomatical error handling in LLVM. Normally in this situation I'd just throw from error() but lld is probably compiled without exceptions. Is ErrorOr the established practice? How does LLVM generally deal with error handling for parsers (like linker script parser) where it's a lot of mutually recursive functions where every single one can fail?</div></div></blockquote><div><br></div><div>Since it's as designed, please run the linker as an external command using fork/exec (or wrappers of them) instead of trying to use that inside the same process.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><span class=""><font color="#888888"><div><br></div><div>Arseny</div></font></span></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div>