From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15063 invoked by alias); 1 Jul 2003 21:44:34 -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 15054 invoked from network); 1 Jul 2003 21:44:33 -0000 Received: from unknown (HELO crack.them.org) (146.82.138.56) by sources.redhat.com with SMTP; 1 Jul 2003 21:44:33 -0000 Received: from dsl093-172-017.pit1.dsl.speakeasy.net ([66.93.172.17] helo=nevyn.them.org ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 19XSwN-0000J4-00 for ; Tue, 01 Jul 2003 16:45:31 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19XSvO-0001KL-00 for ; Tue, 01 Jul 2003 17:44:30 -0400 Date: Tue, 01 Jul 2003 21:44:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: Dwarf unwinder problems with store.exp and preserved regs Message-ID: <20030701214429.GA3913@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.1i X-SW-Source: 2003-07/txt/msg00026.txt.bz2 I see two kinds of failures in store.exp right now, on the two targets I'm testing. On i386, with DWARF 2 unwinding, I see spurious messages; and on ARM (without DWARF 2 unwinding) I see legitimately corrupted values. The latter are easy, so I'll send a patch momentarily. The former are more interesting. Here's the problem: the unwinder does not know what registers are considered call saved. GDB reads some initial CIE unwind information from the debug file: /* Instruction sequence to initialize a register set. */ unsigned char *initial_instructions; /* True if a 'z' augmentation existed. */ unsigned char saw_z_augmentation; cie->saw_z_augmentation = (*augmentation == 'z'); if (cie->saw_z_augmentation) { ULONGEST length; length = read_unsigned_leb128 (unit->abfd, buf, &bytes_read); buf += bytes_read; cie->initial_instructions = buf + length; augmentation++; } However, GCC only emits information about the CFA, not about the default saved-ness of registers. So we get: 168 /* Initialize newly allocated registers. */ 169 memset (rs->reg + rs->num_regs, 0, (num_regs - rs->num_regs) * size); And 0 is UNDEFINED. So $ebx - a call-saved register on i386 - shows up as undefined. There are two things we can do about this, I think, and perhaps we should do both: - Fix GCC. I -believe-, from reading the spec, that GCC is to blame for not emiting this information. - Provide an architecture method to pre-initialize the register table before initial_instructions is evaluated. Thoughts? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer