From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: uweigand@de.ibm.com
Cc: gdb-patches@sourceware.org
Subject: Re: [rfc/rft] [3/5] Untangle register_addr: CANNOT_FETCH/STORE_REGISTER
Date: Sat, 14 Apr 2007 22:55:00 -0000 [thread overview]
Message-ID: <200704142249.l3EMnlut014933@brahms.sibelius.xs4all.nl> (raw)
In-Reply-To: <200704142110.l3ELASpq008358@d12av02.megacenter.de.ibm.com> (uweigand@de.ibm.com)
> Date: Sat, 14 Apr 2007 23:10:28 +0200 (CEST)
> From: "Ulrich Weigand" <uweigand@de.ibm.com>
>
> Hello,
>
> this patch removes the calls to CANNOT_FETCH_REGISTER / CANNOT_STORE_REGISTER
> from within the inf_ptrace_trad_target routines. This is enabled by two
> changes to the register_u_offset callback:
> - the routine is allowed to return (CORE_ADDR)-1 to indicate the
> requested register cannot be accessed
> - the routine gains a new argument STORE_P that indicates whether
> the register is to be fetched or stored
So effectively, this turns CANNOT_FETCH_REGISTER/CANNOT_STORE_REGISTER
from being overloaded as both a native and target property into a
target-architecture-only property instead. That's probably a good
idea.
However, I think you removing the calls from the calls from the
inf_ptrace_trad_target routines is wrong. We should never fetch/store
the registers for which the target architecture says that they cannot
be fetched/stored.
If you leave them in, do any targets remain that have any registers
that can be fetched but cannot be stored by ptrace(2), that are not
defined as such by the target architecture. I'd be surprised if there
were any such registers.
In that cas you wouldn't need the extra store_p argument for the
register_u_addr() callback.
> ChangeLog:
>
> * inf-ptrace.c (inf_ptrace_register_u_offset): Add STORE_P argument.
> (inf_ptrace_fetch_register): Update call. Check for (CORE_ADDR)-1
> return value; replaces CANNOT_FETCH_REGISTER call.
> (inf_ptrace_store_register): Update call. Check for (CORE_ADDR)-1
> return value; replaces CANNOT_STORE_REGISTER call.
> (inf_ptrace_trad_target): Update signature.
> * inf-ptrace.h (inf_ptrace_trad_target): Likewise.
> * linux-nat.c (linux_trad_target): Likewise.
> * linux-nat.h (linux_trad_target): Likewise.
>
> * alpha-linux-nat.c (alpha_linux_register_u_offset): Add STORE_P
> argument. Call CANNOT_STORE_REGISTER / CANNOT_FETCH_REGISTER.
> * mips-linux-nat.c (mips_linux_register_u_offset): Likewise.
> * vax-nat.c (vax_register_u_addr): Add STORE_P argument.
next prev parent reply other threads:[~2007-04-14 22:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-14 21:11 Ulrich Weigand
2007-04-14 22:55 ` Mark Kettenis [this message]
2007-04-16 16:03 ` 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=200704142249.l3EMnlut014933@brahms.sibelius.xs4all.nl \
--to=mark.kettenis@xs4all.nl \
--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