This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc 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]

Re: ptrace for mips n32 and n64


On Fri, Mar 14, 2003 at 09:14:41AM -0700, Kevin Buettner wrote:
> On Mar 14, 10:46am, Daniel Jacobowitz wrote:
> 
> > On Fri, Mar 14, 2003 at 12:39:29PM -0300, Alexandre Oliva wrote:
> > > On Mar 14, 2003, Daniel Jacobowitz <drow at mvista dot com> wrote:
> > > 
> > > > On Fri, Mar 14, 2003 at 11:35:42AM -0300, Alexandre Oliva wrote:
> > > >> Yay.  Lots of code duplication.  I'm sure Uli will love this patch.
> > > >> :-/ Ok?  (the point being that ptrace must take as argument and return
> > > >> 64-bit values on n32)
> > > 
> > > > Why must it?
> > > 
> > > Because that's the ABI defined by the kernel, as much as I dislike
> > > it.  Of course, glibc could adapt the interface and return longs even
> > > though the kernel gives it a long long, and pass a long long where it
> > > gets just a long.  I don't know much about the interface of ptrace,
> > > anyway.  I just did what Kevin told me he needed for his debugging
> > > code to work.
> > 
> > Kevin, mind enlightening me?  I don't see how this works, either in
> > principle or with the mips64-linux port as contributed to GDB.
> 
> It works in RDA.  I haven't spent much time on getting a native
> GDB going.  The mips64 linux specific changes that I've contributed
> for GDB were largely to get core file support working.
> 
> Anyway, for n32, ptrace() needs 64 bit arguments and return values
> because of the need to fetch and store 64-bit registers.  If we want
> to transfer only 32-bit values, then the register numbers associated
> with PTRACE_PEEKUSER / PTRACE_POKEUSER will have to change.  (Recall
> that MIPS uses 0,1,2,...,31 for r0 thru r31.)

Ach, I forgot about PEEKUSER/POKEUSER, how'd I do that?  I must be
spoiled by architectures with GETREGS.  Do we need to be able to use
PEEKUSER/POKEUSER at all in the presence of the more efficient regset
variants?

Passing pointers into the kernel as 64-bit quantities on n32 just
doesn't seem like a good idea.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]