Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@mvista.com>
To: David Mc Kenna <mckennad@esatclear.ie>
Cc: gdb@sources.redhat.com
Subject: Re: GDB speed using Remote Serial Protocol
Date: Mon, 02 Dec 2002 10:55:00 -0000	[thread overview]
Message-ID: <20021202185543.GA17558@nevyn.them.org> (raw)
In-Reply-To: <3debabab.66df.0@esatclear.ie>

No, you missed my gist.  With debug info printing, GDB takes a little
bit longer (because it has to do the printing).  Something is being
sent too quickly, and being dropped and then eventually retried.

On Mon, Dec 02, 2002 at 06:51:23PM +0000, David Mc Kenna wrote:
> I would agree with this except that with debug info switched on it is much faster
> than with it switched off. What is the difference in code execution within GDB
> with debug info switched off?
> 
> Cheers,
> Dave
> 
> >On Mon, Dec 02, 2002 at 05:27:04PM +0000, David Mc Kenna wrote:
> >> Hi all,
> >> 
> >> At present I have an outline for a stub ( GDB RSP -> uController -> Jtag
> ) for
> >> an Arm7TDMi. I have successfully implemented the GDB -> uController side
> of
> >> the equation. Here I have two questions.
> >> 
> >> Is there another way of seeing what GDB sends to the serial port without
> enabling
> >> debug info within GDB ?, i.e. without using the commands :
> >> "set debug remote 1" & " set debug serial 1"
> >> 
> >> My second questions relates to the first. With debug info switched on ( "set
> 
> >> debug remote 1" & " set debug serial 1"), a single step talks < 1 second
> to
> >> complete, including all the debug info being written to the screen. Yet when
> 
> >> I switch off this info the single step time starts at < 1 second but soon
> mushrooms
> >> to ~ 5 seconds.
> >> 
> >> I have tried this on gdb v5 and gdb v5.2.1 with the same results.
> >> GDB configured as arm-elf
> >> 
> >> 
> >> Any ideas??
> >
> >Sounds like something is being sent more quickly than your
> >stub/controller/whatever is ready to handle it.
> >
> >What I recommend in this case is writing (or getting; rproxy may be
> >able to do this?) a stub which just connects a TCP port and a serial
> >port; forwards data from one to the other, and logs.
> >
> >-- 
> >Daniel Jacobowitz
> >MontaVista Software                         Debian GNU/Linux Developer
> >
> >
> --
> http://www.iol.ie
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


  reply	other threads:[~2002-12-02 18:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-02 10:52 David Mc Kenna
2002-12-02 10:55 ` Daniel Jacobowitz [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-12-02  9:28 David Mc Kenna
2002-12-02  9:54 ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20021202185543.GA17558@nevyn.them.org \
    --to=drow@mvista.com \
    --cc=gdb@sources.redhat.com \
    --cc=mckennad@esatclear.ie \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox