From: Daniel Jacobowitz <drow@mvista.com>
To: Jakub Jelinek <jakub@redhat.com>, ac131313@cygnus.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH] Fix sparc-*-linux register fetching/storing
Date: Sat, 10 Nov 2001 16:35:00 -0000 [thread overview]
Message-ID: <20011125115446.A15038@nevyn.them.org> (raw)
In-Reply-To: <20011125113201.C4087@devserv.devel.redhat.com>
On Sun, Nov 25, 2001 at 11:32:01AM -0500, Jakub Jelinek wrote:
> I was fixing what I saw (and the next thing I got hit was a ld bug that
> cleared some .stab values in shared libs, so I had to recompile all shared
> libs).
Ugh. Not my fault, I hope :)
> > > - target_read_memory (*(CORE_ADDR *) & registers[REGISTER_BYTE (SP_REGNUM)],
> > > - ®isters[REGISTER_BYTE (L0_REGNUM)],
> > > + CORE_ADDR sp = *(unsigned int *) & registers[REGISTER_BYTE (SP_REGNUM)];
> > > + target_read_memory (sp, ®isters[REGISTER_BYTE (L0_REGNUM)],
> >
> > How was this going wrong exactly? We don't have any assurance that I
> > can think of that the stack will always be under the 32-bit mark in a
> > true 64-bit userland.
>
> The code in sparc-nat.c is not able to do 64bit userland.
> Solaris I believe uses completely different code, SunOS cannot go 64bit and
> for Linux it would have to use PT_GETREGS64 and the like.
> Actually, Dave Miller and myself used to have a patch for this which made
> gdb work at least a little bit with 64bit binaries, but it was not combo
> 32/64bit gdb which would require far more work (with most complicated stuff
> like solib.c for 32bit and 64bit in the same binary).
>
> > Is the entry in registers[] only four bytes long? If so, it seems that
> > using regcache_collect here is the way to go. For Sparc, which doesn't
> > sign-extend the way MIPS does, collecting four bytes out of the
> > register cache should be fine.
>
> I don't understand how regcache_collect would help here, since the assertion
> REGISTER_RAW_SIZE() == 4 would stay. That's just trading a dereference with
> a memcpy to an int variable.
Well, regcache_collect is the only approved interface to the contents
of registers[] for one thing. It would also prevent the need for the
cast (although you'd have to clear the upper half of the variable
first and make sure to stuff it into the low bytes since we're
big-endian. Ew.).
Andrew? Do we need to have a regcache_collect_core_addr, to sign
extend and shift appropriately for each architecture?
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
next prev parent reply other threads:[~2001-11-25 16:55 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-10 9:20 Jakub Jelinek
2001-11-10 13:03 ` Daniel Jacobowitz
2001-11-10 16:27 ` Jakub Jelinek
2001-11-10 16:35 ` Daniel Jacobowitz [this message]
2001-11-10 16:41 ` Jakub Jelinek
2001-11-10 16:42 ` Daniel Jacobowitz
2001-11-12 10:39 ` Andrew Cagney
2001-11-26 9:18 ` Andrew Cagney
2001-11-26 12:04 ` Daniel Jacobowitz
2001-11-12 18:40 ` Daniel Jacobowitz
2001-11-26 12:34 ` Andrew Cagney
2001-11-12 19:11 ` Andrew Cagney
2001-11-13 8:19 ` Daniel Jacobowitz
2001-11-26 12:43 ` Daniel Jacobowitz
2001-11-26 13:19 ` Andrew Cagney
2001-11-13 8:28 ` Andrew Cagney
2001-11-26 9:08 ` Andrew Cagney
2001-11-12 10:04 ` Andrew Cagney
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=20011125115446.A15038@nevyn.them.org \
--to=drow@mvista.com \
--cc=ac131313@cygnus.com \
--cc=gdb-patches@sources.redhat.com \
--cc=jakub@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