Re: [FYI] Inlining support, rough patch

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> ### Whether this or that case is shown is also dependent on the current
Jan> ### architecture - currently the behavior differs depending of whether there
Jan> ### is at least one instruction of the same source line after the call
Jan> ### instruction.  Next `step' will have to do _nothing_ to the inferior, just
Jan> ### display the next line in GDB.

This is interesting.  Alexandre Oliva has talked about something
similar -- a dwarf extension which would let gdb users "step" through
a sequence of source statements, even when the compiler has optimized
them away.  The idea would be to emit debug info describing the
variables virtually, and this "step" would simply advance through the
debuginfo without updating the PC.  (I'm not really doing this
justice, but I can't find Alexandre's note to the gcc list atm.)

About your proposal: IIUC, it is trying a bit to hide more of the
underlying reality from the user.  Can it really work in all cases?
I'm wondering about things like multiple levels of inlining (you may
need several do-nothing steps?); multiple levels of inlining where the
user wants to "finish" out of each one (you may need a do-nothing
finish as well?); or inlining that results in a tail-call optimization
being applied (there's no good spot to return to).

Does any of this make sense?  I can't tell if I actually understand :-)

Tom