Re: [RFA] Artifical dwarf2 debug info

[Daniel Jacobowitz <drow@mvista.com>]

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