llvm dev - May 2017 - 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

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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170327/bb04769d/attachment.html>

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.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170511/a95afb0f/attachment.html>

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/20170511/379ee814/attachment.html>