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
prev parent 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