[lld] Support for PECOFF in gnu ld mode

[Saleem Abdulrasool]

On Mon, Jun 8, 2015 at 8:36 PM, Rui Ueyama <ruiu at google.com> wrote:

> On Mon, Jun 8, 2015 at 7:17 PM, Saleem Abdulrasool <compnerd at compnerd.org>
> wrote:
>
>> On Sun, Jun 7, 2015 at 8:45 PM, Rui Ueyama <ruiu at google.com> wrote:
>>
>>> Hi Martell,
>>>
>>> The first and the second patches look good. They just add __image_base__
>>> as an alias for __ImageBase (I don't know why mingw uses different symbols
>>> than regular Windows symbols, though).
>>>
>>> The rest is to support COFF files with GNU command line driver. I don't
>>> know if we want to support that. Do you think even if we have a complete
>>> link.exe-compatible linker, we still want to use GNU ld-compatible COFF
>>> linker on Windows?
>>>
>>
>> One of the things that lld supposedly supports is all the major formats
>> (COFF, ELF, MachO).  The binutils driver supports multiple formats as well,
>> and uses the GNU interface for all of them.  It would be convenient if lld
>> did the same.  Beyond link (Windows), ld64 (OS X), the GNU interface is
>> expected much as the GCC driver is.  I think supporting this interface with
>> the ability to switch to any backend would be extremely useful.  Doing so
>> requires a layer above to translate the arguments appropriate to each
>> backend.
>>
>
> That would be awesome if we can do that, but in reality that comes with a
> great cost. As far as I can say, we tried hard and now I personally
> strongly believe that they are just different that we shouldn't push it
> hard to unify them beyond appropriate boundary. That's really going to be a
> mess. Many command line options and file formats expects some specific
> semantics to a backend. PE/COFF linker expects Windows linking semantics
> which is pretty different from Unix's, for example. If we want to write a
> command line translator for one linker to the other, we should write a
> small shim as an external command.
>

I would expect the linking semantics to remain the same.  The semantics for
linking are driven by the target format.  Im merely talking about the
argument parsing, nothing else.  The problem with an external command is
that you need a fair amount of logic duplicated (e.g. what is a linked
module vs argument).  Do you have cases where the command line option
cannot be accommodating?  Embedded directives *could* accept both forms (as
the GNU driver does).


>
>>
>>> On Sun, Jun 7, 2015 at 7:12 PM, Martell Malone <martellmalone at gmail.com>
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> I have added support for PECOFF in gnu ld mode.
>>>> Currently it now works to create x86_64 executable for mingw-w64.
>>>>
>>>> I'm not sure what the review process for lld involves or where i should
>>>> send my series of patches so advice going forward would be appreciated as I
>>>> plan to work on lld a lot over the next while.
>>>>
>>>> I am having link errors still on armv7 and i686 that I would love some
>>>> help with :)
>>>> Attached are the patches and buildlogs for simple hello world programs
>>>> under both i686 and x86_64 insight into the i686 link errors would be great
>>>> :)
>>>> I already know that i686 prepends an underscore to all symbol names but
>>>> I don't think this is the cause other devs may know more which is why I ask
>>>>
>>>> Kind Regards
>>>> Martell
>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Saleem Abdulrasool
>> compnerd (at) compnerd (dot) org
>>
>
>


-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150611/eb05a67e/attachment.html>