[fpc-devel] function evaluation by a debugger

Dmitry Boyarintsev skalogryz.lists at gmail.com
Tue Oct 17 19:58:47 CEST 2017


Hello,

On Fri, Mar 27, 2009 at 3:03 PM, Jonas Maebe <jonas.maebe at elis.ugent.be>
wrote:

> a) even if gdb would not complain, you would probably get a crash because
> as mentioned before, on i386 FPC by default uses the completely
> non-standard "Borland fastcall" calling convention, for which gdb has no
> support (it would try to call it like a cdecl function; and we don't say in
> the DWARF info either that it uses an unsupported calling convention --
> stabs has no way to say anything about used the calling convention)
> b) at least I have never spent any time on trying to get gdb to recognize
> function call symbols (especially not in case of overloaded functions, like
> the above). So I can't say whether it's caused by errors in the debug info,
> missing support for overloaded functions in gdb's Pascal parser, something
> else, or all of those things.
>
> In general, I would not count on being able to call FPC functions from
> inside a debugger any time soon (unless someone starts spending time on
> that; at least I am not interested in doing that right now).


This is quote from 2009, and I was wondering if there was no changes since
then?
(I know that there were a number of improvements in dwarf debug info, but
not sure what they actually were)

I'm looking at stabs (fpc 3.0.0) (even though I know I should look at dwarf)
As of this time, the only issue I'm seeing is missing proper information
about function result.

The code:

{$mode delphi}
function Calc(a,b: integer): Integer;
var
  c : integer;
begin
  c:=a;
  c:=c+b;
  Result:=a+c;
end;

STABS:
   N_FUN: other = 0; desc = 3; value = 4199456; 00401420; CALC:F1
  N_RSYM: other = 0; desc = 3; value = 0; 00000000; A:R1 <<  the first
parameter passed on eax
  N_PSYM: other = 0; desc = 3; value = -4; FFFFFFFC; A:1
  N_RSYM: other = 0; desc = 3; value = 2; 00000002; B:R1 << the second
parameter passed on edx
  N_PSYM: other = 0; desc = 3; value = -8; FFFFFFF8; B:1
  N_PSYM: other = 0; desc = 3; value = -12; FFFFFFF4; result:1
  N_PSYM: other = 0; desc = 5; value = -16; FFFFFFF0; C:1
  N_PSYM: other = 0; desc = 0; value = -12; FFFFFFF4; CALC:X1  <<< shows
the result to be on stack, while it supposed to be in eax?
  N_PSYM: other = 0; desc = 0; value = -12; FFFFFFF4; RESULT:X1
   N_SOL: other = 0; desc = 0; value = 4199456; 00401420; test.pas
 N_SLINE: other = 0; desc = 6; value = 0; 00000000;
 N_SLINE: other = 0; desc = 7; value = 13; 0000000D;
 N_SLINE: other = 0; desc = 8; value = 19; 00000013;
 N_SLINE: other = 0; desc = 9; value = 25; 00000019;
 N_SLINE: other = 0; desc = 10; value = 31; 0000001F;
 N_LBRAC: other = 0; desc = 0; value = 0; 00000000;
 N_RBRAC: other = 0; desc = 0; value = 33; 00000021;

Ultimately a debugger could make "a guess" about the calling convention,
based on the parameters passed.

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20171017/42c5ac50/attachment.html>


More information about the fpc-devel mailing list