From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6516 invoked by alias); 1 Mar 2003 22:38:57 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 6507 invoked from network); 1 Mar 2003 22:38:55 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (62.163.169.212) by 172.16.49.205 with SMTP; 1 Mar 2003 22:38:55 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6/8.12.5) with ESMTP id h21McjUb000453; Sat, 1 Mar 2003 23:38:45 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6/8.12.6) with ESMTP id h21McjVZ035374; Sat, 1 Mar 2003 23:38:45 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6/8.12.6/Submit) id h21Mcim9035371; Sat, 1 Mar 2003 23:38:44 +0100 (CET) Date: Sat, 01 Mar 2003 22:38:00 -0000 Message-Id: <200303012238.h21Mcim9035371@elgar.kettenis.dyndns.org> From: Mark Kettenis To: brobecker@gnat.com CC: mec@shout.net, gdb@sources.redhat.com In-reply-to: <20030301190929.GF11181@gnat.com> (message from Joel Brobecker on Sat, 1 Mar 2003 11:09:29 -0800) Subject: Re: 8-byte register values on a 32-bit machine References: <200302240235.h1O2Zws05373@duracef.shout.net> <864r6n5hw2.fsf@elgar.kettenis.dyndns.org> <20030301190929.GF11181@gnat.com> X-SW-Source: 2003-03/txt/msg00012.txt.bz2 Date: Sat, 1 Mar 2003 11:09:29 -0800 From: Joel Brobecker > Yup, that's defenitely what it does for stabs, and from looking at the > code, it does it for other debug formats as well (including dwarf-2). > Right now, GDB interprets this as that the variable is stored in > consecutive registers starting at the register number indicated by the > debug info. I have a strong suspicion that there are several GDB > targets that rely on this behaviour. However, it isn't working for > the i386 since GCC allocates the registers in an order that's > different from the order that GDB uses. What I have seen as well is GCC an 8 bytes structure over 2 registers (2 fields of 4 bytes, one field on each register). The first register used (and specified in the stabs info) was %ebx, and the next one was sort of consecutive. It was %esi. The only thing is that there are two special registers in the middle (%esp, and %ebp) :-). Yup, GCC allocates %esi after %ebx. By the way, the fact that GDB "thinks" that %esp follows %ebx makes things very interesting if you happen to modify the last 4 bytes of said structure. This will make GDB modify the stack pointer, which most likely makes your program blow up. Because of this, even if we modified GCC to allocate the registers in the same order as the GDB order (or modify the GDB order, if that's possible), we'll still have situations where this is not going to work. Modifying GCC probably wouldn't be a good idea. The order on which GCC allocates the registers seems to be chosen such that it generates optimized code. Modifying the GDB order isn't possible (yet) because of the remote protocol. I think we've lost the stabs battle. Actually, the order in which GCC allocates its registers has been the same for many years (at least since GCC 2.6.3 which was released in 1994). We only need to teach GDB this order in order to make GCC do the right thing for code generated by any version of GCC that's still in wide use. I posted a preliminary patch that does this early februari. If we're concerned about aother compilers than GCC, we can probably tweak things that we only use the heuristics in my patch when the code was compiled by GCC. So I started to look into the DWARF2 format, but could not find anything that helps. Does anybody know if this format supports this sort of situation? The idea was that DWARF2 location expressions could help. I believe GCC should emit location descriptors that are concatenation of locations, just like it already does for complex variables. Mark