Debugger in Pelles C IDE 9.00.9 is wrong

[matze]

I found bugs in Pelles C 9.00.9 in my 64 bit test program. The debugger does not recognize that some lines in the program contain compilable code. Because of this, I can not place valid breakpoints on these lines, and no assembler code will be displayed for those lines.

[frankie]

Try recompiling without optimizations.

[matze]

I'm already used to testing my programs without compiler optimizations.

[frankie]

I'm already used to testing my programs without compiler optimizations.

Good, this should be the correct way to debug.
Anyway looking at the disassembling you provided, and that I haven't observed carefully before, I can deduct a couple of things.
There is no place just following the switch to place a break, it should be placed on the call of the subroutine 'OnInitDialog'. The compare instructions and the following conditional jump are before the execution point you are looking for.
Then more than a bug the point is that the actual debugger isn't smart enough... 

[TimoVJL]

I think Pelle is aware of this problem.
It's a debug info problem in v9, not quite a debugger problem ?
Pelles C debug format for version 9 is available, so it's possible to check it.

EDIT: a test case:

Code: [Select]

void foo1(int id) {}
void foo2(int id) {}
void foo3(int id) {}

int foo(int id, int msg)
{
switch (id) {
case 0:
switch (msg)
{
foo1(id);
break;
case 2:
foo2(id);
break;
case 3:
foo3(id);
break;
default: break;
}
case 1:
foo1(id);
break;
case 2:
foo2(id);
break;
case 3:
foo3(id);
break;
default: return 0;
}
return id;
}

void __cdecl mainCRTStartup(void)
{
foo(0, 0);
foo(1, 1);
foo(2, 2);
foo(3, 3);
}

EDIT 2019-08-16: PrjObjDbgLines_WS_a1.zip show coff line numbers in object file.

EDIT: more info

Code: [Select]

10: {
  [0000004A] 83F802                 cmp               eax,2
  [0000004D] 740E                   je                0000005D
  [0000004F] 83F803                 cmp               eax,3
  [00000052] 7510                   jne               00000064
11: foo1(id);
12: break;
13: case 2:
14: foo2(id);
15: break;
16: case 3:
17: foo3(id);
  [00000054] 53                     push              ebx
  [00000055] E8C6FFFFFF             call              00000020
  [0000005A] 59                     pop               ecx
  [0000005B] EB07                   jmp               00000064
  [0000005D] 53                     push              ebx
  [0000005E] E8ADFFFFFF             call              00000010
  [00000063] 59                     pop               ecx
18: break;
19: default: break;
20: }
21: case 1:
22: foo1(id);
  [00000064] 53                     push              ebx
podump

Code: [Select]

       1 sect # (0-C4)
      11 number of lines:
         lineno   offset
             1         0
             2        10
             3        20
             5        30
             7        3A
             A        4A
            11        54
            16        64
            19        6D
            1C        76
            1E        7F
            20        83
            23        90
            25        93
            26        9F
            27        AB
            28        B7


[frankie]

It's a debug info problem in v9, not quite a debugger problem.

Well, the point seems to be that the debug info specify a line number that points to a compare/jump instruction sequence that aren't the correct location for the breakpoint.
What is missing is a smart routine that interpret the sequence and moves breakpoint to the correct execution point, that is the jumped location.
Easy to say a little bit more difficult to code... 

[RichieL]

I just ran into a similar problem. It looks, from the disassembly, that it has to do with the compiler "out-of-lining" code - i.e. when you type if(condition) {statements}, instead of branching around the bracketed statements if the condition is false, it compiles the bracketed statements at the end of the procedure (followed by a jump to the code following the "if" statement) and jumps to them if the condition is true - and, in the process, it doesn't assign the line numbers correctly in the debug info.

In my case, the code looked like:

    do
    {
       
        if (condition)
        {
            statements;
            continue;
        }
        more statements;
    } while (loop condition);

and the "more statements" were out-of-lined, even with Optimizations set to None. Since I really wanted to set a breakpoint in one of those out-of-lined statements, I inverted the "if" condition and swapped "statements" and "more statements". That worked for me, but it is far from an elegant solution...

    Richie