J. David Bryan wrote:
I am unable to set breakpoints, and therefore unable to debug, GPC programs under GDB. The cause appears to be bad debugging information generated by GPC. For example, compiling:
program debug (output);
var i, j: integer;begin i := 1; j := 2; writeln ('A Pascal test'); writeln ('Variable i is ', i); writeln ('Variable j is ', j) end.
with:
gpc -g -o debug.exe debug.pas
and starting GDB with:
gdb debug.exe
and then trying to set breakpoints, I see the following:
(gdb) break 6 Breakpoint 1 at $4011f2: file <implicit code>, line 6. (gdb) break 8 Note: breakpoint 1 also set at pc $4011f2. Breakpoint 2 at $4011f2: file <implicit code>, line 8. (gdb) break 10 Note: breakpoints 1 and 2 also set at pc $4011f2. Breakpoint 3 at $4011f2: file <implicit code>, line 10.
Note that all breakpoints reference the same address. Attempting to start the program gives:
AFAICS, setting the breakpoints works fine if you specify the file name (break foo.pas:6).
GPC creates some code automatically at the end of the program, including a `main' function which calls the initializers, then the real Pascal main program, and finally the finalizers. In order to avoid another debugging problem (that execution seems to start at the end of the file when you step through it, e.g. in RHIDE), we're telling the debugger that these functions are in a non-existent source file `<implicit code>'.
As I see now, gdb seems to use the file name of `main' as the default source file name. This might be reasonable for C, but here it causes the default source file name to be `<implicit code>' which leads to these strange results.
I don't know so much about gdb, so I don't know if/how one can tell gdb about the real source file, and I don't see what we could change in GPC without introducing the other problem again. If anyone has an idea ...
Is this the same error that is listed in the "Known Bugs" section of the GPC manual as:
"...error in debug entries generated for objects" 8F990E3D9A6FD1118F3B0000F81EA1D84985D7@exchsa2.dsto.defence.gov.au
No, that one was referring to OOP objects. Actually, I just checked it, and it seems to work now. (The report was 4 years old, so I can't tell exactly when or how it was fixed, but there have been so many changes since then ...)
Frank