From: Andrew Cagney <ac131313@cygnus.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [rfa] gdbserver overhaul
Date: Tue, 16 Oct 2001 21:09:00 -0000 [thread overview]
Message-ID: <3BCD045B.4050607@cygnus.com> (raw)
In-Reply-To: <20011011161453.A15989@nevyn.them.org>
> I'd like to commit the attached. It's just the first stage in what will
> probably change a few more times; among other highlights it removes the
> gdbserver dependency on "defs.h" (we still use a few other GDB headers, like
> terminal.h, but those will be easy to deal with down the lines). We lose
> the xm-/tm-/nm- files at the same time, so to know what the target registers
> are we have to hard-code them. This also makes us independent (at last) of
> the GDB register cache layout. GDB does not yet have a corresponding
> independence, but now that the protocols are clearly and compactly described
> in gdbserver, that too can come soon.
Dan, if I'm reading this right there are two changes involved.
Break low-linux.c down into separate files.
Introduce and use regdef.[hc].
With regard to breaking down low-linux.c into CPU specific files. The
actual process doesn't worry me (probably a good move). You would need
to do the other platforms at the same time so that gdbserver doesn't end
up with two different schema. My one concern is the file name choice, I
would definitly use linux in preference to lnx since the former is used
every else in GDB. I'd also consider adding a suffix/prefix - there is
low-* already. (Unless you're proposing we change the other files to lnx.)
Regarding regdef:
> +struct reg arm_regs[] = {
> + R4("r0"), R4("r1"), R4("r2"), R4("r3"),
> + R4("r4"), R4("r5"), R4("r6"), R4("r7"),
> + R4("r8"), R4("r9"), R4("r10"), R4("r11"),
> + R4("r12"), R4("sp"), R4("lr"), R4("pc"),
> + R12("f0"), R12("f1"), R12("f2"), R12("f3"),
> + R12("f4"), R12("f5"), R12("f6"), R12("f7"),
> + R4("fps"), R4("cpsr"),
Have you thought about using something like a colon delimited file:
4:r0
8:r1
to generate these? A definition for a textual form will be needed
eventually. While crude it would allow the sharing of this information
between GDB and gdbserver.
Andrew
> I've added preprocessor gunk to make this compile on other non-Linux
> gdbserver targets, since I only had the Linux ones available to test on. I
> tested on Linux/{ARM,i386,mips,ppc,sh}; the SH bits require some patches
> available from the SH community but not yet in mainstream GDB, but I'm
> including the gdbserver parts anyway. I'm fairly sure that ia64 and m68k
> will continue to work if they did beforehand. Note that the "compile" at the
> beginning of this paragraph is really "compile iff it already did". I tried
> to find a non-Linux target to test; I tried mips64vr5000-unknown-elf
> (low-sim.c) and sparc-sun-solaris2.8 (low-solaris.c). Neither built. It
> would be nice if someone tried, say, the NetBSD port before I committed
> this, but I'm not really insisting on it. I'd rather that every time
> someone notices that such a port is broken, we convert it to the new scheme.
>
>
next prev parent reply other threads:[~2001-10-16 21:09 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-11 13:15 Daniel Jacobowitz
2001-10-14 18:13 ` Andrew Cagney
2001-10-14 18:44 ` Daniel Jacobowitz
2001-10-16 21:12 ` Andrew Cagney
2001-10-16 21:24 ` Daniel Jacobowitz
2001-10-16 21:09 ` Andrew Cagney [this message]
2001-10-16 21:23 ` Daniel Jacobowitz
2001-10-17 4:45 ` Eli Zaretskii
2001-10-17 9:06 ` Andrew Cagney
2001-10-17 10:57 ` Daniel Jacobowitz
2001-10-17 12:34 ` gdbserver/{<foo>,<os>,<bar>}.c?; Was: " Andrew Cagney
2001-10-17 13:39 ` Daniel Jacobowitz
2002-09-27 15:35 ` Andrew Cagney
2002-09-27 15:49 ` Andrew Cagney
2001-10-18 1:11 ` Eli Zaretskii
2001-10-18 9:30 ` Andrew Cagney
2001-10-18 12:36 ` Eli Zaretskii
2001-10-18 11:59 ` Andrew Cagney
2001-10-18 12:08 ` Daniel Jacobowitz
2001-10-21 4:02 ` Mark Kettenis
2001-10-21 9:15 ` Andrew Cagney
2001-10-17 15:17 ` Daniel Jacobowitz
2001-10-18 14:28 ` Andrew Cagney
2001-10-18 17:06 ` 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=3BCD045B.4050607@cygnus.com \
--to=ac131313@cygnus.com \
--cc=drow@mvista.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