From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15922 invoked by alias); 7 Apr 2003 18:53:47 -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 15908 invoked from network); 7 Apr 2003 18:53:45 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (62.163.169.212) by sources.redhat.com with SMTP; 7 Apr 2003 18:53:45 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6/8.12.5) with ESMTP id h37IrV93000243; Mon, 7 Apr 2003 20:53:31 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6/8.12.6) with ESMTP id h37IrVvv000488; Mon, 7 Apr 2003 20:53:31 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6/8.12.6/Submit) id h37IrUZm000485; Mon, 7 Apr 2003 20:53:30 +0200 (CEST) Date: Mon, 07 Apr 2003 18:53:00 -0000 Message-Id: <200304071853.h37IrUZm000485@elgar.kettenis.dyndns.org> From: Mark Kettenis To: ac131313@redhat.com CC: mludvig@suse.cz, gdb-patches@sources.redhat.com In-reply-to: <3E905F90.5080306@redhat.com> (message from Andrew Cagney on Sun, 06 Apr 2003 13:10:40 -0400) Subject: Re: [offbyone RFC] Merge i386newframe References: <3E6FAF64.7070304@suse.cz> <3E70D673.1040504@redhat.com> <200303132246.h2DMk7pH013325@elgar.kettenis.dyndns.org> <3E905F90.5080306@redhat.com> X-SW-Source: 2003-04/txt/msg00118.txt.bz2 Date: Sun, 06 Apr 2003 13:10:40 -0400 From: Andrew Cagney [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. Indeed. > 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. I totally agree with you here. > 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. Please do so. Make things as simple as possible now, and let's optimize *after* the new frame code has stabilized, if the need arises. If SAVED_PC_AFTER_CALL was an optimization, chances are it isn't anymore with the new code. Mark