Re: RFA symtab: Fix for PR c++/1267 ("next" and shared libraries)

Re: RFA symtab: Fix for PR c++/1267 ("next" and shared libraries)

[Michael Elizabeth Chastain]

Off topic thought: would it be hard to enhance gcc so that it
can generate coff (and mdebug) on native i686-pc-linux-gnu?

Then I could add these formats to my test bed.

Michael C

Re: RFA symtab: Fix for PR c++/1267 ("next" and shared libraries)

[Daniel Jacobowitz]

On Fri, Jul 25, 2003 at 12:15:15PM -0400, Michael Elizabeth Chastain wrote:
> Off topic thought: would it be hard to enhance gcc so that it
> can generate coff (and mdebug) on native i686-pc-linux-gnu?
> 
> Then I could add these formats to my test bed.

The interest isn't in coff debugging info, but in COFF (rather than
ELF) binaries.

But the answer is yes, it would be hard.  And I'd rather they silently
die off.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA symtab: Fix for PR c++/1267 ("next" and shared libraries)

[Michael Elizabeth Chastain]

drow> But the answer is yes, it would be hard.  And I'd rather they silently
drow> die off.

Well, if it's hard, then fuhgeddaboutit ... I'll worry about
adding some cross targets instead.  Any cross targets.

Michael C

RFA symtab: Fix for PR c++/1267 ("next" and shared libraries)

[Daniel Jacobowitz]

This patch fixes c++/1267, a bug where stepping over a function call that
went through the PLT (as happens when a -fPIC function makes a call to a
globally visible symbol) would lose control of the inferior.  I'll spare you
the complete debugging session, as it really doesn't make much sense.  But
here's the root of the problem:

When we called frame_pc_unwind on the sentinel frame, we got an address in
the PLT.  But when we called frame_func_unwind, we got "_init", in ".init",
which is generally located right before the PLT.  Then, we'd run the
new-and-improved prologue unwinder on _init, and get some completely bogus
information, since things weren't actually saved on the stack where it
thought they were.  This led to the unwound stack pointer being wrong for
the step_resume breakpoint, so when we hit the step_resume breakpoint we
kept going.

I fixed this by changing lookup_minimal_symbol_pc_section to be paranoid
about returning a minsym in the same section as the PC.  Technically, at
least on ELF targets, that doesn't _have_ to be true.  I've never
encountered an exception or a good reason for one, though.  Does anyone see
any pitfalls for this change?  Symtab maintainers, is this patch OK?

I believe this patch should also fix shlibs/1237, and may also fix
shlibs/1280.  Adam, could you check those?





By the way, I'm convinced that all is not well in step_over_function.  This
comment,

  /* NOTE: cagney/2003-04-06:

     The intent of DEPRECATED_SAVED_PC_AFTER_CALL was to:

     - provide a very light weight equivalent to frame_unwind_pc()
     (nee FRAME_SAVED_PC) that avoids the prologue analyzer

     - avoid handling the case where the PC hasn't been saved in the
     prologue analyzer

     Unfortunatly, not five lines further down, is a call to
     get_frame_id() and that is guarenteed to trigger the prologue
     analyzer.

is either incorrect or has gotten out of sync with the code:

  if (DEPRECATED_SAVED_PC_AFTER_CALL_P ())
    sr_sal.pc = ADDR_BITS_REMOVE (DEPRECATED_SAVED_PC_AFTER_CALL (get_current_frame ()));
  else
    sr_sal.pc = ADDR_BITS_REMOVE (frame_pc_unwind (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);


Note that get_frame_id unwinds from the NEXT frame, and
frame_pc_unwind/DEPRECATED_SAVED_PC_AFTER_CALL unwind from THIS frame.
This throws me a loop every time I have to work in this function.  Also, I
have the nagging feeling we're saving the wrong frame.  I have an old MIPS
patch where I needed to use get_prev_frame in step_over_function.  As soon
as I have time to revisit that patch I'll be back to clean this up some
more.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2003-07-19  Daniel Jacobowitz  <drow@mvista.com>

	PR c++/1267
	* minsyms.c (lookup_minimal_symbol_by_pc_section): If SECTION is
	NULL, default to the section containing PC.

Index: minsyms.c
===================================================================
RCS file: /cvs/src/src/gdb/minsyms.c,v
retrieving revision 1.31
diff -u -p -r1.31 minsyms.c
--- minsyms.c	15 May 2003 22:23:24 -0000	1.31
+++ minsyms.c	19 Jul 2003 18:03:08 -0000
@@ -403,12 +403,22 @@ lookup_minimal_symbol_by_pc_section (COR
   struct objfile *objfile;
   struct minimal_symbol *msymbol;
   struct minimal_symbol *best_symbol = NULL;
+  struct obj_section *pc_section;
 
   /* pc has to be in a known section. This ensures that anything beyond
      the end of the last segment doesn't appear to be part of the last
      function in the last segment.  */
-  if (find_pc_section (pc) == NULL)
+  pc_section = find_pc_section (pc);
+  if (pc_section == NULL)
     return NULL;
