RFC: A new llvm-dlltool driver and llvm-lib driver improvements

Just to follow up here I found some time to progress.
Anyone who wants to follow along can see here.
https://reviews.llvm.org/D29892

Kind Regards
Martell

There are a few things running in parallel and thanks for taking the time to review and help me get this in tree.
I wanted to follow up with a question on the linker side of things.

Since rL289280 I can no longer link programs with the mingw-crt because of dup function errors of the main function.

In mingw-w64-crt/crt/crtexe.c a main function is called from __tmainCRTStartup
mingw-w64-crt/crt/crt0_c.c defines this main and calls WinMain in the case where main does not exist.
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.

Would it be possible to share a repro.tar file created with /linkrepro so that we can reproduce the problem?

Peter

Hey Peter,

Currently I still use the custom frontend I have for using lld so it wouldn’t be much use to do that.
I’m looking to get all the other components merged before I submit an in process shim like Rui suggested.

I think the best way to approach this would be from MSVC terms.

Before rL289280 we had some sort of priority for deciding on which symbol to link.

MSVC Link.exe defines a flag called /FORCE https://msdn.microsoft.com/en-us/library/70abkas3.aspx
We currently implement /FORCE:UNRESOLVED from what I see in the driver.
I would need /FORCE:MULTIPLE to have this functionality back.

I’m not sure how we would go about implementing that since that commit brings us further away from that.
Feedback on what we should do for /FORCE:MULTIPLE would be a good place to start.

Best,
Martell

Hi Martell,

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).

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.

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).

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.

Peter

Hey Peter,

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.

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.
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.
It should be much clearer when MSVC links it and lld doesn’t but I do feel as though this is definitely a regression.

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.

I worked around it earlier by commenting out the path that result in an error on duplicates earlier.
This isn’t ideal of course as you mentioned.

Best,
Martell

Hey Peter,

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.

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.

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.
It should be much clearer when MSVC links it and lld doesn't but I do feel
as though this is definitely a regression.

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.

Peter

Hey Peter,

Wanted to follow up here after getting this test case setup on MSVC link.exe over the weekend.
When I updated LLD to the latest trunk the problem seems to have resolved itself.
I haven’t gotten a decent chance to check through each iteration of the history to find the commit yet but I will move back on to getting a mingw driver into LLD (hopefully this coming weekend) to make sure we have not only a driver but also test cases to ensure this stays working.

For anyone interested, llvm-dlltool landed in rL308379 which was before the 5.0 branch thanks to Rui for his patience on getting this merged.

Best,
Martell