From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28957 invoked by alias); 18 Dec 2002 11:11:58 -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 28908 invoked from network); 18 Dec 2002 11:11:54 -0000 Received: from unknown (HELO localhost.redhat.com) (195.224.55.237) by 209.249.29.67 with SMTP; 18 Dec 2002 11:11:54 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id AD5C14049; Wed, 18 Dec 2002 11:11:39 +0000 (GMT) Message-ID: <3E0057EB.1080104@redhat.com> Date: Wed, 18 Dec 2002 04:39:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.1) Gecko/20021211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: Michal Ludvig , GDB Patches Subject: Re: [RFA] Artifical dwarf2 debug info References: <3DFE14D9.7040102@redhat.com> <20021216181104.GA21047@nevyn.them.org> <3DFE1ECD.5080908@redhat.com> <20021216185750.GA24656@nevyn.them.org> <3DFE289B.3080904@redhat.com> <20021216193459.GA27215@nevyn.them.org> <3DFE3007.3040100@redhat.com> <20021216201117.GA31474@nevyn.them.org> <3DFF185B.9090806@suse.cz> <3DFF3353.2090803@redhat.com> <20021217151304.GA5778@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-12/txt/msg00532.txt.bz2 > On Tue, Dec 17, 2002 at 09:23:15AM -0500, Andrew Cagney wrote: > >> >Ehm ... what's the result regarding to my patch, guys? > >> >> I think pending changes for the most part render the cornerstone of this >> patch obsolete. This is because the dwarf2cfi code wont't be called >> when the frame doesn't have dwarf2 info -> the case that this code is >> trying to handle. >> >> The idea of being able to create debug info at run time, though, is very >> much worth persuing. > > > Eh, I don't agree at all. We'll be calling a function to figure out if > the affected PC value has CFI information. Where's that function going > to live? In the CFI reader presumably, and it would be the appropriate > time to construct fake debug info. > > I think that Michal's patch would look substantively the same after > these pending changes. Not bits like this (michael, is this actually separate and how does it compare to the code identifying a frameless function?) > CORE_ADDR > x86_64_skip_prologue (CORE_ADDR pc) > { > @@ -863,19 +883,8 @@ x86_64_skip_prologue (CORE_ADDR pc) > struct symbol *v_function; > CORE_ADDR endaddr; > > - /* We will handle only functions beginning with: > - 55 pushq %rbp > - 48 89 e5 movq %rsp,%rbp > - */ > - unsigned char prolog_expect[PROLOG_BUFSIZE] = { 0x55, 0x48, 0x89, 0xe5 }, > - prolog_buf[PROLOG_BUFSIZE]; > - > - read_memory (pc, (char *) prolog_buf, PROLOG_BUFSIZE); > - > - /* First check, whether pc points to pushq %rbp, movq %rsp,%rbp. */ > - for (i = 0; i < PROLOG_BUFSIZE; i++) > - if (prolog_expect[i] != prolog_buf[i]) > - return pc; /* ... no, it doesn't. Nothing to skip. */ > + if (! x86_64_function_has_prologue (pc)) > + return pc; And I don't think this would be used either. Instead the decision to create the FDE would have been made earlier. > @@ -839,6 +785,9 @@ frame_state_for (struct context *context > context->lsda = 0; > > fde = get_fde_for_addr (context->ra - 1); > + > + if (fde == NULL) > + fde = guess_generic_fde (context->ra - 1); > > if (fde == NULL) > return; However, the code masaging would likely be the same, yes. Andrew (hmm, bet that context->ra - 1 should be frame_address_in_block (fi))