From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27535 invoked by alias); 1 Feb 2003 14:48:15 -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 27236 invoked from network); 1 Feb 2003 14:48:14 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (62.163.169.212) by 172.16.49.205 with SMTP; 1 Feb 2003 14:48:14 -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 h11EmDx6000602 for ; Sat, 1 Feb 2003 15:48:13 +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 h11EmCuj001179 for ; Sat, 1 Feb 2003 15:48:12 +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 h11EmCkP001176; Sat, 1 Feb 2003 15:48:12 +0100 (CET) Date: Sat, 01 Feb 2003 14:48:00 -0000 Message-Id: <200302011448.h11EmCkP001176@elgar.kettenis.dyndns.org> From: Mark Kettenis To: gdb@sources.redhat.com Subject: RFC: Variables in blocks of registers X-SW-Source: 2003-02/txt/msg00007.txt.bz2 On my i386-unknown-freebsd4.7 system, various tests in gdb.base/store.exp fail. The reason is related to the problem described in tdep/214; register variables that don't fit in a single variable. GDB assumes that such variables are stored in consecutive registers (according to its own register numbering scheme), which defenitely isn't what GCC uses on the i386. I'm looking into the suggestion Daniel made in tdep/214; teaching GDB about the order in which GCC allocates registers. There are several caveats though: * While GCC allocates its registers in a particular order right now, and always allocates blocks of consecutive registers, there is no guarantee that it will continue to do so. * I have no idea what other compilers do. If GDB's register numbering was chosen to match for example the System V compiler, teaching GDB GCC's register ordering will cause regressions on system that use it. We might play tricks with gcc_compiled of course. Since AFAIK GDB's internal register ordering is still not decoupled from the remote interface, I propose to add a new multi-arch function "next_regnum" which returns the next register to look in based on the register number passed to it as an argument. Comments? Mark