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

[RFA/ia64] Limit prologue scanning to end of function


Hello,

This is a local fix that we made a couple of years ago, which we
forgot to submit for inclusion, somehow.

Basically, it's kind of hard to determine the end of a function
prologue on ia64 just by scanning the function code. So the examine_prologue
routine in ia64-tdep.c often ends up scanning a bit more code
than is necessary. As a consequence, this might cause us to go
too far when trying to skip the prologue.

To help in that task, we have a routine, called refine_prologue_limit,
whose job is to try using the line number information to find a better
limit for our function prologue. The problem is that this function needs
to handle optimizations where the compiler intermingles the different
lines:

      /* Handle the case in which compiler's optimizer/scheduler
         has moved instructions into the prologue.  We scan ahead
         in the function looking for address ranges whose corresponding
         line number is less than or equal to the first one that we
         found for the function.  (It can be less than when the
         scheduler puts a body instruction before the first prologue
         instruction.)  */
      for (i = 2 * max_skip_non_prologue_insns;
           i > 0 && (lim_pc == 0 || addr < lim_pc);
           i--)

In some cases, the PC range given is larger than the function size.
As a result, we end up testing some line numbers that are actually
not part of the same routine, and sometimes selecting it (if the line
number is smaller).

The fix is simply to reduce the initial range to the function end
address.

2007-09-17  Joel Brobecker  <brobecker@adacore.com>

        * ia64-tdep.c (refine_prologue_limit): Make sure we don't scan
        the linetable past the function end.

Tested on ia64-linux, no regression.
OK to commit? I also suggest this fix for gdb-6.7, since it looks
pretty safe. However, I think that the chances of a function whose
associated lines are smaller, and yet have a higher PC are relatively
small. So perhaps not worth the risk.

Thanks,
-- 
Joel

Attachment: refine_limit.diff
Description: Text document


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