llvm dev - Jun 2012 - [LLVMdev] Building lld with Visual Studio 2012 RC

OK thanks a lot Michael Spencer!

After getting your latest commit now everything compiles on Visual Studio
2012 RC. I'm just playing around to learn.

Maybe this is the funniest place to start assessing my possibilities of
contributing to llvm in the free time:

Writer* createWriterPECOFF(const WriterOptionsPECOFF &options) {
  assert(0 && "PE/COFF support not implemented yet");
  return nullptr;
}

:-)

Best regards!
Mello


On Sat, Jun 16, 2012 at 10:22 PM, Michael Spencer <bigcheesegs at
gmail.com>wrote:
> On Sat, Jun 16, 2012 at 4:15 PM, Cesar Mello <cmello at gmail.com>
wrote:
> > Hi!
> >
> > I'm trying to build lld Microsoft Visual Studio 2012 RC, but it
seems the
> > bzero function is not available.
> >
> > Could memset be used instead of bzero? Or maybe define a bzero for
msvc
> > using memset.
> >
> > For example:
> >
> >       // in-memory matches on-disk, so copy first fields followed by
path
> >       ::memcpy(to, (uint8_t*)&cmd, 12);
> >       ::memcpy(&to[12], _name.data(), _name.size());
> >       ::bzero(&to[12+_name.size()], cmdsize-(12+_name.size()));
> >
> > The bzero line could be changed to:
> >
> >  ::memset(&to[12+_name.size()], 0, cmdsize-(12+_name.size()));
> >
> > Thanks a lot for the attention and congratulations for the great
work!!!
> >
> > Best regards
> > Mello
>
> While this will make it compile, the code is not valid to begin with.
> It is trying to do a raw memory copy of a non standard-layout type.
> nameoffset is not guaranteed to directly follow cmdsize.
>
> Fixing this will require quite a few changes, so for now I've
> committed your change.
>
> - Michael Spencer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120617/6039a9dd/attachment.html>

On Jun 16, 2012, at 8:23 PM, Cesar Mello wrote:
> While this will make it compile, the code is not valid to begin with.
> It is trying to do a raw memory copy of a non standard-layout type.
> nameoffset is not guaranteed to directly follow cmdsize.
Are you saying that in:

struct A {
    int  f1;   // offset 0
    int  f2;   // offset 4
};

struct B : public A {
    int  f3;   // offset 8 ?
};

that f3 is not guaranteed to have the same offset it would have had, had it been
the third field of A (offset 8)?

-Nick


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120616/ef9e57ba/attachment.html>

On Sat, Jun 16, 2012 at 8:50 PM, Nick Kledzik <kledzik at apple.com>
wrote:
> On Jun 16, 2012, at 8:23 PM, Cesar Mello wrote:
>
> While this will make it compile, the code is not valid to begin with.
> It is trying to do a raw memory copy of a non standard-layout type.
> nameoffset is not guaranteed to directly follow cmdsize.
>
>
> Are you saying that in:
>
> struct A {
>     int  f1;   // offset 0
>     int  f2;   // offset 4
> };
>
> struct B : public A {
>     int  f3;   // offset 8 ?
> };
>
> that f3 is not guaranteed to have the same offset it would have had, had it
> been the third field of A (offset 8)?
>
> -Nick
In the case of non-standard-layout types, yes.

"Unless it is a bit-field (9.6), a most derived object shall have a
non-zero size and shall occupy one or more
bytes of storage. Base class subobjects may have zero size. An object
of trivially copyable or standard-layout
type (3.9) shall occupy contiguous bytes of storage."

"A standard-layout class is a class that:
— has no non-static data members of type non-standard-layout class (or
array of such types) or reference,
— has no virtual functions (10.3) and no virtual base classes (10.1),
— has the same access control (Clause 11) for all non-static data members,
— has no non-standard-layout base classes,
— either has no non-static data members in the most derived class and
at most one base class with
non-static data members, or has no base classes with non-static data
members, and
— has no base classes of the same type as the first non-static data member.
108"

"Nonstatic data members of a (non-union) class with the same access
control (Clause 11) are allocated so
that later members have higher addresses within a class object. The
order of allocation of non-static data
members with different access control is unspecified (11).
Implementation alignment requirements might
cause two adjacent members not to be allocated immediately after each
other; so might requirements for
space for managing virtual functions (10.3) and virtual base classes
(10.1)."

load_command has two virtual functions and dylinker_command has
non-static data members with different access specifiers.

- Michael Spencer

Yes, if I was a woman, I'd be sending you kisses!  PE-COFF support is
definitely wanted!

Do you have the PE-COFF docs from Microsoft?    I linked to it in an
earlier post, but here it is again:

http://msdn.microsoft.com/en-us/library/windows/hardware/gg463119.aspx

You are probably familiar with DUMPBIN, but that's going to be a very, very
useful tool for you.

2012/6/17 Cesar Mello <cmello at gmail.com>
> OK thanks a lot Michael Spencer!
>
> After getting your latest commit now everything compiles on Visual Studio
> 2012 RC. I'm just playing around to learn.
>
> Maybe this is the funniest place to start assessing my possibilities of
> contributing to llvm in the free time:
>
> Writer* createWriterPECOFF(const WriterOptionsPECOFF &options) {
>   assert(0 && "PE/COFF support not implemented yet");
>   return nullptr;
> }
>
> :-)
>
> Best regards!
> Mello
>
>
> On Sat, Jun 16, 2012 at 10:22 PM, Michael Spencer <bigcheesegs at
gmail.com>wrote:
>
>> On Sat, Jun 16, 2012 at 4:15 PM, Cesar Mello <cmello at
gmail.com> wrote:
>> > Hi!
>> >
>> > I'm trying to build lld Microsoft Visual Studio 2012 RC, but
it seems
>> the
>> > bzero function is not available.
>> >
>> > Could memset be used instead of bzero? Or maybe define a bzero for
msvc
>> > using memset.
>> >
>> > For example:
>> >
>> >       // in-memory matches on-disk, so copy first fields followed
by
>> path
>> >       ::memcpy(to, (uint8_t*)&cmd, 12);
>> >       ::memcpy(&to[12], _name.data(), _name.size());
>> >       ::bzero(&to[12+_name.size()],
cmdsize-(12+_name.size()));
>> >
>> > The bzero line could be changed to:
>> >
>> >  ::memset(&to[12+_name.size()], 0, cmdsize-(12+_name.size()));
>> >
>> > Thanks a lot for the attention and congratulations for the great
work!!!
>> >
>> > Best regards
>> > Mello
>>
>> While this will make it compile, the code is not valid to begin with.
>> It is trying to do a raw memory copy of a non standard-layout type.
>> nameoffset is not guaranteed to directly follow cmdsize.
>>
>> Fixing this will require quite a few changes, so for now I've
>> committed your change.
>>
>> - Michael Spencer
>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120617/4ef44b4f/attachment.html>