[llvm-dev] RFC: A new llvm-dlltool driver and llvm-lib driver improvements

[Martell Malone via llvm-dev]

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


On Thu, May 11, 2017 at 6:41 PM, Peter Collingbourne <peter at pcc.me.uk>
wrote:

> Would it be possible to share a repro.tar file created with /linkrepro so
> that we can reproduce the problem?
>
> Peter
>
> On Thu, May 11, 2017 at 3:00 AM, Martell Malone <martellmalone at gmail.com>
> wrote:
>
>> 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.
>>
>>
>> On Mon, Mar 27, 2017 at 7:00 PM, Martell Malone <martellmalone at gmail.com>
>> wrote:
>>
>>> 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
>>>
>>> On Tue, Feb 14, 2017 at 2:21 AM, Rui Ueyama <ruiu at google.com> wrote:
>>>
>>>> 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.
>>>>
>>>> The library shouldn't be complicated. In fact, it would export only one
>>>> function.
>>>>
>>>>   std::vector<uint8_t> createImportLibrary(std::vector<ExportSymbol>)
>>>>
>>>> I.e. it takes a list of DLLExported symbols and returns a .lib file.
>>>> ExportSymbol type contains information about DLLExported symbols.
>>>>
>>>
>>>
>>
>
>
> --
> --
> Peter
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170521/667c7d1e/attachment.html>