[lld] r194349 - [ELF] Un-break undef-from-main-dso.test on MSVC 2012.

Rui Ueyama ruiu at google.com
Sun Nov 10 00:30:05 PST 2013


On Sun, Nov 10, 2013 at 12:15 AM, Chandler Carruth <chandlerc at google.com>wrote:

> On Sun, Nov 10, 2013 at 12:06 AM, Rui Ueyama <ruiu at google.com> wrote:
>
>> What was proposed? Is that something that might have helped me find the
>> issue? It actually took a whole day to find it and workaround, so any help
>> would have been appreciated...
>>
>
> I'm not sure we have looked at anything that would have helped in this
> specific case. =/
>
> Essentially, when Warren was working on the record layout in Clang to be
> compatible with MSVC he found a lot of cases where the behavior might be
> "buggy" from the perspective of the application developer. We'd like to
> have warnings in Clang for when these situations arise, but haven't yet
> implemented them.
>

Sounds like a plan. And I'd think having an ABI compatible compiler itself
would have helped me figure out whether this is a bug of a specific
compiler or not. :)


>
>
>>
>>
>> On Sat, Nov 9, 2013 at 11:56 PM, Chandler Carruth <chandlerc at google.com>wrote:
>>
>>> This commit might help motivate the warnings we've discussed surrounding
>>> MSVC record layout...
>>>
>>>
>>> On Sat, Nov 9, 2013 at 11:48 PM, Rui Ueyama <ruiu at google.com> wrote:
>>>
>>>> Author: ruiu
>>>> Date: Sun Nov 10 01:48:33 2013
>>>> New Revision: 194349
>>>>
>>>> URL: http://llvm.org/viewvc/llvm-project?rev=194349&view=rev
>>>> Log:
>>>> [ELF] Un-break undef-from-main-dso.test on MSVC 2012.
>>>>
>>>> The result of sizeof(SymbolTable<ELFT>::SymbolEntry) in
>>>> DynamicSymbolTable
>>>> <ELFT>::write() was different from the same expression in
>>>> RelocationTable
>>>> <ELFT>::write(), although the same template parameters were passed.
>>>> They were
>>>> 40 and 32, respectively. As a result, the same vector was treated as a
>>>> vector of 40 byte values in some places and a vector of 32 values in
>>>> other
>>>> places. That caused an weird issue, resulting in collapse of the
>>>> rela.dyn
>>>> section.
>>>>
>>>> I suspect that this is a padding size calculation bug in MSVC 2012, but
>>>> I
>>>> may be wrong. Reordering the fields to eliminate padding seems to fix
>>>> the
>>>> issue.
>>>>
>>>> Modified:
>>>>     lld/trunk/lib/ReaderWriter/ELF/SectionChunks.h
>>>>
>>>> Modified: lld/trunk/lib/ReaderWriter/ELF/SectionChunks.h
>>>> URL:
>>>> http://llvm.org/viewvc/llvm-project/lld/trunk/lib/ReaderWriter/ELF/SectionChunks.h?rev=194349&r1=194348&r2=194349&view=diff
>>>>
>>>> ==============================================================================
>>>> --- lld/trunk/lib/ReaderWriter/ELF/SectionChunks.h (original)
>>>> +++ lld/trunk/lib/ReaderWriter/ELF/SectionChunks.h Sun Nov 10 01:48:33
>>>> 2013
>>>> @@ -614,12 +614,12 @@ class SymbolTable : public Section<ELFT>
>>>>    struct SymbolEntry {
>>>>      SymbolEntry(const Atom *a, const Elf_Sym &sym,
>>>>                  const lld::AtomLayout *layout)
>>>> -        : _atom(a), _symbol(sym), _atomLayout(layout) {}
>>>> +        : _atom(a), _atomLayout(layout), _symbol(sym) {}
>>>>      SymbolEntry() : _atom(nullptr) {}
>>>>
>>>>      const Atom *_atom;
>>>> -    Elf_Sym _symbol;
>>>>      const lld::AtomLayout *_atomLayout;
>>>> +    Elf_Sym _symbol;
>>>>    };
>>>>
>>>>  public:
>>>>
>>>>
>>>> _______________________________________________
>>>> 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/20131110/5a34ce3c/attachment.html>


More information about the llvm-commits mailing list