From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11074 invoked by alias); 9 Dec 2003 23:10:23 -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 11066 invoked from network); 9 Dec 2003 23:10:22 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 9 Dec 2003 23:10:22 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id AEEB52B8F; Tue, 9 Dec 2003 18:10:20 -0500 (EST) Message-ID: <3FD6565C.5000300@gnu.org> Date: Tue, 09 Dec 2003 23:10:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joel Brobecker Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] OSF/1 - "next" over prologueless function call References: <20031202042646.GW1186@gnat.com> <3FCD6468.9020708@gnu.org> <20031204005521.GD716@gnat.com> <3FCE92A1.6010007@gnu.org> <20031204232410.GI1652@gnat.com> <3FD0E83F.30203@gnu.org> <20031208232502.GF698@gnat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-12/txt/msg00279.txt.bz2 > So I think we should follow your suggestion above and separate > completely the two conditions, conditionalized by legacy_frame_p(). > The function name we could use, at least for now, could be > handle_subroutine_call() or handle_step_into_function(). > > It seems that the correct test when legacy_frame_p() is nonzero > would only be the frame ID equality test, but I must admit being > nervous again not knowing how reliable the new frame implementations > are... Despite the fact that the current heuristics (check if PC == > address of function first instruction or is inside function prologue) > doesn't cover 100% of the cases, it was still a simple, platform > independent, solid test that worked in most cases. We are about to > replace that by something that's a bit more complex and might cause some > unexpected behavior if the unwinder fails to unwind properly (imagine > for instance that the unwinder skipped one frame). The new frame code is reliable. If it wasn't many other areas of the testsuite will fail. I'm ok with the change going in with the new handle_step_into_function(). Andrew > I am really torn, so I am relying on you who has had a closer look at > the frame implementations that have been converted so far. If it was > just me, I would be very conservative and simply add and extra > > || (legacy_frame_p() && frame_id_eq (...)) > > It only fixes one problem, but the changes of introducing another is > smaller. I am a coward :-). > > -- Joel