Debugger problem displaying long long bitfields

[RichieL]

unsigned long long bitfields are part of the Microsoft extensions to Pelles C. They generate correct code, however the debugger will not correctly display the contents of bitfields that are not completely contained in the first 32 bits of the bitfield definition.

Example program:

Code: [Select]

// Demonstrate debugger problem: bad display of ull bitfields

struct {
unsigned long long  a : 15, b : 15, c : 15, d : 15, e : 4;
} foo;

int main(int argc, char **argv)
{
    foo.a = 1234;
    foo.b = 5678;
    foo.c = 1111;
    foo.d = 2222;
    foo.e = 5;
    return foo.b;   // Set breakpoint here
When this program is run with the breakpoint set as indicated, the resulting debugger panel is attached as a .JPG. If you can't see it (preview doesn't show it), fields a and b are displayed correctly, but c, d, and e are not.

        Richie

[RichieL]

Should have mentioned: this is using V8.00.60 of Pelles C, Full compiler debug info, CodeView & COFF linker output, no optimizations. Project was defined either as a Win32 Console Program or a Win64 Console Program (incorrect fields display the same bad value in both projects).

Sorry...

        Richie

[Bitbeisser]

Probably not the answer you would like to hear, but a "long long" (64bit) bit field just doesn't make any sense.
AFAIK, nothing over an int (which should be regarded as a 16bit int) is safe...
C99 states:

Code: [Select]

    6.7.2.1 Structure and union specifiers

    4 A bit-field shall have a type that is a qualified or unqualified version of _Bool, signed int, unsigned int, or some other implementation-defined type.

a and b show up correct, as they fit within the internally allocated width, the rest is simply undefined. And I would be surprised if by default, you do not get at least a warning message when you try to compile that code...

Ralf

[jj2007]

a "long long" (64bit) bit field just doesn't make any sense.

Technically speaking, a bit field can have a length of up to 2^(32-3)-1 bits. There is a dedicated instruction, bt:

Code: [Select]

include \masm32\MasmBasic\MasmBasic.inc
  Init
  Let esi=String$(12, Chr$(7)) ; a field of 96 bits
  mov ebx, Len(esi)
  shl ebx, 3 ; 8 bits per byte
  xor ecx, ecx
  .Repeat
bt [esi], ecx ; test the bit at index ecx
.if Carry?
Print "1"
.else
Print "0"
.endif
inc ecx
  .Until ecx>ebx
  Exit
EndOfCode
Output:

1110000011100000111000001110000011100000111000001110000011100000111000001110000011100000111000000

Of course, this is assembler, not C...

[frankie]

The bug is confirmed.
I suppose that it is due to the dynamic nature of the debugger that should be able to handle any conformation of bitfield that the user can use, and the long long type is very unusual so Pelle have not considered it yet.
Ralf the standard (as you reported) says "some other implementation-defined type", and long long is one of them. Infact the compiler correctly supports the long long bitfield, and you can test it adding a printf before the return statement and you'll get the correct values.

Code: [Select]

printf("a=%lld, b=%lld, c=%lld, d=%lld, e=%lld\n", foo.a, foo.b, foo.c, foo.d, foo.e);

[Bitbeisser]

The "implementation-defined" part is what is the problem here, it just doesn't define what has is implemented. Out of experience, I would not use any bitfield larger than a 16bit int.
I checked the online help for Pelle's C, and it does state that it supports long long bit fields, however not by default, but only when the Microsoft Extensions are enabled for the compiler

bit-field must have a type that is a qualified or unqualified version of _Bool, signed int, unsigned int (also char, unsigned char, short, unsigned short, long, unsigned long, long long, unsigned long long if Microsoft extensions are used).

with the default confirming what I would have assumed to be on the safe side...

Ralf

[Bitbeisser]

a "long long" (64bit) bit field just doesn't make any sense.

Technically speaking, a bit field can have a length of up to 2^(32-3)-1 bits. There is a dedicated instruction, bt:

<snip>
Of course, this is assembler, not C...

And hence totally irrelevant here...

Ralf

[frankie]

Ralf I agree with you about to stay on safe side and consider the int to be the maximum reasonable value.
BTW since the compiler accepts long long the debugger have to show the correct value, so we have to say that there is a minor bug in debugger.