From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13022 invoked by alias); 2 Apr 2004 17:31:37 -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 12941 invoked from network); 2 Apr 2004 17:31:35 -0000 Received: from unknown (HELO esds.vss.fsi.com) (66.136.174.212) by sources.redhat.com with SMTP; 2 Apr 2004 17:31:35 -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 i32HVYW02456; Fri, 2 Apr 2004 11:31:34 -0600 (CST) Received: from localhost (ford@localhost) by thing1.vss.fsi.com (8.11.6+Sun/8.11.6) with ESMTP id i32HVYw23030; Fri, 2 Apr 2004 11:31:34 -0600 (CST) X-Authentication-Warning: thing1-200.fsi.com: ford owned process doing -bs Date: Fri, 02 Apr 2004 17:31:00 -0000 From: Brian Ford X-X-Sender: ford@thing1-200 To: Eli Zaretskii cc: jimb@redhat.com, gdb-patches@sources.redhat.com Subject: Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp) In-Reply-To: <8011-Fri02Apr2004094123+0300-eliz@gnu.org> Message-ID: References: <8011-Fri02Apr2004094123+0300-eliz@gnu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-04/txt/msg00060.txt.bz2 On Fri, 2 Apr 2004, Eli Zaretskii wrote: > On Thu, 1 Apr 2004, Brian Ford wrote: > > On Thu, 1 Apr 2004, Jim Blandy wrote: > > > 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? > > > > This isn't really relevant > > Why not? Well first, it's not really Windows, it's DOS. Secondly, it's pure COFF with a custom loader, as I understand, not PE/COFF. I just don't see any reason to try and be "compatible" with it. I'm not even sure what that means? I certainly don't want to break it, though. > > but DJGPP does. > > That's true: DJGPP does support DWARF2 debug info in COFF object file > format. > > > It appears to me that they use the dbx_register_map for DWARF2. So, > > I don't understand why they don't have the problem my patch was > > trying to address. Actually, I understand why my patch would not even affect them. But, that's a bug, not a feature :-). I don't understand why they don't have even *bigger* problems, though. See the explanation below. > I marked this thread for checking, but never had time to do it. If > you can send me a sample program and a description of what I should do > to see whether DJGPP has the same problem, I will gladly try that and > report the results. Please also tell what versions of GCC and GDB > should I try. > You mean source code, right? You would obviously need a DJGPP toolchain for testing. I don't have one right now. A sample program would be trivial, so you might as well make one yourself. Just throw in some stack variables, preferably some in main, and some in a function called from main. Oh, and make a few of them floating point so you can test that too. As for the gcc/gdb versions, I don't really think it matters much. The only ones I have looked at in detail and expect to contain the bug are gcc 3.4+ and cvs HEAD gdb. Don't let these version numbers get in the way of your test, though. Try whatever you have laying around (if you do have something laying around). Let me try to explain what I think you will find. As I said before, it appears that DJGPP uses the dbx_register_map for DWARF 2 in gcc. Currently, all targets using i386-tdep.c in gdb use the i386_dwarf_reg_to_regnum translation function for DWARF 2. That function corresponds to the svr4_register_map in gcc. i386_stabs_reg_to_regnum is supposed to correspond to the dbx_register_map, but it only does so after my patch. Here are the differences in the two maps: register #'s dbx svr4 esp 5 4 ebp 4 5 fp regs 12-19 11-18 flags -1 9 If gdb can properly find and print the values for variables on the stack and in floating point registers, then DJGPP must have coded around the differences. ie. It must not use the gdb standard numbering scheme like other targets. Also, if you can dump the DWARF 2 information, look for the DW_AT_frame_base attribute. See if that is set to DW_op_reg4, or DW_op_reg5. That should tell you which register number is being used for ebp, and thus which register map was used in gcc. I contend that to use the standard gdb regnums, DJGPP should be using the i386_stabs_reg_to_regnum function (with my patch) for DWARF 2 translations. (I still think those functions should be renamed to dbx and svr4 instead of stabs and dwarf). If DJGPP currently works, then the go32 backend needs to be adjusted as well so it conforms to the gdb standard regnums. There are just too many oportunities for translation here ;-). > > The forward part of my compatability argument is that all known working > > (I still don't understand how DJGPP is working without my patch) i386 targets > > with DWARF2 support use the svr4_register_numbering scheme. So, I was > > trying to go with that precident instead of the one you observed. > > Some time ago I did find a problem in register numbering, and IIRC it > was fixed, although I don't recall the details and don't see anything > in the logs. Perhaps the fix was in GCC rather than GDB. And I don't > remember whether I looked at EBP and ESP back then. > Well, I'd really like to stop talking about DJGPP and start fixing Cygwin ;-). I'd also like to hear Jim's comments about my previous mail. Thanks again. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444