(remote) hellishly slow single stepping over library calls

(remote) hellishly slow single stepping over library calls

[Kris Warkentin]

When debugging using our QNX pdebug remote protocol and single stepping over
a library call like printf, it takes a LOOOONG time.  I'm talking like two
or three minutes.  A 'next' is fine but looking at the output of running our
pdebug server in verbose mode, gdb is doing step, step, step, all the way
through the whole library call.  Every single step results in fetching
registers and there is a huge amount of wire traffic generated.

This didn't happen with older (ie 5.0) gdbs which didn't seem to know how to
single step through our shared lib code but now that it does, this is pretty
painful.  Obviously it makes more sense to 'next' over a library call,
especially if you don't want to go into it but the question is, can anyone
think of a way to optimize this?  I though of putting in a hack like:

if (reg == PC_REGNUM)
    only_get_pc();

to avoid fetching the whole regset but it probably won't make that much
difference since there's still a packet over the wire each time and most
regsets fit in one packet anyway.

Would this problem also exist with the normal remote protocol?  (stupid
users...clicking step instead of next....;-)

cheers,

Kris

Re: (remote) hellishly slow single stepping over library calls

[Theodore A. Roth]

On Fri, 16 May 2003, Kris Warkentin wrote:

:) When debugging using our QNX pdebug remote protocol and single stepping over
:) a library call like printf, it takes a LOOOONG time.  I'm talking like two
:) or three minutes.  A 'next' is fine but looking at the output of running our
:) pdebug server in verbose mode, gdb is doing step, step, step, all the way
:) through the whole library call.  Every single step results in fetching
:) registers and there is a huge amount of wire traffic generated.
:)
:) This didn't happen with older (ie 5.0) gdbs which didn't seem to know how to
:) single step through our shared lib code but now that it does, this is pretty
:) painful.  Obviously it makes more sense to 'next' over a library call,
:) especially if you don't want to go into it but the question is, can anyone
:) think of a way to optimize this?  I though of putting in a hack like:
:)
:) if (reg == PC_REGNUM)
:)     only_get_pc();
:)
:) to avoid fetching the whole regset but it probably won't make that much
:) difference since there's still a packet over the wire each time and most
:) regsets fit in one packet anyway.
:)
:) Would this problem also exist with the normal remote protocol?  (stupid
:) users...clicking step instead of next....;-)

Not sure if this is totally related (how does pdebug differ from rsp?)
but maybe a solution could help avr users too.

