From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32390 invoked by alias); 2 Feb 2003 16:13:14 -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 32089 invoked from network); 2 Feb 2003 16:10:27 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (62.163.169.212) by 172.16.49.205 with SMTP; 2 Feb 2003 16:10:27 -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 h11MZ35k000439; Sat, 1 Feb 2003 23:35:04 +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 h11MZ3CC023845; Sat, 1 Feb 2003 23:35:03 +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 h11MZ30D023842; Sat, 1 Feb 2003 23:35:03 +0100 (CET) Date: Sun, 02 Feb 2003 16:13:00 -0000 Message-Id: <200302012235.h11MZ30D023842@elgar.kettenis.dyndns.org> From: Mark Kettenis To: ac131313@redhat.com CC: drow@mvista.com, gdb@sources.redhat.com In-reply-to: <3E3C3200.8070803@redhat.com> (message from Andrew Cagney on Sat, 01 Feb 2003 15:45:52 -0500) Subject: Re: RFC: Variables in blocks of registers References: <200302011448.h11EmCkP001176@elgar.kettenis.dyndns.org> <3E3BEC50.9040104@redhat.com> <20030201171001.GB29662@nevyn.them.org> <3E3C3200.8070803@redhat.com> X-SW-Source: 2003-02/txt/msg00025.txt.bz2 Date: Sat, 01 Feb 2003 15:45:52 -0500 From: Andrew Cagney > Michael, I think the new multi-arch function is a good idea as long as > it is a fallback from explicit debug info support, when we have such. > I also think it needs a better name; but I'm not quite sure what. Hmm, > that could be mitigated by adequate commenting. I suppose Daniel meant me, Mark, here ;-). I think it is very dangerous. It's assuming a specific algorithm in the compiler. That locks both GDB and GCC into something of a death spiral. I think its far better to try and get a proper location mechanism working. Hmm, I agree that it is better to get a proper location mechanism working. However, I don't think we have any hope at getting such a mechanism working with stabs. And I don't agree that it is very dangerous to assume the specific algorithm that GCC has been using for several years. Besides GDB already uses a specific algorithm since it assumes that registers have been allocated by the compiler in the order that is dictated by GDB's register cache. That algorithm is known to be wrong for the majority of GDB's users, makes GDB print bugus values and can lead to segfaults in the inferior when setting variables. Why not replace this algorithm with something better? The changes that are necessary aren't very invasive (see the end of this message for the changes to findvar.c and valops.c). Daniel, do you think next_allocated_regnum is a better name? Mark Index: findvar.c =================================================================== RCS file: /cvs/src/src/gdb/findvar.c,v retrieving revision 1.44 diff -u -p -r1.44 findvar.c --- findvar.c 14 Jan 2003 00:49:03 -0000 1.44 +++ findvar.c 1 Feb 2003 22:29:45 -0000 @@ -753,17 +753,18 @@ value_from_register (struct type *type, for (local_regnum = regnum; value_bytes_copied < len; (value_bytes_copied += REGISTER_RAW_SIZE (local_regnum), - ++local_regnum)) + local_regnum = gdbarch_next_allocated_regnum (current_gdbarch, + local_regnum))) { + if (local_regnum == -1) + return NULL; /* Register unknown. */ + get_saved_register (value_bytes + value_bytes_copied, - &optim, - &addr, - frame, - local_regnum, + &optim, &addr, frame, local_regnum, &lval); Index: valops.c =================================================================== RCS file: /cvs/src/src/gdb/valops.c,v retrieving revision 1.89 diff -u -p -r1.89 valops.c --- valops.c 30 Jan 2003 16:44:20 -0000 1.89 +++ valops.c 1 Feb 2003 22:29:47 -0000 @@ -704,13 +704,17 @@ value_assign (struct value *toval, struc /* Copy it out. */ for (regno = reg_offset, amount_copied = 0; amount_copied < amount_to_copy; - amount_copied += REGISTER_RAW_SIZE (regno), regno++) + (amount_copied += REGISTER_RAW_SIZE (regno), + regno = gdbarch_next_allocated_regnum (current_gdbarch, regno))) { enum lval_type lval; CORE_ADDR addr; int optim; int realnum; - + + if (regno == -1) + error ("Location of variable is unknown."); + /* Just find out where to put it. */ frame_register (frame, regno, &optim, &lval, &addr, &realnum, NULL);