[fpc-devel] function evaluation by gdb

[Jonas Maebe]

On 27 Mar 2009, at 19:44, Paul Ishenin wrote:

> and evaluate Ord('a'):
>
> [gdb log]
> <-data-evaluate-expression Ord('a')>
> &"No symbol \"Ord\" in current context.\n"
> ^error,msg="No symbol \"Ord\" in current context."
> [/gdb log]

Ord() is not a regular function, it's implemented using compiler magic  
(just like chr(), write(), read(), val(), str(), ...). The debugger  
has no idea about what it is, or even that it exists. We might be able  
to fake it in the debug information by simply defining ord() as an  
alias for longint/int64 or so (although then it will of course also  
work in cases where the normal ord() expression would fail -- to solve  
that, you could of course also adapt gdb's Pascal parser).

> and evaluate IntToStr(I):
>
> [gdb log]
> <-data-evaluate-expression IntToStr(I)>
> &"too few arguments in function call\n"
> ^error,msg="too few arguments in function call"
> [/gdb log]
>
> Are that all gdb bugs or wrong debug info?

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


Jonas