NO

Author Topic: Debugger problem displaying long long bitfields  (Read 3940 times)

RichieL

  • Guest
Debugger problem displaying long long bitfields
« on: May 28, 2015, 08:12:32 AM »
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

  • Guest
Re: Debugger problem displaying long long bitfields
« Reply #1 on: May 28, 2015, 08:23:33 AM »
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

Offline Bitbeisser

  • Global Moderator
  • Member
  • *****
  • Posts: 772
Re: Debugger problem displaying long long bitfields
« Reply #2 on: May 29, 2015, 08:24:37 PM »
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

Offline jj2007

  • Member
  • *
  • Posts: 536
Re: Debugger problem displaying long long bitfields
« Reply #3 on: May 30, 2015, 05:06:53 AM »
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...

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 2096
Re: Debugger problem displaying long long bitfields
« Reply #4 on: May 30, 2015, 06:47:16 PM »
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);
« Last Edit: May 30, 2015, 06:48:49 PM by frankie »
It is better to be hated for what you are than to be loved for what you are not. - Andre Gide

Offline Bitbeisser

  • Global Moderator
  • Member
  • *****
  • Posts: 772
Re: Debugger problem displaying long long bitfields
« Reply #5 on: May 31, 2015, 06:07:11 AM »
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
Quote
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

Offline Bitbeisser

  • Global Moderator
  • Member
  • *****
  • Posts: 772
Re: Debugger problem displaying long long bitfields
« Reply #6 on: May 31, 2015, 06:09:56 AM »
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

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 2096
Re: Debugger problem displaying long long bitfields
« Reply #7 on: May 31, 2015, 12:11:36 PM »
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.
« Last Edit: May 31, 2015, 12:13:32 PM by frankie »
It is better to be hated for what you are than to be loved for what you are not. - Andre Gide