From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18598 invoked by alias); 1 Apr 2004 18:00:17 -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 18548 invoked from network); 1 Apr 2004 18:00:15 -0000 Received: from unknown (HELO esds.vss.fsi.com) (66.136.174.212) by sources.redhat.com with SMTP; 1 Apr 2004 18:00:15 -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 i31I0FW26638; Thu, 1 Apr 2004 12:00:15 -0600 (CST) Received: from localhost (ford@localhost) by thing1.vss.fsi.com (8.11.6+Sun/8.11.6) with ESMTP id i31I0EG04126; Thu, 1 Apr 2004 12:00:15 -0600 (CST) X-Authentication-Warning: thing1-200.fsi.com: ford owned process doing -bs Date: Thu, 01 Apr 2004 18:00:00 -0000 From: Brian Ford X-X-Sender: ford@thing1-200 To: Jim Blandy cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-04/txt/msg00028.txt.bz2 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]) > The points where they differ are in the numbering of the > floating-point registers, and in numbering %eip and %eflags. And, of course, ebp and esp :). > 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. > $ cat fpregs.c [snip] > In other words, GCC is using the same numbering for floating-point > registers in both formats --- which verifies what we expected from > looking at the code anyway. So we're not crazy. I assume this was all on i?86 Linux? It doesn't use a different numbering scheme. See the previous comment. > So I think the best fix is to have i386-tdep.c use two register number > translation functions that correspond to gcc/config/i386/i386.c's > dbx_register_map and svr4_dbx_register_map, and then register one > function or the other as both the stabs and dwarf 2 translation > functions, as appropriate for a given platform. > No, nothing is broken/wrong other than what I pointed out. You just didn't "get" all the details yet. 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 :-). > The problem is that this affects lots of other targets, which we can't > test. And it assumes that GCC has its register numberings right on > all those targets. I have no idea whether it does. > I've looked at most of them in detail trying to compare differences if it matters. > 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? -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444