Some sort of optimization here would be boon for avr users. In our
case we use gdb to talk to our avarice program
(http://sourceforge.net/projects/avarice) which talks to a jtagice box
which in turn talks to the actual target device via a jtag interface.
Single stepping is painfully slow: step, wait 1-5 seconds, step, etc.

The bottleneck for us not so much sending info over the wire via rsp,
but in reading the registers from the device via jtag. If we could
reduce the number registers that need to be read at each step, I think
it could speed things up.

For comparision, I also have a avr simulator which is controlled by
gdb via rsp. Single stepping in the simulator is fairly fast (feels
almost as fast as stepping a native program).

Ted Roth

Re: (remote) hellishly slow single stepping over library calls

[Kris Warkentin]

> Not sure if this is totally related (how does pdebug differ from rsp?)
> but maybe a solution could help avr users too.
>
> Some sort of optimization here would be boon for avr users. In our
> case we use gdb to talk to our avarice program
> (http://sourceforge.net/projects/avarice) which talks to a jtagice box
> which in turn talks to the actual target device via a jtag interface.
> Single stepping is painfully slow: step, wait 1-5 seconds, step, etc.
>
> The bottleneck for us not so much sending info over the wire via rsp,
> but in reading the registers from the device via jtag. If we could
> reduce the number registers that need to be read at each step, I think
> it could speed things up.

Well, once upon a time, we would get one register at a time.  Then we
decided to optimize and get the whole regset since we can supply them to gdb
and then it won't ask for any more.  The only place this really optimizes is
when you're asking for more than one per stop which isn't the case when
single stepping.  Like I said before though, in our case it might not matter
since we have to send a packet anyway and it costs no more to have the whole
regset in there.

You, however, I could see really benefitting from this if the jtag is
relatively slow at fetching registers and you have to do it one at a time.
There isn't any way to tell the jtag to send a whole set I suppose?

cheers,

Kris

Re: (remote) hellishly slow single stepping over library calls

[Quality Quorum]

On Fri, 16 May 2003, Kris Warkentin wrote:

> When debugging using our QNX pdebug remote protocol and single stepping over
> a library call like printf, it takes a LOOOONG time.  I'm talking like two
> or three minutes.  A 'next' is fine but looking at the output of running our
> pdebug server in verbose mode, gdb is doing step, step, step, all the way
> through the whole library call.  Every single step results in fetching
> registers and there is a huge amount of wire traffic generated.
>
> This didn't happen with older (ie 5.0) gdbs which didn't seem to know how to
> single step through our shared lib code but now that it does, this is pretty
> painful.  Obviously it makes more sense to 'next' over a library call,
> especially if you don't want to go into it but the question is, can anyone
> think of a way to optimize this?  I though of putting in a hack like:
>
> if (reg == PC_REGNUM)
>     only_get_pc();
>
> to avoid fetching the whole regset but it probably won't make that much
> difference since there's still a packet over the wire each time and most
> regsets fit in one packet anyway.
>
> Would this problem also exist with the normal remote protocol?  (stupid
> users...clicking step instead of next....;-)
>


What about using the T-format with a value of PC to report status, instead
of using the S-format, for the purpose.

> Kris

Thanks,

Aleksey

Re: (remote) hellishly slow single stepping over library calls

[Kris Warkentin]

> > Would this problem also exist with the normal remote protocol?  (stupid
> > users...clicking step instead of next....;-)
>
> What about using the T-format with a value of PC to report status, instead
> of using the S-format, for the purpose.

We're not using gdb's remote protocol but rather our own.  I see from
remote.c though that T-format is just an expedited reply with just a signal
and the appropriate registers.  I'm assuming that each target would be in
charge of knowing what it needs to put in these replies and when to use
them.

I'll look into implementing that sort of thing on our end.

Thanks,

Kris

Re: (remote) hellishly slow single stepping over library calls

[Daniel Jacobowitz]

On Fri, May 16, 2003 at 03:24:30PM -0400, Kris Warkentin wrote:
> > > Would this problem also exist with the normal remote protocol?  (stupid
> > > users...clicking step instead of next....;-)
> >
> > What about using the T-format with a value of PC to report status, instead
> > of using the S-format, for the purpose.
> 
> We're not using gdb's remote protocol but rather our own.  I see from
> remote.c though that T-format is just an expedited reply with just a signal
> and the appropriate registers.  I'm assuming that each target would be in
> charge of knowing what it needs to put in these replies and when to use
> them.

Yes, that's how it works.

> I'll look into implementing that sort of thing on our end.

It should be pretty straightforward to do.  When you get the right
registers, it's quite effective, too.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: (remote) hellishly slow single stepping over library calls

[Kris Warkentin]

> > I'll look into implementing that sort of thing on our end.
>
> It should be pretty straightforward to do.  When you get the right
> registers, it's quite effective, too.

I took a look at our notify message and it already has space for various
registers in it depending on what the notification is for (ie. single step,
break, etc.)  I should be able to stuff them on the target end and supply
them every time gdb stops.  Other than empirically, where can I discover
what registers are needed for various targets?  I'm thinking IP for everyone
but are some going to want stack and frame pointers as well?

cheers,

Kris

Re: (remote) hellishly slow single stepping over library calls

[Quality Quorum]

On Fri, 16 May 2003, Kris Warkentin wrote:

> > > I'll look into implementing that sort of thing on our end.
> >
> > It should be pretty straightforward to do.  When you get the right
> > registers, it's quite effective, too.
>
> I took a look at our notify message and it already has space for various
> registers in it depending on what the notification is for (ie. single step,
> break, etc.)  I should be able to stuff them on the target end and supply
> them every time gdb stops.  Other than empirically, where can I discover
> what registers are needed for various targets?  I'm thinking IP for everyone
> but are some going to want stack and frame pointers as well?

I suppose that a program counter, a frame pointer and a stack pointer will
be enough. It is easy to test, if gdb needs more resiters it will pull
them all in.

>
> cheers,
>
> Kris
>

Thanks,

Aleksey

Re: (remote) hellishly slow single stepping over library calls

[Andrew Cagney]

> On Fri, May 16, 2003 at 03:24:30PM -0400, Kris Warkentin wrote:
> 
>> > > Would this problem also exist with the normal remote protocol?  (stupid
>> > > users...clicking step instead of next....;-)
> 
>> >
>> > What about using the T-format with a value of PC to report status, instead
>> > of using the S-format, for the purpose.
> 
>> 
>> We're not using gdb's remote protocol but rather our own.  I see from
>> remote.c though that T-format is just an expedited reply with just a signal
>> and the appropriate registers.  I'm assuming that each target would be in
>> charge of knowing what it needs to put in these replies and when to use
>> them.
> 
> 
> Yes, that's how it works.
> 
> 
>> I'll look into implementing that sort of thing on our end.
> 
> 
> It should be pretty straightforward to do.  When you get the right
> registers, it's quite effective, too.

Something useful here would be a mod to regcache.[hc] to track the 
registers requested (after a flush/invalidate) (via regcache_raw_read) 
rather than the registers supplied (via supply_register) (displayed via 
maint print raw-registers)

That, and a few single steps, would pretty quickly tell you what is needed.

The other way is to watch the output of 'set debug target'.

Andrew