llvm dev - Jan 2018 - [lldb-dev] Trying out lld to link windows binaries (using msvc as a compiler)

it does.

I just had an epiphany: why not just write a .ghash file and have lld read
those if they exist for an .obj file?

Seem much simpler than trying to wire up a 20 year old file format. I will
try to do this, is something like this acceptable for LLD? The cool thing
is that I can generate .ghash for .lib or any obj lying around (maybe even
for pdb in the future).

On Fri, Jan 26, 2018 at 8:32 PM, Zachary Turner <zturner at google.com>
wrote:
> In general, we should be able to accept any MSVC .obj file to LLD.  At the
> very least, we're not aware of any cases that don't work.
>
> Does your MSVC .obj file link fine before you add the .debug$H?
>
> On Fri, Jan 26, 2018 at 11:23 AM Leonardo Santagada <santagada at
gmail.com>
> wrote:
>
>> Okay, apparently coff2yaml and yaml2coff are not in a great place as
they
>> both don't deal well with the fact that you can have overlapping
sections,
>> which seems to be what clang-cl produces (the .data section points to
the
>> same place as a later section). Which is not a big big problem for me
>> particularly because msvc doesn't even generate .data sections in
.obj.
>>
>> I'm trying to put support for .bss sections in both coff2yaml and
>> yaml2coff... but I still can link just fine with my transformations
>> clang-cl generated files... what does give me problems is msvc .obj
files.
>> Have you tried to link one of these?
>>
>> On Fri, Jan 26, 2018 at 8:05 PM, Leonardo Santagada <santagada at
gmail.com>
>> wrote:
>>
>>> yeah, apparently .bss has a flag of unitialized data that is not
being
>>> respected on the layout of the coff files (it should skip those
sections)
>>> but I dunno what to do with .data as it doesn't have a size.
>>>
>>> (resending as apparently my pastes generated a ton of hidden html
data
>>> and this message hit the mailinglist limit of 100k)
>>> --
>>>
>>> Leonardo Santagada
>>>
>>
>>
>>
>> --
>>
>> Leonardo Santagada
>>
>

-- 

Leonardo Santagada
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180126/e41d11ab/attachment.html>

We considered that early on, but most object files actually end up in .lib
files so unless there were a way to connect the objects in the .lib to the
corresponding .ghash files, this would disable ghash usage for a large
amount of inputs. Supporting both is an option, but it adds a bit of
complexity and I’m not totally convinced it’s worth it
On Fri, Jan 26, 2018 at 11:38 AM Leonardo Santagada <santagada at
gmail.com>
wrote:
> it does.
>
> I just had an epiphany: why not just write a .ghash file and have lld read
> those if they exist for an .obj file?
>
> Seem much simpler than trying to wire up a 20 year old file format. I will
> try to do this, is something like this acceptable for LLD? The cool thing
> is that I can generate .ghash for .lib or any obj lying around (maybe even
> for pdb in the future).
>
> On Fri, Jan 26, 2018 at 8:32 PM, Zachary Turner <zturner at
google.com>
> wrote:
>
>> In general, we should be able to accept any MSVC .obj file to LLD.  At
>> the very least, we're not aware of any cases that don't work.
>>
>> Does your MSVC .obj file link fine before you add the .debug$H?
>>
>> On Fri, Jan 26, 2018 at 11:23 AM Leonardo Santagada <santagada at
gmail.com>
>> wrote:
>>
>>> Okay, apparently coff2yaml and yaml2coff are not in a great place
as
>>> they both don't deal well with the fact that you can have
overlapping
>>> sections, which seems to be what clang-cl produces (the .data
section
>>> points to the same place as a later section). Which is not a big
big
>>> problem for me particularly because msvc doesn't even generate
.data
>>> sections in .obj.
>>>
>>> I'm trying to put support for .bss sections in both coff2yaml
and
>>> yaml2coff... but I still can link just fine with my transformations
>>> clang-cl generated files... what does give me problems is msvc .obj
files.
>>> Have you tried to link one of these?
>>>
>>> On Fri, Jan 26, 2018 at 8:05 PM, Leonardo Santagada <santagada
at gmail.com
>>> > wrote:
>>>
>>>> yeah, apparently .bss has a flag of unitialized data that is
not being
>>>> respected on the layout of the coff files (it should skip those
sections)
>>>> but I dunno what to do with .data as it doesn't have a
size.
>>>>
>>>> (resending as apparently my pastes generated a ton of hidden
html data
>>>> and this message hit the mailinglist limit of 100k)
>>>> --
>>>>
>>>> Leonardo Santagada
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Leonardo Santagada
>>>
>>
>
>
> --
>
> Leonardo Santagada
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180126/c020f05d/attachment.html>

We don't generate any .lib as those don't work well with incremental
linking (and give zero advantages when linking AFAIK), and it would be
pretty easy to have a modern format for having a .ghash for multiple files,
something simple like size prefixed name and then size prefixed ghash blobs.

On Fri, Jan 26, 2018 at 8:44 PM, Zachary Turner <zturner at google.com>
wrote:
> We considered that early on, but most object files actually end up in .lib
> files so unless there were a way to connect the objects in the .lib to the
> corresponding .ghash files, this would disable ghash usage for a large
> amount of inputs. Supporting both is an option, but it adds a bit of
> complexity and I’m not totally convinced it’s worth it
>
> On Fri, Jan 26, 2018 at 11:38 AM Leonardo Santagada <santagada at
gmail.com>
> wrote:
>
>> it does.
>>
>> I just had an epiphany: why not just write a .ghash file and have lld
>> read those if they exist for an .obj file?
>>
>> Seem much simpler than trying to wire up a 20 year old file format. I
>> will try to do this, is something like this acceptable for LLD? The
cool
>> thing is that I can generate .ghash for .lib or any obj lying around
(maybe
>> even for pdb in the future).
>>
>> On Fri, Jan 26, 2018 at 8:32 PM, Zachary Turner <zturner at
google.com>
>> wrote:
>>
>>> In general, we should be able to accept any MSVC .obj file to LLD. 
At
>>> the very least, we're not aware of any cases that don't
work.
>>>
>>> Does your MSVC .obj file link fine before you add the .debug$H?
>>>
>>> On Fri, Jan 26, 2018 at 11:23 AM Leonardo Santagada <santagada
at gmail.com>
>>> wrote:
>>>
>>>> Okay, apparently coff2yaml and yaml2coff are not in a great
place as
>>>> they both don't deal well with the fact that you can have
overlapping
>>>> sections, which seems to be what clang-cl produces (the .data
section
>>>> points to the same place as a later section). Which is not a
big big
>>>> problem for me particularly because msvc doesn't even
generate .data
>>>> sections in .obj.
>>>>
>>>> I'm trying to put support for .bss sections in both
coff2yaml and
>>>> yaml2coff... but I still can link just fine with my
transformations
>>>> clang-cl generated files... what does give me problems is msvc
.obj files.
>>>> Have you tried to link one of these?
>>>>
>>>> On Fri, Jan 26, 2018 at 8:05 PM, Leonardo Santagada <
>>>> santagada at gmail.com> wrote:
>>>>
>>>>> yeah, apparently .bss has a flag of unitialized data that
is not being
>>>>> respected on the layout of the coff files (it should skip
those sections)
>>>>> but I dunno what to do with .data as it doesn't have a
size.
>>>>>
>>>>> (resending as apparently my pastes generated a ton of
hidden html data
>>>>> and this message hit the mailinglist limit of 100k)
>>>>> --
>>>>>
>>>>> Leonardo Santagada
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Leonardo Santagada
>>>>
>>>
>>
>>
>> --
>>
>> Leonardo Santagada
>>
>

-- 

Leonardo Santagada
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180126/d649e578/attachment.html>