This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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:
pgp00000.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |