From: Andrew Cagney <ac131313@redhat.com>
To: Kevin Buettner <kevinb@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [rfa:ppc] Eliminate write_sp, but how?
Date: Thu, 11 Sep 2003 19:26:00 -0000 [thread overview]
Message-ID: <3F60CC4A.3040304@redhat.com> (raw)
In-Reply-To: <1030910221444.ZM19183@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 610 bytes --]
>> So, in addition to eliminating deprecated write_sp, would it be ok to
>> move the write SP code to the end of the push_dummy_call methods?
>
>
> I can't think of any problems that would arise from moving the "write
> SP" code to the end of the various push_dummy_call() methods. But
> just in case, when you change it, please note how it used to be done
> and why doing it in a different location *shouldn't* be a problem.
> (It may someday make it easier to debug that obscure target which
> randomly picks a stopped thread's stack to service an interrupt...)
This is what I've checked in.
Andrew
[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 2983 bytes --]
2003-09-11 Andrew Cagney <cagney@redhat.com>
* rs6000-tdep.c (rs6000_push_dummy_call): Use
regcache_raw_write_signed to set SP_REGNUM, move the operation to
near the function's end.
(rs6000_gdbarch_init): Do not set "deprecated_dummy_write_sp".
* ppc-sysv-tdep.c (ppc_sysv_abi_push_dummy_call): Use
regcache_raw_write_signed to set SP_REGNUM.
Index: ppc-sysv-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/ppc-sysv-tdep.c,v
retrieving revision 1.8
diff -u -r1.8 ppc-sysv-tdep.c
--- ppc-sysv-tdep.c 9 Sep 2003 22:41:47 -0000 1.8
+++ ppc-sysv-tdep.c 11 Sep 2003 19:23:29 -0000
@@ -189,8 +189,8 @@
/* Make sure that we maintain 16 byte alignment */
sp &= ~0x0f;
- /* Update %sp before proceeding any further */
- write_register (SP_REGNUM, sp);
+ /* Update %sp before proceeding any further. */
+ regcache_raw_write_signed (regcache, SP_REGNUM, sp);
/* write the backchain */
store_unsigned_integer (old_sp_buf, 4, saved_sp);
Index: rs6000-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/rs6000-tdep.c,v
retrieving revision 1.155
diff -u -r1.155 rs6000-tdep.c
--- rs6000-tdep.c 9 Sep 2003 22:41:47 -0000 1.155
+++ rs6000-tdep.c 11 Sep 2003 19:23:34 -0000
@@ -1246,14 +1246,6 @@
space = (space + 15) & -16;
sp -= space;
- /* This is another instance we need to be concerned about
- securing our stack space. If we write anything underneath %sp
- (r1), we might conflict with the kernel who thinks he is free
- to use this area. So, update %sp first before doing anything
- else. */
-
- write_register (SP_REGNUM, sp);
-
/* If the last argument copied into the registers didn't fit there
completely, push the rest of it into stack. */
@@ -1294,14 +1286,17 @@
ii += ((len + 3) & -4) / 4;
}
}
- else
- /* Secure stack areas first, before doing anything else. */
- write_register (SP_REGNUM, sp);
/* set back chain properly */
store_unsigned_integer (tmp_buffer, 4, saved_sp);
write_memory (sp, tmp_buffer, 4);
+ /* Set the stack pointer. According to the ABI, the SP is ment to
+ be set _before_ the corresponding stack space is used. No need
+ for that here though - the target has been completly stopped - it
+ isn't possible for an exception handler to stomp on the stack. */
+ regcache_raw_write_signed (regcache, SP_REGNUM, sp);
+
/* Point the inferior function call's return address at the dummy's
breakpoint. */
regcache_raw_write_signed (regcache, tdep->ppc_lr_regnum, bp_addr);
@@ -2896,7 +2891,6 @@
set_gdbarch_print_insn (gdbarch, gdb_print_insn_powerpc);
set_gdbarch_write_pc (gdbarch, generic_target_write_pc);
- set_gdbarch_deprecated_dummy_write_sp (gdbarch, deprecated_write_sp);
set_gdbarch_num_regs (gdbarch, v->nregs);
set_gdbarch_num_pseudo_regs (gdbarch, v->npregs);
prev parent reply other threads:[~2003-09-11 19:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-10 21:39 Andrew Cagney
2003-09-10 22:14 ` Kevin Buettner
2003-09-11 19:26 ` 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=3F60CC4A.3040304@redhat.com \
--to=ac131313@redhat.com \
--cc=gdb-patches@sources.redhat.com \
--cc=kevinb@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