One potential issue might be (not tested): the generic code is compiled without debug information, but code that uses it is compiled with and thus the specialization will have debug information as well. Thus when stepping through the latter code one might suddenly land in the generic code which one assumed is without debug information.
On the other hand, I invariably use a locally-built FPC+Lazarus and looking at my build log for FPC 3.2.0 I see
make NO_GDB=1 CPU_TARGET=i386 OPT='-V3.0.4 -O- -gl -Xs- -vt' all |/usr/local/bin/fpc-filter-vt
Lazarus+LCL though is built with default options, so it could be there.
I'll try to keep an eye open for what I think I've seen, and will report back.
I've caught it in the act. If a method is declared virtual+abstract and then overridden in a subclass, stepping into the method's implementation takes you through fpc_check_object_ext() which is in generic.inc. So it gives the impression that generic stuff is being pulled in, even if that's not in fact happening.
Well, not everything that's named “generic” does involve generics.
Though I wonder why it steps through
fpc_check_object_check? Do you have the RTL compiled with debug information?
Sidenote: This check is only active if either object checks or range checks are enabled