Re: gdbstub initial code, v9

2010-09-09 Thread Jan Kratochvil 
Hi Oleg,

kernel-devel-2.6.34.6-54.fc13.x86_64 (real F13) says:

ugdb.c:1988: error: implicit declaration of function ‘hex_to_bin’


Jan

Re: gdbstub initial code, v9

2010-09-09 Thread Oleg Nesterov 
On 09/09, Frank Ch. Eigler wrote:

 Oleg Nesterov o...@redhat.com writes:

  [...]
  But, Jan. Implementing the memory writes does not mean breakpoints
  automatically start to work!

 It approximately should though.

  Yes, gdb writes cc, and yes the tracee reports SIGTRAP. But after
  that continue does nothing except $c, and the tracee naturally
  gets SIGILL. I expected that, since ugdb doesn't even know the code
  was changed, gdb should write the original byte back before continue,
  but this doesn't happen.

 In normal all-stop mode,

Currently ugdb only supports non-stop

 gdb does normally replace the old
 instruction, in order to single-step over it with the 's' packet.

Yes, probably single-stepping is needed... I am still trying to
understand how this works with gdbserver, but I see vCont:s packets.

 Perhaps you're testing some buggy non-stop aspect that only works
 with 'Z' breakpoint management packets?

No. Just a trivial test-case which printfs in a loop.

 A fuller packet trace
 would help explain.

Please see below. But the only important part is:

$M4005ba,1:cc   --- set bp
$c  --- resume

of course, this can't work.

Full trace:

= qSupported:multiprocess+
= PacketSize=400;QStartNoAckMode+;QNonStop+;multiprocess+;QPassS...
= QStartNoAckMode
= OK
= !
= OK
= Hgp0.0
= E01
= QNonStop:1
= OK
= qfThreadInfo
= E01
= ?
= OK
= qSymbol::
=
= vAttach;95b
= OK
= qfThreadInfo
= mp95b.95b
= qsThreadInfo
= l
= Hgp95b.95b
= OK
= vCont?
= vCont;t
= vCont;t:p95b.-1
= OK
= %Stop:T00thread:p95b.95b;
= vStopped
= OK
= g
= fcfd90ad5329ff7f00...
= m600880,8
= 403c6d7d007f
= m7f007d6d3c48,8
= 00106d7d007f
= m7f007d6d1000,28
= f6e04c7d007fe807600080156d7d007f00...
= m7f007d6d1580,28
= 00f0ef29ff7ff6e04c7d007f50f45f29ff7f00c06c7d007f00...
= m7f007d4ce0f4,4
= 090a0069
= m7f007d6cc000,28
= 0030167d007f781f6d7d007f400b4b7d007fe8346d7d007f00...
= m7f007d6d1f78,4
= 2f6c6962
= m7f007d6d1f7c,4
= 2f6c6962
= m7f007d6d1f80,4
= 632e736f
= m7f007d6d1f84,4
= 2e36
= m7f007d6d34e8,28
= 00704b7d007f0002482e6d7d007f00...
= m400200,4
= 2f6c6962
= m400204,4
= 2f6c642d
= m400208,4
= 6c696e75
= m40020c,4
= 782d7838
= m400210,4
= 362d3634
= m400214,4
= 2e736f2e
= m400218,4
= 3200
= m7f007d6d3c40,4
= 0100
= m7f007d6d3c48,8
= 00106d7d007f
= m7f007d6d3c50,8
= c04e4c7d007f
= Z0,7f007d4c4ec0,1
=
= m7f007d4c4ec0,1
= f3
= X7f007d4c4ec0,0:
=
= M7f007d4c4ec0,1:cc
= OK
= m600880,8
= 403c6d7d007f
= m7f007d6d3c48,8
= 00106d7d007f
= m7f007d6d1000,28
= f6e04c7d007fe807600080156d7d007f00...
= m7f007d6d1580,28
= 00f0ef29ff7ff6e04c7d007f50f45f29ff7f00c06c7d007f00...
= m7f007d4ce0f4,4
= 090a0069
= m7f007d6cc000,28
= 0030167d007f781f6d7d007f400b4b7d007fe8346d7d007f00...
= m7f007d6d1f78,4
= 2f6c6962
= m7f007d6d1f7c,4
= 2f6c6962
= m7f007d6d1f80,4
= 632e736f
= m7f007d6d1f84,4
= 2e36
= m7f007d6d34e8,28
= 00704b7d007f0002482e6d7d007f00...
= m400200,4
= 2f6c6962
= m400204,4
= 2f6c642d
= m400208,4
= 6c696e75
= m40020c,4
= 782d7838
= m400210,4
= 362d3634
= m400214,4
= 2e736f2e
= m400218,4
= 3200
= m7f007d6d3c40,4
= 0100
= vCont;t:p95b.-1
= OK
= m7f007d201f40,1
= 48
= m7f007d201f40,1
= 48
= g
= fcfd90ad5329ff7f00...
= m7f007d201f40,1
= 48
= m7f007d201f40,1
= 48
= m40056c,12
= 554889e5e8e3fe89c6ba0700bfdc
= m40056c,1
= 55
= m40056d,3
= 4889e5
= m40056c,12
= 554889e5e8e3fe89c6ba0700bfdc
= m40056c,1
= 55
= m40056d,3
= 4889e5
= m4005ba,1
= e8
= m4005ba,1
= e8

