Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <dmj+@andrew.cmu.edu>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [rfa] gdbserver 1/n - PBUFSIZ
Date: Thu, 19 Jul 2001 16:12:00 -0000	[thread overview]
Message-ID: <20010719161206.A30475@nevyn.them.org> (raw)
In-Reply-To: <3B575B8F.4050407@cygnus.com>

On Thu, Jul 19, 2001 at 06:13:35PM -0400, Andrew Cagney wrote:
> >> I take it you've also got a few more steps planned, can you give a quick 
> >> sketch of where you're going?
> > 
> > 
> > Short term: enough to make gdbserver compile on any targets it still
> > currently builds on (I have no clue which these are, for lack of test
> > hosts on many of the types) as well as more Linux targets.  If you're
> > willing, I'd like to do this somewhat messily and before the release of
> > 5.1.  It doesn't matter too much to me, since I've got no real
> > compunctions about shipping a CVS snapshot instead, but it goes against
> > my instincts to let gdbserver out the door building on so many fewer
> > targets than it did in 5.0.
> 
> 
> Where's the fire?  I know there is going to be a gdb 5.2 or 5.1.1 
> because of all the on-going C++ work.  I think getting it right is more 
> important than getting something that looks right.  Get it half right 
> and it it will stay that way for years.

Yes, that's true.  I'm going to need gdbserver to work in the
relatively short-term future, though.  I'm perfectly willing to let it
slip past 5.1 (and at this stage it seems inevitable).  Especially
since no one seems to be concerned with gdbserver having broken.

> > What I envision from here, longer term:
> >   - gdbserver registers cleanup.  This will mean precisely defining,
> >     according to present usage, the register packets of every
> >     gdbserver-supported target, or at least the ones I can test or
> >     find someone to test for me.  A lot of documentation; a lot of
> >     duplicate code elimination in gdbserver.  I'm also going to try to
> >     define the gdbserver register layout in such a way that GDB can use
> >     it too (possibly by your flexible string description approach, or
> >     just a shared structure).
> 
> 
> Just FYI, structures have compiler compatibility problems.

I didn't mean something sent over the wire; I meant a source file that
could be linked into both gdb and gdbserver.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer


  parent reply	other threads:[~2001-07-19 16:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-19 11:36 Daniel Jacobowitz
2001-07-19 13:14 ` Andrew Cagney
2001-07-19 13:21   ` Daniel Jacobowitz
     [not found]     ` <3B575B8F.4050407@cygnus.com>
2001-07-19 16:12       ` Daniel Jacobowitz [this message]
2001-07-19 16:16     ` Daniel Jacobowitz
2001-07-20 16:54       ` Andrew Cagney

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=20010719161206.A30475@nevyn.them.org \
    --to=dmj+@andrew.cmu.edu \
    --cc=ac131313@cygnus.com \
    --cc=gdb-patches@sources.redhat.com \
    /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