I have 2 matching reports (but so far unable to reproduce myself)

- both are 64 bit
- at least one is linux and uses gdb 7.5.1
I believe the other is linux too, not sure what gdb, (and he tested on win (not sure 64 or 32bit) where it did not happen) [ this may point to a linker issue (maybe) ]

- They both state, that they did not use optimization, or smart linking

When stepping (step over) GDB suddenly stops in fpc_ansistring_copy (or other functions in the RTL that are called during the step)

I am seeking for any ideas....

I know it likely is to be something in GDB and needs to be asked there. But it appears to react to some diff bthat happened in fpc (2.6.x) seems not to trigger it).

And other than the fact that those functions are optimized, and do not have a full gdb detectable stackframe, there is nothing I could suspect....

possible: http://bugs.freepascal.org/view.php?id=14399

Martin wrote

possible: http://bugs.freepascal.org/view.php?id=14399

I am a bit lost:
The bug says "GDB always steps *into* the interface (depite it should step over)

But at:
http://sourceware.org/ml/gdb/2009-04/msg00008.html

When encountering such a stub, gdb currently does not step into them

It is about gdb not being able to step into them?

I got the attached sample from one of the 2people. With the instructions below:

I have no 64 bit linux to test myself. I therefore do not know, if it will indeed reproduce.
According to the reporter, it happens with stabs and dwarf.

I am not sure which versions of gdb (the reporter had 7.5.1) Testing with an upgraded 7.5.9 or 7.6 is of limited use, since both crash easily if debugging fpc generated apps.

---------------
If the report is correct, then apps generated with fpc 2.7.1 may not be debug-able in gdb (unless you want to step through ansistring internals)

Maybe someone can give it a try?

And if it is reproducible, find if it is fpc or gdb?