* [RFC] sh-tdep.c: Don't fetch FPSCR register if it doesn't exist
@ 2012-03-01 0:34 Kevin Buettner
2012-03-01 1:33 ` Joel Brobecker
0 siblings, 1 reply; 10+ messages in thread
From: Kevin Buettner @ 2012-03-01 0:34 UTC (permalink / raw)
To: gdb-patches; +Cc: Thomas Schwinge
The patch below fixes 119 failures for the default sh-elf multilib (using
sh-sim.) I can post a list if there's interest in seeing them.
Comments? Is there a better way to test for the existence of a register?
Kevin
* sh-tdep.c (sh_frame_cache): Don't fetch the FPSCR register
unless it exists for this architecture.
Index: sh-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/sh-tdep.c,v
retrieving revision 1.239
diff -u -p -r1.239 sh-tdep.c
--- sh-tdep.c 27 Feb 2012 16:40:48 -0000 1.239
+++ sh-tdep.c 1 Mar 2012 00:31:31 -0000
@@ -2553,7 +2553,12 @@ sh_frame_cache (struct frame_info *this_
if (cache->pc != 0)
{
ULONGEST fpscr;
- fpscr = get_frame_register_unsigned (this_frame, FPSCR_REGNUM);
+ const char *fpscr_name = gdbarch_register_name (gdbarch, FPSCR_REGNUM);
+
+ if (fpscr_name && fpscr_name[0])
+ fpscr = get_frame_register_unsigned (this_frame, FPSCR_REGNUM);
+ else
+ fpscr = 0;
sh_analyze_prologue (gdbarch, cache->pc, current_pc, cache, fpscr);
}
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [RFC] sh-tdep.c: Don't fetch FPSCR register if it doesn't exist 2012-03-01 0:34 [RFC] sh-tdep.c: Don't fetch FPSCR register if it doesn't exist Kevin Buettner @ 2012-03-01 1:33 ` Joel Brobecker 2012-03-01 5:09 ` Kevin Buettner 0 siblings, 1 reply; 10+ messages in thread From: Joel Brobecker @ 2012-03-01 1:33 UTC (permalink / raw) To: Kevin Buettner; +Cc: gdb-patches, Thomas Schwinge > Comments? Is there a better way to test for the existence of a register? Perhaps an idea... Apparently, this is a property of the arch, so something relatively static. This is typically the type of information the sh_gdbarch_init routine would save in the gdbarch_tdep structure. You can create a new flag in that structure, and then set it at the same time you register the register_name gdbarch hook. > * sh-tdep.c (sh_frame_cache): Don't fetch the FPSCR register > unless it exists for this architecture. -- Joel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC] sh-tdep.c: Don't fetch FPSCR register if it doesn't exist 2012-03-01 1:33 ` Joel Brobecker @ 2012-03-01 5:09 ` Kevin Buettner 2012-03-01 10:30 ` Thomas Schwinge 2012-03-01 15:57 ` Joel Brobecker 0 siblings, 2 replies; 10+ messages in thread From: Kevin Buettner @ 2012-03-01 5:09 UTC (permalink / raw) To: gdb-patches On Wed, 29 Feb 2012 17:33:18 -0800 Joel Brobecker <brobecker@adacore.com> wrote: > > Comments? Is there a better way to test for the existence of a register? > > Perhaps an idea... Apparently, this is a property of the arch, so > something relatively static. This is typically the type of information > the sh_gdbarch_init routine would save in the gdbarch_tdep structure. > You can create a new flag in that structure, and then set it at the > same time you register the register_name gdbarch hook. I considered that approach. It'll work, but seemed like more coding than it was worth when I first wrote the patch. But thinking about it now, I don't find this to be a very compelling reason to code it the way that I did. That said, I'm not fond of the tdep flag idea, at least not in this instance... If we were to use a tdep flag, we must ensure that this flag is set correctly for each architecture variant. For sh, there are a bunch of `register_name' and `register_type' implementations. It seems like a shame to have to add redundant knowledge about fpscr to the tdep struct. If we were to keep that knowledge together or somehow derive it from knowledge we already had it'd be different. But in order to determine the correct value of this new flag, the most obvious course of action is (for one of us) to examine the register names to see if fpscr is present. We'll have to transcribe that knowledge to the various cases in sh_gdbarch_init(). It's still doable, but I'd like to consider another approach first. I've seen the register name test used in other instances to check for the existence of a register. One of the places it's used is in various `register_reggroup_p' implementations. It's used in both default_register_reggroup_p() and sh_register_reggroup_p(). This suggests the following approach: if (gdbarch_register_reggroup_p (gdbarch, FPSCR_REGNUM, all_reggroup)) ... else ... We know that gdbarch_register_reggroup_p() called in that fashion will somehow determine whether the given register number is a member of the "all" register group. We don't care how it figures this out, whether it be by examining the register name, or a flag in the tdep struct, or some other method altogether. But we do know that it'll return 1 for registers that exist and 0 for those that don't. What do you think? Here's an updated patch: * sh-tdep.c (sh_frame_cache): Don't fetch the FPSCR register unless it exists for this architecture. Index: sh-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/sh-tdep.c,v retrieving revision 1.239 diff -u -p -r1.239 sh-tdep.c --- sh-tdep.c 27 Feb 2012 16:40:48 -0000 1.239 +++ sh-tdep.c 1 Mar 2012 05:02:47 -0000 @@ -2553,7 +2553,12 @@ sh_frame_cache (struct frame_info *this_ if (cache->pc != 0) { ULONGEST fpscr; - fpscr = get_frame_register_unsigned (this_frame, FPSCR_REGNUM); + + /* Check existence of FPSCR. */ + if (gdbarch_register_reggroup_p (gdbarch, FPSCR_REGNUM, all_reggroup)) + fpscr = get_frame_register_unsigned (this_frame, FPSCR_REGNUM); + else + fpscr = 0; sh_analyze_prologue (gdbarch, cache->pc, current_pc, cache, fpscr); } ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC] sh-tdep.c: Don't fetch FPSCR register if it doesn't exist 2012-03-01 5:09 ` Kevin Buettner @ 2012-03-01 10:30 ` Thomas Schwinge 2012-03-01 19:11 ` Kevin Buettner 2012-03-01 15:57 ` Joel Brobecker 1 sibling, 1 reply; 10+ messages in thread From: Thomas Schwinge @ 2012-03-01 10:30 UTC (permalink / raw) To: Kevin Buettner; +Cc: gdb-patches [-- Attachment #1: Type: text/plain, Size: 832 bytes --] Hi! On Wed, 29 Feb 2012 22:09:32 -0700, Kevin Buettner <kevinb@redhat.com> wrote: > * sh-tdep.c (sh_frame_cache): Don't fetch the FPSCR register > unless it exists for this architecture. Your reasoning and this patch look good to me. (But I didn't test it.) Basically, you now relay the test to sh_register_reggroup_p, which already contains the FPSCR existence test you first proposed. (The same test exists in arch-utils.c:legacy_register_sim_regno, by the way.) Still learning about GDB's code layout -- is there any benefit in invoking gdbarch_register_reggroup_p (as you're doing) in contrast to directly going for sh_register_reggroup_p? Also, we assume that simply passing 0 for fpscr to sh_analyze_prologue doesn't do any harm (which it doesn't). (Worth a comment, perhaps?) Grüße, Thomas [-- Attachment #2: Type: application/pgp-signature, Size: 489 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC] sh-tdep.c: Don't fetch FPSCR register if it doesn't exist 2012-03-01 10:30 ` Thomas Schwinge @ 2012-03-01 19:11 ` Kevin Buettner 2012-03-02 9:24 ` Thomas Schwinge 2012-03-03 1:29 ` Kevin Buettner 0 siblings, 2 replies; 10+ messages in thread From: Kevin Buettner @ 2012-03-01 19:11 UTC (permalink / raw) To: gdb-patches; +Cc: Thomas Schwinge On Thu, 01 Mar 2012 11:30:13 +0100 Thomas Schwinge <thomas@codesourcery.com> wrote: > On Wed, 29 Feb 2012 22:09:32 -0700, Kevin Buettner <kevinb@redhat.com> wrote: > > * sh-tdep.c (sh_frame_cache): Don't fetch the FPSCR register > > unless it exists for this architecture. > > Your reasoning and this patch look good to me. (But I didn't test it.) > Basically, you now relay the test to sh_register_reggroup_p, which > already contains the FPSCR existence test you first proposed. (The same > test exists in arch-utils.c:legacy_register_sim_regno, by the way.) Thanks for looking it over. Yes, that test in legacy_register_sim_regno bit me recently when doing the rl78 register rearrangement. That's an interesting case to consider, actually. For rl78 (and for mips too as I recall), there are a certain set of "raw" registers which are then mapped to "cooked" versions. The raw registers do not have names, but the cooked ones do. So, assuming the same implementation of `register_reggroup_p', asking about one of the raw registers will fail (return 0), but asking about a cooked register will succeed. The reason I'm pondering this is that I'm now wondering about the suitability of using `register_reggroup_p' for this purpose. I think it is still okay because presumably the code should be asking about the cooked version of the register instead of the uncooked version. In fact, for rl78, this is how the stack pointer is implemented; it's a cooked register formed from two raw registers. It is never correct for anything aside from the pseudo register read/write code to try to access the raw versions of the two stack pointer registers. > Still learning about GDB's code layout -- is there any benefit in > invoking gdbarch_register_reggroup_p (as you're doing) in contrast to > directly going for sh_register_reggroup_p? Well, the way I'm doing it is slower. But, if at some point someone were to add another `register_reggroup_p' method for some other sh variant (as is the case for `register_name'), the code that I wrote will still work. If I called sh_register_reggroup_p directly, then presumably the wrong function would be called for that new architecture variant. > Also, we assume that simply passing 0 for fpscr to sh_analyze_prologue > doesn't do any harm (which it doesn't). (Worth a comment, perhaps?) Yes, that's a good idea. Below is an updated patch. * sh-tdep.c (sh_frame_cache): Don't fetch the FPSCR register unless it exists for this architecture. Index: sh-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/sh-tdep.c,v retrieving revision 1.239 diff -u -p -r1.239 sh-tdep.c --- sh-tdep.c 27 Feb 2012 16:40:48 -0000 1.239 +++ sh-tdep.c 1 Mar 2012 18:11:17 -0000 @@ -2553,7 +2553,16 @@ sh_frame_cache (struct frame_info *this_ if (cache->pc != 0) { ULONGEST fpscr; - fpscr = get_frame_register_unsigned (this_frame, FPSCR_REGNUM); + + /* Check for the existence of the FPSCR register. If it exists, + fetch its value for use in prologue analysis. Passing a zero + value is the best choice for architecture variants upon which + there's no FPSCR register. */ + if (gdbarch_register_reggroup_p (gdbarch, FPSCR_REGNUM, all_reggroup)) + fpscr = get_frame_register_unsigned (this_frame, FPSCR_REGNUM); + else + fpscr = 0; + sh_analyze_prologue (gdbarch, cache->pc, current_pc, cache, fpscr); } ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC] sh-tdep.c: Don't fetch FPSCR register if it doesn't exist 2012-03-01 19:11 ` Kevin Buettner @ 2012-03-02 9:24 ` Thomas Schwinge 2012-03-02 13:46 ` Kevin Buettner 2012-03-03 1:29 ` Kevin Buettner 1 sibling, 1 reply; 10+ messages in thread From: Thomas Schwinge @ 2012-03-02 9:24 UTC (permalink / raw) To: Kevin Buettner; +Cc: gdb-patches [-- Attachment #1: Type: text/plain, Size: 1397 bytes --] Hi Kevin! On Thu, 1 Mar 2012 11:19:26 -0700, Kevin Buettner <kevinb@redhat.com> wrote: > I think it is still okay because [...] I agree with your reasoning. > On Thu, 01 Mar 2012 11:30:13 +0100 > Thomas Schwinge <thomas@codesourcery.com> wrote: > > Still learning about GDB's code layout -- is there any benefit in > > invoking gdbarch_register_reggroup_p (as you're doing) in contrast to > > directly going for sh_register_reggroup_p? > > Well, the way I'm doing it is slower. > > But, if at some point someone were to add another > `register_reggroup_p' method for some other sh variant (as is the case > for `register_name'), the code that I wrote will still work. If I > called sh_register_reggroup_p directly, then presumably the wrong > function would be called for that new architecture variant. Sure, but a person adding a new variant of sh_register_reggroup_p would surely be checking all places where the current only implementation is invoked, and decide which is now applicable, the old or the new -- or simply defer that decision to gdbarch_register_reggroup_p then; so we might as well do that right now. > * sh-tdep.c (sh_frame_cache): Don't fetch the FPSCR register > unless it exists for this architecture. Looks good; before committing, you may want to unify spaces/tabs usage used for indenting the comment. Grüße, Thomas [-- Attachment #2: Type: application/pgp-signature, Size: 489 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC] sh-tdep.c: Don't fetch FPSCR register if it doesn't exist 2012-03-02 9:24 ` Thomas Schwinge @ 2012-03-02 13:46 ` Kevin Buettner 0 siblings, 0 replies; 10+ messages in thread From: Kevin Buettner @ 2012-03-02 13:46 UTC (permalink / raw) To: gdb-patches On Fri, 02 Mar 2012 10:23:47 +0100 Thomas Schwinge <thomas@codesourcery.com> wrote: > > * sh-tdep.c (sh_frame_cache): Don't fetch the FPSCR register > > unless it exists for this architecture. > > Looks good; before committing, you may want to unify spaces/tabs usage > used for indenting the comment. Thanks for noticing that. I've fixed it in my tree. (Don't think it's worth posting a new patch for it.) Kevin ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC] sh-tdep.c: Don't fetch FPSCR register if it doesn't exist 2012-03-01 19:11 ` Kevin Buettner 2012-03-02 9:24 ` Thomas Schwinge @ 2012-03-03 1:29 ` Kevin Buettner 1 sibling, 0 replies; 10+ messages in thread From: Kevin Buettner @ 2012-03-03 1:29 UTC (permalink / raw) To: gdb-patches On Thu, 1 Mar 2012 11:19:26 -0700 Kevin Buettner <kevinb@redhat.com> wrote: > * sh-tdep.c (sh_frame_cache): Don't fetch the FPSCR register > unless it exists for this architecture. Committed. Thanks to Joel and Thomas for looking it over. Kevin ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC] sh-tdep.c: Don't fetch FPSCR register if it doesn't exist 2012-03-01 5:09 ` Kevin Buettner 2012-03-01 10:30 ` Thomas Schwinge @ 2012-03-01 15:57 ` Joel Brobecker 2012-03-01 19:10 ` Kevin Buettner 1 sibling, 1 reply; 10+ messages in thread From: Joel Brobecker @ 2012-03-01 15:57 UTC (permalink / raw) To: Kevin Buettner; +Cc: gdb-patches > What do you think? > > Here's an updated patch: > > * sh-tdep.c (sh_frame_cache): Don't fetch the FPSCR register > unless it exists for this architecture. FWIW, I don't know if it is *the* canonical approach (or if there is any), but it seems like a very reasonable one. -- Joel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC] sh-tdep.c: Don't fetch FPSCR register if it doesn't exist 2012-03-01 15:57 ` Joel Brobecker @ 2012-03-01 19:10 ` Kevin Buettner 0 siblings, 0 replies; 10+ messages in thread From: Kevin Buettner @ 2012-03-01 19:10 UTC (permalink / raw) To: gdb-patches On Thu, 1 Mar 2012 07:56:45 -0800 Joel Brobecker <brobecker@adacore.com> wrote: > > What do you think? > > > > Here's an updated patch: > > > > * sh-tdep.c (sh_frame_cache): Don't fetch the FPSCR register > > unless it exists for this architecture. > > FWIW, I don't know if it is *the* canonical approach (or if there is > any), but it seems like a very reasonable one. Thanks for looking it over. I'll go with this approach then, unless there are objections. Kevin ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2012-03-03 1:29 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-03-01 0:34 [RFC] sh-tdep.c: Don't fetch FPSCR register if it doesn't exist Kevin Buettner 2012-03-01 1:33 ` Joel Brobecker 2012-03-01 5:09 ` Kevin Buettner 2012-03-01 10:30 ` Thomas Schwinge 2012-03-01 19:11 ` Kevin Buettner 2012-03-02 9:24 ` Thomas Schwinge 2012-03-02 13:46 ` Kevin Buettner 2012-03-03 1:29 ` Kevin Buettner 2012-03-01 15:57 ` Joel Brobecker 2012-03-01 19:10 ` Kevin Buettner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox