From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25548 invoked by alias); 18 Dec 2002 15:37:09 -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 25537 invoked from network); 18 Dec 2002 15:37:07 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 209.249.29.67 with SMTP; 18 Dec 2002 15:37:07 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18Oi7q-000051-00; Wed, 18 Dec 2002 11:36:54 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18OgGM-00036l-00; Wed, 18 Dec 2002 10:37:34 -0500 Date: Wed, 18 Dec 2002 10:05:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Michal Ludvig , GDB Patches Subject: Re: [RFA] Artifical dwarf2 debug info Message-ID: <20021218153733.GA11738@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Michal Ludvig , GDB Patches References: <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> <3E0057EB.1080104@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E0057EB.1080104@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-12/txt/msg00535.txt.bz2 On Wed, Dec 18, 2002 at 11:11:39AM +0000, Andrew Cagney wrote: > >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. That's just code factoring - he broke x86_64_function_has_prologue out of x86_64_skip_prologue. Or am I missing your point? You're right, some bits would change. How pending are the other frame changes - are they really worth him waiting for? (In respone to "what's the fire" - I know how annoying it is to have to shelve something and pick it up when you've completely lost the train of thought that produced it...) > >@@ -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)) Probably, but do we have the right frame at that point? Answer is apparently no. It means the same thing though. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer