Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@mvista.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Mark Kettenis <kettenis@wins.uva.nl>, gdb@sources.redhat.com
Subject: Re: Fixing Linux/SPARC
Date: Wed, 07 Nov 2001 16:06:00 -0000	[thread overview]
Message-ID: <20011117152046.A23292@nevyn.them.org> (raw)
In-Reply-To: <3BF6B812.1080102@cygnus.com>

On Sat, Nov 17, 2001 at 02:18:42PM -0500, Andrew Cagney wrote:
> >On Wed, Oct 17, 2001 at 04:07:52PM +0200, Mark Kettenis wrote:
> >
> >>Hi Dan & other interested folks,
> >>
> >>Something like the code below (completely untested, probably doesn't
> >>even compile) is needed to fix Linux/SPARC.
> >
> >
> >Compiles, after fixing the obvious typos.  I'm going to commit it to
> >the mainline as obvious, since it takes Linux/SPARC from not-building
> >to building; test results are abysmal, though.  It looks as if we can't
> >figure out the memory location variables are stored at correctly. 
> >They're being accessed in the unmapped 0x90000000 segment instead of
> >0x70000000, and not even at the right offsets.  I'll look in to it more
> >later.
> 
> Dan, can you please replace the calls to read_register_gen() with 
> regcache_collect().

Done.

Threads don't work on Sparc still, because prgregset_t is much smaller
than an elf_gregset_t, so we corrupt memory in thread_db_fetch_registers.
You know by now what my opinion of this problem is :)

It appears that, for Sparc at least, this was fixed on:
2000-03-21  Jakub Jelinek  <jakub@redhat.com>

My Sparc test machine runs a glibc older than that.  I'd like to to
come up with some autoconf test to either not compile at all when this
bug is present, disable thread support, or compile in some hack to make
the type the right size.  Any objection?

Actually, gross as it may be, something like this in thread-db.c ought
to do the trick:
union big_enough_gregset_t {
  prgregset_t p;
  gdb_gregset_t g;
};

and replacing uses of the prgregset with uses of big_enough_gregset_t.p
should fix the warnings without any autoconf checks.  How's that sound?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

2001-11-17  Daniel Jacobowitz  <drow@mvista.com>

        * sparc-linux-nat.c (fill_gregset): Replace read_register_gen
        with regcache_collect.
        (fill_fpregset): Likewise.

Index: sparc-linux-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/sparc-linux-nat.c,v
retrieving revision 1.1
diff -u -p -r1.1 sparc-linux-nat.c
--- sparc-linux-nat.c	2001/11/17 18:38:29	1.1
+++ sparc-linux-nat.c	2001/11/17 20:18:40
@@ -56,22 +56,22 @@ fill_gregset (elf_gregset_t *gregsetp, i
 
   for (i = G0_REGNUM; i <= I7_REGNUM; i++)
     if (regno == -1 || regno == i)
-      read_register_gen (i, (char *) (regp + (i - G0_REGNUM)));
+      regcache_collect (i, regp + (i - G0_REGNUM));
 
   if (regno == -1 || regno == PS_REGNUM)
-    read_register_gen (PS_REGNUM, (char *) (regp + 32));
+    regcache_collect (PS_REGNUM, regp + 32);
 
   if (regno == -1 || regno == PC_REGNUM)
-    read_register_gen (PC_REGNUM, (char *) (regp + 33));
+    regcache_collect (PC_REGNUM, regp + 33);
   if (regno == -1 || regno == NPC_REGNUM)
-    read_register_gen (NPC_REGNUM, (char *) (regp + 34));
+    regcache_collect (NPC_REGNUM, regp + 34);
   if (regno == -1 || regno == Y_REGNUM)
-    read_register_gen (Y_REGNUM, (char *) (regp + 35));
+    regcache_collect (Y_REGNUM, regp + 35);
 
   if (regno == -1 || regno == WIM_REGNUM)
-    read_register_gen (WIM_REGNUM, (char *) (regp + 36));
+    regcache_collect (WIM_REGNUM, regp + 36);
   if (regno == -1 || regno == TBR_REGNUM)
-    read_register_gen (TBR_REGNUM, (char *) (regp + 37));
+    regcache_collect (TBR_REGNUM, regp + 37);
 }
 
 void
@@ -92,8 +92,8 @@ fill_fpregset (elf_fpregset_t *fpregsetp
 
   for (i = FP0_REGNUM; i < FP0_REGNUM + 32; i++)
     if (regno == -1 || regno == i)
-      read_register_gen (i, (char *) &fpregsetp->pr_fr.pr_regs[i - FP0_REGNUM]);
+      regcache_collect (i, &fpregsetp->pr_fr.pr_regs[i - FP0_REGNUM]);
 
   if (regno == -1 || regno == FPS_REGNUM)
-    read_register_gen (FPS_REGNUM, (char *) &fpregsetp->pr_fsr);
+    regcache_collect (FPS_REGNUM, &fpregsetp->pr_fsr);
 }


      reply	other threads:[~2001-11-17 20:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-17  7:08 Mark Kettenis
2001-11-07  7:12 ` Daniel Jacobowitz
2001-11-07  9:22   ` Andrew Cagney
2001-11-07 16:06     ` Daniel Jacobowitz [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=20011117152046.A23292@nevyn.them.org \
    --to=drow@mvista.com \
    --cc=ac131313@cygnus.com \
    --cc=gdb@sources.redhat.com \
    --cc=kettenis@wins.uva.nl \
    /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