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

[Nick Kledzik]

On Jan 3, 2014, at 1:12 PM, Joey Gouly <joey.gouly at gmail.com> wrote:

> 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?
> 
Yes

-Nick


> 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/33b789bb/attachment.html>