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

Looks impressive. I'll start testing right now.

Leonardo M. Ramé
http://leonardorame.blogspot.com

Ah, how does that work?

Will do (weekend just ahead, what a coincidence... :) )

Oh, you can download it here: http://www.lazarussupport.com/gdb_lazarssupport_20110930.zip Joost

How can this be possible? Some internal virtual machine?

Best regards,
Paul Ishenin.

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

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:

.
.

.
.

I suppose that Paul wondered about "evaluating method values without actually calling them"...

Tomas

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"

It's nothing important. It's just a very small bug in gdb that got fixed.

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

Yep, that's what I figured. Initially I though 1 (and I thought, how?)

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 ()

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.

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.

Did you get also a libgdb.a which you could provide for the fpc ide?

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.rpath 2011-02-13 22:00:08.000000000 +0100 +++ gdb-7.3-mingw/config.rpath 2011-08-04 03:30:58.000000000 +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.000000000 +0200 +++ gdb-7.3-mingw/gdb/linespec.c 2011-08-04 03:30:58.000000000 +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.c 2011-03-23 19:23:55.000000000 +0100 +++ gdb-7.3-mingw/gdb/source.c 2011-08-04 03:30:59.000000000 +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.000000000 +0200 +++ gdb-7.3-mingw/gdb/utils.c 2011-08-04 03:30:59.000000000 +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);

}

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.

Thanks, I will test.

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)

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.

(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)

btw: I could not reproduce the external-linker and stabs crashes. Can you give me some more info?

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...

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.

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-win32>ld.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

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.

No. I don't know how to build a libgdb.a. I'll look into it later.

Joost.

Pierre Free Pascal wrote

Did you use the mingw 7.3 patch that handles the windows style path containing ':'?

No.

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/msg00003.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

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 -0000 1.153 +++ gdbtypes.h 3 Oct 2011 14:39:08 -0000
@@ -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) \

Just replace TYPE_NAME by TYPE_SAFE_NAME
at each occurrence within printf calls.

roflol. Take a good look at this patch. Especially the last few lines...

I'll use TYPE_ERROR_NAME. Thanks for the hint. ;)

Joost.

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.

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

Loook at packages/gdbint/gen-gdblib-inc.sh script, it should also work for mingw.

Pierre