From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Jacobowitz To: Kevin Buettner Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa/ppc/branch too] Fix PowerPC/Linux cores Date: Mon, 30 Jul 2001 15:54:00 -0000 Message-id: <20010730155455.A3552@nevyn.them.org> References: <20010730142328.A6323@nevyn.them.org> <1010730224404.ZM5571@ocotillo.lan> X-SW-Source: 2001-07/msg00736.html On Mon, Jul 30, 2001 at 03:44:04PM -0700, Kevin Buettner wrote: > 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. :-( Once upon a time... > > 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...) I would go with a warning (), probably - although I suppose internal_error () might be appropriate. > > 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.) The danger in that is that the gdb_*regset_t types mean a lot of different things to a lot of different ports. For all Linux targets, certainly, such a change would be appropriate. I have no idea what other targets it would or wouldn't work for. As I've said, half of the binutils changes for cross core debugging have been checked in, and I'm just cleaning up the other platform-specific bits now. Once I've done that I'm going to tweak (replace?) core-regset.c to not use the sizeof() operator; that's the only thing it does at present which causes it to be native-dependent. After that, the copies in mips-linux-tdep, m68klinux-nat, and maybe now ppc-linux-nat (which are all my fault to some degree) can disappear. My preference would be to use this patch for the moment, given the branch timeframe; while not ideal, it is certainly correct. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer