From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4980 invoked by alias); 31 Dec 2004 15:14:32 -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 4864 invoked from network); 31 Dec 2004 15:14:20 -0000 Received: from unknown (HELO smtp1.wanadoo.fr) (193.252.22.30) by sourceware.org with SMTP; 31 Dec 2004 15:14:20 -0000 Received: from me-wanadoo.net (reject.steria.net [127.0.0.1]) by mwinf0107.wanadoo.fr (SMTP Server) with SMTP id 7BD0CA0001B6 for ; Fri, 31 Dec 2004 16:14:19 +0100 (CET) Received: from takamaka.act-europe.fr (AStDenis-103-1-2-247.w81-249.abo.wanadoo.fr [81.249.112.247]) by mwinf0107.wanadoo.fr (SMTP Server) with ESMTP id 2BA69A0001A9 for ; Fri, 31 Dec 2004 16:14:17 +0100 (CET) Received: by takamaka.act-europe.fr (Postfix, from userid 507) id A297147DAD; Fri, 31 Dec 2004 19:14:15 +0400 (RET) Date: Fri, 31 Dec 2004 16:13:00 -0000 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: [RFA/pa-risc] Correct incorrect frame base Message-ID: <20041231151415.GL1824@adacore.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="mYCpIKhGyMATD0i+" Content-Disposition: inline User-Agent: Mutt/1.4i X-SW-Source: 2004-12/txt/msg00452.txt.bz2 --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 1776 hello, I noticed a problem trying to print the value of a variable with a program compiled with GNAT (based on GCC 3.2.3). The problem comes from the fact that GDB does not compute the correct frame base. I think this is related to the fact that the function frame is larger than usual. Here is the what the assembly code looks like: _ada_dbtest .PROC .CALLINFO FRAME=18880,CALLS,SAVE_RP,ENTRY_GR=3 .ENTRY stw %r2,-20(%r30) copy %r3,%r1 copy %r30,%r3 stwm %r1,8128(%r30) addil L'10752,%r30 ldo R'10752(%r1),%r30 As you see, the frame size as published in the unwind record is 18880 bytes, and the frame is setup in 3 instructions: stwm %r1,8128(%r30) addil L'10752,%r30 ldo R'10752(%r1),%r30 Unfortunately, a little oops in prologue_inst_adjust_sp() made it miss the second instruction: /* addil high21,%r1; ldo low11,(%r1),%r30) save high bits in save_high21 for later use. */ if ((inst & 0xffe00000) == 0x28200000) There is a small confusion in the source register for the addil instruction. The actual sequence should be addil high21,%r30 ldo low11(%r1),%r30 I think the confusion comes from the fact that the result of the sum is stored in %r1. Anyway, I replaced r1 by r30 in the check above, and that fixed the problem. 2004-12-31 Joel Brobecker * hppa-tdep.c (prologue_inst_adjust_sp): Fix small confusion in register number for ldil instruction. Tested on HP/UX 11.00, no regression. OK to apply? -- Joel PS: I will be away for 3 weeks starting Jan 3rd, so please apply this change for me if approved after I leave. Thank you! --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ldil.diff" Content-length: 769 Index: hppa-tdep.c =================================================================== RCS file: /nile.c/cvs/Dev/gdb/gdb-6.3/gdb/hppa-tdep.c,v retrieving revision 1.11 diff -u -p -r1.11 hppa-tdep.c --- hppa-tdep.c 30 Dec 2004 07:10:36 -0000 1.11 +++ hppa-tdep.c 31 Dec 2004 13:18:54 -0000 @@ -1154,9 +1154,9 @@ prologue_inst_adjust_sp (unsigned long i if ((inst & 0xffe00008) == 0x73c00008) return (inst & 0x1 ? -1 << 13 : 0) | (((inst >> 4) & 0x3ff) << 3); - /* addil high21,%r1; ldo low11,(%r1),%r30) + /* addil high21,%r30; ldo low11,(%r1),%r30) save high bits in save_high21 for later use. */ - if ((inst & 0xffe00000) == 0x28200000) + if ((inst & 0xffe00000) == 0x2bc00000) { save_high21 = hppa_extract_21 (inst); return 0; --mYCpIKhGyMATD0i+--