Stepping

Stepping

[Mike Cvet]

[-- Attachment #1: Type: text/plain, Size: 680 bytes --]

As of about five minutes ago, both instruction stepping (for one or
multiple threads) and line stepping (currently only for all threads of
the process) have been implemented in the source window. 

The source re-drawing is a little clunky right now, but it gets the job
done. There might also be some problems with correct line highlighting
when stepping / running / stack-frame-clicking are combined, but these
won't be hard to work out.

Please give it a shot and file any bugs with it against me!

Line-stepping is run through the 'step' button, and the instruction
stepping is available through the 'Program' menu.

I've attached another testlet you can use for this.

- Mike

[-- Attachment #2: tester2.c --]
[-- Type: text/x-csrc, Size: 1116 bytes --]

// gcc -g -o test -lpthread tester2.c

#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>


pthread_t tester_thread;

pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t cond = PTHREAD_COND_INITIALIZER;

void
*do_it ()
{
  int t = 34543;
  while (t > 0)
    t--;

  fprintf (stderr,"tester_thread: looping\n");

  int d = 0;
  int e = 0;

  while (1)
    {
      d++;
      e++;
      if (d == 3)
	{
	  if (e == 3)
	    e = 0;
	  d = 0;
	}
    }
    
  return NULL;
}

void
bak ()
{
  while (1)
    {
      fprintf (stderr,"main: looping\n");
      int a = 0;
      int b = 0;
      int c = 0;
      while (1)
	{
	  a++;
	  b++;
	  c++;
	  if (a + b > 4)
	    {
	      a = a - c;
	      b = b - c;
	      c = 0;
	    }
	}
    }
}

void 
baz ()
{
  int a;
  int b = 0;
  bak ();
}

void 
bar ()
{
  close (-1);
  close (-1);
  baz ();
  /*Comment */
}

void
foo ()
{
  bar ();
}


int 
main (char **argv, int argc)
{
  pthread_attr_t attr;
  pthread_attr_init (&attr);
  pthread_create (&tester_thread, &attr, do_it, NULL);

  /* This is a comment */
  foo ();
  int t = 30;

  exit (0);
}

Re: Stepping

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 860 bytes --]

Hi Mike,

On Fri, 2006-11-03 at 17:03 -0500, Mike Cvet wrote:
> As of about five minutes ago, both instruction stepping (for one or
> multiple threads) and line stepping (currently only for all threads of
> the process) have been implemented in the source window. 

This is so cool! Seems to work nicely for me now. The only issues I had
were, as you said, clunky re-drawing (sourcewindow jumps to top after a
step) and some interface gotchas (it is hard to see where/which
highlight is for which thread).

> Line-stepping is run through the 'step' button, and the instruction
> stepping is available through the 'Program' menu.

When instruction stepping we might want to switch to the disassembly
window. Why is that disabled for x86_64 btw? I have used the
lib.opcodes.Disassembler for fstep and that does seem to work.

Cheers,

Mark

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Stepping

[Mike Cvet]

On Mon, 2006-11-06 at 11:54 +0100, Mark Wielaard wrote:
> Hi Mike,
> 
> On Fri, 2006-11-03 at 17:03 -0500, Mike Cvet wrote:
> > As of about five minutes ago, both instruction stepping (for one or
> > multiple threads) and line stepping (currently only for all threads of
> > the process) have been implemented in the source window. 
> 
> This is so cool! Seems to work nicely for me now. The only issues I had
> were, as you said, clunky re-drawing (sourcewindow jumps to top after a
> step) and some interface gotchas (it is hard to see where/which
> highlight is for which thread).

Yup, hopefully I'll get these fixed this week.

> 
> > Line-stepping is run through the 'step' button, and the instruction
> > stepping is available through the 'Program' menu.
> 
> When instruction stepping we might want to switch to the disassembly
> window. Why is that disabled for x86_64 btw? I have used the
> lib.opcodes.Disassembler for fstep and that does seem to work.
> 

That's a good question - I just tried it out myself and it seems to
work. It was disabled previously because of several inua bugs which
broke it on x86_64, same with the memory window. But it appears that
these might be fixed by Tim as to allow both these windows to be
enabled. I'll investigate a little more - thanks for the heads up.

- Mike

Re: Stepping

[Mike Cvet]

> > 
> > When instruction stepping we might want to switch to the disassembly
> > window. Why is that disabled for x86_64 btw? I have used the
> > lib.opcodes.Disassembler for fstep and that does seem to work.
> > 
> 
> That's a good question - I just tried it out myself and it seems to
> work. It was disabled previously because of several inua bugs which
> broke it on x86_64, same with the memory window. But it appears that
> these might be fixed by Tim as to allow both these windows to be
> enabled. I'll investigate a little more - thanks for the heads up.


Strange. Looks like the disassembler and memory windows work fine on
Intel 64, but not AMD 64. Uh oh.

By the way, instruction stepping is technically already implemented in
the disassembler by 'incrementing' the memory address, which iterates to
the next full assembly instruction in memory. The idea for the
SourceWindow is to step a series of individual instructions,
highlighting the relevant line, be it 2 or 4 or 6 instructions before
the next line step.

- Mike

Re: Stepping

[Andrew Cagney]

Mark Wielaard wrote:
>> Line-stepping is run through the 'step' button, and the instruction
>> stepping is available through the 'Program' menu.
>>     
>
> When instruction stepping we might want to switch to the disassembly
> window.
>   
"We"'re not doing that ;-)

The disassembler window is just for examining memory as instructions, is 
not intended to be part of the step work-flow.
The source window will eventually need to be extended so that it 
displays assembler directly.

Andrew

Re: Stepping

[Mark Wielaard]

Hi Andrew,

On Mon, 2006-11-06 at 19:28 -0500, Andrew Cagney wrote:
> Mark Wielaard wrote:
> >> Line-stepping is run through the 'step' button, and the instruction
> >> stepping is available through the 'Program' menu.
> >>     
> >
> > When instruction stepping we might want to switch to the disassembly
> > window.
> >   
> "We"'re not doing that ;-)
> 
> The disassembler window is just for examining memory as instructions, is 
> not intended to be part of the step work-flow.
> The source window will eventually need to be extended so that it 
> displays assembler directly.

If you feel that is more natural and it is easy to extend the source
window to also show the assembly level instructions then go for it. But
it seems more natural to me to do instruction stepping from them
disassembler window and line stepping from the source window for now.

Cheers,

Mark

Re: Stepping

[Andrew Cagney]

Mark Wielaard wrote:
>
>
> If you feel that is more natural and it is easy to extend the source
> window to also show the assembly level instructions then go for it. But
> it seems more natural to me to do instruction stepping from them
> disassembler window and line stepping from the source window for now.
>
>   
Sure, that would mean adding stack and thread views to the disassembler 
view; oh look, that's a re-implementation of a source window :-^

The approach being taken is for that window to display the program in 
different formats:
- source
- assembler
- combined source and assembler - inline, side by side, ...
questions arise such as should step-instruction auto-display the 
assembler, but I think the basic mechanics are pretty standard and 
understood.

Andrew

Re: Stepping

[Mark Wielaard]

On Tue, 2006-11-07 at 11:04 -0500, Andrew Cagney wrote:
> The approach being taken is for that window to display the program in 
> different formats:
> - source
> - assembler
> - combined source and assembler - inline, side by side, ...
> questions arise such as should step-instruction auto-display the 
> assembler, but I think the basic mechanics are pretty standard and 
> understood.

Found some screenshots of insight that do this:
http://sources.redhat.com/insight/screenshots/source-and-asm-separate.png
http://sources.redhat.com/insight/screenshots/source-and-asm-mixed.png

Re: Stepping

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 3209 bytes --]

Hi,

Mike asked for a quick rundown how low-level stepping worked at the
moment and I thought it would be a good idea to CC the mailinglist with
my answer so it is in the archives (and others can point at it and make
fun of any design mistakes).

I am currently desperately (still trying to get all tests working again)
trying to get my new low-level breakpoint-stepping code in. It
introduces 2 low-level ways of doing breakpoint-stepping, but I think
the code is a little cleaner since it is easier to separate the state
machine from the underlying stepping mechanism used. I'll write a bit
more about it when that is finally in. The following is how it happens
at this time:

Lets assume (since that was actually what Mike asked) that we installed
an InstructionObserver, the Task stopped notified the observer which
decided that the Task needed to be blocked which turned the TaskState
into BlockedSignal. If you are interested in what would happen while
stepping and the Task not being blocked already, start reading from (*)
and assume we are in the Running state and just want to continue running
the task after some event happened.

So we start at Task.unblock(InstructionObserver) look at
frysk/proc/ptrace/LinuxTaskState.java (around line 1212) the
BlockedSignal class. The handleUnblock() method will be triggered.
Depending on which observers are actually installed (and whether all
blocking observer have been cleared now) a Running TaskState is
determined and sendContinue(task, sig) is called on that Running state
(also in the same java source file, see around line 725).

(*) We are interested in the following line in sendContinue():

  // Step when there is a breakpoint at the current location            
  // or there are Instruction observers installed.                      
  if (bp != null
      || task.instructionObservers.numberOfObservers() > 0)
    task.sendStepInstruction(sig);

The instance of sendStepInstruction() that we call here is defined in
frysk/proc/ptrace/LinuxTask.java (around line 250). This will do some
bookkeeping to remember that a step instruction was requested, which
signal number was requested and whether or not the Task is currently at
a signal return instruction. We need to do that here so we know what we
were doing when we get a callback from the kernel after the step. Then
the appropriate ptrace command is invoked so the Task is doing the
actual step.

If the Task made its step then we will get a TrappedEvent. We are in a
Running state so see LinuxTaskState.java again at line 930. Here things
get a little messy since ptrace/wait uses trap events for signaling
almost everything. Luckily the Isa should be able to tell us if the
current Task just did an instruction step. If it did (and it isn't a
breakpoint address in which case we need to do some extra things) then
we inform all InstructionObservers and if any of them tells us to Block
then we move into the BlockedSignal state, otherwise we keep in the
Running state and continue from (*).

Hope this helps. I'll send an update about the handwavy
breakpoint-stepping case above soon after my code hits cvs.

Cheers,

mark

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]