Bug 10689

Summary:	replay mode should not or only optionally enter code executed by call()
Product:	gdb	Reporter:	Andre' <andre.poenitz>
Component:	backtrace	Assignee:	Not yet assigned to anyone <unassigned>
Status:	UNCONFIRMED ---
Severity:	enhancement	CC:	gdb-prs, msnyder, teawater
Priority:	P2
Version:	unknown
Target Milestone:	6.8
Host:		Target:
Build:		Last reconfirmed:

Description Andre' 2009-09-23 12:20:43 UTC

Reverse execution currently also steps into code that was 'manually' executed
using  'call'. That is unfortunate in situations where 'calls' are used in an
automated way (like a stop hook, or initiated by a front end). It would be nice
if the tracking of the call execution could be temporarily (or globally) disabled.

Comment 1 teawater 2009-09-24 03:00:41 UTC

Do you mean disable record in "call" command?

Comment 2 Andre' 2009-09-24 15:41:50 UTC

Yes.

Comment 3 teawater 2009-09-27 02:54:03 UTC

I think record the most of memory and reg change is better.

If it affect something, could you please give a example?

Comment 4 Andre' 2009-09-28 06:44:48 UTC

I use call() to extract information from the inferior after each stop (be it
triggered by a breakpoint or by stepping). The result is pretty much what the
Python pretty printers do, except that the code is run natively in the inferior
and I therefore do not have to deploy Python. With call() activity being
recorded I am basically unable to step backwards as I always end up in my
helper code.

Comment 5 teawater 2009-10-10 02:42:04 UTC

I think add a switch for prec to close record in call() can handle it.

Do you think it's OK?

Michael, what do you think about it?

Thanks,
Hui

Comment 6 msnyder@vmware.com 2009-10-11 03:09:04 UTC

Subject: Re:  replay mode should not or only optionally
 enter code executed by call()

teawater at gmail dot com wrote:
> ------- Additional Comments From teawater at gmail dot com  2009-10-10 02:42 -------
> I think add a switch for prec to close record in call() can handle it.
> 
> Do you think it's OK?
> 
> Michael, what do you think about it?

Well, this actually brings up a number of related questions.
What if, during the recording, the user makes changes such as:
  * Change memory
  * Change registers
  * Change the course of execution, eg. by
     - change the PC
     - "jump" command
     - "call" command

I think if user changes memory or registers, you record that.
Right?

And if user changes PC, or uses "jump" command, we will
record it also, right?

So in that case, it seems like we should also record the
"call" command.

Comment 7 teawater 2009-10-12 07:15:39 UTC

If the call() call the function that will not change the global value (some
memory), it will change the most of registers (for example: pc) to the value
before call().

Comment 8 msnyder@vmware.com 2009-10-12 22:38:36 UTC

Subject: Re:  replay mode should not or only optionally
 enter code executed by call()

teawater at gmail dot com wrote:
> ------- Additional Comments From teawater at gmail dot com  2009-10-12 07:15 -------
> If the call() call the function that will not change the global value (some
> memory), it will change the most of registers (for example: pc) to the value
> before call().
> 

Oh yeah, sorry, I mis-understood you.  I thought you were talking
about record mode.

Yes, during replay mode, any "call" will certainly fail.
But I don't worry about it, because, well, it will fail.
Call will try to change the PC, as you say, and that will
error out.

You would like to catch the error earlier?

Comment 9 teawater 2009-10-13 06:11:44 UTC

Sorry I didn't talk it very clear.

I am talking about record mode.  "call()" will not change the a lot of memory
(we can ignore stack change) and register (gdb will change them back).  So maybe
we can ignore record the "call()" code.