[lld] Support for PECOFF in gnu ld mode

[Sean Silva]

On Thu, Jun 11, 2015 at 7:48 PM, Saleem Abdulrasool <compnerd at compnerd.org>
wrote:

> 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 argument parsing and symbol resolution logic based on command line
arguments varies between linkers.
E.g. gnu ld is sensitive to the order of command line arguments; not all
linkers are.

-- Sean Silva


>   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
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150611/bea41614/attachment.html>