[PATCH] [lld] [MachO] Begin to flesh out normalizedToAtoms

[Joey Gouly]

Nick,

Is it okay to land this change with a FIXME to the MachODefinedAtom and a
FIXME to see if we can avoid copying the data?
On 3 Jan 2014 03:14, "Nick Kledzik" <kledzik at apple.com> wrote:

>
> On Jan 2, 2014, at 5:48 PM, Chandler Carruth <chandlerc at google.com> wrote:
>
>
> On Thu, Jan 2, 2014 at 8:07 PM, Nick Kledzik <kledzik at apple.com> wrote:
>
>> On Jan 2, 2014, at 4:41 PM, Joey Gouly <joey.gouly at gmail.com> wrote:\
>> >
>> >
>> > ================
>> > Comment at: lib/ReaderWriter/MachO/MachONormalizedFileYAML.cpp:282
>> > @@ -280,1 +281,3 @@
>> > +        io, sect.content);
>> > +    io.mapOptional("content",         content->normalizedContent);
>> >     io.mapOptional("relocations",     sect.relocations);
>> > ----------------
>> > kledzik at apple.com wrote:
>> >> I think you can just cast the address of sect.content to be of type
>> ContentBytes and it should all just work with no need for NormalizedContent.
>> > mapOptional wants a reference to the content, so I cant use the address
>> of content, and as far as I can tell, I can't change the type of a
>> reference.
>> >
>> > Unless I'm mistaken, I can't do this without copying.
>>
>> This works for me:
>>
>> Index: lib/ReaderWriter/MachO/MachONormalizedFileYAML.cpp
>> ===================================================================
>> --- lib/ReaderWriter/MachO/MachONormalizedFileYAML.cpp  (revision 198349)
>> +++ lib/ReaderWriter/MachO/MachONormalizedFileYAML.cpp  (working copy)
>> @@ -276,7 +276,8 @@
>>      io.mapOptional("attributes",      sect.attributes);
>>      io.mapOptional("alignment",       sect.alignment, 0U);
>>      io.mapRequired("address",         sect.address);
>> -    io.mapOptional("content",         sect.content);
>> +    ContentBytes &cont = *reinterpret_cast<ContentBytes*>(&sect.content);
>>
>
> Using the vector after this is totally undefined behavior. You can't just
> cast vector<T>* to vector<U>* and then access the vector with that pointer
> when T != U. It doesn't matter what the layout or size of T and U are, the
> vector types are completely different and might have nothing to do with
> each other.
>
> Are you saying that the compiler can layout the vector<T> object
> differently than a vector<U> object, or that that actual array buffer can
> be laid out differently,  or that the compiler can do something wild in the
> cast because it thinks that types are incompatible?
>
> How can two compilers generate binary compatible code if the the layout of
> classes is not deterministic?  If the layout is deterministic, why would
> vector<T> and vector<U> be different?
>
> -Nick
>
>
> _______________________________________________
> 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/20140103/bc464095/attachment.html>