From: Pedro Alves <pedro@codesourcery.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFA/commit/ia64-linux] Allow libunwind to fetch register 0
Date: Wed, 26 Oct 2011 00:27:00 -0000 [thread overview]
Message-ID: <201110252224.37861.pedro@codesourcery.com> (raw)
In-Reply-To: <20111025204052.GR19246@adacore.com>
On Tuesday 25 October 2011 21:40:52, Joel Brobecker wrote:
> Hi again Pedro,
>
> I will make the small changes you suggested at the beginning of
> the patch. I just wanted to confirm something:
>
> > > + gdb_assert (sizeof (r0_value) == register_size (gdbarch, regnum));
> > > + regcache_raw_supply (regcache, regnum, r0_value);
> > > + return;
> > > + }
> > > +
> >
> > I don't speak ia64, but this is the right direction.
> > I think we should make ia64_cannot_fetch_register return true for
> > gr0 too though.
>
> I assume that you mean that ia64_cannot_fetch_register should return
> False as well (meaning that we can in fact fetch the register - don't
> you love double negatives?).
Bleh. :-) Yes, I meant return false.
> I had originally interpreted the name
> of that function very strictly, meaning that, no, the kernel does
> not provide that register value, so we cannot fetch it. But at the
> same time, I think I see you point of having the fetch_register
> routine saying we can get the value, while at the same time the
> cannot_fetch_register function says we can't.
Hmm, yeah, I looking at it from the perspective that the gdbarch
hook can be used outside the ia64 target/arch dependent code, and at
that point, it shouldn't matter if we're talking to ptrace or to
a core or to something else. The core code calling the hook would
only be interested in knowing whether the value can be fetched or
not. But that looks moot, as this is used to mean "ptrace can fetch
the register".
alpha-nat.c: if (gdbarch_cannot_fetch_register (gdbarch, regno))
hppa-linux-nat.c: if (gdbarch_cannot_fetch_register (gdbarch, regno))
inf-ptrace.c: || gdbarch_cannot_fetch_register (gdbarch, regnum))
These are all legacy, and all look broken by design to me. I mean, what
ptrace can or not return is a target-y thing, not gdbarch thing, and
certainly the corresponding struct target can override the register
fetching hook to do the same thing.
I thought there were more uses of the hook... where have they gone
to? :-D
Given that, I don't see reason to change the hook on ia64-linux. In
fact, I don't think there's any need for the hook to be installed
on ia64-linux. Oh, wait, it _isn't_ installed as a gdbarch hook,
is it? Eh. I'm tempted to go
s/gdbarch_cannot_fetch_register/deprecated_gdbarch_cannot_fetch_register/g. :-)
--
Pedro Alves
next prev parent reply other threads:[~2011-10-25 21:25 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-25 16:55 Joel Brobecker
2011-10-25 17:27 ` Pedro Alves
2011-10-25 17:37 ` Pedro Alves
2011-10-25 20:49 ` Joel Brobecker
2011-10-26 0:27 ` Pedro Alves [this message]
2012-03-27 19:32 ` Pedro Alves
2012-03-27 23:03 ` Joel Brobecker
2012-03-28 12:52 ` Pedro Alves
2012-03-28 14:55 ` [PATCH] IA64: $fr0==0.0, $fr1==1.0 Pedro Alves
2012-03-28 17:15 ` Joel Brobecker
2012-03-28 17:56 ` Pedro Alves
2012-03-28 14:55 ` [PATCH] IA64: EC, the Epilog Count register, is available in ptrace Pedro Alves
2012-03-28 17:12 ` Joel Brobecker
2012-03-28 17:55 ` Pedro Alves
2012-03-28 17:10 ` [RFA/commit/ia64-linux] Allow libunwind to fetch register 0 Joel Brobecker
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=201110252224.37861.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
/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