From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15478 invoked by alias); 11 Apr 2003 22:21:33 -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 15460 invoked from network); 11 Apr 2003 22:21:31 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 11 Apr 2003 22:21:31 -0000 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 837B8800087 for ; Fri, 11 Apr 2003 18:21:31 -0400 (EDT) Message-ID: <3E973FEB.1090500@redhat.com> Date: Fri, 11 Apr 2003 22:21:00 -0000 From: "J. Johnston" Organization: Red Hat Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: prev_pc problem on ia64 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-04/txt/msg00120.txt.bz2 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. 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 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. 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? -- Jeff J.