Pelles C forum
Pelles C => Bug reports => Topic started by: matze on August 11, 2019, 10:37:35 PM
-
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.
-
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
-
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