When debugging GPC 2.1 programs with GDB, I am unable to print the values of variables that are of the "standard" types. Variables of user-defined types appear to print OK. I am using the Chief's "i486-mingw32" port from:
http://www.gnu-pascal.de/contrib/chief/win32/mingw32/
...but I have observed the same problem in a Mingw version that I built myself.
Test case:
program gdbtest (output);
var i : integer; r : real; c : char; e : (enum1, enum2); s : 0..10; t : string (12);
begin i := 3; r := 3.14159; c := 'Q'; e := enum2; s := 4; t := 'test string';
writeln (i, r, c, s, t); end.
To reproduce:
D:>gpc -v Reading specs from /mingw/lib/gcc-lib/mingw32/2.95.3-6/specs gpc version 2.1 (20020510), based on 2.95.3-6 (mingw special)
D:>gpc -o gdbtest.exe -g gdbtest.pas
D:>gdb gdbtest.exe
GNU gdb 5.1.1 (mingw experimental) Copyright 2002 Free Software Foundation, Inc. [...] This GDB was configured as "mingw32"... (gdb) b gdbtest.pas:18 Breakpoint 1 at $4012c2: file gdbtest.pas, line 18. (gdb) r Starting program: D:/gdbtest.exe
Breakpoint 1, pascal_main_program () at gdbtest.pas:18 18 writeln (i, r, c, s, t); (gdb) p i $1 = void (gdb) p r $2 = void (gdb) p c $3 = void (gdb) p e $4 = Enum2 (gdb) p s $5 = 4 (gdb) p t $6 = 'test string' (gdb) c Continuing.
[program prints "3 3.141590000000000e+00Q4test string" as expected]
Note that the first three variables (of standard types "Integer", "Real", and "Char") print void values in the debugger. I have also tried this with GDB 4.18 and observe the same problem.
Could someone please confirm whether these results are reproducible across platforms or are specific to the ix86-mingw32 platform? Thanks!
-- Dave Bryan
On 27 Aug 2002 at 20:12, J. David Bryan wrote:
When debugging GPC 2.1 programs with GDB, I am unable to print the values of variables that are of the "standard" types. Variables of user-defined types appear to print OK. I am using the Chief's "i486-mingw32" port from:
[...]
Perhaps because that GPC binary distro was compiled with "-s" ?
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~African_Chief email: African_Chief@bigfoot.com
On 28 Aug 2002, at 7:52, Prof Abimbola Olowofoyeku wrote:
Perhaps because that GPC binary distro was compiled with "-s" ?
Thank you for your reply. I am not certain that I understand, though. Are you saying that because the compiler itself is stripped of debugging information, it does not generate proper debugging information for programs that it compiles?
I note that gpc-20020410, when built with the same options, produces an executable from the test program I supplied that works as expected with gdb. Something appears to have changed between 20020410 and 20020510 to the debugging type information for the predefined types.
-- Dave Bryan
On 30 Aug 2002 at 10:37, J. David Bryan wrote:
On 28 Aug 2002, at 7:52, Prof Abimbola Olowofoyeku wrote:
Perhaps because that GPC binary distro was compiled with "-s" ?
Thank you for your reply. I am not certain that I understand, though. Are you saying that because the compiler itself is stripped of debugging information, it does not generate proper debugging information for programs that it compiles?
No. But the "-s" switch may have strayed into the flags for the RTS. Frank, can you please tell us whether CFLAGS are passed through to building the RTS? I think that RTSFLAGS deals with that, but I am not sure.
I note that gpc-20020410, when built with the same options, produces an executable from the test program I supplied that works as expected with gdb. Something appears to have changed between 20020410 and 20020510 to the debugging type information for the predefined types.
Not sure what the problem is, if it is not a CFLAGS issue.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~African_Chief email: African_Chief@bigfoot.com
On 30 Aug 2002, at 15:45, Prof Abimbola Olowofoyeku wrote:
But the "-s" switch may have strayed into the flags for the RTS.
I still don't understand. The GCC manual says that "-s" will "Remove all symbol table and relocation information from the executable," and further that "These options come into play when the compiler links object files into an executable output file. They are meaningless if the compiler is not doing a link step."
But the RTS doesn't involve an executable. From the make file, it appears that RTS source files are compiled to object files, then the object files are merged into a library with "ar". No linking is involved, so "-s" should not be relevant here.
Not sure what the problem is, if it is not a CFLAGS issue.
I'm not sure either, but I note that the debug information appearing in the intermediate assembler output file defines all of the predefined Pascal types in terms of themselves, e.g.:
.stabs "String:t(0,17)=(0,17)",128,0,0,0 .stabs "Complex:t(0,18)=(0,18)",128,0,0,0 .stabs "Timestamp:t(0,19)=(0,19)",128,0,0,0 .stabs "Bindingtype:t(0,20)=(0,20)",128,0,0,0 .stabs "Integer:t(0,21)=(0,21)",128,0,0,0 .stabs "Real:t(0,22)=(0,22)",128,0,0,0 .stabs "Boolean:t(0,23)=(0,23)",128,0,0,0 .stabs "Char:t(0,24)=(0,24)",128,0,0,0 .stabs "Text:t(0,25)=(0,25)",128,0,0,0
The FSF document titled "The STABS Debug Format" notes that the C "void" type is likewise defined in terms of itself, as above. That would seem to explain why GDB shows the above types as void. I haven't been able to determine why they are generated that way in 20020510, however.
-- Dave Bryan
J. David Bryan wrote:
When debugging GPC 2.1 programs with GDB, I am unable to print the values of variables that are of the "standard" types. Variables of user-defined types appear to print OK.
program gdbtest (output);
var i : integer; r : real; c : char; e : (enum1, enum2); s : 0..10; t : string (12);begin i := 3; r := 3.14159; c := 'Q'; e := enum2; s := 4; t := 'test string';
writeln (i, r, c, s, t);end.
Breakpoint 1, pascal_main_program () at gdbtest.pas:18 18 writeln (i, r, c, s, t); (gdb) p i $1 = void (gdb) p r $2 = void (gdb) p c $3 = void (gdb) p e $4 = Enum2 (gdb) p s $5 = 4 (gdb) p t $6 = 'test string'
Could someone please confirm whether these results are reproducible across platforms or are specific to the ix86-mingw32 platform? Thanks!
Reproducible.
Note that the first three variables (of standard types "Integer", "Real", and "Char") print void values in the debugger. I have also tried this with GDB 4.18 and observe the same problem.
I note that gpc-20020410, when built with the same options, produces an executable from the test program I supplied that works as expected with gdb. Something appears to have changed between 20020410 and 20020510 to the debugging type information for the predefined types.
These two hints enabled me to find the problematic change by looking through the respective diffs. I think the following should fix it.
--- /home/gpc/src/p/gpc-decl.c.orig Sun Aug 25 05:03:34 2002 +++ /home/gpc/src/p/gpc-decl.c Sun Sep 1 04:02:45 2002 @@ -3134,7 +3134,9 @@
if (TREE_CODE (x) == TYPE_DECL) { - if (DECL_SOURCE_LINE (x) == 0 && TYPE_NAME (TREE_TYPE (x)) == 0) + if (TYPE_NAME (TREE_TYPE (x)) == x) + ; + else if (DECL_SOURCE_LINE (x) == 0 && TYPE_NAME (TREE_TYPE (x)) == 0) TYPE_NAME (TREE_TYPE (x)) = x; else if (TREE_TYPE (x) != error_mark_node) {
Prof Abimbola Olowofoyeku wrote:
No. But the "-s" switch may have strayed into the flags for the RTS. Frank, can you please tell us whether CFLAGS are passed through to building the RTS?
Yes, they are. (However, since the affected types are compiler built-ins, not declared in the RTS, this was not the issue here, anyway. And, as Dave said, I think `-s' should not matter while building libraries.)
I think that RTSFLAGS deals with that, but I am not sure.
They are given in addition -- after CFLAGS, so they can overwrite them.
BTW, I wouldn't actually recommend distributing stripped binaries. As we all know, GPC sometimes does unexpected things ;-), and in such cases a stack dump etc. generated from a compiler with debug info can provide useful information ...
Frank
Frank Heckenbach wrote:
J. David Bryan wrote:
These two hints enabled me to find the problematic change by looking through the respective diffs. I think the following should fix it.
--- /home/gpc/src/p/gpc-decl.c.orig Sun Aug 25 05:03:34 2002 +++ /home/gpc/src/p/gpc-decl.c Sun Sep 1 04:02:45 2002 @@ -3134,7 +3134,9 @@
if (TREE_CODE (x) == TYPE_DECL) {
if (DECL_SOURCE_LINE (x) == 0 && TYPE_NAME (TREE_TYPE (x)) == 0)
if (TYPE_NAME (TREE_TYPE (x)) == x);else if (DECL_SOURCE_LINE (x) == 0 && TYPE_NAME (TREE_TYPE (x)) == 0) TYPE_NAME (TREE_TYPE (x)) = x; else if (TREE_TYPE (x) != error_mark_node) {
The bug did not show up with the default debugging format for djgpp (COFF). But since stabs is much better for pascal debugging than COFF, I have recompiled gpc 2.1 with this only change (not others which might be in CVS) and uploaded it in the "contrib" section under
http://www.gnu-pascal.de/contrib/maurice/gpc-2.1-gcc-2953.i586-pc-msdosdjgpp...
(not yet in the "current" section to avoid confusion: pgp signatures etc..)
I use gdb 5.2 under rhide/djgpp (it is necessary to compile with the explicit option -gstabs)
I have checked that there are no errors in the test suite, the program given by David Bryan and some other programs of mine.
Hope this helps
Maurice
Maurice Lombardi wrote:
The bug did not show up with the default debugging format for djgpp (COFF). But since stabs is much better for pascal debugging than COFF, I have recompiled gpc 2.1 with this only change (not others which might be in CVS) and uploaded it in the "contrib" section under
http://www.gnu-pascal.de/contrib/maurice/gpc-2.1-gcc-2953.i586-pc-msdosdjgpp...
(not yet in the "current" section to avoid confusion: pgp signatures etc..)
Actually, I'm not sure we should put it in current at all. It might be better to leave 2.1 (only) in current until some major changes have taken place -- maybe even until the release of 2.2 (provided the time between 2.1 and 2.2 will be a little shorter than that between 2.0 and 2.1 ;-).
So I think when I upload the next patch, I'll put it in alpha (which is currently empty), and move the contents of beta to old (to avoid confusion), and leave current as it is. Would this be reasonable?
(The GPC manual says: "You can download the source code of the current GNU Pascal release from http://www.gnu-pascal.de/current/" -- which remains true if we consider alphas not releases, but snapshots. ;-)
I could see a problem for the install.gpc script, though ...
Hmm, if necessary I could create `latest' or so which always contains the most recent upload (whether snapshot or release).
Or we could move 2.1 from current to, say, `stable', and put the new alpha in current.
I remember we talked about this some time ago, but I don't remember the final conclusions (if any). And I'm not familiar with the current status of the script (does or should it allow the user to select between alpha/beta/stable/latest, whatever?) ...
Frank
On 3 Sep 2002 at 17:12, Frank Heckenbach wrote:
Maurice Lombardi wrote:
The bug did not show up with the default debugging format for djgpp (COFF). But since stabs is much better for pascal debugging than COFF, I have recompiled gpc 2.1 with this only change (not others which might be in CVS) and uploaded it in the "contrib" section under
http://www.gnu-pascal.de/contrib/maurice/gpc-2.1-gcc-2953.i586-pc-msdo sdjgpp.zip
(not yet in the "current" section to avoid confusion: pgp signatures etc..)
Actually, I'm not sure we should put it in current at all. It might be better to leave 2.1 (only) in current until some major changes have taken place -- maybe even until the release of 2.2 (provided the time between 2.1 and 2.2 will be a little shorter than that between 2.0 and 2.1 ;-).
So I think when I upload the next patch, I'll put it in alpha (which is currently empty), and move the contents of beta to old (to avoid confusion), and leave current as it is. Would this be reasonable?
(The GPC manual says: "You can download the source code of the current GNU Pascal release from http://www.gnu-pascal.de/current/" -- which remains true if we consider alphas not releases, but snapshots. ;-)
I could see a problem for the install.gpc script, though ...
Hmm, if necessary I could create `latest' or so which always contains the most recent upload (whether snapshot or release).
Or we could move 2.1 from current to, say, `stable', and put the new alpha in current.
I remember we talked about this some time ago, but I don't remember the final conclusions (if any). And I'm not familiar with the current status of the script (does or should it allow the user to select between alpha/beta/stable/latest, whatever?) ...
Perhaps we can move 2.1 to "releases" (which could also contain old releases), or leave it where it is, and have a new "snapshots" directory for snapshots only.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~African_Chief email: African_Chief@bigfoot.com
Prof Abimbola Olowofoyeku wrote:
Perhaps we can move 2.1 to "releases" (which could also contain old releases),
I don't think we should put old releases (i.e., <= 2.0, i.e "prehistoric" ;-) anywhere but in "old". Anyone who would get them and actually try to use them would seem to be a little insane. ;-)
or leave it where it is, and have a new "snapshots" directory for snapshots only.
We already have "alpha" and "beta" for this purpose.
Frank
Frank Heckenbach a écrit:
Maurice Lombardi wrote:
The bug did not show up with the default debugging format for djgpp (COFF). But since stabs is much better for pascal debugging than COFF, I have recompiled gpc 2.1 with this only change (not others which might be in CVS) and uploaded it in the "contrib" section under
http://www.gnu-pascal.de/contrib/maurice/gpc-2.1-gcc-2953.i586-pc-msdosdjgpp...
(not yet in the "current" section to avoid confusion: pgp signatures etc..)
Actually, I'm not sure we should put it in current at all. It might be better to leave 2.1 (only) in current until some major changes have taken place -- maybe even until the release of 2.2 (provided the time between 2.1 and 2.2 will be a little shorter than that between 2.0 and 2.1 ;-).
OK . I have changed the previous name to a one I think meaningfull
http://www.gnu-pascal.de/contrib/maurice/gpc-2.1-stabs-gcc-2953.i586-pc-msdo...
and made the fixed link
http://www.gnu-pascal.de/contrib/maurice/gpc2953b.zip
to point towards it.
I will continue to put under this fixed link the best current binary (pass at least the test suite), which is usually an alpha.
Maurice
On 1 Sep 2002 at 13:42, Frank Heckenbach wrote:
Reproducible.
Thanks.
I think the following should fix it.
--- /home/gpc/src/p/gpc-decl.c.orig Sun Aug 25 05:03:34 2002 +++ /home/gpc/src/p/gpc-decl.c Sun Sep 1 04:02:45 2002
That indeed appears to fix the problem. Much appreciated.
-- Dave Bryan
-
Frank Heckenbach -
J. David Bryan -
Maurice Lombardi -
Prof Abimbola Olowofoyeku