crash fix, need help

Worked on tracking down the crash I have with my small test app, a.k.a.
clc.

The crash is actually a failed assertion at
RecordOrganizer::addPaddingFields, due to the RequiredBits not being a
multiple of 8.

The struct in question is struct _win_st from ncurses.h, and the field
causing this is _clear, which is of type _Bool, and immediately followed
another _Bool, _notimeout. These are the first two _Bool types in the
source.

The alignment is off by a single bit. I'm figuring what is happening is
that the first _Bool is being added as a single bit field to the struct,
and then the second _Bool is trying to add padding and failing because
the addPaddingFields method can only add padding with bits in multiples
of 8.

What I'm wondering is what the proper fix is. Either _Bool should be an
8-bit type, or addPaddingFields needs to be able to pad by arbitrary
bits _and_ two (or more) consecutive _Bool types should not be forcing
extra padding. (It seems that _Bool wants 32-bit alignment, for that
matter, or I'm just failing to understand the meaning of the
AlignmentInBits calculated in addLLVMField.)

Once that's figured out, of course, I need to determine how to actually
do either of those. :slight_smile:

By the way, I must say, given its size and the complexity of its subject
material, the clang code is really quite readable. In my line of work,
I run into small 30 line barely-functional scripts that are harder to
grok than clang. This is great work!

- Sean

Devang is the keeper of struct layout :slight_smile: , any ideas Devang?

-Chris

Here is a test case for the crash.

I looked over the C standard, and it doesn't specify any actual size or
padding requirements for _Bool. Not much of a surprise. I'm going to
look at what GCC does, since I figure we want binaries compiled with
clang to work when linked against binaries compiled with gcc on the same
arch/platform.

Note that I'm running on an Linux/amd64. Not sure if this bug occurs on
other archs.

$ clang -emit-llvm _boolpad.c

clang: CodeGenTypes.cpp:471:
void<unnamed>::RecordOrganizer::addPaddingFields(unsigned int):
Assertion `(RequiredBits % 8) == 0 && "FIXME Invalid struct layout"'
failed.

_boolpad.c (129 Bytes)

Hi Sean,

Worked on tracking down the crash I have with my small test app, a.k.a.
clc.

The crash is actually a failed assertion at
RecordOrganizer::addPaddingFields, due to the RequiredBits not being a
multiple of 8.

The struct in question is struct _win_st from ncurses.h, and the field
causing this is _clear, which is of type _Bool, and immediately followed
another _Bool, _notimeout. These are the first two _Bool types in the
source.

The alignment is off by a single bit. I'm figuring what is happening is
that the first _Bool is being added as a single bit field to the struct,
and then the second _Bool is trying to add padding and failing because
the addPaddingFields method can only add padding with bits in multiples
of 8.

What I'm wondering is what the proper fix is. Either _Bool should be an
8-bit type, or addPaddingFields needs to be able to pad by arbitrary
bits _and_ two (or more) consecutive _Bool types should not be forcing
extra padding. (It seems that _Bool wants 32-bit alignment, for that
matter, or I'm just failing to understand the meaning of the
AlignmentInBits calculated in addLLVMField.)

Once that's figured out, of course, I need to determine how to actually
do either of those. :slight_smile:

Even though size of bool may be 1 bit it should occupy 8-bit in struct.
Fixed.
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20071210/003265.html

Neat. Thanks!

Now my application code is causing clang to crash in llvm proper in
LeakDetector.cpp. There's still some fun for me to track down. :slight_smile:

Try updating your LLVM tree, there was a window where a patch yesterday broke a ton of stuff. If you checked out llvm in that window, it could just be llvm that is broken.

-Chris

> Now my application code is causing clang to crash in llvm proper in
> LeakDetector.cpp. There's still some fun for me to track down. :slight_smile:

Try updating your LLVM tree, there was a window where a patch
yesterday broke a ton of stuff. If you checked out llvm in that
window, it could just be llvm that is broken.

Heh. I svn updated again, and now LLVM doesn't even compile. :slight_smile:
Something about "bad register expression" in the x86 JIT code. Guess
I'll have to try again later.

Yes, it is darwin/x86 specific breakage, try now.

-Chris