From: Stan Shebs <shebs@apple.com>
To: Daniel Jacobowitz <dmj+@andrew.cmu.edu>
Cc: gdb@sources.redhat.com
Subject: Re: Current (non-) state of gdbserver
Date: Wed, 11 Jul 2001 12:03:00 -0000 [thread overview]
Message-ID: <3B4CA2DA.EB9DCB43@apple.com> (raw)
In-Reply-To: <20010710234505.A5814@nevyn.them.org>
Daniel Jacobowitz wrote:
>
> Based on the lack of response I got last time I inquired about gdbserver,
> I'd say that no one has really picked it up since Stan stepped back. It
> hasn't built in a while; the multiarch support completely stops it from
> working, on the targets I tried at least (ppc-linux and mips-linux).
>
> Unless someone steps up with something already done (if you're out there,
> we're waiting...), I'm going to start working on this. I'm not sure how
> multiarch will fit in to gdbserver in the future, but for now my intent is
> to bloat it somewhat with the necessary support code. It'll probably
> involve splitting a lot of tdep files into two pieces.
As Andrew observes, you'll probably get tangled up in dependencies,
but those are likely to be mistakes in GDB's architecture - there's
no good reason why lowest-level native and target support (which is
all that gdbserver needs) has to be making references to user-interface
code and the like.
Thought 1: split the arch vector into a general vector and a nano-vector
with only the register definitions and such. If we really don't care
about the extra footprint from unused arch code (either because it's
small, or we know linker will discard), then instead you could have
an optional <arch>-ui.c to be a home for target-specific commands.
Thought 2: foo-nat.c will probably need to be split, again foo-ui.c
could be a home for higher-level and symbolic stuff.
Thought 3: AIX is especially ugly to handle, because you need to make
a ptrace call and pick apart OS-supplied structures even to find the
entry point. Might even need a protocol addition to get it to work.
> I'd also like to start building gdbserver by default on platforms which
> support it (and I have patches to extend the list a bit). That way we can
> at least notice this sort of thing...
An excellent idea. One thing I wanted to do as part of this was to
move gdbserver out of its subdirectory, since by the time you're
done integrating with the rest of GDB sources, you should only have
one file unique to gdbserver (main()), and the semi-duplicated
Makefile.in make trouble.
Stan
next prev parent reply other threads:[~2001-07-11 12:03 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-10 23:45 Daniel Jacobowitz
2001-07-11 10:36 ` Andrew Cagney
2001-07-11 12:03 ` Stan Shebs [this message]
2001-07-11 13:17 ` J.T. Conklin
2001-07-11 13:55 ` Andrew Cagney
2001-07-11 15:06 ` Quality Quorum
2001-07-12 12:21 ` J.T. Conklin
2001-07-12 12:45 ` Andrew Cagney
2001-07-13 7:53 ` Quality Quorum
2001-07-15 0:30 ` Eli Zaretskii
2001-07-15 0:58 ` Fabrice Gautier
2001-07-15 3:15 ` Eli Zaretskii
2001-07-15 6:21 ` Fabrice Gautier
2001-07-16 14:08 ` Quality Quorum
2001-07-11 13:44 ` Andrew Cagney
2001-07-11 12:43 ` J.T. Conklin
2001-07-12 13:04 ` 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=3B4CA2DA.EB9DCB43@apple.com \
--to=shebs@apple.com \
--cc=dmj+@andrew.cmu.edu \
--cc=gdb@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