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

[Nick Kledzik]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140102/6d731c48/attachment.html>