This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] Artifical dwarf2 debug info
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