Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2011-09

Calling virtual methods in GDB

5 messages · 4 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Joost van der Sluis

Hi all,

I've just committed a fix (r19253) which makes it possible to call virtual methods within GDB. (Or other Dwarf-debuggers, when they support that properly)

Only problem is that when GDB is in Pascal mode, it won't work. I have written a patch for that
(http://cygwin.com/ml/gdb/2011-09/msg00072.html) or you can set GDB to use C, and then call the virtual function.

Note however that there still could be issues regarding the calling-convention. With a simple function returning an integer it works, however. ;)

Reply by email

Martin
to Joost van der Sluis
Joost van der Sluis wrote 10 lines
Hi all, I've just committed a fix (r19253) which makes it possible to call virtual methods within GDB. (Or other Dwarf-debuggers, when they support that properly) Only problem is that when GDB is in Pascal mode, it won't work. I have written a patch for that (http://cygwin.com/ml/gdb/2011-09/msg00072.html) or you can set GDB to use C, and then call the virtual function.

Ah, cygwin => I have never tested the gdb from them. I always use the mingw version

Show quoted text 5 lines
Note however that there still could be issues regarding the calling-convention. With a simple function returning an integer it works, however. ;)

In theory, it should be possible to prepare the stack, and set the pc via register modification? But, no, no, no, i do not think it is a good idea, and probably will bring more new problems.

But there is another issue to be looked into. I haven't done that yet.

- Breakpoints => if in the executed function, any breakpoints are hit...
- Exceptions => I know gdb has some features to restore the stackframe => but I have no idea, if that relies on c-style stuff, or would work with fpc exceptions too.

Reply by email

Jonas Maebe
to Martin
Martin wrote 7 lines
On 27/09/2011 16:58, Joost van der Sluis wrote: > > Only problem is that when GDB is in Pascal mode, it won't work. I have > written a patch for that > (http://cygwin.com/ml/gdb/2011-09/msg00072.html) or you can set GDB to > use C, and then call the virtual function. Ah, cygwin => I have never tested the gdb from them. I always use the mingw version

The patch is unrelated to cygwin. cygwin.com simply hosts one of the archives of the gdb mailing list.

But there is another issue to be looked into. I haven't done that yet. - Breakpoints => if in the executed function, any breakpoints are hit...

Then the execution stops at the breakpoint.

- Exceptions => I know gdb has some features to restore the stackframe => but I have no idea, if that relies on c-style stuff, or would work with fpc exceptions too.

It does not rely on anything C-specific. However, FPC's exception handling modifies global variables and there is not much gdb can do about that. The proper way to fix this (and many other issues) would be to implement FPC exception handling using DWARF EH-frame information.

Jonas

Reply by email

Paul Ishenin
to Jonas Maebe
Jonas Maebe wrote
> - Exceptions => I know gdb has some features to restore the stackframe => but I have no idea, if that relies on c-style stuff, or would work with fpc exceptions too. It does not rely on anything C-specific. However, FPC's exception handling modifies global variables and there is not much gdb can do about that. The proper way to fix this (and many other issues) would be to implement FPC exception handling using DWARF EH-frame information.

I thought exceptions does not work properly because they don't use SEH on windows and the proper way to solve the problems is to implement compiler and RTL support for SEH.

Best regards,
Paul Ishenin.

Reply by email

Jonas Maebe
to Paul Ishenin
Paul Ishenin wrote 14 lines
28.09.2011 4:08, Jonas Maebe wrote: >> - Exceptions => I know gdb has some features to restore the >> stackframe => but I have no idea, if that relies on c-style >> stuff, or would work with fpc exceptions too. > > It does not rely on anything C-specific. However, FPC's exception > handling modifies global variables and there is not much gdb can do > about that. The proper way to fix this (and many other issues) > would be to implement FPC exception handling using DWARF EH-frame > information. I thought exceptions does not work properly because they don't use SEH on windows and the proper way to solve the problems is to implement compiler and RTL support for SEH.

That's indeed the Windows-specific version of EH-frame based exception handling. I should have written "EH-frame" instead of "DWARF EH-frame".

Jonas

Reply by email