This is the mail archive of the gdb-patches@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]

[mips] Getting rid of heuristic proc_desc


Hello Andrew,

Looking at the mips code, I think the goal is to get rid entirely
of heuristic procedure descriptors. Right now, they are used as
an intermediate frame information recipient on our way to create
frame caches, which is OK in non heuristic cases, but unnecessary
in the heuristic ones. And I'd like to keep the usage of non-heuristic
procedure descriptors as locally contained as possible.

Looking a bit closer, though, I found that we are not quite there
yet. There is a case where we to create proc_descs without
needing a frame cache (to skip the prologue, presumably). And this
is a bit problematic, because in this case we can't replace the
proc desc by the frame cache, since we can not necessarily create
the frame cache.

The only place I see where heuristic_proc_desc() is called and where
it could cause a bit of trouble getting rid of is in after_prologue().
I'll let you look at the code, but this check basically is the only
reason why we try finding the non-heuristic proc_desc and/or the
heuristic one:

  if (proc_desc)
    {
      /* If function is frameless, then we need to do it the hard way.  I
         strongly suspect that frameless always means prologueless... */
      if (PROC_FRAME_REG (proc_desc) == MIPS_SP_REGNUM
          && PROC_FRAME_OFFSET (proc_desc) == 0)
        return 0;
    }

On the one hand, all we appear to be using from the proc_desc is
the PROC_FRAME_REG and PROC_FRAME_OFFSET. So I am thinking we could
in the heuristic case the two values returned by
mips32/mips16__heuristic_proc_desc, and somehow get these values
back to after_prologue.  So we would no longer need the proc_desc,
just these two values.

On the other hand, when I look a bit deeper, I find that
mips_skip_prologue is only used in mips_skip_prologue().

   static CORE_ADDR
   mips_skip_prologue (CORE_ADDR pc)
   {
     /* See if we can determine the end of the prologue via the symbol table.
        If so, then return either PC, or the PC after the prologue, whichever
        is greater.  */
   
     CORE_ADDR post_prologue_pc = after_prologue (pc);
   
     if (post_prologue_pc != 0)
       return max (pc, post_prologue_pc);
   
     /* Can't determine prologue from the symbol table, need to examine
        instructions.  */
   
     if (pc_is_mips16 (pc))
       return mips16_skip_prologue (pc);
     else
       return mips32_skip_prologue (pc);
   }

I was thinking that it should be possible to merge mips32_skip_prologue
inside mips32_heuristic_proc_desc (what a bad name for this function
now).  But I am wondering if this wouldn't make heuristic_proc_desc too
complicated?

I am thinking also that if we were to inline after_prologue inside
mips_skip_prologue, then maybe this would allow us to make some
simplifications...

And maybe all three ideas are orthogonal, and should all be applied?

Hmm.... Not sure which way I should go. Any hunch?

-- 
Joel


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