(gdb) b BP.c:13
Breakpoint 1 at 0x4005ba: file BP.c,

Re: gdbstub initial code, v9

2010-09-09 Thread Oleg Nesterov 
On 09/09, Oleg Nesterov wrote:

 the tracee hits this bp and reports SIGTRAP

   = vStopped
   = OK
   = g
   = 00064000401f207d007f00...
   = P10=ba054000
   =
   = G00064000401f207d007f0...
   =

May be this can explain...

Probably I need to implement G/P first, otherwise gdb can't change ip.

Still, I'd appreciate if someone can explain me what gdb needs/expects
to handle breakpoints before I start to read the sources.

Oleg.

Re: gdbstub initial code, v9

2010-09-09 Thread Frank Ch. Eigler 
Hi -

On Thu, Sep 09, 2010 at 05:50:47PM +0200, Oleg Nesterov wrote:

 Probably I need to implement G/P first, otherwise gdb can't change ip.

Perhaps.

 Still, I'd appreciate if someone can explain me what gdb needs/expects
 to handle breakpoints before I start to read the sources.

It'd be simpler if the normal all-stop mode was what you first focused
on.  That mode works fine with Z/z and with M/m based breakpoint
insertion/removal and c/s continue/singlestep.  (This stuff was all
working in the earlier gdbstub code.)

Re. non-stop mode, see
http://www.codesourcery.com/publications/non_stop_multi_threaded_debugging_in_gdb.pdf

- FChE

Re: gdbstub initial code, v9

2010-09-09 Thread Jan Kratochvil 
On Thu, 09 Sep 2010 18:30:31 +0200, Oleg Nesterov wrote:
 OOPS! indeed, unhex() confuses lo and hi.

It works for 0xcc, though.

 Cough... could you tell me how can I change the variable done
 without printing it?

(gdb) help set variable 
Evaluate expression EXP and assign result to variable VAR, using assignment
syntax appropriate for the current language (VAR = EXP or VAR := EXP for
example).  VAR may be a debugger convenience variable (names starting
with $), a register (a few standard names starting with $), or an actual
variable in the program being debugged.  EXP is any valid expression.
This may usually be abbreviated to simply set.


Regards,
Jan

Re: gdbstub initial code, v9

2010-09-09 Thread Tom Tromey 
 Oleg == Oleg Nesterov o...@redhat.com writes:

Oleg   (gdb) set var 0

You need:  set variable var = 0
The variable can be abbreviated.

FWIW, print, set variable, and call are basically aliases.
print just happens to print the result of the expression.

Tom