GDB Support?

[madhavpcm]

GDB Support?

[ltratt]

I've seen (well @vext01 has seen) a long-standing problem with gdb where pressing "up" causes huge delays as it scans through code (nothing to do with grmtools: this happens with C code as well). From memory, a recent-ish fix has eased the problem a bit, although it still somewhat remains.

Warning: I might be very wrong about all of this!

[vext01]

FWIW: here's my original bug report: https://sourceware.org/bugzilla/show_bug.cgi?id=26024

[ratmice]

I don't seem to be able to reproduce this when using the lrpar/examples/calc_actions setting a breakpoint on calc_actions::calc_y::parse_int after entering an expression up/down can succesfully traverse all the stack frames.
mildly curious whether adding the --readnow flag to force symbol tables to be expanded upon startup rather than lazily affects the behavior you see at all.

[madhavpcm]

mildly curious whether adding the --readnow flag to force symbol tables to be expanded upon startup rather than lazily affects the behavior you see at all.

My bad, this was the case. My parser.y.rs file is nearly 6000 lines long and probably took some time to load (and I Ctrl+C more often than not). However I had this 'delay' from a long time and this used to happen only when jumping between action regions.

Thanks again!

[ratmice]

Somewhat newer than that bug report/fix it seems, but gdb 12.1 also added multithreaded symbol loading it seems.