Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Kris Kennaway <kris@obsecurity.org>
To: Marcel Moolenaar <marcel@xcllnt.net>
Cc: Mark Kettenis <kettenis@chello.nl>,
	freebsd-hackers@freebsd.org, tech-toolchain@netbsd.org,
	gdb-patches@sources.redhat.com
Subject: Re: [PATCH/RFC] *BSD kernel debugging
Date: Tue, 18 May 2004 01:20:00 -0000	[thread overview]
Message-ID: <20040518012043.GA47770@xor.obsecurity.org> (raw)
In-Reply-To: <20040517221703.GB67833@ns1.xcllnt.net>

On Mon, May 17, 2004 at 03:17:03PM -0700, Marcel Moolenaar wrote:
> On Mon, May 17, 2004 at 10:45:39PM +0200, Mark Kettenis wrote:
> > 
> >    I cannot prevent you from committing this, but if it doesn't address
> >    the items mentioned above, it may not be used on FreeBSD.  Unless I'm
> >    being relieved of gdb duties of course :-)
> > 
> > Let's see.  My kvm stuff would still serve a purpose for older
> > releases.
> 
> [still about FreeBSD] Yes, to certain extend. There's already a port
> for gdb6 in the ports collection and I presume it also works on
> FreeBSD 4.x. Nonetheless, I like having gdb work without local hacks,
> so from that perspective it's definitely valuable.

Actually no version of gdb in the ports collection works on 4.x.  Some
don't even work on 5.x.

Kris
Attachment:
pgp00000.pgp
Description: PGP signature

-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)

iD8DBQFAqWTrWry0BWjoQKURAtDxAKDlU+7DwuYaDh43dq4GFdERiJRifgCg281q
ZgougBprTK6UTqMSAi13DqE=
=WMbH
-----END PGP SIGNATURE-----
From jimb@redhat.com Tue May 18 01:26:00 2004
From: Jim Blandy <jimb@redhat.com>
To: gdb-patches@sources.redhat.com
Subject: RFA: reorder initializations in rs6000_gdbarch_init
Date: Tue, 18 May 2004 01:26:00 -0000
Message-id: <vt265au8r7p.fsf@zenia.home>
X-SW-Source: 2004-05/msg00520.html
Content-length: 4221

The current code leaves some fields of the tdep structure
uninitialized until the per-mach switch, and then leaves it up to each
case to remember to initialize everything.

This changes the code to initialize everything to neutral values, and
then let each case override the values that are inappropriate.

This fixes the fact that the bfd_mach_ppc_e500 case leaves
ppc_ev0_regnum and ppc_ev31_regnum uninitialized, although I don't
know that that causes any actual misbehavior.  The real motivation is
that it clears the way for the e500 code to override the register
offsets.

2004-05-17  Jim Blandy  <jimb@redhat.com>

	* rs6000-tdep.c (rs6000_gdbarch_init): Initialize tdep fields
	before the mach-specific switch, and then let the individual cases
	override the defaults, rather than leaving them uninitialized
	until the switch and then setting them in each case.

