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

[Zachary Turner via llvm-dev]

Hmm, ok.  In that case let me try again without my local changes.  Maybe
they are getting in the way :-/

On Fri, Jan 26, 2018 at 9:51 AM Leonardo Santagada <santagada at gmail.com>
wrote:

> it is identical to me... wierd.
>
> On Fri, Jan 26, 2018 at 6:49 PM, Zachary Turner <zturner at google.com>
> wrote:
>
>> (Ignore the fact that my hashes are 8 byte in the "good" file, this is
>> due to some local changes I've been experimenting with)
>>
>> On Fri, Jan 26, 2018 at 9:48 AM Zachary Turner <zturner at google.com>
>> wrote:
>>
>>> I did this:
>>>
>>> // a.cpp
>>> static int x = 0;
>>> void b(int);
>>> void a(int) {
>>>   if (x)
>>>     b(x);
>>> }
>>> int main(int argc, char **argv) {
>>>   a(argc);
>>>   return x;
>>> }
>>>
>>>
>>> clang-cl /Z7 /c a.cpp /Foa.noghash.obj
>>> clang-cl /Z7 /c a.cpp -mllvm -emit-codeview-ghash-section
>>> /Foa.ghash.good.obj
>>> llvm-objcopy a.noghash.obj a.ghash.bad.obj
>>> obj2yaml a.ghash.good.obj > a.ghash.good.yaml
>>> obj2yaml a.ghash.bad.obj > a.ghash.bad.yaml
>>>
>>> Then open these 2 yaml files up in a diff viewer.  It looks like the
>>> hashes aren't getting emitted at all.  For example, in the good yaml file I
>>> see this:
>>>
>>>   - Name:            '.debug$H'
>>>     Characteristics: [ IMAGE_SCN_CNT_INITIALIZED_DATA,
>>> IMAGE_SCN_MEM_DISCARDABLE, IMAGE_SCN_MEM_READ ]
>>>     Alignment:       4
>>>     SectionData:
>>>  C5C93301000001005549419E78044E3896D45CD7009428758BE4A1E2B3E022BA267DEE221F5C42B17BCA182AF84584814A8B5E7E3FB17B397A9E3DEA75CD5627
>>>     GlobalHashes:
>>>       Version:         0
>>>       HashAlgorithm:   1
>>>       HashValues:
>>>         - 5549419E78044E38
>>>         - 96D45CD700942875
>>>         - 8BE4A1E2B3E022BA
>>>         - 267DEE221F5C42B1
>>>         - 7BCA182AF8458481
>>>         - 4A8B5E7E3FB17B39
>>>         - 7A9E3DEA75CD5627
>>>   - Name:            .pdata
>>>
>>> And in the bad yaml file I see this:
>>>   - Name:            '.debug$H'
>>>     Characteristics: [ IMAGE_SCN_CNT_INITIALIZED_DATA,
>>> IMAGE_SCN_MEM_DISCARDABLE, IMAGE_SCN_MEM_READ ]
>>>     Alignment:       4
>>>     SectionData:     C5C9330100000000
>>>     GlobalHashes:
>>>       Version:         0
>>>       HashAlgorithm:   0
>>>   - Name:            .pdata
>>>
>>> Don't focus too much on trying to figure out weird linker errors.  Just
>>> get the output of obj2yaml to be identical when run under a diff utility,
>>> then everything should work fine.
>>>
>>> On Fri, Jan 26, 2018 at 7:27 AM Leonardo Santagada <santagada at gmail.com>
>>> wrote:
>>>
>>>> I'm so close I can almost smell it :)
>>>>
>>>> I know how bad the code looks, I don't intend to submit this, but if
>>>> you want to try it out its at:
>>>> https://gist.github.com/santagada/544136b1ee143bf31653b1158ac6829e
>>>>
>>>> I'm seeing: lld-link.exe: error: duplicate symbol:
>>>> "<redacted_unmangled>" (<redacted>) in <internal> and in
>>>> <redacted_filename>.obj, looking at the .yaml dump the symbols are all
>>>> similar to this:
>>>>
>>>> - Name: <redacted>
>>>> Value: 0
>>>> SectionNumber: 0
>>>> SimpleType: IMAGE_SYM_TYPE_NULL
>>>> ComplexType: IMAGE_SYM_DTYPE_FUNCTION
>>>> StorageClass: IMAGE_SYM_CLASS_WEAK_EXTERNAL
>>>> WeakExternal:
>>>> TagIndex: 134
>>>> Characteristics: IMAGE_WEAK_EXTERN_SEARCH_LIBRARY
>>>>
>>>> On Thu, Jan 25, 2018 at 8:01 PM, Zachary Turner <zturner at google.com>
>>>> wrote:
>>>>
>>>>> I haven't really dabbled in this part of the COFF format personally,
>>>>> so hopefully I'm not leading you astray :)
>>>>>
>>>>> But I checked the code for coff2yaml, and I see this:
>>>>>
>>>>>       } else if (Symbol.isSectionDefinition()) {
>>>>>         // This symbol represents a section definition.
>>>>>         assert(Symbol.getNumberOfAuxSymbols() == 1 &&
>>>>>                "Expected a single aux symbol to describe this
>>>>> section!");
>>>>>         const object::coff_aux_section_definition *ObjSD =
>>>>>             reinterpret_cast<const object::coff_aux_section_definition
>>>>> *>(
>>>>>                 AuxData.data());
>>>>>
>>>>> So it looks like you need exactly 1 aux symbol for each section symbol.
>>>>>
>>>>> I then scrolled up in this function to figure out where AuxData comes
>>>>> from, and it comes from COFFObjectFile::getSymbolAuxData.  I think that
>>>>> function holds the clue to what you need to do.  It looks like you need to
>>>>> set coff::symbol::NumberOfAuxSymbols to 1, and then there is a comment in
>>>>> getSymbolAuxData which says:
>>>>>
>>>>>     // AUX data comes immediately after the symbol in COFF
>>>>>     Aux = reinterpret_cast<const uint8_t *>(Symbol.getRawPtr()) +
>>>>> SymbolSize;
>>>>>
>>>>> So I think you just need to write the bytes immediately after the
>>>>> coff::symbol.  The thing you need to write looks like a
>>>>> coff::coff_aux_section_definition structure.
>>>>>
>>>>> For the CheckSum, look at WinCOFFObjectWriter::writeSection.  It looks
>>>>> like its a CRC32 of the actual section contents, which you can generate
>>>>> with a couple of lines of code:
>>>>>
>>>>>   JamCRC JC(/*Init=*/0);
>>>>>   JC.update(DebugHContents);
>>>>>   AuxSymbol.CheckSum = JC.getCRC();
>>>>>
>>>>> Hope this helps
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180126/76f12887/attachment-0001.html>