From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18302 invoked by alias); 1 Apr 2004 21:29:19 -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 18293 invoked from network); 1 Apr 2004 21:29:17 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 1 Apr 2004 21:29:17 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i31LTGjj013940 for ; Thu, 1 Apr 2004 16:29:16 -0500 Received: from zenia.home.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i31LTEj23804; Thu, 1 Apr 2004 16:29:14 -0500 To: Brian Ford Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp) References: From: Jim Blandy Date: Thu, 01 Apr 2004 21:29:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-04/txt/msg00041.txt.bz2 Brian Ford writes: > On Thu, 1 Apr 2004, Jim Blandy wrote: > > > Brian Ford writes: > > > Notice that gcc regno 6 (ebp) and 7 (esp) map to regno 4 and 5 > > > respectively in the "default" (aka dbx, stabs, sdb) table. But, in > > > the svr4 (aka dwarf, dwarf2, stabs-in-elf) table, they map to regno 5 and > > > 4 respectively. > > > > > > I'm not sure if/how this should affect i386_register_names. I also hope > > > that targets have not already coded around this bug so that fixing it will > > > break something else :-). Please do have a look at these issues before > > > applying the patch. I'm afraid they are over my head right now. > > > > Yeah, wow. So, one thing that surprised me is that, for any given > > platform, GCC always uses the same register numbering in STABS and > > Dwarf 2 --- gcc/dwarf2out.c and gcc/dbxout.c both use > > DBX_REGISTER_NUMBER. But if that's so, why does gdb/i386-tdep.c have > > two separate (and different!) STABS and Dwarf register number > > functions? > > Actually, that's not true. In fact, that is how I'm planning on fixing > my/our original problem :^). In gcc/config/i386/cygming.h: > > #undef DBX_REGISTER_NUMBER > #define DBX_REGISTER_NUMBER(n) (write_symbols == DWARF2_DEBUG \ > ? svr4_dbx_register_map[n] \ > : dbx_register_map[n]) Aside from the one you're introducing here, the only other target/platform where Dwarf and STABS have different register numberings is the rs6000. Of the 33 other #definitions of DBX_REGISTER_NUMBER in the tree, none of them make this distinction. On all i386-based platforms, the numbering is the same, as far as I can see from the GCC sources. > > But it doesn't look to me as if Dwarf and STABS actually do differ in > > the numbering of floating-point registers: > > That depends on the target ;-). And, it is the reason why gdb/i386-tdep.c > (i386_elf_init_abi) exists. > > I chose the fix above to preserve forward and backward > compatibility. Sorry --- is there an existing toolchain using Dwarf 2 on Windows? If not, then what existing tools, already in use by others, are you being forward and backward compatible with? I thought we were the first people to put Dwarf 2 in COFF at all. If that's the case, we get to choose the numbering as best makes sense. And it seems to me there's pretty clear precedent for using the same numbering in both STABS and Dwarf. > BTW, I didn't mention it to avoid confusion, but there is also a > dbx64_register_map. It is unconditionally used in 64 bit mode by > all targets that support it for all debug formats. I don't see how > gdb handles that at all, but I didn't care that much since Cygwin > doesn't currently support 64 bit mode :-). It's the AMD x86_64 stuff. Yes, it's not relevant to us here. > > Having said all that, I'd guess the right immediate fix is to register > > an osabi handler for GDB_OSABI_CYGWIN, down at the bottom of > > gdb/i386-tdep.c:_initialize_i386_tdep, that plugs in the right > > gdbarch_dwarf2_reg_to_regnum function for Cygwin. And leave the > > existing _to_regnum functions unchanged. > > > I disagree. Has your opinion changed now? I don't yet understand what you're preserving compatibility with. If there are extant toolchains we need to match, then that's definitely important. But it's my understanding that we're breaking new ground here; if that's so, we should break that ground consistently with existing GNU toolchain targets.