Hi,
 x64 Suse 11.1, the program:
"
program gdbvarparam;
{$ifdef FPC}{$mode objfpc}{$h+}{$endif}
{$ifdef mswindows}{$apptype console}{$endif}
uses
 sysutils;
procedure test(var par1: integer);
begin
end;
var
 int1: integer;
begin
 int1:= 123;
 test(int1);
end.
"
The debug session:
"

/home/mse/packs/standard/svn/fp/fixes_2_4/compiler/ppcx64 -dsvnfixes_2_4 -gl -B -O-

gdbvarparam.pas
Free Pascal Compiler version 2.3.1 [2009/10/23] for x86_64 Copyright (c) 1993-2009 by Florian Klaempfl
Target OS: Linux for x86-64
Compiling gdbvarparam.pas
Linking gdbvarparam
16 lines compiled, 0.6 sec

gdb ./gdbvarparam

GNU gdb (GDB; openSUSE 11.1) 6.8.50.20081120-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-suse-linux".
For bug reporting instructions, please see:
<http://bugs.opensuse.org/>...
(gdb) break test
Function "test" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n (gdb) break main
Breakpoint 1 at 0x4001f9: file gdbvarparam.pas, line 14. (gdb) break gdbvarparam.pas:8
Breakpoint 2 at 0x4001ec: file gdbvarparam.pas, line 9. (gdb) run
Starting program: /home/mse/proj/testcase/mse/gdbvarparam/gdbvarparam

Breakpoint 1, main () at gdbvarparam.pas:14
14 int1:= 123;
(gdb) c
Continuing.

Breakpoint 2, TEST () at gdbvarparam.pas:9
9 end;
(gdb) print PAR1
$1 = (&LONGINT) @0x65cb70
(gdb)
"

Why is it not possible to set a breakpoint to "test"? Is it as designed that the displayed value of a var parameter is the address instead the value?

Martin

Martin Schreiber wrote on Fri, 23 Oct 2009:

Why is it not possible to set a breakpoint to "test"?

You have to use TEST. This is the same for Stabs on 32 bit platforms, afaik: you always have to use the uppercase name for setting breakpoints on procedures/functions.

Is it as designed that the displayed value of a var parameter is the address instead the value?

It's because nobody bothered to submit a patch to GDB yet to add support for var parameters in their DWARF parser, so we currently encode them as C++-style references. That's the way references are displayed by GDB.

Jonas

---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

I do not know the different debug formats, is it correct that FPC uses STABS on x86 and DWARF on x64?
What do you recommend, should MSEide parse the gdb watch results and run another query in order to get the values of var parameters? How does Lazarus solve the problem?

Martin

Martin Schreiber wrote on Sat, 24 Oct 2009:

I do not know the different debug formats, is it correct that FPC uses STABS on x86 and DWARF on x64?

Yes. The reason is that Stabs is defined as a 32 bit format and does not work for 64 bit.

What do you recommend, should MSEide parse the gdb watch results and run another query in order to get the values of var parameters?

I guess that's the only way currently, yes.

How does Lazarus solve the problem?

I don't know.

Jonas

---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

Hello Martin,

Saturday, October 24, 2009, 10:42:27 AM, you wrote:

MS> What do you recommend, should MSEide parse the gdb watch results and run MS> another query in order to get the values of var parameters? How does Lazarus MS> solve the problem?

I'm working in the Lazarus GDB interface to perform such operations, but currently I'm working in records, classes, enums, etc but not as parameters. Currently some types as reevaluated to get the "usable" value, like pointers which are dereferenced and both data is displayed. Something like:

Variable = ^LONGINT 0x12345678 = 5

So you plan to run a second query to show the parameter value? BTW MSEide has some code to display dynamic arrays and the like, it is located in lib/common/designutils/msegdbutils.pas, function tgdbmi.readpascalvariable() and tgdbmi.matchpascalformat(), maybe you will find it useful.

Martin

Does this mean the 32-bit version of FPC generates STABS and the 64-bit version generates DWARF?

If my goal was to use gdb on a large application written in Pascal, am I better off using the 32-bit version because the debugger support is better?

Also, I'm assuming it's the DWARF parser in gdb that needs "fixing". Is this specific to Pascal, or is the DWARF support generally broken?

I'm pretty confused by this...

-- Bruce

Bruce Bauman wrote

Does this mean the 32-bit version of FPC generates STABS and the 64- bit version generates DWARF?

By default, yes. You can also force the 32 bit version generate DWARF by using -gw2 rather than -g

If my goal was to use gdb on a large application written in Pascal, am I better off using the 32-bit version because the debugger support is better?

It depends.

Advantages of using Stabs instead of DWARF
* var parameters (although if you simply print the value of a reference parameter in gdb, you also get the value; it's just in the stack frame info that they're displayed as addresses)
* symbolic constants (i.e., not "typed constants) are supported in Stabs, but not in DWARF
* shortstrings are sometimes truncated to 8 characters when you use DWARF (but I still haven't figured out why)

Advantages of using DWARF instead of Stabs
* faster linking
* support for absolute variables (in FPC 2.3.x and later)
* support for properties that map directly to fields (in FPC 2.3.x and later)
* support for 64 bit systems
* will get support for dynamic arrays, ansistrings etc in the future
* will keep improving in the future, while Stabs is a dead end

Also, I'm assuming it's the DWARF parser in gdb that needs "fixing". Is this specific to Pascal, or is the DWARF support generally broken?

The full DWARF specs are simply not yet implemented in gdb. Just like in FPC, GDB development outside the interest of the main contributors is mainly driven by user patches. And at least C and C++ don't have the notion of "var" parameters.

Jonas