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] |
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] |