RE: [fpc-devel] New Windows gdb-binary
Use this new macro: $ cvs diff -u -p gdbtypes.h Index: gdbtypes.h === RCS file: /cvs/src/src/gdb/gdbtypes.h,v retrieving revision 1.153 diff -u -p -r1.153 gdbtypes.h --- gdbtypes.h 5 Jul 2011 13:36:41 - 1.153 +++ gdbtypes.h 3 Oct 2011 14:39:08 - @@ -1115,6 +1115,11 @@ extern void allocate_gnat_aux_type (stru || TYPE_NFN_FIELDS (thistype) == 0) \ (TYPE_STUB (thistype) || !TYPE_STUB_SUPPORTED (thistype))) +/* A helper macro that returns the name of a type or unnamed type if the type + has no name. */ +#define TYPE_SAFE_NAME(type) \ + (TYPE_NAME (type) ? TYPE_NAME (type) : _(unnamed type)) + /* A helper macro that returns the name of an error type. If the type has a name, it is used; otherwise, a default is used. */ #define TYPE_ERROR_NAME(type) \ roflol. Take a good look at this patch. Especially the last few lines... Of course I saw the TYPE_ERROR_NAME macro and I adapted it because I believed that you were using this in a case where the type itself was not an error type. I'll use TYPE_ERROR_NAME. Thanks for the hint. ;) Again, it all depends if you only need it for types that are already flagged as error type (which has a precise meaning inside GDB). Pierre ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] New Windows gdb-binary
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Joost van der Sluis Envoyé : lundi 3 octobre 2011 16:24 À : FPC developers' list Objet : Re: [fpc-devel] New Windows gdb-binary On Sat, 2011-10-01 at 10:26 +0200, Florian Klämpfl wrote: Am 30.09.2011 15:02, schrieb Joost van der Sluis: Please test this gdb-version, and tell me about your experiences. Especially Martin. ;) Oh, you can download it here: http://www.lazarussupport.com/gdb_lazarssupport_20110930.zip Did you get also a libgdb.a which you could provide for the fpc ide? No. I don't know how to build a libgdb.a. I'll look into it later. Loook at packages/gdbint/gen-gdblib-inc.sh script, it should also work for mingw. Pierre ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New Windows gdb-binary
On Sat, 2011-10-01 at 10:26 +0200, Florian Klämpfl wrote: Am 30.09.2011 15:02, schrieb Joost van der Sluis: Please test this gdb-version, and tell me about your experiences. Especially Martin. ;) Oh, you can download it here: http://www.lazarussupport.com/gdb_lazarssupport_20110930.zip Did you get also a libgdb.a which you could provide for the fpc ide? No. I don't know how to build a libgdb.a. I'll look into it later. Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] New Windows gdb-binary
On Sat, 2011-10-01 at 11:00 +0200, Pierre Free Pascal wrote: Did you use the mingw 7.3 patch that handles the windows style path containing ':'? No. I recreated the patch below by doing a diff from official GDB 7.3 release and mingw7.3.2 sources. Without this, debug information containing drive letters are wrongly cut into parts at the ':' position... Thanks. That was one of the issues I still had, without a clue how to fix it. Can you also think about this problem: http://www.cygwin.com/ml/gdb/2011-10/msg3.html Because I've got this problem now at two places (two different warnings) already. The second warning is also in stock-fsf-gdb. I can't imagine that the official GDB 7.3 also has this problem with nul-parameters and fprintf. Joost -- My Lazarus blog: http://www.lazarussupport.com/lazarus/weblog ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] New Windows gdb-binary
On Mon, 2011-10-03 at 16:40 +0200, Pierre Free Pascal wrote: -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Joost van der Sluis Envoyé : lundi 3 octobre 2011 16:29 À : FPC developers' list Objet : RE: [fpc-devel] New Windows gdb-binary On Sat, 2011-10-01 at 11:00 +0200, Pierre Free Pascal wrote: Did you use the mingw 7.3 patch that handles the windows style path containing ':'? No. I recreated the patch below by doing a diff from official GDB 7.3 release and mingw7.3.2 sources. Without this, debug information containing drive letters are wrongly cut into parts at the ':' position... Thanks. That was one of the issues I still had, without a clue how to fix it. Can you also think about this problem: http://www.cygwin.com/ml/gdb/2011-10/msg3.html Because I've got this problem now at two places (two different warnings) already. The second warning is also in stock-fsf-gdb. I can't imagine that the official GDB 7.3 also has this problem with nul-parameters and fprintf. Use this new macro: $ cvs diff -u -p gdbtypes.h Index: gdbtypes.h === RCS file: /cvs/src/src/gdb/gdbtypes.h,v retrieving revision 1.153 diff -u -p -r1.153 gdbtypes.h --- gdbtypes.h 5 Jul 2011 13:36:41 - 1.153 +++ gdbtypes.h 3 Oct 2011 14:39:08 - @@ -1115,6 +1115,11 @@ extern void allocate_gnat_aux_type (stru || TYPE_NFN_FIELDS (thistype) == 0) \ (TYPE_STUB (thistype) || !TYPE_STUB_SUPPORTED (thistype))) +/* A helper macro that returns the name of a type or unnamed type if the type + has no name. */ +#define TYPE_SAFE_NAME(type) \ + (TYPE_NAME (type) ? TYPE_NAME (type) : _(unnamed type)) + /* A helper macro that returns the name of an error type. If the type has a name, it is used; otherwise, a default is used. */ #define TYPE_ERROR_NAME(type) \ roflol. Take a good look at this patch. Especially the last few lines... I'll use TYPE_ERROR_NAME. Thanks for the hint. ;) Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New Windows gdb-binary
Am 03.10.2011 16:23, schrieb Joost van der Sluis: On Sat, 2011-10-01 at 10:26 +0200, Florian Klämpfl wrote: Am 30.09.2011 15:02, schrieb Joost van der Sluis: Please test this gdb-version, and tell me about your experiences. Especially Martin. ;) Oh, you can download it here: http://www.lazarussupport.com/gdb_lazarssupport_20110930.zip Did you get also a libgdb.a which you could provide for the fpc ide? No. I don't know how to build a libgdb.a. I'll look into it later. Afaik it is generated by default. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New Windows gdb-binary
On Mon, 2011-10-03 at 19:27 +0200, Florian Klämpfl wrote: Am 03.10.2011 16:23, schrieb Joost van der Sluis: On Sat, 2011-10-01 at 10:26 +0200, Florian Klämpfl wrote: Am 30.09.2011 15:02, schrieb Joost van der Sluis: Please test this gdb-version, and tell me about your experiences. Especially Martin. ;) Oh, you can download it here: http://www.lazarussupport.com/gdb_lazarssupport_20110930.zip Did you get also a libgdb.a which you could provide for the fpc ide? No. I don't know how to build a libgdb.a. I'll look into it later. Afaik it is generated by default. You are right. I included it in this new version: http://www.lazarussupport.com/gdb_lazarussupport_20111003b.zip The libgdb.a file is not tested whatsoever, so I can't tell if it works. The zipfile also contains some instructions how to build it, and all the changes compared to the Archer branch on which is it was based. This version includes some fixes for the several crashes that Martin encountered and the changes for the Windows-paths that Pierre mailed. Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New Windows gdb-binary
On Sat, 2011-10-01 at 09:08 +0200, Joost van der Sluis wrote: On Sat, 2011-10-01 at 01:05 +0100, Martin wrote: On 30/09/2011 23:23, Martin wrote: On 30/09/2011 14:02, Joost van der Sluis wrote: Please test this gdb-version, and tell me about your experiences. Especially Martin. ;) Oh, you can download it here: http://www.lazarussupport.com/gdb_lazarssupport_20110930.zip It crashes when -Xe (external linker) was used. Also crashes with stabs... I am not 100% sure, but it appears to choke on -data-evaluate-expression FPC_THREADVAR_RELOCATE_PROC Ok, seems to have big issues with strings in fields. Ow, man.. That's probably difficult again. While evaluating values, it does not 'recurse' into the structure, but uses all kinds of work-arounds. (For example: an array of strings wasn't working either) It was easier then I thought. The recursive calls were ok, but you did a 'ptype class.stringprop'. But when evaluating the type, there was object-address set (which is logical) New version: http://www.lazarussupport.com/gdb_lazarssupport_20111002.zip There are more things that we need to discuss, though. For example, when I want to evaluate 'object.stringprop', Lazarus issues a '-data-evaluate-expression object.stringprop^', which obviously won't work with that '^' in the end. Something similar when a method is called (from within the evaluation window). Lazarus does 'ptype object.method()'. That doesn't work (could be fixable, though) while calling '-data-evaluate-expression object.stringprop()' directly will work. Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New Windows gdb-binary
On 02/10/2011 14:05, Joost van der Sluis wrote: On Sat, 2011-10-01 at 09:08 +0200, Joost van der Sluis wrote: On Sat, 2011-10-01 at 01:05 +0100, Martin wrote: Ok, seems to have big issues with strings in fields. Ow, man.. That's probably difficult again. While evaluating values, it does not 'recurse' into the structure, but uses all kinds of work-arounds. (For example: an array of strings wasn't working either) It was easier then I thought. The recursive calls were ok, but you did a 'ptype class.stringprop'. But when evaluating the type, there was object-address set (which is logical) New version: http://www.lazarussupport.com/gdb_lazarssupport_20111002.zip Thanks, I will test. There are more things that we need to discuss, though. For example, when I want to evaluate 'object.stringprop', Lazarus issues a '-data-evaluate-expression object.stringprop^', which obviously won't work with that '^' in the end. Afaik it should fallback to omit it. Anyway, those gdb workarounds that Lazarus does, will be updated, as soon as the major gdb crashes are gone. IIRC, Lazarus uses the ptype result, to detect if the variable/expression, is of an internal pointer type (object, dyn-array, string). If so, it will attempt the ^ postfix. This is important for: - objects, without the ^ gdb only reports the address, but with it, all the values of all the fields are listed. (afaik this still aplies iin dwarf 3) And (also afaik) this behaviour is important, as it allows for expressions like Obj1=Obj2 to work the way it is pascal-expectation. Such expression are used in breakpoint-conditions. - dyn array: to be tested under dwarf 3, probably no longer needing the ^. with dwarf2 dyn array do need the ^ - strings: little tested, they are treated as dyn array of chars. Obviously, with dwarf3 strings may be improved, and the IDE will get better detection. In dwarf2/stabs they are reported as ^(array of char) which could also be dyn-array. It is possible to get the type-name, but: - the user may have aliased it: type MyAnsi = type Ansistring; - the user may have a local type type Ansistring = array of char; (0-based) Still even with what dwarf2 delivers (as far as can be detected through gdb), it may be possible to improve. I simply hadn't yet spent the time on it (And most likely dwarf2 has enough info, if the IDE reads it directly from the file, but that's not even started yet / planed though) Something similar when a method is called (from within the evaluation window). Lazarus does 'ptype object.method()'. That doesn't work (could be fixable, though) while calling '-data-evaluate-expression object.stringprop()' directly will work. No need to fix in gdb. That must anyway be fixed in the IDE. The IDE will need settings to allow/disable function calls (global / per watch). In order to enforce those, the gdb must scan all expressions for brackets, and detect if they are type casts, or function calls. And then do whatever is correct. As function calls are not officially yet implemented, I simply left the backdoor open. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New Windows gdb-binary
On Sun, 2011-10-02 at 14:29 +0100, Martin wrote: On 02/10/2011 14:05, Joost van der Sluis wrote: On Sat, 2011-10-01 at 09:08 +0200, Joost van der Sluis wrote: On Sat, 2011-10-01 at 01:05 +0100, Martin wrote: Ok, seems to have big issues with strings in fields. Ow, man.. That's probably difficult again. While evaluating values, it does not 'recurse' into the structure, but uses all kinds of work-arounds. (For example: an array of strings wasn't working either) It was easier then I thought. The recursive calls were ok, but you did a 'ptype class.stringprop'. But when evaluating the type, there was object-address set (which is logical) New version: http://www.lazarussupport.com/gdb_lazarssupport_20111002.zip Thanks, I will test. (To test the function-calls you have to do 'set cp-abi gnu-v3' I forgot to set that as the default. Will place a new version which does that later) There are more things that we need to discuss, though. For example, when I want to evaluate 'object.stringprop', Lazarus issues a '-data-evaluate-expression object.stringprop^', which obviously won't work with that '^' in the end. Afaik it should fallback to omit it. Anyway, those gdb workarounds that Lazarus does, will be updated, as soon as the major gdb crashes are gone. btw: I could not reproduce the external-linker and stabs crashes. Can you give me some more info? IIRC, Lazarus uses the ptype result, to detect if the variable/expression, is of an internal pointer type (object, dyn-array, string). If so, it will attempt the ^ postfix. This is important for: - objects, without the ^ gdb only reports the address, but with it, all the values of all the fields are listed. (afaik this still aplies iin dwarf 3) Yes, when I changed that people started to complain. I don't know anymore what the exact reason for those complaints was. Maybe because a object really is a pointer, or that with this change it got impossible to obtain the address. And (also afaik) this behaviour is important, as it allows for expressions like Obj1=Obj2 to work the way it is pascal-expectation. Maybe that this was the reason... Such expression are used in breakpoint-conditions. - dyn array: to be tested under dwarf 3, probably no longer needing the ^. with dwarf2 dyn array do need the ^ - strings: little tested, they are treated as dyn array of chars. Obviously, with dwarf3 strings may be improved, and the IDE will get better detection. In dwarf2/stabs they are reported as ^(array of char) which could also be dyn-array. It is possible to get the type-name, but: - the user may have aliased it: type MyAnsi = type Ansistring; - the user may have a local type type Ansistring = array of char; (0-based) We should find a way to detect if -gw3 is used. Then you don't need those adaptations for strings anymore. Just do 'p variable', it will always give the right result. Joost. -- My Lazarus blog: http://www.lazarussupport.com/lazarus/weblog ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New Windows gdb-binary
On 02/10/2011 15:02, Joost van der Sluis wrote: btw: I could not reproduce the external-linker and stabs crashes. Can you give me some more info? Hm, I have to check what version of the external linker I have. C:\FPC\trunk\bin\i386-win32ld.exe -v GNU ld version 2.16.91 20050827 Maybe time to check for something newer I will look into it. Maybe it is a case of mixed symbols... I will do some more testing Such expression are used in breakpoint-conditions. - dyn array: to be tested under dwarf 3, probably no longer needing the ^. with dwarf2 dyn array do need the ^ - strings: little tested, they are treated as dyn array of chars. Obviously, with dwarf3 strings may be improved, and the IDE will get better detection. In dwarf2/stabs they are reported as ^(array of char) which could also be dyn-array. It is possible to get the type-name, but: - the user may have aliased it: type MyAnsi = type Ansistring; - the user may have a local type type Ansistring = array of char; (0-based) We should find a way to detect if -gw3 is used. Then you don't need those adaptations for strings anymore. Just do 'p variable', it will always give the right result. True, but: There are already checks for stabs vs dwarf = but they are of little use, since symbol type info can be mixed, if packages where compiled with diff settings. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New Windows gdb-binary
On Sat, 2011-10-01 at 01:05 +0100, Martin wrote: On 30/09/2011 23:23, Martin wrote: On 30/09/2011 14:02, Joost van der Sluis wrote: Please test this gdb-version, and tell me about your experiences. Especially Martin. ;) Oh, you can download it here: http://www.lazarussupport.com/gdb_lazarssupport_20110930.zip It crashes when -Xe (external linker) was used. Also crashes with stabs... I am not 100% sure, but it appears to choke on -data-evaluate-expression FPC_THREADVAR_RELOCATE_PROC Ok, seems to have big issues with strings in fields. Ow, man.. That's probably difficult again. While evaluating values, it does not 'recurse' into the structure, but uses all kinds of work-arounds. (For example: an array of strings wasn't working either) I'll have to dig into this. Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New Windows gdb-binary
Am 30.09.2011 15:02, schrieb Joost van der Sluis: Hi all, For all those who are interested in new debug-features of fpc and gdb, I have cross-compiled a gdb-executable for Windows. It's based on the Fedora-16 branch from the Archer project. But I added a few patches of my own, namely the patch to recognize methods, setting case-sensitivity off by default and a patch to allow evaluating method-values (without actually calling them.) With this gdb-version you can: - Print strings properly, this means that indexes are evaluated properly and strings can contain #0 characters (when compiled with -gw3) - Dynamic array are evaluated properly (when compiled with -gw3) - Case of identifiers are preserved (when compiled with -gw3) - It is possible to identify class-methods (fpc 2.7.1 only) - It is possible to call simple class-methods (fpc 2.7.1 only. Some problems on i386 regarding the calling conventions remain, and there seems to be some problems still with overridden functions) Please test this gdb-version, and tell me about your experiences. Especially Martin. ;) Oh, you can download it here: http://www.lazarussupport.com/gdb_lazarssupport_20110930.zip Did you get also a libgdb.a which you could provide for the fpc ide? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] New Windows gdb-binary
Hi Joost,
Did you use the mingw 7.3 patch that handles
the windows style path containing ':'?
I recreated the patch below by doing a diff
from official GDB 7.3 release
and mingw7.3.2 sources.
Without this, debug information containing drive letters
are wrongly cut into parts at the ':' position...
Pierre
diff -r -u -p -N gdb-7.3/config.rpath gdb-7.3-mingw/config.rpath
--- gdb-7.3/config.rpath2011-02-13 22:00:08.0 +0100
+++ gdb-7.3-mingw/config.rpath 2011-08-04 03:30:58.0 +0200
@@ -438,7 +438,7 @@ case $host_os in
bsdi4*)
;;
cygwin* | mingw* | pw32*)
-shrext=.dll
+shrext=.dll.a
;;
darwin* | rhapsody*)
shrext=.dylib
diff -r -u -p -N gdb-7.3/gdb/linespec.c gdb-7.3-mingw/gdb/linespec.c
--- gdb-7.3/gdb/linespec.c 2011-07-04 16:19:14.0 +0200
+++ gdb-7.3-mingw/gdb/linespec.c2011-08-04 03:30:58.0 +0200
@@ -1222,7 +1222,8 @@ locate_first_half (char **argptr, int *i
quotes we do not break on enclosed spaces. */
if (!*p
|| p[0] == '\t'
- || (p[0] == ':')
+ || ((p[0] == ':')
+ ((p[1] == ':') || (strchr (p + 1, ':') == NULL)))
|| ((p[0] == ' ') !*is_quote_enclosed))
break;
if (p[0] == '.' strchr (p, ':') == NULL)
diff -r -u -p -N gdb-7.3/gdb/source.c gdb-7.3-mingw/gdb/source.c
--- gdb-7.3/gdb/source.c2011-03-23 19:23:55.0 +0100
+++ gdb-7.3-mingw/gdb/source.c 2011-08-04 03:30:59.0 +0200
@@ -991,6 +991,7 @@ find_and_open_source (const char *filena
char *path = source_path;
const char *p;
int result;
+ char *lpath;
/* Quick way out if we already know its full name. */
@@ -1009,7 +1010,12 @@ find_and_open_source (const char *filena
result = open (*fullname, OPEN_MODE);
if (result = 0)
- return result;
+{
+ lpath = gdb_realpath(*fullname);
+ xfree(*fullname);
+ *fullname = lpath;
+ return result;
+}
/* Didn't work -- free old one, try again. */
xfree (*fullname);
*fullname = NULL;
diff -r -u -p -N gdb-7.3/gdb/utils.c gdb-7.3-mingw/gdb/utils.c
--- gdb-7.3/gdb/utils.c 2011-05-17 23:26:28.0 +0200
+++ gdb-7.3-mingw/gdb/utils.c 2011-08-04 03:30:59.0 +0200
@@ -3634,6 +3634,30 @@ gdb_realpath (const char *filename)
}
#endif
+ /* The MS Windows method. If we don't have realpath, we assume we
+ don't have symlinks and just canonicalize to a Windows absolute
+ path. GetFullPath converts ../ and ./ in relative paths to
+ absolute paths, filling in current drive if one is not given
+ or using the current directory of a specified drive (eg, E:foo).
+ It also converts all forward slashes to back slashes. */
+#if defined (_WIN32)
+ {
+char buf[MAX_PATH];
+char* basename;
+DWORD len = GetFullPathName (filename, MAX_PATH, buf, basename);
+if (len == 0 || len MAX_PATH - 1)
+ return xstrdup (filename);
+else
+ {
+/* The file system is case-preserving but case-insensitive,
+ Canonicalize to lowercase, using the codepage associated
+ with the process locale. */
+CharLowerBuff (buf, len);
+return xstrdup (buf);
+ }
+ }
+#endif
+
/* This system is a lost cause, just dup the buffer. */
return xstrdup (filename);
}
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New Windows gdb-binary
From: Joost van der Sluis jo...@cnoc.nl To: fpc-devel@lists.freepascal.org Sent: Friday, September 30, 2011 10:02 AM Subject: [fpc-devel] New Windows gdb-binary Hi all, For all those who are interested in new debug-features of fpc and gdb, I have cross-compiled a gdb-executable for Windows. It's based on the Fedora-16 branch from the Archer project. But I added a few patches of my own, namely the patch to recognize methods, setting case-sensitivity off by default and a patch to allow evaluating method-values (without actually calling them.) With this gdb-version you can: - Print strings properly, this means that indexes are evaluated properly and strings can contain #0 characters (when compiled with -gw3) - Dynamic array are evaluated properly (when compiled with -gw3) - Case of identifiers are preserved (when compiled with -gw3) - It is possible to identify class-methods (fpc 2.7.1 only) - It is possible to call simple class-methods (fpc 2.7.1 only. Some problems on i386 regarding the calling conventions remain, and there seems to be some problems still with overridden functions) Please test this gdb-version, and tell me about your experiences. Especially Martin. ;) Oh, you can download it here: http://www.lazarussupport.com/gdb_lazarssupport_20110930.zip Joost -- My Lazarus blog: http://www.lazarussupport.com/lazarus/weblog ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Looks impressive. I'll start testing right now. Leonardo M. Ramé http://leonardorame.blogspot.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New Windows gdb-binary
On 30/09/2011 14:02, Joost van der Sluis wrote: Hi all, For all those who are interested in new debug-features of fpc and gdb, I have cross-compiled a gdb-executable for Windows. It's based on the Fedora-16 branch from the Archer project. But I added a few patches of my own, namely the patch to recognize methods, setting case-sensitivity off by default and a patch to allow evaluating method-values (without actually calling them.) Ah, how does that work? With this gdb-version you can: - Print strings properly, this means that indexes are evaluated properly and strings can contain #0 characters (when compiled with -gw3) - Dynamic array are evaluated properly (when compiled with -gw3) - Case of identifiers are preserved (when compiled with -gw3) - It is possible to identify class-methods (fpc 2.7.1 only) - It is possible to call simple class-methods (fpc 2.7.1 only. Some problems on i386 regarding the calling conventions remain, and there seems to be some problems still with overridden functions) Please test this gdb-version, and tell me about your experiences. Especially Martin. ;) Will do (weekend just ahead, what a coincidence... :) ) Oh, you can download it here: http://www.lazarussupport.com/gdb_lazarssupport_20110930.zip Joost ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New Windows gdb-binary
30.09.2011 21:02, Joost van der Sluis wrote: Hi all, For all those who are interested in new debug-features of fpc and gdb, I have cross-compiled a gdb-executable for Windows. It's based on the Fedora-16 branch from the Archer project. But I added a few patches of my own, namely the patch to recognize methods, setting case-sensitivity off by default and a patch to allow evaluating method-values (without actually calling them.) How can this be possible? Some internal virtual machine? Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New Windows gdb-binary
On Fri, 2011-09-30 at 21:47 +0800, Paul Ishenin wrote: 30.09.2011 21:02, Joost van der Sluis wrote: Hi all, For all those who are interested in new debug-features of fpc and gdb, I have cross-compiled a gdb-executable for Windows. It's based on the Fedora-16 branch from the Archer project. But I added a few patches of my own, namely the patch to recognize methods, setting case-sensitivity off by default and a patch to allow evaluating method-values (without actually calling them.) How can this be possible? Some internal virtual machine? Huh? The compilation of the Fedora-gdb-sources for Windows? Fedora comes with an out-of-the-box mingw cross-compiler. (Not really a vm) yum install mingw32-gcc mingw32-binutils mingw32-w32api get gdb sources through git (Archer) ./configure --host=i686-pc-mingw32 --disable-werror make Wait and copy gdb/gdb.exe to a Windows machine to test. For this to work you need to have all other gdb build-dependencies installed on your machine, ofcourse. Joost -- My Lazarus blog: http://www.lazarussupport.com/lazarus/weblog ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New Windows gdb-binary
On Fri, September 30, 2011 16:45, Joost van der Sluis wrote: On Fri, 2011-09-30 at 21:47 +0800, Paul Ishenin wrote: 30.09.2011 21:02, Joost van der Sluis wrote: . . case-sensitivity off by default and a patch to allow evaluating method-values (without actually calling them.) How can this be possible? Some internal virtual machine? Huh? The compilation of the Fedora-gdb-sources for Windows? Fedora comes with an out-of-the-box mingw cross-compiler. (Not really a vm) . . I suppose that Paul wondered about evaluating method values without actually calling them... Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New Windows gdb-binary
On 30/09/2011 15:45, Joost van der Sluis wrote: On Fri, 2011-09-30 at 21:47 +0800, Paul Ishenin wrote: 30.09.2011 21:02, Joost van der Sluis wrote: Hi all, For all those who are interested in new debug-features of fpc and gdb, I have cross-compiled a gdb-executable for Windows. It's based on the Fedora-16 branch from the Archer project. But I added a few patches of my own, namely the patch to recognize methods, setting case-sensitivity off by default and a patch to allow evaluating method-values (without actually calling them.) How can this be possible? Some internal virtual machine? Huh? The compilation of the Fedora-gdb-sources for Windows? Fedora comes with an out-of-the-box mingw cross-compiler. (Not really a vm) I think this was about: evaluating method-values (without actually calling them.) which got me curious too. Now reading it again, does it mean: 1) gdb can (magically?) get the return value of a function/method, but WITHOUT calling/invoking the function (e.g. for properties) 2) gdb can evaluate the type of a method. e.g return ptype Tfoo.Method = function(a:int): boolean ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New Windows gdb-binary
On Fri, 2011-09-30 at 15:54 +0100, Martin wrote:
On 30/09/2011 15:45, Joost van der Sluis wrote:
On Fri, 2011-09-30 at 21:47 +0800, Paul Ishenin wrote:
30.09.2011 21:02, Joost van der Sluis wrote:
Hi all,
For all those who are interested in new debug-features of fpc and gdb, I
have cross-compiled a gdb-executable for Windows.
It's based on the Fedora-16 branch from the Archer project. But I added
a few patches of my own, namely the patch to recognize methods, setting
case-sensitivity off by default and a patch to allow evaluating
method-values (without actually calling them.)
How can this be possible? Some internal virtual machine?
Huh? The compilation of the Fedora-gdb-sources for Windows? Fedora comes
with an out-of-the-box mingw cross-compiler. (Not really a vm)
I think this was about:
evaluating
method-values (without actually calling them.)
which got me curious too.
It's nothing important. It's just a very small bug in gdb that got
fixed.
Now reading it again, does it mean:
1) gdb can (magically?) get the return value of a function/method, but
WITHOUT calling/invoking the function (e.g. for properties)
2) gdb can evaluate the type of a method. e.g return ptype
Tfoo.Method = function(a:int): boolean
The second. When you do 'p functionname' you get some background
information about the function. When you do 'p functionname()' it will
call the function.
This didn't work for methods, so 'p class.methodname()' did work while
'p class.methodname' didn't. That's what's fixed.
The (simple) patch is attached.
But what we could do now is write debuginfo for properties with getters
as if it is a function. The answer of 'p class.propertyname' will tell
you it's a function, which yould be called if you want to.
Joost
--
My Lazarus blog: http://www.lazarussupport.com/lazarus/weblog
diff --git a/gdb/p-valprint.c b/gdb/p-valprint.c
index d98b3a4..9d14a9e 100644
--- a/gdb/p-valprint.c
+++ b/gdb/p-valprint.c
@@ -391,6 +391,7 @@ pascal_val_print (struct type *type, const gdb_byte *valaddr,
break;
case TYPE_CODE_FUNC:
+case TYPE_CODE_METHOD:
if (options-format)
{
val_print_scalar_formatted (type, valaddr, embedded_offset,
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New Windows gdb-binary
On 30/09/2011 16:22, Joost van der Sluis wrote: On Fri, 2011-09-30 at 15:54 +0100, Martin wrote: Now reading it again, does it mean: 1) gdb can (magically?) get the return value of a function/method, but WITHOUT calling/invoking the function (e.g. for properties) 2) gdb can evaluate the type of a method. e.g return ptype Tfoo.Method = function(a:int): boolean The second. When you do 'p functionname' you get some background information about the function. When you do 'p functionname()' it will call the function. Yep, that's what I figured. Initially I though 1 (and I thought, how?) This didn't work for methods, so 'p class.methodname()' did work while 'p class.methodname' didn't. That's what's fixed. The (simple) patch is attached. But what we could do now is write debuginfo for properties with getters as if it is a function. The answer of 'p class.propertyname' will tell you it's a function, which yould be called if you want to. Yep, I need to improve the IDE to detect functions in expressions, and enable/disable execution, depend on user settings (rather than letting the user type the () ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New Windows gdb-binary
On 30/09/2011 14:02, Joost van der Sluis wrote: Please test this gdb-version, and tell me about your experiences. Especially Martin. ;) Oh, you can download it here: http://www.lazarussupport.com/gdb_lazarssupport_20110930.zip It crashes when -Xe (external linker) was used. Also crashes with stabs... I am not 100% sure, but it appears to choke on -data-evaluate-expression FPC_THREADVAR_RELOCATE_PROC ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New Windows gdb-binary
On 30/09/2011 23:23, Martin wrote:
On 30/09/2011 14:02, Joost van der Sluis wrote:
Please test this gdb-version, and tell me about your experiences.
Especially Martin. ;)
Oh, you can download it here:
http://www.lazarussupport.com/gdb_lazarssupport_20110930.zip
It crashes when -Xe (external linker) was used. Also crashes with
stabs...
I am not 100% sure, but it appears to choke on
-data-evaluate-expression FPC_THREADVAR_RELOCATE_PROC
Ok, seems to have big issues with strings in fields.
Run the ExceptionPrg from debugger\test\Gdbmi\TestApps\ExceptPrg.lpr in
lazarus.
On hitting the breakpoint in fpc_raise_exception:
TCmdLineDebugger.SendCmdLn x/s Exception($eax).FMessage
TCmdLineDebugger.ReadLn x/s Exception($eax).FMessage\n
TCmdLineDebugger.ReadLn Cannot resolve DW_OP_push_object_address
for a missing object\n
if you keep the session running, and set the stackframe to
fpc_raise_exception (the IDE will have lowered it), then you can send
the following commands:
p Exception($eax)
p Exception($eax)\n
~$2 = (^Exception = class ) 0x78660\n
^done
(gdb)
p Exception($eax)^
p Exception($eax)^\n
~$3 = {TObject = {_vptr$TOBJECT = 0x415018}, fmessage = 'abc'
~, fhelpcontext = 0
~, HelpContext = 0
~, Message = 'abc'
~}
~\n
^done
(gdb)
p Exception($eax).Message
p Exception($eax).Message\n
Cannot access memory at address 0x636260ff\n
^error,msg=Cannot access memory at address 0x636260ff
(gdb)
p Exception($eax).FMessage
p Exception($eax).FMessage\n
Cannot access memory at address 0x636260ff\n
^error,msg=Cannot access memory at address 0x636260ff
(gdb)
p Exception($eax)^.FMessage
p Exception($eax)^.FMessage\n
Cannot access memory at address 0x636260ff\n
^error,msg=Cannot access memory at address 0x636260ff
(gdb)
--
In an other attempt, using this program:
program Project1;
{$mode objfpc}{$H+}
type
TFoo=class
private
FText:string;
end;
var
a: TFoo;
begin
a := TFoo.Create;
a.FText := 'abcde';
writeln(1);
readln;
end.
sending to the debugger (without the )
p a
p a\n
~$1 = 0x107488\n
^done
(gdb)
p a^
p a^\n
~$2 = {TObject = {_vptr$TOBJECT = 0x40e018}, FText = 'abcde'
~}
~\n
^done
(gdb)
p a.FText
p a.FText\n
~$3 = 'abcde'
~\n
the text is correct = but gdb crashes at this point.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
