From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13401 invoked by alias); 6 Apr 2003 17:10:53 -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 13394 invoked from network); 6 Apr 2003 17:10:52 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.166.107) by sources.redhat.com with SMTP; 6 Apr 2003 17:10:52 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 632452B23; Sun, 6 Apr 2003 13:10:40 -0400 (EDT) Message-ID: <3E905F90.5080306@redhat.com> Date: Sun, 06 Apr 2003 17:10: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: Mark Kettenis , mludvig@suse.cz Cc: gdb-patches@sources.redhat.com Subject: Re: [offbyone RFC] Merge i386newframe References: <3E6FAF64.7070304@suse.cz> <3E70D673.1040504@redhat.com> <200303132246.h2DMk7pH013325@elgar.kettenis.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-04/txt/msg00102.txt.bz2 [picking up old thread] > The need for the above suggests code trying to walk up the frame chain > when it shouldn't need to. Do you have more details? > > > static CORE_ADDR > > i386_saved_pc_after_call (struct frame_info *frame) > > { > > - if (get_frame_type (frame) == SIGTRAMP_FRAME) > > - return i386_sigtramp_saved_pc (frame); > > + char buf[4]; > > > > - return read_memory_unsigned_integer (read_register (SP_REGNUM), 4); > > + /* Our frame unwinder handles this just fine. */ > > + frame_unwind_register (frame, PC_REGNUM, buf); > > + return extract_address (buf, 4); > > } > > Idea's for what to do with this architecture method welcome. > > I believe the intent is for this method to have relatively low overhead > (when measured by the number of target interactions). Hence, it should > avoid doing prologue analysis (which frame_unwind_register() will trigger). If that was the intent, then it no longer applies. The call site looks like: sr_sal.pc = ADDR_BITS_REMOVE (SAVED_PC_AFTER_CALL (get_current_frame ())); sr_sal.section = find_pc_overlay (sr_sal.pc); check_for_old_step_resume_breakpoint (); step_resume_breakpoint = set_momentary_breakpoint (sr_sal, get_frame_id (get_current_frame ()), bp_step_resume); Not five lines after the SAVED_PC_AFTER_CALL call is a call to get_frame_id() and that is going to trigger the prologue analyser. Kind of makes avoiding prologue analysis futile. I suspect that, originally, there was a read_fp() call here (that was cheap) but that was later changed to get_frame_base() / get_frame_id() when it was realised that read_fp() was not going to be sufficient. > Hmm. I was under the impression that we have this function because on > some targets (the i386 is one of them) the frame hasn't been setup yet > when we've stopped on the first instruction of a function. I think the prologue analyzer needs to handle this case regardless. It is just an edge case of the more general problem of determing the frame ID when still part way through the prologue. The d10v handles this by bailing out of the prologue analysis when it reaches the current instruction. > Perhaphs it should be superseeded by a method that takes a regcache > instead of a frame (making the non-analysis of the prologue clearer)? > > I think that would be a good idea. On second thoughts, I'm back to thinking that deprecating it is the right thing to do. Architectures need to fix their prologue analyzer. Andrew