<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Hello,<br></div><div class="gmail_quote"><div><br></div></div><div class="gmail_quote">On Fri, Mar 27, 2009 at 3:03 PM, Jonas Maebe <span dir="ltr"><<a href="mailto:jonas.maebe@elis.ugent.be" target="_blank">jonas.maebe@elis.ugent.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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)<br>
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.<br>
<br>
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).</blockquote><div><br></div><div>This is quote from 2009, and I was wondering if there was no changes since then?</div><div>(I know that there were a number of improvements in dwarf debug info, but not sure what they actually were)</div><div><br></div><div>I'm looking at stabs (fpc 3.0.0) (even though I know I should look at dwarf)</div><div>As of this time, the only issue I'm seeing is missing proper information about function result.</div><div><br></div><div>The code:</div><div><div><br></div><div>{$mode delphi}</div><div>function Calc(a,b: integer): Integer;<br></div><div>var</div><div>  c : integer;</div><div>begin</div><div>  c:=a;</div><div>  c:=c+b;</div><div>  Result:=a+c;</div><div>end;</div></div><div><br></div><div>STABS:</div><div>   N_FUN: other = 0; desc = 3; value = 4199456; 00401420; CALC:F1<br></div><div><div>  N_RSYM: other = 0; desc = 3; value = 0; 00000000; A:R1 <<  the first parameter passed on eax</div><div>  N_PSYM: other = 0; desc = 3; value = -4; FFFFFFFC; A:1</div><div>  N_RSYM: other = 0; desc = 3; value = 2; 00000002; B:R1 << the second parameter passed on edx</div><div>  N_PSYM: other = 0; desc = 3; value = -8; FFFFFFF8; B:1</div><div>  N_PSYM: other = 0; desc = 3; value = -12; FFFFFFF4; result:1</div><div>  N_PSYM: other = 0; desc = 5; value = -16; FFFFFFF0; C:1</div><div>  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?</div><div>  N_PSYM: other = 0; desc = 0; value = -12; FFFFFFF4; RESULT:X1</div><div>   N_SOL: other = 0; desc = 0; value = 4199456; 00401420; test.pas</div><div> N_SLINE: other = 0; desc = 6; value = 0; 00000000; </div><div> N_SLINE: other = 0; desc = 7; value = 13; 0000000D; </div><div> N_SLINE: other = 0; desc = 8; value = 19; 00000013; </div><div> N_SLINE: other = 0; desc = 9; value = 25; 00000019; </div><div> N_SLINE: other = 0; desc = 10; value = 31; 0000001F; </div><div> N_LBRAC: other = 0; desc = 0; value = 0; 00000000; </div><div> N_RBRAC: other = 0; desc = 0; value = 33; 00000021; </div></div><div><br></div><div>Ultimately a debugger could make "a guess" about the calling convention, based on the parameters passed.</div><div><br></div><div>thanks,</div><div>Dmitry</div></div></div></div>