From: Kevin Buettner <kevinb@redhat.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] Add support for 64-bit MIPS GNU/Linux targets
Date: Mon, 23 Dec 2002 22:37:00 -0000 [thread overview]
Message-ID: <1021224062810.ZM26995@localhost.localdomain> (raw)
In-Reply-To: Daniel Jacobowitz <drow@mvista.com> "Re: [RFA] Add support for 64-bit MIPS GNU/Linux targets" (Dec 23, 6:56pm)
On Dec 23, 6:56pm, Daniel Jacobowitz wrote:
> > @@ -95,15 +109,15 @@ supply_gregset (elf_gregset_t *gregsetp)
> > memset (zerobuf, 0, MAX_REGISTER_RAW_SIZE);
> >
> > for (regi = EF_REG0; regi <= EF_REG31; regi++)
> > - supply_register ((regi - EF_REG0), (char *)(regp + regi));
> > + supply_32bit_reg ((regi - EF_REG0), (char *)(regp + regi));
> >
> > - supply_register (LO_REGNUM, (char *)(regp + EF_LO));
> > - supply_register (HI_REGNUM, (char *)(regp + EF_HI));
> > + supply_32bit_reg (LO_REGNUM, (char *)(regp + EF_LO));
> > + supply_32bit_reg (HI_REGNUM, (char *)(regp + EF_HI));
> >
> > - supply_register (PC_REGNUM, (char *)(regp + EF_CP0_EPC));
> > - supply_register (BADVADDR_REGNUM, (char *)(regp + EF_CP0_BADVADDR));
> > - supply_register (PS_REGNUM, (char *)(regp + EF_CP0_STATUS));
> > - supply_register (CAUSE_REGNUM, (char *)(regp + EF_CP0_CAUSE));
> > + supply_32bit_reg (PC_REGNUM, (char *)(regp + EF_CP0_EPC));
> > + supply_32bit_reg (BADVADDR_REGNUM, (char *)(regp + EF_CP0_BADVADDR));
> > + supply_32bit_reg (PS_REGNUM, (char *)(regp + EF_CP0_STATUS));
> > + supply_32bit_reg (CAUSE_REGNUM, (char *)(regp + EF_CP0_CAUSE));
> >
> > /* Fill inaccessible registers with zero. */
> > supply_register (UNUSED_REGNUM, zerobuf);
>
> Correct me if I'm wrong, but native thread debugging isn't going to
> work if you do this. proc-service.c calls supply_gregset directly and
> everything blows up.
True, but see below.
> Is it time to multiarch supply_gregset?
Maybe.
I've given this some thought and it seems to me that if we're going to
multiarch supply_gregset, we'll have to change its prototype; basically,
we'll have to pass gregsetp around as a void *. I'm not against this,
but I think it needs to be discussed first. (Also, either the regset
size or perhaps an allocation function will need to be provided using
a multiarch method.)
There are several other problems with native thread support on Linux/MIPS:
1) For o32, the core gregset layout is incompatible with that used for
threads. (The sizes of the arrays and the layouts are different.)
Hopefully this won't be a problem for n32 and n64.
2) There are actually three libthread_db.so libraries, one each for
o32, n32, and n64. Yet the gdb binary will (obviously) use only
one of these ABIs. It's not possible to dlopen() a library of
a differing ABI, which (unfortunately) means that a given gdb
binary can only provide thread support for only one ABI.
There are, of course, several technical options open to us to
work around this difficulty. One approach is to arrange for
each of these libraries to be built to use the ABI that gdb uses,
yet still know the details about the target ABI. Another is to
somehow combine the knowledge concerning the three ABIs into a
single libthread_db.so library. There may be other approaches
too, but at the moment, I don't think any of these solutions
will be trivial to implement (though some are clearly easier than
others).
Anyway, given all of the above it seems to me that native thread support
for Linux/MIPS which supports all three ABIs is quite a ways off.
[...]
> So:
> supply_gregset?
> GDBSERVER_DEPFILES nit
> tm-linux64 nit
>
> Otherwise, this is OK.
Thanks for the quick (but thorough) patch review!
I'll fix the GDBSERVER_DEPFILES and tm-linux64 nits, but the
supply_gregset issue will require further discussion. In the interim,
how would you like to proceed?
Kevin
next prev parent reply other threads:[~2002-12-24 6:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-23 15:07 Kevin Buettner
2002-12-23 16:01 ` Daniel Jacobowitz
2002-12-23 22:37 ` Kevin Buettner [this message]
2002-12-24 9:25 ` Daniel Jacobowitz
2002-12-24 11:37 ` Kevin Buettner
2002-12-24 12:09 ` Daniel Jacobowitz
2002-12-24 19:25 ` Kevin Buettner
2003-01-07 0:26 ` Andrew Cagney
2003-01-07 23:16 ` Daniel Jacobowitz
2003-01-08 0:00 ` 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=1021224062810.ZM26995@localhost.localdomain \
--to=kevinb@redhat.com \
--cc=drow@mvista.com \
--cc=gdb-patches@sources.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