This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfa/ppc/branch too] Fix PowerPC/Linux cores
- To: Daniel Jacobowitz <drow at mvista dot com>, gdb-patches at sources dot redhat dot com
- Subject: Re: [rfa/ppc/branch too] Fix PowerPC/Linux cores
- From: Kevin Buettner <kevinb at cygnus dot com>
- Date: Mon, 30 Jul 2001 15:44:04 -0700
- References: <20010730142328.A6323@nevyn.them.org>
On Jul 30, 2:23pm, Daniel Jacobowitz wrote:
> I figure it would be nice if core files for Linux/PPC worked on the branch.
It would be nice. It even used to work. :-(
> Linux/PPC doesn't have gregset_t or fpregset_t in its headers, so the body
> of fetch_core_registers in core-regset.c gets #if'd out by autoconf. Cores
> load but are absolutely useless. I have the feeling those #if's ought to be
> outside the function rather than inside...
You may be right. The other alternative that occurs to me is to put
a #else branch in with a call to internal_error(). (It's a choice
between not linking vs. not running and it's not clear which way the
tradeoff should go. Personally, when I'm doing a new baseport, I'd
rather have it link with the understanding that the functionality may
be limited...)
> but in any case, for now, this
> patch fixes it the same way most other Linux targets do. I'll get back to
> my rework of core support in the next few weeks now that we've branched.
>
> OK to commit, trunk and branch?
I think I'd like to explore some alternatives first. The only
real difference that I see between the version of fetch_core_registers()
that you want to add to ppc-linux-nat.c and the one in core-regset.c is
that the former uses elf_{g,fp}regset_t whereas the latter uses
{g,fp}regset_t, right?
If that's the case, couldn't we simply make the core-regset.c version
use gdb_gregset_t and gdb_fpgregset_t? That seems cleaner to me than
propagating nearly identical copies of fetch_core_registers() to the
various *-nat.c files. (I see that mips-linux-tdep.c and
m68klinux-nat.c have taken the approach that you're suggesting;
i386-linux-nat.c has a good excuse for having its own version since
the format that it needs to support can't be handled by the generic
code.)