From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15414 invoked by alias); 6 Apr 2006 05:06:54 -0000 Received: (qmail 15405 invoked by uid 22791); 6 Apr 2006 05:06:54 -0000 X-Spam-Check-By: sourceware.org Received: from dsl027-180-168.sfo1.dsl.speakeasy.net (HELO sunset.davemloft.net) (216.27.180.168) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 06 Apr 2006 05:06:49 +0000 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.60) (envelope-from ) id 1FRMhh-0006rC-1W; Wed, 05 Apr 2006 22:06:45 -0700 Date: Thu, 06 Apr 2006 13:15:00 -0000 Message-Id: <20060405.220644.04932953.davem@davemloft.net> To: drow@false.org Cc: mark.kettenis@xs4all.nl, gdb@sources.redhat.com Subject: Re: core regs vs. proc-service regs mess From: "David S. Miller" In-Reply-To: <20060405132258.GA28872@nevyn.them.org> References: <20060405.000621.41243752.davem@davemloft.net> <12186.192.87.1.22.1144225521.squirrel@webmail.xs4all.nl> <20060405132258.GA28872@nevyn.them.org> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00054.txt.bz2 From: Daniel Jacobowitz Date: Wed, 5 Apr 2006 09:23:00 -0400 > On Wed, Apr 05, 2006 at 10:25:21AM +0200, Mark Kettenis wrote: > > > This is completely contradictory, and I don't have any idea how to > > > cleanly resolve this outside of duplicating the entirety of > > > linux_nat_make_corefile_notes() on Linux/Sparc which is silly. > > > > > > Daniel any ideas? :-) Maybe we can have a "linux_tdep" struct where we > > > can place a "->to_fill_core_gregset()" type method or similar? > > > > What really should happen is to convert linux_nat_make_corefile_notes() to > > use the regset_from_core_section() interface. Unfortunately that is quite > > a bit of work since most Linux targets don't provide that interface yet. > > Shouldn't this be pretty simple: gdbarch_regset_from_core_section_p? So something like the following patch? I didn't know what to do with the fpxregset stuff, I guess we'll just have to pick some random string for that? I couldn't find a ELF section name string assigned to that stuff. I tested this patch along with Linux/Sparc regset_from_core_section() support, and it all seems to work fine. --- linux-nat.c.~1~ 2006-04-05 18:08:11.000000000 -0700 +++ linux-nat.c 2006-04-05 18:41:57.000000000 -0700 @@ -36,6 +36,7 @@ #include "gdbthread.h" #include "gdbcmd.h" #include "regcache.h" +#include "regset.h" #include "inf-ptrace.h" #include "auxv.h" #include /* for MAXPATHLEN */ @@ -2529,15 +2530,33 @@ gdb_fpxregset_t fpxregs; #endif unsigned long lwp = ptid_get_lwp (ptid); + struct gdbarch *gdbarch = current_gdbarch; + const struct regset *regset; - fill_gregset (&gregs, -1); + if (gdbarch && gdbarch_regset_from_core_section_p (gdbarch) + && (regset = gdbarch_regset_from_core_section (gdbarch, ".reg", + sizeof gregs)) != NULL) + { + regset->collect_regset (regset, current_regcache, -1, + &gregs, sizeof gregs); + } + else + fill_gregset (&gregs, -1); note_data = (char *) elfcore_write_prstatus (obfd, note_data, note_size, lwp, stop_signal, &gregs); - fill_fpregset (&fpregs, -1); + if (gdbarch && gdbarch_regset_from_core_section_p (gdbarch) + && (regset = gdbarch_regset_from_core_section (gdbarch, ".reg2", + sizeof fpregs)) != NULL) + { + regset->collect_regset (regset, current_regcache, -1, + &fpregs, sizeof fpregs); + } + else + fill_fpregset (&fpregs, -1); note_data = (char *) elfcore_write_prfpreg (obfd, note_data, note_size,