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.
Try recompiling without optimizations.
I'm already used to testing my programs without compiler optimizations.
Quote from: matze on August 12, 2019, 08:05:19 PM
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... :(
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: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 info10: {
[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 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
Quote from: TimoVJL on August 13, 2019, 05:38:27 PM
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... :(
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