Building lld with Visual Studio 2012 RC


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.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

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

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!

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


I would be sorely tempted to just do the memset first:

      ::memset(to, 0, cmdsize);
      ::memcpy(to, (uint8_t*)&cmd, 12);
      ::memcpy(&to[12],, _name.size());

Easy to understand, easy to convince yourself that it is correct, and slightly slower at runtime.

-- Marshall

Marshall Clow Idio Software <>

A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait).
        -- Yu Suzuki

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.

"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:

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

2012/6/17 Cesar Mello <>