Given the following example:

----------------------------------------
program project1;
{$mode objfpc}{$H+}
  procedure doit (var s : ansistring);
  begin
    s := s + ' ' + s;
  end;
var
  s : ansistring;
begin
  s := 'test';
  doit(s);
end.
----------------------------------------

When I compile for x86_64 with "fpc -Px86_64 -g -gl -gw project1.lpr", and set a breakpoint in "doit" in GDB, I see the following:

(gdb) whatis S
type = &ANSISTRING
(gdb) print S
$12 = (&ANSISTRING) @0x627130
(gdb) whatis S^
type = ANSISTRING
(gdb) print S^
$13 = 116 't'
(gdb) x/s S
0x74: <Address 0x74 out of bounds>
(gdb) x/s S^
0x74: <Address 0x74 out of bounds>

When I compile with "fpc -Px86_64 -g -gl project1.lpr", I get the same result. When I compile for i386 with "fpc -Pi386 -g -gl -gw project1.lpr", I have the same issue. However, when I compile for i386 with "fpc -Pi386 -g -gl project1.lpr", I get:

(gdb) whatis S
type = ANSISTRING
(gdb) print S
$1 = (ANSISTRING) 0x8064074 "test"
(gdb) x/s S
0x8064074 <_$PROJECT1$_Ld3>: "test"

How can I print the value of a var ansistring parameter in gdb with dwarf debugging information compiled in?

I am compiling with FPC 2.4.0 (built from svn from the 2.4.0 release tag) on Ubuntu 9.10 x86_64.

Thanks,

-SG

Seth Grover wrote

How can I print the value of a var ansistring parameter in gdb with dwarf debugging information compiled in?

I believe this is a bug that was introduced with GDB 7.0 (I can reproduce it with GDB 7.0). Can you try with GDB 6.8 instead? With GDB 6.5 variants I get this:

(gdb) p s
$1 = (&ANSISTRING) @0x6252a0: 0x61fbc8 'test'

I don't know whether anyone already reported this bug to the GDB developers.

Jonas

I believe this is a bug that was introduced with GDB 7.0 Jonas

You're right, I tried it with gdb 6.8 and it worked as you described:

(gdb) print S
$1 = (&ANSISTRING) @0x8069410: 0x8065074 'test'

-SG

I believe this is a bug that was introduced with GDB 7.0

...

I don't know whether anyone already reported this bug to the GDB developers.

http://sourceware.org/bugzilla/show_bug.cgi?id=11349

I just reported it as a bug to GDB.

-SG

To ensure that it's as easy as possible to reproduce and fix by the gdb people, you should preferably include a compiled version of the program, and the result of "readelf -gw", and optionally if possible a version of a program that demonstrates the problem compiled to assembler code with any dependencies on the FPC RTL removed (so they can add it to the gdb test suite). E.g., maybe the problem is also reproducible with a pchar that's passed as "var" parameter (since ansistring is currently just an alias for pchar in the DWARF debug info) and the string concatenation is also unnecessary to reproduce the problem.

It's similar to how people reporting a bug in FPC shouldn't include a test program that depends on Qt, KDE or even Lazarus, because that a) makes it harder to test (because you have to install all dependencies, and then figure out whether the problem is in these extra libraries, how they are used, or in the compiler/rtl) b) harder to reduce to a test case that can included in the test suite

I.e., I think this program will also demonstrate the problem:

procedure doit (var s : pchar);
begin
end;
var
  s : pchar;
begin
  s := 'test';
  doit(s);
end.

If you compile this to assembler code and strip out all the unnecessary references to threadvars, RTL init code etc, it should become a nice, self-contained example that the GDB developers can easily use without having to install FPC first.

Jonas

Thanks, I have done as you suggested and attached a compiled version of the program, the output of readelf -gw, and the assembly generated by "fpc -a -al -an" as well.

Hopefully this will allow the GDB developers to more easily figure out the problem.

-SG