+
+  /* If no section was specified, then just make sure that the PC is in
+     the same section as the minimal symbol we find.  */
+  if (section == NULL)
+    section = pc_section->the_bfd_section;
+
+  /* FIXME drow/2003-07-19: Should we also check that PC is in SECTION
+     if we were passed a non-NULL SECTION argument?  */
 
   for (objfile = object_files;
        objfile != NULL;

Re: RFA symtab: Fix for PR c++/1267 ("next" and shared libraries)

[Adam Fedor]

Daniel Jacobowitz wrote:
> This patch fixes c++/1267, a bug where stepping over a function call that
> went through the PLT (as happens when a -fPIC function makes a call to a
> globally visible symbol) would lose control of the inferior.  I'll spare you
> the complete debugging session, as it really doesn't make much sense.  But
> here's the root of the problem:
> 
> When we called frame_pc_unwind on the sentinel frame, we got an address in
> the PLT.  But when we called frame_func_unwind, we got "_init", in ".init",
> which is generally located right before the PLT.  Then, we'd run the
> new-and-improved prologue unwinder on _init, and get some completely bogus
> information, since things weren't actually saved on the stack where it
> thought they were.  This led to the unwound stack pointer being wrong for
> the step_resume breakpoint, so when we hit the step_resume breakpoint we
> kept going.
> 
> I fixed this by changing lookup_minimal_symbol_pc_section to be paranoid
> about returning a minsym in the same section as the PC.  Technically, at
> least on ELF targets, that doesn't _have_ to be true.  I've never
> encountered an exception or a good reason for one, though.  Does anyone see
> any pitfalls for this change?  Symtab maintainers, is this patch OK?
> 
> I believe this patch should also fix shlibs/1237, and may also fix
> shlibs/1280.  Adam, could you check those?
> 

Yes this fixes both cases (shlibs/1237 and shlibs/1280) for me. Thanks!

Re: RFA symtab: Fix for PR c++/1267 ("next" and shared libraries)

[Jim Blandy]

I think this is a great idea.  How widely have you tested it?

Daniel Jacobowitz <drow@mvista.com> writes:

> This patch fixes c++/1267, a bug where stepping over a function call that
> went through the PLT (as happens when a -fPIC function makes a call to a
> globally visible symbol) would lose control of the inferior.  I'll spare you
> the complete debugging session, as it really doesn't make much sense.  But
> here's the root of the problem:
> 
> When we called frame_pc_unwind on the sentinel frame, we got an address in
> the PLT.  But when we called frame_func_unwind, we got "_init", in ".init",
> which is generally located right before the PLT.  Then, we'd run the
> new-and-improved prologue unwinder on _init, and get some completely bogus
> information, since things weren't actually saved on the stack where it
> thought they were.  This led to the unwound stack pointer being wrong for
> the step_resume breakpoint, so when we hit the step_resume breakpoint we
> kept going.
> 
> I fixed this by changing lookup_minimal_symbol_pc_section to be paranoid
> about returning a minsym in the same section as the PC.  Technically, at
> least on ELF targets, that doesn't _have_ to be true.  I've never
> encountered an exception or a good reason for one, though.  Does anyone see
> any pitfalls for this change?  Symtab maintainers, is this patch OK?
> 
> I believe this patch should also fix shlibs/1237, and may also fix
> shlibs/1280.  Adam, could you check those?
> 
> 
> 
> 
> 
> By the way, I'm convinced that all is not well in step_over_function.  This
> comment,
> 
>   /* NOTE: cagney/2003-04-06:
> 
>      The intent of DEPRECATED_SAVED_PC_AFTER_CALL was to:
> 
>      - provide a very light weight equivalent to frame_unwind_pc()
>      (nee FRAME_SAVED_PC) that avoids the prologue analyzer
> 
>      - avoid handling the case where the PC hasn't been saved in the
>      prologue analyzer
> 
>      Unfortunatly, not five lines further down, is a call to
>      get_frame_id() and that is guarenteed to trigger the prologue
>      analyzer.
> 
> is either incorrect or has gotten out of sync with the code:
> 
>   if (DEPRECATED_SAVED_PC_AFTER_CALL_P ())
>     sr_sal.pc = ADDR_BITS_REMOVE (DEPRECATED_SAVED_PC_AFTER_CALL (get_current_frame ()));
>   else
>     sr_sal.pc = ADDR_BITS_REMOVE (frame_pc_unwind (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);
> 
> 
> Note that get_frame_id unwinds from the NEXT frame, and
> frame_pc_unwind/DEPRECATED_SAVED_PC_AFTER_CALL unwind from THIS frame.
> This throws me a loop every time I have to work in this function.  Also, I
> have the nagging feeling we're saving the wrong frame.  I have an old MIPS
> patch where I needed to use get_prev_frame in step_over_function.  As soon
> as I have time to revisit that patch I'll be back to clean this up some
> more.
> 
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
> 
> 2003-07-19  Daniel Jacobowitz  <drow@mvista.com>
> 
> 	PR c++/1267
> 	* minsyms.c (lookup_minimal_symbol_by_pc_section): If SECTION is
> 	NULL, default to the section containing PC.
> 
> Index: minsyms.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/minsyms.c,v
> retrieving revision 1.31
> diff -u -p -r1.31 minsyms.c
> --- minsyms.c	15 May 2003 22:23:24 -0000	1.31
> +++ minsyms.c	19 Jul 2003 18:03:08 -0000
> @@ -403,12 +403,22 @@ lookup_minimal_symbol_by_pc_section (COR
>    struct objfile *objfile;
>    struct minimal_symbol *msymbol;
>    struct minimal_symbol *best_symbol = NULL;
> +  struct obj_section *pc_section;
>  
>    /* pc has to be in a known section. This ensures that anything beyond
>       the end of the last segment doesn't appear to be part of the last
>       function in the last segment.  */
> -  if (find_pc_section (pc) == NULL)
> +  pc_section = find_pc_section (pc);
> +  if (pc_section == NULL)
>      return NULL;
> +
> +  /* If no section was specified, then just make sure that the PC is in
> +     the same section as the minimal symbol we find.  */
> +  if (section == NULL)
> +    section = pc_section->the_bfd_section;
> +
> +  /* FIXME drow/2003-07-19: Should we also check that PC is in SECTION
> +     if we were passed a non-NULL SECTION argument?  */
>  
>    for (objfile = object_files;
>         objfile != NULL;

Re: RFA symtab: Fix for PR c++/1267 ("next" and shared libraries)

[Daniel Jacobowitz]

Only the testsuite on i386-linux.  What would you recommend?

On Mon, Jul 21, 2003 at 02:13:55AM -0500, Jim Blandy wrote:
> 
> I think this is a great idea.  How widely have you tested it?
> 
> Daniel Jacobowitz <drow@mvista.com> writes:
> 
> > This patch fixes c++/1267, a bug where stepping over a function call that
> > went through the PLT (as happens when a -fPIC function makes a call to a
> > globally visible symbol) would lose control of the inferior.  I'll spare you
> > the complete debugging session, as it really doesn't make much sense.  But
> > here's the root of the problem:
> > 
> > When we called frame_pc_unwind on the sentinel frame, we got an address in
> > the PLT.  But when we called frame_func_unwind, we got "_init", in ".init",
> > which is generally located right before the PLT.  Then, we'd run the
> > new-and-improved prologue unwinder on _init, and get some completely bogus
> > information, since things weren't actually saved on the stack where it
> > thought they were.  This led to the unwound stack pointer being wrong for
> > the step_resume breakpoint, so when we hit the step_resume breakpoint we
> > kept going.
> > 
> > I fixed this by changing lookup_minimal_symbol_pc_section to be paranoid
> > about returning a minsym in the same section as the PC.  Technically, at
> > least on ELF targets, that doesn't _have_ to be true.  I've never
> > encountered an exception or a good reason for one, though.  Does anyone see
> > any pitfalls for this change?  Symtab maintainers, is this patch OK?
> > 
> > I believe this patch should also fix shlibs/1237, and may also fix
> > shlibs/1280.  Adam, could you check those?
> > 
> > 
> > 
> > 
> > 
> > By the way, I'm convinced that all is not well in step_over_function.  This
> > comment,
> > 
> >   /* NOTE: cagney/2003-04-06:
> > 
> >      The intent of DEPRECATED_SAVED_PC_AFTER_CALL was to:
> > 
> >      - provide a very light weight equivalent to frame_unwind_pc()
> >      (nee FRAME_SAVED_PC) that avoids the prologue analyzer
> > 
> >      - avoid handling the case where the PC hasn't been saved in the
> >      prologue analyzer
> > 
> >      Unfortunatly, not five lines further down, is a call to
> >      get_frame_id() and that is guarenteed to trigger the prologue
> >      analyzer.
> > 
> > is either incorrect or has gotten out of sync with the code:
> > 
> >   if (DEPRECATED_SAVED_PC_AFTER_CALL_P ())
> >     sr_sal.pc = ADDR_BITS_REMOVE (DEPRECATED_SAVED_PC_AFTER_CALL (get_current_frame ()));
> >   else
> >     sr_sal.pc = ADDR_BITS_REMOVE (frame_pc_unwind (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);
> > 
> > 
> > Note that get_frame_id unwinds from the NEXT frame, and
> > frame_pc_unwind/DEPRECATED_SAVED_PC_AFTER_CALL unwind from THIS frame.
> > This throws me a loop every time I have to work in this function.  Also, I
> > have the nagging feeling we're saving the wrong frame.  I have an old MIPS
> > patch where I needed to use get_prev_frame in step_over_function.  As soon
> > as I have time to revisit that patch I'll be back to clean this up some
> > more.
> > 
> > -- 
> > Daniel Jacobowitz
> > MontaVista Software                         Debian GNU/Linux Developer
> > 
> > 2003-07-19  Daniel Jacobowitz  <drow@mvista.com>
> > 
> > 	PR c++/1267
> > 	* minsyms.c (lookup_minimal_symbol_by_pc_section): If SECTION is
> > 	NULL, default to the section containing PC.
> > 
> > Index: minsyms.c
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/minsyms.c,v
> > retrieving revision 1.31
> > diff -u -p -r1.31 minsyms.c
> > --- minsyms.c	15 May 2003 22:23:24 -0000	1.31
> > +++ minsyms.c	19 Jul 2003 18:03:08 -0000
> > @@ -403,12 +403,22 @@ lookup_minimal_symbol_by_pc_section (COR
> >    struct objfile *objfile;
> >    struct minimal_symbol *msymbol;
> >    struct minimal_symbol *best_symbol = NULL;
> > +  struct obj_section *pc_section;
> >  
> >    /* pc has to be in a known section. This ensures that anything beyond
> >       the end of the last segment doesn't appear to be part of the last
> >       function in the last segment.  */
> > -  if (find_pc_section (pc) == NULL)
> > +  pc_section = find_pc_section (pc);
> > +  if (pc_section == NULL)
> >      return NULL;
> > +
> > +  /* If no section was specified, then just make sure that the PC is in
> > +     the same section as the minimal symbol we find.  */
> > +  if (section == NULL)
> > +    section = pc_section->the_bfd_section;
> > +
> > +  /* FIXME drow/2003-07-19: Should we also check that PC is in SECTION
> > +     if we were passed a non-NULL SECTION argument?  */
> >  
> >    for (objfile = object_files;
> >         objfile != NULL;
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA symtab: Fix for PR c++/1267 ("next" and shared libraries)

[Jim Blandy]

For the trunk, put it in, definitely.

For 6.0, could you test it on a COFF toolchain, and on some non-GNU
toolchain?  It would be nice to have those three PR's closed in 6.0.

Daniel Jacobowitz <drow@mvista.com> writes:
> Only the testsuite on i386-linux.  What would you recommend?
> 
> On Mon, Jul 21, 2003 at 02:13:55AM -0500, Jim Blandy wrote:
> > 
> > I think this is a great idea.  How widely have you tested it?
> > 
> > Daniel Jacobowitz <drow@mvista.com> writes:
> > 
> > > This patch fixes c++/1267, a bug where stepping over a function call that
> > > went through the PLT (as happens when a -fPIC function makes a call to a
> > > globally visible symbol) would lose control of the inferior.  I'll spare you
> > > the complete debugging session, as it really doesn't make much sense.  But
> > > here's the root of the problem:
> > > 
> > > When we called frame_pc_unwind on the sentinel frame, we got an address in
> > > the PLT.  But when we called frame_func_unwind, we got "_init", in ".init",
> > > which is generally located right before the PLT.  Then, we'd run the
> > > new-and-improved prologue unwinder on _init, and get some completely bogus
> > > information, since things weren't actually saved on the stack where it
> > > thought they were.  This led to the unwound stack pointer being wrong for
> > > the step_resume breakpoint, so when we hit the step_resume breakpoint we
> > > kept going.
> > > 
> > > I fixed this by changing lookup_minimal_symbol_pc_section to be paranoid
> > > about returning a minsym in the same section as the PC.  Technically, at
> > > least on ELF targets, that doesn't _have_ to be true.  I've never
> > > encountered an exception or a good reason for one, though.  Does anyone see
> > > any pitfalls for this change?  Symtab maintainers, is this patch OK?
> > > 
> > > I believe this patch should also fix shlibs/1237, and may also fix
> > > shlibs/1280.  Adam, could you check those?
> > > 
> > > 
> > > 
> > > 
> > > 
> > > By the way, I'm convinced that all is not well in step_over_function.  This
> > > comment,
> > > 
> > >   /* NOTE: cagney/2003-04-06:
> > > 
> > >      The intent of DEPRECATED_SAVED_PC_AFTER_CALL was to:
> > > 
> > >      - provide a very light weight equivalent to frame_unwind_pc()
> > >      (nee FRAME_SAVED_PC) that avoids the prologue analyzer
> > > 
> > >      - avoid handling the case where the PC hasn't been saved in the
> > >      prologue analyzer
> > > 
> > >      Unfortunatly, not five lines further down, is a call to
> > >      get_frame_id() and that is guarenteed to trigger the prologue
> > >      analyzer.
> > > 
> > > is either incorrect or has gotten out of sync with the code:
> > > 
> > >   if (DEPRECATED_SAVED_PC_AFTER_CALL_P ())
> > >     sr_sal.pc = ADDR_BITS_REMOVE (DEPRECATED_SAVED_PC_AFTER_CALL (get_current_frame ()));
> > >   else
> > >     sr_sal.pc = ADDR_BITS_REMOVE (frame_pc_unwind (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);
> > > 
> > > 
> > > Note that get_frame_id unwinds from the NEXT frame, and
> > > frame_pc_unwind/DEPRECATED_SAVED_PC_AFTER_CALL unwind from THIS frame.
> > > This throws me a loop every time I have to work in this function.  Also, I
> > > have the nagging feeling we're saving the wrong frame.  I have an old MIPS
> > > patch where I needed to use get_prev_frame in step_over_function.  As soon
> > > as I have time to revisit that patch I'll be back to clean this up some
> > > more.
> > > 
> > > -- 
> > > Daniel Jacobowitz
> > > MontaVista Software                         Debian GNU/Linux Developer
> > > 
> > > 2003-07-19  Daniel Jacobowitz  <drow@mvista.com>
> > > 
> > > 	PR c++/1267
> > > 	* minsyms.c (lookup_minimal_symbol_by_pc_section): If SECTION is
> > > 	NULL, default to the section containing PC.
> > > 
> > > Index: minsyms.c
> > > ===================================================================
> > > RCS file: /cvs/src/src/gdb/minsyms.c,v
> > > retrieving revision 1.31
> > > diff -u -p -r1.31 minsyms.c
> > > --- minsyms.c	15 May 2003 22:23:24 -0000	1.31
> > > +++ minsyms.c	19 Jul 2003 18:03:08 -0000
> > > @@ -403,12 +403,22 @@ lookup_minimal_symbol_by_pc_section (COR
> > >    struct objfile *objfile;
> > >    struct minimal_symbol *msymbol;
> > >    struct minimal_symbol *best_symbol = NULL;
> > > +  struct obj_section *pc_section;
> > >  
> > >    /* pc has to be in a known section. This ensures that anything beyond
> > >       the end of the last segment doesn't appear to be part of the last
> > >       function in the last segment.  */
> > > -  if (find_pc_section (pc) == NULL)
> > > +  pc_section = find_pc_section (pc);
> > > +  if (pc_section == NULL)
> > >      return NULL;
> > > +
> > > +  /* If no section was specified, then just make sure that the PC is in
> > > +     the same section as the minimal symbol we find.  */
> > > +  if (section == NULL)
> > > +    section = pc_section->the_bfd_section;
> > > +
> > > +  /* FIXME drow/2003-07-19: Should we also check that PC is in SECTION
> > > +     if we were passed a non-NULL SECTION argument?  */
> > >  
> > >    for (objfile = object_files;
> > >         objfile != NULL;
> > 
> 
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer

Re: RFA symtab: Fix for PR c++/1267 ("next" and shared libraries)

[Daniel Jacobowitz]

On Thu, Jul 24, 2003 at 02:59:27PM -0500, Jim Blandy wrote:
> 
> For the trunk, put it in, definitely.
> 
> For 6.0, could you test it on a COFF toolchain, and on some non-GNU
> toolchain?  It would be nice to have those three PR's closed in 6.0.

I no longer have access to any non-GNU toolchains.  I'll try to build a
COFF simulator target and give it a whirl, though...

> 
> Daniel Jacobowitz <drow@mvista.com> writes:
> > Only the testsuite on i386-linux.  What would you recommend?
> > 
> > On Mon, Jul 21, 2003 at 02:13:55AM -0500, Jim Blandy wrote:
> > > 
> > > I think this is a great idea.  How widely have you tested it?
> > > 
> > > Daniel Jacobowitz <drow@mvista.com> writes:
> > > 
> > > > This patch fixes c++/1267, a bug where stepping over a function call that
> > > > went through the PLT (as happens when a -fPIC function makes a call to a
> > > > globally visible symbol) would lose control of the inferior.  I'll spare you
> > > > the complete debugging session, as it really doesn't make much sense.  But
> > > > here's the root of the problem:
> > > > 
> > > > When we called frame_pc_unwind on the sentinel frame, we got an address in
> > > > the PLT.  But when we called frame_func_unwind, we got "_init", in ".init",
> > > > which is generally located right before the PLT.  Then, we'd run the
> > > > new-and-improved prologue unwinder on _init, and get some completely bogus
> > > > information, since things weren't actually saved on the stack where it
> > > > thought they were.  This led to the unwound stack pointer being wrong for
> > > > the step_resume breakpoint, so when we hit the step_resume breakpoint we
> > > > kept going.
> > > > 
> > > > I fixed this by changing lookup_minimal_symbol_pc_section to be paranoid
> > > > about returning a minsym in the same section as the PC.  Technically, at
> > > > least on ELF targets, that doesn't _have_ to be true.  I've never
> > > > encountered an exception or a good reason for one, though.  Does anyone see
> > > > any pitfalls for this change?  Symtab maintainers, is this patch OK?
> > > > 
> > > > I believe this patch should also fix shlibs/1237, and may also fix
> > > > shlibs/1280.  Adam, could you check those?
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > By the way, I'm convinced that all is not well in step_over_function.  This
> > > > comment,
> > > > 
> > > >   /* NOTE: cagney/2003-04-06:
> > > > 
> > > >      The intent of DEPRECATED_SAVED_PC_AFTER_CALL was to:
> > > > 
> > > >      - provide a very light weight equivalent to frame_unwind_pc()
> > > >      (nee FRAME_SAVED_PC) that avoids the prologue analyzer
> > > > 
> > > >      - avoid handling the case where the PC hasn't been saved in the
> > > >      prologue analyzer
> > > > 
> > > >      Unfortunatly, not five lines further down, is a call to
> > > >      get_frame_id() and that is guarenteed to trigger the prologue
> > > >      analyzer.
> > > > 
> > > > is either incorrect or has gotten out of sync with the code:
> > > > 
> > > >   if (DEPRECATED_SAVED_PC_AFTER_CALL_P ())
> > > >     sr_sal.pc = ADDR_BITS_REMOVE (DEPRECATED_SAVED_PC_AFTER_CALL (get_current_frame ()));
> > > >   else
> > > >     sr_sal.pc = ADDR_BITS_REMOVE (frame_pc_unwind (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);
> > > > 
> > > > 
> > > > Note that get_frame_id unwinds from the NEXT frame, and
> > > > frame_pc_unwind/DEPRECATED_SAVED_PC_AFTER_CALL unwind from THIS frame.
> > > > This throws me a loop every time I have to work in this function.  Also, I
> > > > have the nagging feeling we're saving the wrong frame.  I have an old MIPS
> > > > patch where I needed to use get_prev_frame in step_over_function.  As soon
> > > > as I have time to revisit that patch I'll be back to clean this up some
> > > > more.
> > > > 
> > > > -- 
> > > > Daniel Jacobowitz
> > > > MontaVista Software                         Debian GNU/Linux Developer
> > > > 
> > > > 2003-07-19  Daniel Jacobowitz  <drow@mvista.com>
> > > > 
> > > > 	PR c++/1267
> > > > 	* minsyms.c (lookup_minimal_symbol_by_pc_section): If SECTION is
> > > > 	NULL, default to the section containing PC.
> > > > 
> > > > Index: minsyms.c
> > > > ===================================================================
> > > > RCS file: /cvs/src/src/gdb/minsyms.c,v
> > > > retrieving revision 1.31
> > > > diff -u -p -r1.31 minsyms.c
> > > > --- minsyms.c	15 May 2003 22:23:24 -0000	1.31
> > > > +++ minsyms.c	19 Jul 2003 18:03:08 -0000
> > > > @@ -403,12 +403,22 @@ lookup_minimal_symbol_by_pc_section (COR
> > > >    struct objfile *objfile;
> > > >    struct minimal_symbol *msymbol;
> > > >    struct minimal_symbol *best_symbol = NULL;
> > > > +  struct obj_section *pc_section;
> > > >  
> > > >    /* pc has to be in a known section. This ensures that anything beyond
> > > >       the end of the last segment doesn't appear to be part of the last
> > > >       function in the last segment.  */
> > > > -  if (find_pc_section (pc) == NULL)
> > > > +  pc_section = find_pc_section (pc);
> > > > +  if (pc_section == NULL)
> > > >      return NULL;
> > > > +
> > > > +  /* If no section was specified, then just make sure that the PC is in
> > > > +     the same section as the minimal symbol we find.  */
> > > > +  if (section == NULL)
> > > > +    section = pc_section->the_bfd_section;
> > > > +
> > > > +  /* FIXME drow/2003-07-19: Should we also check that PC is in SECTION
> > > > +     if we were passed a non-NULL SECTION argument?  */
> > > >  
> > > >    for (objfile = object_files;
> > > >         objfile != NULL;
> > > 
> > 
> > -- 
> > Daniel Jacobowitz
> > MontaVista Software                         Debian GNU/Linux Developer
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA symtab: Fix for PR c++/1267 ("next" and shared libraries)

[Adam Fedor]

I have Solaris with Sun CC. Does that count? What do I do, just run the 
testsuite?

On Thursday, July 24, 2003, at 02:58 PM, Daniel Jacobowitz wrote:

> On Thu, Jul 24, 2003 at 02:59:27PM -0500, Jim Blandy wrote:
>>
>> For the trunk, put it in, definitely.
>>
>> For 6.0, could you test it on a COFF toolchain, and on some non-GNU
>> toolchain?  It would be nice to have those three PR's closed in 6.0.
>
> I no longer have access to any non-GNU toolchains.  I'll try to build a
> COFF simulator target and give it a whirl, though...
>
>>
>> Daniel Jacobowitz <drow@mvista.com> writes:
>>> Only the testsuite on i386-linux.  What would you recommend?
>>>
>>> On Mon, Jul 21, 2003 at 02:13:55AM -0500, Jim Blandy wrote:
>>>>
>>>> I think this is a great idea.  How widely have you tested it?
>>>>
>>>> Daniel Jacobowitz <drow@mvista.com> writes:
>>>>
>>>>> This patch fixes c++/1267, a bug where stepping over a function 
>>>>> call that
>>>>> went through the PLT (as happens when a -fPIC function makes a 
>>>>> call to a
>>>>> globally visible symbol) would lose control of the inferior.  I'll 
>>>>> spare you
>>>>> the complete debugging session, as it really doesn't make much 
>>>>> sense.  But
>>>>> here's the root of the problem:
>>>>>
>>>>> When we called frame_pc_unwind on the sentinel frame, we got an 
>>>>> address in
>>>>> the PLT.  But when we called frame_func_unwind, we got "_init", in 
>>>>> ".init",
>>>>> which is generally located right before the PLT.  Then, we'd run 
>>>>> the
>>>>> new-and-improved prologue unwinder on _init, and get some 
>>>>> completely bogus
>>>>> information, since things weren't actually saved on the stack 
>>>>> where it
>>>>> thought they were.  This led to the unwound stack pointer being 
>>>>> wrong for
>>>>> the step_resume breakpoint, so when we hit the step_resume 
>>>>> breakpoint we
>>>>> kept going.
>>>>>
>>>>> I fixed this by changing lookup_minimal_symbol_pc_section to be 
>>>>> paranoid
>>>>> about returning a minsym in the same section as the PC.  
>>>>> Technically, at
>>>>> least on ELF targets, that doesn't _have_ to be true.  I've never
>>>>> encountered an exception or a good reason for one, though.  Does 
>>>>> anyone see
>>>>> any pitfalls for this change?  Symtab maintainers, is this patch 
>>>>> OK?
>>>>>
>>>>> I believe this patch should also fix shlibs/1237, and may also fix
>>>>> shlibs/1280.  Adam, could you check those?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> By the way, I'm convinced that all is not well in 
>>>>> step_over_function.  This
>>>>> comment,
>>>>>
>>>>>   /* NOTE: cagney/2003-04-06:
>>>>>
>>>>>      The intent of DEPRECATED_SAVED_PC_AFTER_CALL was to:
>>>>>
>>>>>      - provide a very light weight equivalent to frame_unwind_pc()
>>>>>      (nee FRAME_SAVED_PC) that avoids the prologue analyzer
>>>>>
>>>>>      - avoid handling the case where the PC hasn't been saved in 
>>>>> the
>>>>>      prologue analyzer
>>>>>
>>>>>      Unfortunatly, not five lines further down, is a call to
>>>>>      get_frame_id() and that is guarenteed to trigger the prologue
>>>>>      analyzer.
>>>>>
>>>>> is either incorrect or has gotten out of sync with the code:
>>>>>
>>>>>   if (DEPRECATED_SAVED_PC_AFTER_CALL_P ())
>>>>>     sr_sal.pc = ADDR_BITS_REMOVE (DEPRECATED_SAVED_PC_AFTER_CALL 
>>>>> (get_current_frame ()));
>>>>>   else
>>>>>     sr_sal.pc = ADDR_BITS_REMOVE (frame_pc_unwind 
>>>>> (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);
>>>>>
>>>>>
>>>>> Note that get_frame_id unwinds from the NEXT frame, and
>>>>> frame_pc_unwind/DEPRECATED_SAVED_PC_AFTER_CALL unwind from THIS 
>>>>> frame.
>>>>> This throws me a loop every time I have to work in this function.  
>>>>> Also, I
>>>>> have the nagging feeling we're saving the wrong frame.  I have an 
>>>>> old MIPS
>>>>> patch where I needed to use get_prev_frame in step_over_function.  
>>>>> As soon
>>>>> as I have time to revisit that patch I'll be back to clean this up 
>>>>> some
>>>>> more.
>>>>>
>>>>> -- 
>>>>> Daniel Jacobowitz
>>>>> MontaVista Software                         Debian GNU/Linux 
>>>>> Developer
>>>>>
>>>>> 2003-07-19  Daniel Jacobowitz  <drow@mvista.com>
>>>>>
>>>>> 	PR c++/1267
>>>>> 	* minsyms.c (lookup_minimal_symbol_by_pc_section): If SECTION is
>>>>> 	NULL, default to the section containing PC.
>>>>>
>>>>> Index: minsyms.c
>>>>> ===================================================================
>>>>> RCS file: /cvs/src/src/gdb/minsyms.c,v
>>>>> retrieving revision 1.31
>>>>> diff -u -p -r1.31 minsyms.c
>>>>> --- minsyms.c	15 May 2003 22:23:24 -0000	1.31
>>>>> +++ minsyms.c	19 Jul 2003 18:03:08 -0000
>>>>> @@ -403,12 +403,22 @@ lookup_minimal_symbol_by_pc_section (COR
>>>>>    struct objfile *objfile;
>>>>>    struct minimal_symbol *msymbol;
>>>>>    struct minimal_symbol *best_symbol = NULL;
>>>>> +  struct obj_section *pc_section;
>>>>>
>>>>>    /* pc has to be in a known section. This ensures that anything 
>>>>> beyond
>>>>>       the end of the last segment doesn't appear to be part of the 
>>>>> last
>>>>>       function in the last segment.  */
>>>>> -  if (find_pc_section (pc) == NULL)
>>>>> +  pc_section = find_pc_section (pc);
>>>>> +  if (pc_section == NULL)
>>>>>      return NULL;
>>>>> +
>>>>> +  /* If no section was specified, then just make sure that the PC 
>>>>> is in
>>>>> +     the same section as the minimal symbol we find.  */
>>>>> +  if (section == NULL)
>>>>> +    section = pc_section->the_bfd_section;
>>>>> +
>>>>> +  /* FIXME drow/2003-07-19: Should we also check that PC is in 
>>>>> SECTION
>>>>> +     if we were passed a non-NULL SECTION argument?  */
>>>>>
>>>>>    for (objfile = object_files;
>>>>>         objfile != NULL;
>>>>
>>>
>>> -- 
>>> Daniel Jacobowitz
>>> MontaVista Software                         Debian GNU/Linux 
>>> Developer
>>
>
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer

Re: RFA symtab: Fix for PR c++/1267 ("next" and shared libraries)

[Jim Blandy]

Adam Fedor <fedor@doc.com> writes:
> I have Solaris with Sun CC. Does that count? What do I do, just run
> the testsuite?

Yes, with and without the patch, and show that there are no
regressions.

Some of the thread tests are nondeterministic, so don't worry about
much there.

Re: RFA symtab: Fix for PR c++/1267 ("next" and shared libraries)

[Eli Zaretskii]

> Date: Thu, 24 Jul 2003 16:58:40 -0400
> From: Daniel Jacobowitz <drow@mvista.com>
> > 
> > For 6.0, could you test it on a COFF toolchain, and on some non-GNU
> > toolchain?  It would be nice to have those three PR's closed in 6.0.
> 
> I no longer have access to any non-GNU toolchains.  I'll try to build a
> COFF simulator target and give it a whirl, though...

You could build a cross DJGPP version.  DJGPP supports COFF if you
compile with -gcoff.

Re: RFA symtab: Fix for PR c++/1267 ("next" and shared libraries)

[Daniel Jacobowitz]

On Fri, Jul 25, 2003 at 09:04:09AM +0200, Eli Zaretskii wrote:
> > Date: Thu, 24 Jul 2003 16:58:40 -0400
> > From: Daniel Jacobowitz <drow@mvista.com>
> > > 
> > > For 6.0, could you test it on a COFF toolchain, and on some non-GNU
> > > toolchain?  It would be nice to have those three PR's closed in 6.0.
> > 
> > I no longer have access to any non-GNU toolchains.  I'll try to build a
> > COFF simulator target and give it a whirl, though...
> 
> You could build a cross DJGPP version.  DJGPP supports COFF if you
> compile with -gcoff.

Yes - unfortunately there's no simulator, so I couldn't test it.

I tried my usual COFF targets: arm-coff did not build GCC, and sh-coff
built but the testsuite results were terrible (1680 failures even
without my patch).  I give up - I can't test it on a COFF system.

Adam's results on Solaris were perfect, however - no regressions except
for an expect fluke in one of the prompt tests.

Thoughts?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA symtab: Fix for PR c++/1267 ("next" and shared libraries)

[Daniel Jacobowitz]

On Thu, Jul 24, 2003 at 02:59:27PM -0500, Jim Blandy wrote:
> 
> For the trunk, put it in, definitely.

Done.

> For 6.0, could you test it on a COFF toolchain, and on some non-GNU
> toolchain?  It would be nice to have those three PR's closed in 6.0.

With some help, I've done this.  Solaris CC, no regressions; sh-coff,
no regressions (but crappy test results - 671 failures).

If nothing shows up on the trunk this week, I'll move it over.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA symtab: Fix for PR c++/1267 ("next" and shared libraries)

[Andrew Cagney]

> By the way, I'm convinced that all is not well in step_over_function.  This
> comment,
> 
>   /* NOTE: cagney/2003-04-06:
> 
>      The intent of DEPRECATED_SAVED_PC_AFTER_CALL was to:
> 
>      - provide a very light weight equivalent to frame_unwind_pc()
>      (nee FRAME_SAVED_PC) that avoids the prologue analyzer
> 
>      - avoid handling the case where the PC hasn't been saved in the
>      prologue analyzer
> 
>      Unfortunatly, not five lines further down, is a call to
>      get_frame_id() and that is guarenteed to trigger the prologue
>      analyzer.
> 
> is either incorrect or has gotten out of sync with the code:

Nope (it pays to look at the archives).

>   if (DEPRECATED_SAVED_PC_AFTER_CALL_P ())
>     sr_sal.pc = ADDR_BITS_REMOVE (DEPRECATED_SAVED_PC_AFTER_CALL (get_current_frame ()));
>   else
>     sr_sal.pc = ADDR_BITS_REMOVE (frame_pc_unwind (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);
> 
> 
> Note that get_frame_id unwinds from the NEXT frame, and
> frame_pc_unwind/DEPRECATED_SAVED_PC_AFTER_CALL unwind from THIS frame.
> This throws me a loop every time I have to work in this function.  Also, I
> have the nagging feeling we're saving the wrong frame.  I have an old MIPS
> patch where I needed to use get_prev_frame in step_over_function.  As soon
> as I have time to revisit that patch I'll be back to clean this up some
> more.

The complete code body is:

   if (DEPRECATED_SAVED_PC_AFTER_CALL_P ())
     sr_sal.pc = ADDR_BITS_REMOVE (DEPRECATED_SAVED_PC_AFTER_CALL 
(get_current_frame ()));
   else
     sr_sal.pc = ADDR_BITS_REMOVE (frame_pc_unwind (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);

   if (frame_id_p (step_frame_id)
       && !IN_SOLIB_DYNSYM_RESOLVE_CODE (sr_sal.pc))
     step_resume_breakpoint->frame_id = step_frame_id;

while the original code looks like:

   struct symtab_and_line sr_sal;

   init_sal (&sr_sal);		/* initialize to zeros */
   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_current_frame (), 
bp_step_resume);

   if (step_frame_address && !IN_SOLIB_DYNSYM_RESOLVE_CODE (sr_sal.pc))
     step_resume_breakpoint->frame = step_frame_address;

   if (breakpoints_inserted)
     insert_breakpoints ();

It would appear that the get_frame_id() call has been wrong for a long 
long time but, at a guess, was worked around by picking up step_frame_id 
/ step_frame_address.

Andrew

Re: RFA symtab: Fix for PR c++/1267 ("next" and shared libraries)

[Daniel Jacobowitz]

On Mon, Jul 21, 2003 at 12:18:28PM -0400, Andrew Cagney wrote:
> 
> >By the way, I'm convinced that all is not well in step_over_function.  This
> >comment,
> >
> >  /* NOTE: cagney/2003-04-06:
> >
> >     The intent of DEPRECATED_SAVED_PC_AFTER_CALL was to:
> >
> >     - provide a very light weight equivalent to frame_unwind_pc()
> >     (nee FRAME_SAVED_PC) that avoids the prologue analyzer
> >
> >     - avoid handling the case where the PC hasn't been saved in the
> >     prologue analyzer
> >
> >     Unfortunatly, not five lines further down, is a call to
> >     get_frame_id() and that is guarenteed to trigger the prologue
> >     analyzer.
> >
> >is either incorrect or has gotten out of sync with the code:
> 
> Nope (it pays to look at the archives).
> 
> >  if (DEPRECATED_SAVED_PC_AFTER_CALL_P ())
> >    sr_sal.pc = ADDR_BITS_REMOVE (DEPRECATED_SAVED_PC_AFTER_CALL 
> >    (get_current_frame ()));
> >  else
> >    sr_sal.pc = ADDR_BITS_REMOVE (frame_pc_unwind (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);
> >
> >
> >Note that get_frame_id unwinds from the NEXT frame, and
> >frame_pc_unwind/DEPRECATED_SAVED_PC_AFTER_CALL unwind from THIS frame.
> >This throws me a loop every time I have to work in this function.  Also, I
> >have the nagging feeling we're saving the wrong frame.  I have an old MIPS
> >patch where I needed to use get_prev_frame in step_over_function.  As soon
> >as I have time to revisit that patch I'll be back to clean this up some
> >more.
> 
> The complete code body is:
> 
>   if (DEPRECATED_SAVED_PC_AFTER_CALL_P ())
>     sr_sal.pc = ADDR_BITS_REMOVE (DEPRECATED_SAVED_PC_AFTER_CALL 
> (get_current_frame ()));
>   else
>     sr_sal.pc = ADDR_BITS_REMOVE (frame_pc_unwind (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);
> 
>   if (frame_id_p (step_frame_id)
>       && !IN_SOLIB_DYNSYM_RESOLVE_CODE (sr_sal.pc))
>     step_resume_breakpoint->frame_id = step_frame_id;
> 
> while the original code looks like:
> 
>   struct symtab_and_line sr_sal;
> 
>   init_sal (&sr_sal);		/* initialize to zeros */
>   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_current_frame (), 
> bp_step_resume);
> 
>   if (step_frame_address && !IN_SOLIB_DYNSYM_RESOLVE_CODE (sr_sal.pc))
>     step_resume_breakpoint->frame = step_frame_address;
> 
>   if (breakpoints_inserted)
>     insert_breakpoints ();

No, really, I still think that the comment is wrong.  The get_frame_id
call triggers the prologue analyzer to analyze the NEXT frame.  I.E.
this_id is called with the NEXT frame, and THIS cache.

The call to frame_pc_unwind uses THIS frame and creates the PREV cache. 
It's one frame off on the stack.  The frame it would be saving from
prologue analysis is not the one we'd need to analyze for the
get_frame_id call.

What am I missing?  Certainly you converted the code correctly, I just
don't understand the comment.

> It would appear that the get_frame_id() call has been wrong for a long 
> long time but, at a guess, was worked around by picking up step_frame_id 
> / step_frame_address.

Maybe...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA symtab: Fix for PR c++/1267 ("next" and shared libraries)

[Andrew Cagney]

> 
> No, really, I still think that the comment is wrong.  The get_frame_id
> call triggers the prologue analyzer to analyze the NEXT frame.  I.E.
> this_id is called with the NEXT frame, and THIS cache.

Nope. get_frame_id triggers the analysis of THIS frame's prologue (i.e., 
next_frame & this_cache).

> The call to frame_pc_unwind uses THIS frame and creates the PREV cache. 
> It's one frame off on the stack.  The frame it would be saving from
> prologue analysis is not the one we'd need to analyze for the
> get_frame_id call.

Nope.  frame_pc_unwind would turn into frame_register_unwind (this, 
PC_REGNUM) and that will also trigger the analysis of THIS frame's 
prologue (i.e., next_frame & this_cache).

Andrew

Re: RFA symtab: Fix for PR c++/1267 ("next" and shared libraries)

[Daniel Jacobowitz]

On Mon, Jul 21, 2003 at 02:22:34PM -0400, Andrew Cagney wrote:
> >
> >No, really, I still think that the comment is wrong.  The get_frame_id
> >call triggers the prologue analyzer to analyze the NEXT frame.  I.E.
> >this_id is called with the NEXT frame, and THIS cache.
> 
> Nope. get_frame_id triggers the analysis of THIS frame's prologue (i.e., 
> next_frame & this_cache).
> 
> >The call to frame_pc_unwind uses THIS frame and creates the PREV cache. 
> >It's one frame off on the stack.  The frame it would be saving from
> >prologue analysis is not the one we'd need to analyze for the
> >get_frame_id call.
> 
> Nope.  frame_pc_unwind would turn into frame_register_unwind (this, 
> PC_REGNUM) and that will also trigger the analysis of THIS frame's 
> prologue (i.e., next_frame & this_cache).

Ah, I see where I was confused.  Thanks.  I really need to spend more
time looking at this.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer