This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [mips] When to use a proc_desc


On Wed, Apr 07, 2004 at 01:33:34AM +0200, Mark Kettenis wrote:
>    Date: Tue, 6 Apr 2004 17:58:10 -0400
>    From: Daniel Jacobowitz <drow@false.org>
> 
>    On Tue, Apr 06, 2004 at 05:56:46PM -0400, Andrew Cagney wrote:
>    > >I'll need to study this further, however, look at HP/UX.
>    > >
>    > >That unwinder checks its equivalent PDR against the prologue, ticking each 
>    > >register off as it is encountered.
>    > 
>    > I think the long answer is the same -- look at HP/UX.  Fetch the PDR and 
>    > then compare it against the instructions up-to $pc to see how many of 
>    > those stores actually occured.
> 
>    I think that defeats the point of having the proc_desc in the first
>    place.  If we're only going to acknowledge register saves that we can
>    'easily' find, then why bother reading any of this out of the proc_desc
>    at all?
> 
> Because it allows one to determine where the prologue actually ends,
> which is after all registers described by the descriptor have been
> saved.

Hmm, you're saying - scan the function until we have seen all the
marked registers saved and then stop scanning for more saves?  That's
interesting, but I'm not sure how useful it is.  It's very different
from the way we use proc_desc's now.  I'll have to think about it.

Or just punt, rip out the GAS .pdr support, and add dwarf2 CFI support;
it should just be a matter of flipping the switch now.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]