Re: [RFA/RFC] fix problems with unwinder on mips-irix

[Andrew Cagney <cagney at gnu dot org>]

[something ate some e-mail during a local mailer upgrade, I'm replying 
using what I saw on the web]

> Reading your last commit to this file, I discovered that you added frame
> sniffers, so, if I understand correctly, we can now more or less predict
> the circumstances under which find_proc_desc should be called (heuristic
> vs non-heuristic). Is that right?

Right, but it is stronger than more-or-less :-)  mips_insn32_frame_cache 
need only worry about 32-bit sized instructions and a heuristic prologue 
analysis.

As for inlineing, remember the focus is solely on 
mips_insn32_frame_cache as that's the one with the immediate bug:

>   3. mips_insn32_frame_cache
>
>      In these two cases, the call to find_proc_desc can be reduced to
>      the case where the heuristics have to be used. You said it can be
>      inline using something like this:
>
>       if (startaddr == 0)
>         startaddr = heuristic_proc_start (pc);
>
>       proc_desc = heuristic_proc_desc (startaddr, pc, next_frame, cur_frame);
>
>      I see that linked_proc_desc_table is never used, which explains
>      why we can get rid of:
>
>       /* Is linked_proc_desc_table really necessary?  It only seems to be used
>          by procedure call dummys.  However, the procedures being called ought
>          to have their own proc_descs, and even if they don't,
>          heuristic_proc_desc knows how to create them! */
>
>       struct linked_proc_info *link;
>
>       for (link = linked_proc_desc_table; link; link = link->next)
>         if (PROC_LOW_ADDR (&link->info) <= pc
>             && PROC_HIGH_ADDR (&link->info) > pc)
>           return &link->info;

as for the other potential inlines, I'd let them be.  The'll follow in 
their own good time.

Andrew