Index: gdb/rs6000-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/rs6000-tdep.c,v
retrieving revision 1.205
diff -c -p -r1.205 rs6000-tdep.c
*** gdb/rs6000-tdep.c	15 May 2004 05:57:16 -0000	1.205
--- gdb/rs6000-tdep.c	17 May 2004 21:49:54 -0000
*************** rs6000_gdbarch_init (struct gdbarch_info
*** 2821,2826 ****
--- 2821,2830 ----
      tdep->ppc_mq_regnum = -1;
    tdep->ppc_fp0_regnum = 32;
    tdep->ppc_fpscr_regnum = power ? 71 : 70;
+   tdep->ppc_vr0_regnum = -1;
+   tdep->ppc_vrsave_regnum = -1;
+   tdep->ppc_ev0_regnum = -1;
+   tdep->ppc_ev31_regnum = -1;
  
    set_gdbarch_pc_regnum (gdbarch, 64);
    set_gdbarch_sp_regnum (gdbarch, 1);
*************** rs6000_gdbarch_init (struct gdbarch_info
*** 2835,2854 ****
        set_gdbarch_deprecated_store_return_value (gdbarch, rs6000_store_return_value);
      }
  
    if (v->arch == bfd_arch_powerpc)
      switch (v->mach)
        {
        case bfd_mach_ppc: 
  	tdep->ppc_vr0_regnum = 71;
  	tdep->ppc_vrsave_regnum = 104;
- 	tdep->ppc_ev0_regnum = -1;
- 	tdep->ppc_ev31_regnum = -1;
  	break;
        case bfd_mach_ppc_7400:
  	tdep->ppc_vr0_regnum = 119;
  	tdep->ppc_vrsave_regnum = 152;
- 	tdep->ppc_ev0_regnum = -1;
- 	tdep->ppc_ev31_regnum = -1;
  	break;
        case bfd_mach_ppc_e500:
          tdep->ppc_gp0_regnum = 41;
--- 2839,2870 ----
        set_gdbarch_deprecated_store_return_value (gdbarch, rs6000_store_return_value);
      }
  
+   /* Set lr_frame_offset.  */
+   if (wordsize == 8)
+     tdep->lr_frame_offset = 16;
+   else if (sysv_abi)
+     tdep->lr_frame_offset = 4;
+   else
+     tdep->lr_frame_offset = 8;
+ 
+   /* Calculate byte offsets in raw register array.  */
+   tdep->regoff = xmalloc (v->num_tot_regs * sizeof (int));
+   for (i = off = 0; i < v->num_tot_regs; i++)
+     {
+       tdep->regoff[i] = off;
+       off += regsize (v->regs + i, wordsize);
+     }
+ 
    if (v->arch == bfd_arch_powerpc)
      switch (v->mach)
        {
        case bfd_mach_ppc: 
  	tdep->ppc_vr0_regnum = 71;
  	tdep->ppc_vrsave_regnum = 104;
  	break;
        case bfd_mach_ppc_7400:
  	tdep->ppc_vr0_regnum = 119;
  	tdep->ppc_vrsave_regnum = 152;
  	break;
        case bfd_mach_ppc_e500:
          tdep->ppc_gp0_regnum = 41;
*************** rs6000_gdbarch_init (struct gdbarch_info
*** 2868,2899 ****
          set_gdbarch_pseudo_register_read (gdbarch, e500_pseudo_register_read);
          set_gdbarch_pseudo_register_write (gdbarch, e500_pseudo_register_write);
  	break;
-       default:
- 	tdep->ppc_vr0_regnum = -1;
- 	tdep->ppc_vrsave_regnum = -1;
- 	tdep->ppc_ev0_regnum = -1;
- 	tdep->ppc_ev31_regnum = -1;
- 	break;
        }   
  
    /* Sanity check on registers.  */
    gdb_assert (strcmp (tdep->regs[tdep->ppc_gp0_regnum].name, "r0") == 0);
- 
-   /* Set lr_frame_offset.  */
-   if (wordsize == 8)
-     tdep->lr_frame_offset = 16;
-   else if (sysv_abi)
-     tdep->lr_frame_offset = 4;
-   else
-     tdep->lr_frame_offset = 8;
- 
-   /* Calculate byte offsets in raw register array.  */
-   tdep->regoff = xmalloc (v->num_tot_regs * sizeof (int));
-   for (i = off = 0; i < v->num_tot_regs; i++)
-     {
-       tdep->regoff[i] = off;
-       off += regsize (v->regs + i, wordsize);
-     }
  
    /* Select instruction printer.  */
    if (arch == power)
--- 2884,2893 ----


  reply	other threads:[~2004-05-18  1:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-17 11:32 Mark Kettenis
2004-05-17 20:04 ` Marcel Moolenaar
     [not found]   ` <200405172045.i4HKjd4k014106@elgar.kettenis.dyndns.org>
2004-05-17 22:17     ` Marcel Moolenaar
2004-05-18  1:20       ` Kris Kennaway [this message]
     [not found] ` <40A9172B.9000300@gnu.org>
2004-05-17 21:05   ` Mark Kettenis

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=20040518012043.GA47770@xor.obsecurity.org \
    --to=kris@obsecurity.org \
    --cc=freebsd-hackers@freebsd.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=kettenis@chello.nl \
    --cc=marcel@xcllnt.net \
    --cc=tech-toolchain@netbsd.org \
    /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