Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Doug Evans <dje@google.com>
To: Yao Qi <yao@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC] Don't allow setting register in non-innermost frame
Date: Mon, 20 Aug 2012 20:19:00 -0000	[thread overview]
Message-ID: <CADPb22SGp-9TaoA3rNi_PJordCuv_bjwFQZiHvfjktHx3Y_krA@mail.gmail.com> (raw)
In-Reply-To: <1345170040-25959-1-git-send-email-yao@codesourcery.com>

On Thu, Aug 16, 2012 at 7:20 PM, Yao Qi <yao@codesourcery.com> wrote:
> Hi,
> When playing with 'set $reg=0xXXX', I am thinking about the expected
> behaviour of setting register when the frame is not innermost.  Current
> GDB will invalidate regcaches and reinit frache_caches for any register
> changes (on innermost and non-innermost frame).  However, the semantics
> of 'setting register on non-innermost frame' is tricky.  On innermost
> frame, 'setting register' means writing something to register in cpu,
> while on non-innermost frame, it means writing something to either
> real register (regcache) or memory (frame).  On the other head, I am
> trying to figure out a situation that user has to set register on
> non-innermost frame.  Why does this user have to do that?
>
> Literally, IMO, 'set $reg=0xXXXX' means 'setting the cpu register $reg
> to value 0xXXX', which is simple and clear.  I propose to restrict
> setting register in innermost frame only.  WDYT?
>
> Regression tested on x86_64-linux.  Surprisingly, we don't have a test
> case for 'set register', so I add one.  In the future, I plan to add
> more tests here for 'set register', such as 'set some bits of a register'
> and 'set multiple registers in one time', to cover the different
> paths in value_assign for 'lval_register'.

I wonder if there'll be a bit of a gnome vs kde battle here.  :-)
[the analogy isn't entirely accurate, but it's the best one I could think of]

fwiw, I've been able to work around corrupt, or otherwise not
completely useful, core files by setting registers in non-innermost
frames.
Granted, I knew what was happening underneath the covers, so to speak,
and I could have done things differently, but I like this capability.

If gdb had started out disallowing changing registers in non-innermost
frames, we mightn't be thinking of restricting it now.
"It's easier to relax restrictions than it is to impose them after the fact."
I'd like to hear more justification for this change.
I *could* accept a warning when changing a register in a non-innermost
frame, fwiw.


  reply	other threads:[~2012-08-20 20:19 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-17  2:21 Yao Qi
2012-08-20 20:19 ` Doug Evans [this message]
2012-08-21  3:27   ` Yao Qi
2012-08-23 16:25   ` Tom Tromey
2012-08-29  9:51     ` Yao Qi
2012-09-04 22:37       ` dje
2012-09-07 10:01         ` Yao Qi
2012-09-07 10:11           ` Eli Zaretskii
2012-09-07 10:21             ` Yao Qi
2012-09-07 11:27               ` Eli Zaretskii
2012-09-07 13:14                 ` Yao Qi
2012-09-07 14:32                   ` Eli Zaretskii
2012-09-07 16:46     ` Jan Kratochvil
2012-09-09  2:31       ` Yao Qi
2012-09-10  2:02       ` Yao Qi
2012-09-10  7:47         ` Jan Kratochvil
2012-09-10 19:43           ` Jan Kratochvil
2012-09-11 17:12         ` Tom Tromey
2012-09-11 17:19           ` Jan Kratochvil
2012-09-11 17:23             ` Tom Tromey
2012-09-12  0:51           ` Yao Qi
2012-09-12 13:19             ` Jan Kratochvil

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=CADPb22SGp-9TaoA3rNi_PJordCuv_bjwFQZiHvfjktHx3Y_krA@mail.gmail.com \
    --to=dje@google.com \
    --cc=gdb-patches@sourceware.org \
    --cc=yao@codesourcery.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