Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@redhat.com>
To: Joel Brobecker <brobecker@gnat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFC] hppa/multiarch - PUSH_DUMMY_FRAME depends on inf_status
Date: Sat, 11 Jan 2003 20:35:00 -0000	[thread overview]
Message-ID: <3E20800A.7040502@redhat.com> (raw)
In-Reply-To: <20030111102928.GM30359@gnat.com>

> tm-hppa.h contains the following macro definition for PUSH_DUMMY_FRAME:
> 
>     /* FIXME: brobecker 2002-12-26.  This macro definition takes advantage
>        of the fact that PUSH_DUMMY_FRAME is called within a function where
>        a variable inf_status of type struct inferior_status * is defined.
>        Ugh!  Until this is fixed, we will not be able to move to multiarch
>        partial.  */
>     #define PUSH_DUMMY_FRAME hppa_push_dummy_frame (inf_status)
>     extern void hppa_push_dummy_frame (struct inferior_status *);
> 
> As said in the comment, there is this nasty dependency of the fact that
> there is a variable called inf_status in the scope where this macro is
> "invoked". This dependency is getting in the way of the multiarch conversion,
> so I'd like to remove it.
> 
> I looked at the only place where PUSH_DUMMY_FRAME is used, and found
> the following code (function hand_function_call in valops.c):
> 
>     /* A cleanup for the inferior status.  Create this AFTER the retbuf
>        so that this can be discarded or applied without interfering with
>        the regbuf.  */
>     inf_status = save_inferior_status (1);
>     inf_status_cleanup = make_cleanup_restore_inferior_status (inf_status);

[tangent]

This makes a copy of the inferior's registers.

Hmm, this means that there are potentially two copies of the system 
registers - inf_status and dummy-frame's (but HP doesn't yet use dummy 
frames).

In fact, this means that all targets, even the ones that don't use 
generic dummy frames, are restoring their registers from a regcache and 
_not_ from the the register values pushed onto the stack!

>     /* PUSH_DUMMY_FRAME is responsible for saving the inferior registers
>        (and POP_FRAME for restoring them).  (At least on most machines)
>        they are saved on the stack in the inferior.  */
>     PUSH_DUMMY_FRAME;
> 
> So inf_status is obtained by a call to save_inferior_status. OK.
> 
> HP's push_dummy_frame uses it exclusively to hack in some of the
> registers.  A comment explains why this is necessary:
> 
>   /* Oh, what a hack.  If we're trying to perform an inferior call
>      while the inferior is asleep, we have to make sure to clear
>      the "in system call" bit in the flag register (the call will
>      start after the syscall returns, so we're no longer in the system
>      call!)  This state is kept in "inf_status", change it there.
>   
>      We also need a number of horrid hacks to deal with lossage in the
>      PC queue registers (apparently they're not valid when the in syscall
>      bit is set).  */


> They do it like this:
> 
>       write_inferior_status_register (inf_status, 0, int_buffer);
>       write_inferior_status_register (inf_status, PCOQ_HEAD_REGNUM, pc + 0);
>       write_inferior_status_register (inf_status, PCOQ_TAIL_REGNUM, pc + 4);

Joel,

I think I'm missing something pretty fundamental here.  This shouldn't 
work.  I can't figure out why it doesn't end up trying to do a write to 
a read-only copy of current_regcache?

- inf_status->registers is created using regcache_dup (current_regcache)
gdb_assert (inf_status->registers != current_registers) true?
gdb_assert (inf_status->registers->readonly_p) true?

- inf_status->registers->regcache_raw_write() is calling (you've got 
legacy code :-) legacy_write_register_gen(), but first it checks:
gdb_assert (!regcache->readonly_p);
gdb_assert (regcache == current_regcache);

- legacy_write_register_gen() is then both writing the value into the 
current_regcache and direct to the target.

i.e., those writes are hitting the target directly.

Any idea what I'm missing?

confused,
Andrew





      reply	other threads:[~2003-01-11 20:35 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-11 10:29 Joel Brobecker
2003-01-11 20:35 ` Andrew Cagney [this message]

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=3E20800A.7040502@redhat.com \
    --to=ac131313@redhat.com \
    --cc=brobecker@gnat.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