From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22136 invoked by alias); 14 Apr 2003 20:17:20 -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 22127 invoked from network); 14 Apr 2003 20:17:20 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 14 Apr 2003 20:17:20 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h3EKHJD22528 for ; Mon, 14 Apr 2003 16:17:19 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h3EKHJq29731; Mon, 14 Apr 2003 16:17:19 -0400 Received: from localhost.redhat.com (romulus-int.sfbay.redhat.com [172.16.27.46]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h3EKHII03837; Mon, 14 Apr 2003 16:17:18 -0400 Received: by localhost.redhat.com (Postfix, from userid 469) id 7FD292C43F; Mon, 14 Apr 2003 16:21:40 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16027.6227.694651.833559@localhost.redhat.com> Date: Mon, 14 Apr 2003 20:17:00 -0000 To: "J. Johnston" Cc: gdb@sources.redhat.com Subject: Re: prev_pc problem on ia64 In-Reply-To: <3E973FEB.1090500@redhat.com> References: <3E973FEB.1090500@redhat.com> X-SW-Source: 2003-04/txt/msg00131.txt.bz2 J. Johnston writes: > I am running into a problem on ia64 regarding performing a next > after an inferior function call or after using "return" from > a function. > > What's occurring is that an inferior function call ends up setting > the static prev_pc value in infrun.c: stop_stepping(). When we > return to the gdb prompt prev_pc is not restored to its original > value. A similar problem occurs when we return from a function > using the gdb return command. > Can you post the sequence that will make the error occur? stop_stepping is not called by the inferior function call code. So it must be afterwards. > On the ia64, there are extraneous line table entries that do not > increase the line number. When we perform a next after the inferior > call, we step until the line number changes from the one set for > prev_pc. Unfortunately, this only gets us part way through the line as > we run until the next line table entry. > > For the x86, this problem does not crop up in the test case I am looking > at because there are none of these additional line table entries. When > we perform a next, it finds the next line regardless of the fact that prev_pc is > not correctly set. > > The following is an example of the line table entries I am talking about on > the ia64 (generated by readelf -wl). I am using a recent gcc but this behavior > also occurs for gcc 2.96 > > Special opcode 20: advance Address by 1 to 0x40000000000007e1 and Line by 1 to 31 > Special opcode 215: advance Address by 15 to 0x40000000000007f0 and Line by 0 to 31 > Special opcode 19: advance Address by 1 to 0x40000000000007f1 and Line by 0 to 31 > Special opcode 19: advance Address by 1 to 0x40000000000007f2 and Line by 0 to 31 > Special opcode 201: advance Address by 14 to 0x4000000000000800 and Line by 0 to 31 > Special opcode 20: advance Address by 1 to 0x4000000000000801 and Line by 1 to 32 > Special opcode 243: advance Address by 17 to 0x4000000000000812 and Line by 0 to 32 > Special opcode 201: advance Address by 14 to 0x4000000000000820 and Line by 0 to 32 > Special opcode 19: advance Address by 1 to 0x4000000000000821 and Line by 0 to 32 > Special opcode 19: advance Address by 1 to 0x4000000000000822 and Line by 0 to 32 > Special opcode 201: advance Address by 14 to 0x4000000000000830 and Line by 0 to 32 > Special opcode 19: advance Address by 1 to 0x4000000000000831 and Line by 0 to 32 > What does gdb show for info line 31 and info line 32? How about disasembling instructions around those lines? I wonder if these addresses are legitimate at all. > Same function compiled for i686: > > Special opcode 76: advance Address by 5 to 0x804839e and Line by 1 to 31 > Special opcode 230: advance Address by 16 to 0x80483ae and Line by 1 to 32 > Special opcode 146: advance Address by 10 to 0x80483b8 and Line by 1 to 33 > Special opcode 160: advance Address by 11 to 0x80483c3 and Line by 1 to 34 > > I have a patch whereby I reset prev_pc in infrun.c:init_execution_control_state(): > > if (prev_pc != 0) > prev_pc = read_pc (); > > prior to setting the ecs->sal. This works for me in both scenarios. The check for > 0 was needed because I get a failure on the ia64 trying to read the pc too early when > the psr register was invalid. > maybe read_pc should return an error code? Ah wait, it errors out, so you should encapsulate that in a catch_errors(). please post the patch to gdb-patches. It's hard to judge, like this. > This may or may not be the best way of doing this. Any other platforms experiencing > this problem in call-ar-st.exp or return.exp? > Not that I remember. elena > -- Jeff J.