From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3886 invoked by alias); 30 Mar 2003 16:57:48 -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 3879 invoked from network); 30 Mar 2003 16:57:47 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.166.107) by sources.redhat.com with SMTP; 30 Mar 2003 16:57:47 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 869572B23; Sun, 30 Mar 2003 11:57:44 -0500 (EST) Message-ID: <3E872208.2050401@redhat.com> Date: Sun, 30 Mar 2003 16:57:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz , Jim Blandy Cc: gdb@sources.redhat.com Subject: Re: [Fwd: Re: tdep/1155: s/390 Linux: GDB can't reselect the right frame after an inferior function call] References: <3E836DFA.2070603@redhat.com> <20030327213715.GA19131@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-03/txt/msg00406.txt.bz2 > > The original bug, as filed, said: > > > If you ask GDB to make an inferior function call when the youngest > frame is a frameless function, and the selected frame is the > second-to-youngest frame, then GDB will not properly re-select the > second-to-youngest frame when the inferior call returns. > > On the S/390, if a function doesn't use alloca, then the compiler just > uses the stack pointer as the frame pointer. This means that GDB's > frame_info structures use the address of the low end of the frame as > the frame base, not the high end. (The S/390 stack grows downwards.) > So, if the youngest function call hasn't allocated any stack space, > then its frame base address is equal to that of its caller. This means > that frame_find_by_id is unable to distinguish between the two. > > > In what way do you see this problem as resolved? Just to close this, further analysis revealed that the s390's frame ID's stack address wasn't correct (wasn't constant, pointing at the wrong end of the frame). Fixing that will fix the above. It's also useful to note that, in the critical edge cases, GDB is already doing frame/func comparisons vis: case PRINT_UNKNOWN: /* FIXME: cagney/2002-12-01: Given that a frame ID does (or should) carry around the function and does (or should) use that when doing a frame comparison. */ if (stop_step && frame_id_eq (step_frame_id, get_frame_id (get_current_frame ())) && step_start_function == find_pc_function (stop_pc)) Moving the test to frame_id_eq() is something of a clean up. It will also make it possible to flush out all those remaining edge cases though. Andrew