From: Daniel Jacobowitz <drow@false.org>
To: Ulrich Weigand <uweigand@de.ibm.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [rfc][2/3] gdbserver bi-arch support: core s390x part
Date: Tue, 29 Jan 2008 20:28:00 -0000 [thread overview]
Message-ID: <20080129202548.GA15063@caradoc.them.org> (raw)
In-Reply-To: <200801211745.m0LHjqHo002475@d12av02.megacenter.de.ibm.com>
On Mon, Jan 21, 2008 at 06:45:52PM +0100, Ulrich Weigand wrote:
> @@ -548,6 +548,7 @@ status_pending_p (struct inferior_list_e
> static void
> linux_wait_for_process (struct process_info **childp, int *wstatp)
> {
> + static int arch_setup_done = 0;
> int ret;
> int to_wait_for = -1;
>
This isn't quite good enough. It's already possible for the
architecture to change during a single gdbserver run, so I think we
have to support re-calling arch_setup. Right now you have to run in
extended mode and replace a 32-bit binary with a 64-bit one before
restarting it, but I'll be checking in the support for "set remote
exec-file" shortly if I catch up on patch review :-)
All it takes is hopefully a global flag that we can reset when
switching to a new inferior.
> diff -urNp gdb-orig/gdb/gdbserver/linux-s390-low.c gdb-head/gdb/gdbserver/linux-s390-low.c
> --- gdb-orig/gdb/gdbserver/linux-s390-low.c 2008-01-18 00:57:40.000000000 +0100
> +++ gdb-head/gdb/gdbserver/linux-s390-low.c 2008-01-18 01:00:18.000000000 +0100
> @@ -102,24 +102,61 @@ static const unsigned char s390_breakpoi
> static CORE_ADDR
> s390_get_pc ()
> {
> - unsigned long pc;
> - collect_register_by_name ("pswa", &pc);
> + if (register_size (0) == 4)
> + {
> + unsigned int pc;
> + collect_register_by_name ("pswa", &pc);
> #ifndef __s390x__
> - pc &= 0x7fffffff;
> + pc &= 0x7fffffff;
> #endif
> - return pc;
> + return pc;
> + }
> + else
> + {
> + unsigned long pc;
> + collect_register_by_name ("pswa", &pc);
> + return pc;
> + }
> }
This is harmlessly if dead if gdbserver is 32-bit, right?
> +static void
> +s390_arch_setup (void)
> +{
> + /* Assume 31-bit inferior process. */
> + init_registers_s390 ();
> +
> + /* On a 64-bit host, check the low bit of the (31-bit) PSWM
> + -- if this is one, we actually have a 64-bit inferior. */
> +#ifdef __s390x__
> + {
> + unsigned int pswm;
> + collect_register_by_name ("pswm", &pswm);
> + if (pswm & 1)
> + init_registers_s390x ();
> + }
> +#endif
This makes my head hurt quite a lot. You're fetching registers into
the cache before you know their size for sure? I think using
ptrace directly in this case might be more obvious.
--
Daniel Jacobowitz
CodeSourcery
next prev parent reply other threads:[~2008-01-29 20:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-21 17:46 Ulrich Weigand
2008-01-29 20:28 ` Daniel Jacobowitz [this message]
2008-01-29 23:35 ` Ulrich Weigand
2008-02-01 0:04 ` Ulrich Weigand
2008-02-26 3:57 ` Daniel Jacobowitz
2008-02-27 3:44 ` Ulrich Weigand
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=20080129202548.GA15063@caradoc.them.org \
--to=drow@false.org \
--cc=gdb-patches@sourceware.org \
--cc=uweigand@de.ibm.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