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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
