<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, May 21, 2017 at 3:11 PM, Martell Malone <span dir="ltr"><<a href="mailto:martellmalone@gmail.com" target="_blank">martellmalone@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"><div style="font-size:12.8px">Hey Peter,<span class="gmail-"><br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">How is crt0_c.c being added to the link? If crt0_c.c is supplying a definition of the main function I would expect it to be in an archive which would appear after the user supplied inputs on the command line. Archives and objects appearing earlier in the link have priority over archives appearing later, so the user's definition of main should then have priority over the CRT's definition. However, objects added to the link have equal priority, so if crt0_c.c is being added directly as an object file I would expect it to cause a duplicate symbol error, as its definition of main would conflict with the user's definition.</span></blockquote><br></span>crt0_c.c is not being added directly to the linker, this is when linking a simple hello world program with libmingwex.a and the other MS libraries.</div></div></blockquote><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 style="font-size:12.8px">A few months ago I was able to alter mingw-w64 to be able to link with msvc link.exe, I will try pull out those patches again to produce a link repo.<br>It should be much clearer when MSVC links it and lld doesn't but I do feel as though this is definitely a regression.</div></div></blockquote><div><br></div><div>So the crt0_c.c object file is a member of libmingwex.a? If so, this does sound like a regression to me. Please do send the repro once you have something that links with the MSVC linker and fails with lld.</div><div><br></div><div>Peter </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 style="font-size:12.8px"><span class="gmail-"><br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">We should probably implement /FORCE:MULTIPLE for MSVC compatibility, but I don't think you should be passing it from your driver, as that would just be working around the bug that was presumably introduced by r289280. If you just want to get past this issue though, implementing it would probably just involve downgrading the fatal error in SymbolTable::reportDuplicate to a warning if /FORCE:MULTIPLE is passed.</span></blockquote></span>I worked around it earlier by commenting out the path that result in an error on duplicates earlier.<br>This isn't ideal of course as you mentioned.<br><br>Best,<br>Martell<br><br></div></div><div class="gmail-HOEnZb"><div class="gmail-h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 21, 2017 at 9:51 PM, Peter Collingbourne <span dir="ltr"><<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</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">Hi Martell,<div><br></div><div>r289280 was not intended to be a significant functional change in the sense that it would cause programs to fail to link, so this may be a bug I introduced in r289280 (or one of the followup patches, which also changed link order).</div><div><br></div><div>How is crt0_c.c being added to the link? If crt0_c.c is supplying a definition of the main function I would expect it to be in an archive which would appear after the user supplied inputs on the command line. Archives and objects appearing earlier in the link have priority over archives appearing later, so the user's definition of main should then have priority over the CRT's definition. However, objects added to the link have equal priority, so if crt0_c.c is being added directly as an object file I would expect it to cause a duplicate symbol error, as its definition of main would conflict with the user's definition.</div><div><br></div><div>Note that this is all how I would expect things to work both before and after my change. The priority that existed before was just an implementation detail; priority is now implicit in the link order (i.e. the order in which files appear in the linker's command line, roughly speaking).<br></div><div><br></div><div><div>We should probably implement /FORCE:MULTIPLE for MSVC compatibility, but I don't think you should be passing it from your driver, as that would just be working around the bug that was presumably introduced by r289280. If you just want to get past this issue though, implementing it would probably just involve downgrading the fatal error in SymbolTable::reportDuplicate to a warning if /FORCE:MULTIPLE is passed.</div><div><br></div></div><div>Peter</div></div><div class="gmail_extra"><div><div class="gmail-m_8497120069891326536h5"><br><div class="gmail_quote">On Sun, May 21, 2017 at 7:05 AM, Martell Malone <span dir="ltr"><<a href="mailto:martellmalone@gmail.com" target="_blank">martellmalone@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">Hey Peter,<br><br>Currently I still use the custom frontend I have for using lld so it wouldn't be much use to do that.<br>I'm looking to get all the other components merged before I submit an in process shim like Rui suggested.<br><br>I think the best way to approach this would be from MSVC terms.<br><br>Before <span style="font-size:12.8px">rL289280 we had some sort of priority for deciding on which symbol to link.</span><br><span style="font-size:12.8px"><br>MSVC Link.exe defines a flag called /FORCE <a href="https://msdn.microsoft.com/en-us/library/70abkas3.aspx" target="_blank">https://msdn.microsoft.com/en-<wbr>us/library/70abkas3.aspx</a> </span><br>We currently implement /FORCE:UNRESOLVED from what I see in the driver.<br>I would need /FORCE:MULTIPLE to have this functionality back.<br><br>I'm not sure how we would go about implementing that since that commit brings us further away from that.<br>Feedback on what we should do for /FORCE:MULTIPLE would be a good place to start.<br><br>Best,<br>Martell<br><br></div><div class="gmail-m_8497120069891326536m_8325981603127152031HOEnZb"><div class="gmail-m_8497120069891326536m_8325981603127152031h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 11, 2017 at 6:41 PM, Peter Collingbourne <span dir="ltr"><<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</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"><div>Would it be possible to share a repro.tar file created with /linkrepro so that we can reproduce the problem?</div><div><br></div><div>Peter</div></div><div class="gmail_extra"><div><div class="gmail-m_8497120069891326536m_8325981603127152031m_1100734178692475519h5"><br><div class="gmail_quote">On Thu, May 11, 2017 at 3:00 AM, Martell Malone <span dir="ltr"><<a href="mailto:martellmalone@gmail.com" target="_blank">martellmalone@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">There are a few things running in parallel and thanks for taking the time to review and help me get this in tree.<div>I wanted to follow up with a question on the linker side of things.<div><br></div><div>Since rL289280 I can no longer link programs with the mingw-crt because of dup function errors of the main function.</div><div><br></div><div>In mingw-w64-crt/crt/crtexe.c a main function is called from __tmainCRTStartup</div><div>mingw-w64-crt/crt/crt0_c.c defines this main and calls WinMain in the case where main does not exist.</div><div>What used to happen before was the crt0_c.c main would be ignored at link time because of priority on the users main function but now I just get a dup symbol error as there is no checking on priority anymore.</div><div><br></div></div></div><div class="gmail-m_8497120069891326536m_8325981603127152031m_1100734178692475519m_-8209548303983919132HOEnZb"><div class="gmail-m_8497120069891326536m_8325981603127152031m_1100734178692475519m_-8209548303983919132h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 27, 2017 at 7:00 PM, Martell Malone <span dir="ltr"><<a href="mailto:martellmalone@gmail.com" target="_blank">martellmalone@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">Just to follow up here I found some time to progress.<br>Anyone who wants to follow along can see here.<br><a href="https://reviews.llvm.org/D29892" target="_blank">https://reviews.llvm.org/D2989<wbr>2</a><br><br>Kind Regards<span class="gmail-m_8497120069891326536m_8325981603127152031m_1100734178692475519m_-8209548303983919132m_-1683425470177692784HOEnZb"><font color="#888888"><br>Martell</font></span></div><div class="gmail-m_8497120069891326536m_8325981603127152031m_1100734178692475519m_-8209548303983919132m_-1683425470177692784HOEnZb"><div class="gmail-m_8497120069891326536m_8325981603127152031m_1100734178692475519m_-8209548303983919132m_-1683425470177692784h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 14, 2017 at 2:21 AM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.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 class="gmail-m_8497120069891326536m_8325981603127152031m_1100734178692475519m_-8209548303983919132m_-1683425470177692784m_-6892423382837528502HOEnZb"><div class="gmail-m_8497120069891326536m_8325981603127152031m_1100734178692475519m_-8209548303983919132m_-1683425470177692784m_-6892423382837528502h5"><div dir="ltr"><div><div>The code in LLD is somewhat tightly coupled with the rest of the linker. Probably it is better to create a new library rather than trying to split LLD into two. I believe this would result in a better API. Of course you can reuse code, but what we need is a clean interface.</div><div><br></div><div>The library shouldn't be complicated. In fact, it would export only one function.</div><div><br></div><div>  std::vector<uint8_t> createImportLibrary(std::vecto<wbr>r<ExportSymbol>)</div><div><br></div><div>I.e. it takes a list of DLLExported symbols and returns a .lib file. ExportSymbol type contains information about DLLExported symbols.</div></div></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="gmail-m_8497120069891326536m_8325981603127152031m_1100734178692475519HOEnZb"><font color="#888888">-- <br><div class="gmail-m_8497120069891326536m_8325981603127152031m_1100734178692475519m_-8209548303983919132gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</font></span></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="gmail-m_8497120069891326536HOEnZb"><font color="#888888">-- <br><div class="gmail-m_8497120069891326536m_8325981603127152031gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</font></span></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</div></div>