From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26095 invoked by alias); 19 Apr 2004 16:21:39 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 26040 invoked from network); 19 Apr 2004 16:21:37 -0000 Received: from unknown (HELO esds.vss.fsi.com) (66.136.174.212) by sources.redhat.com with SMTP; 19 Apr 2004 16:21:37 -0000 Received: from thing1.vss.fsi.com (thing1.vss.fsi.com [198.51.29.21]) by esds.vss.fsi.com (8.11.6+Sun/8.9.1) with ESMTP id i3JGLad10729; Mon, 19 Apr 2004 11:21:36 -0500 (CDT) Received: from localhost (ford@localhost) by thing1.vss.fsi.com (8.11.6+Sun/8.11.6) with ESMTP id i3JGLZq23746; Mon, 19 Apr 2004 11:21:35 -0500 (CDT) X-Authentication-Warning: thing1-200.fsi.com: ford owned process doing -bs Date: Mon, 19 Apr 2004 16:21:00 -0000 From: Brian Ford X-X-Sender: ford@thing1-200 To: Eli Zaretskii cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] Proper _to_regnum for DWARF on Cygwin In-Reply-To: Message-ID: References: <200404161650.i3GGoPxI054716@elgar.kettenis.dyndns.org> <200404181838.i3IIccMf006115@elgar.kettenis.dyndns.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-04/txt/msg00426.txt.bz2 On Mon, 19 Apr 2004, Eli Zaretskii wrote: > On Sun, 18 Apr 2004 20:38:38 +0200 (CEST) Mark Kettenis wrote: > >> + /* We typically use DWARF-in-COFF with the dbx register numbering. */ >> + set_gdbarch_dwarf_reg_to_regnum (gdbarch, i386_dbx_reg_to_regnum); >> + set_gdbarch_dwarf2_reg_to_regnum (gdbarch, i386_dbx_reg_to_regnum); > > Mark, doesn't this code above from i386_coff_init_abi contradict the > code further down (and the register mapping used by GCC), viz: It does contradict the code further down by design, but not the proposed DWARF register numbering for Cygwin, which is currently the only target to call this function. When this patch was written, it was assumed based on the vanilla FSF GCC sources, that DJGPP would need the same functionality. Thus the generic function name, but now we know better. I'm seriously considering reverting that change. I believe my original gut feeling was correct before Jim Blandy convinced me otherwise. Comments before I post the patch to do so? > > + /* Use the SVR4 register numbering scheme for DWARF and DWARF 2. */ > > + set_gdbarch_dwarf_reg_to_regnum (gdbarch, i386_svr4_reg_to_regnum); > > + set_gdbarch_dwarf2_reg_to_regnum (gdbarch, i386_svr4_reg_to_regnum); > > ? For DJGPP, at least, DWARF2-in-COFF uses i386_svr4_reg_to_regnum > register mapping, not i386_dbx_reg_to_regnum. Am I missing something > here? Nope, we were missing the DJGPP specific GCC patch you listed below. Don't worry, nothing has been broken regardless. [snip typo comment] > > + Currently, each GCC i386 target always uses the same register > > + numbering scheme across all its supported debugging formats > > + i.e. SDB (COFF), stabs and DWARF 2. This is because > > + gcc/sdbout.c, gcc/dbxout.c and gcc/dwarf2out.c all use the > > + DBX_REGISTER_NUMBER macro which is defined by each target's > > + respective config header in a manner independent of the requested > > + output debugging format. > > As the following fragment (already posted here yesterday) from > gcc/config/i386/djgpp.h shows, both of these assertions are not true > for the DJGPP target: > > #undef DBX_REGISTER_NUMBER > #define DBX_REGISTER_NUMBER(n) \ > ((write_symbols == DWARF2_DEBUG) ? svr4_dbx_register_map[n] : dbx_register_map[n]) But we had no way of knowing that ;-). > Also, in this old message: > > http://sources.redhat.com/ml/gdb/2001-07/msg00398.html > > you pointed out to me that: > > Several GCC targets redefine DBX_REGISTER_NUMBER, see for example > linux.h in that same directory [gcc/config/i386/]. Yes, but they all follow: > > + DBX_REGISTER_NUMBER macro which is defined by each target's > > + respective config header in a manner independent of the requested > > + output debugging format. > > So gcc/*out.c files are clearly not the whole story here (unless > things have changed in GCC since then; I cannot check this easily > where I'm typing this). True. They are not the *whole* story, but it was assumed that examining all those config files mentioned above was the *relevant* part of the story. > The upshot of all this is that either (a) I'm still confused by the > issues involved, or (b) the comments and, possibly, the code need to > be amended to clarify/fix that. a, the comment part of b, and I'm now convinced the code part of b should be reverted for Cygwin. I'll post a patch soon. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444