diff options
| author | Martin Galvan <martin.galvan@tallertechnologies.com> | 2015-05-26 11:59:17 +0100 |
|---|---|---|
| committer | Yao Qi <yao.qi@linaro.org> | 2015-05-26 12:07:59 +0100 |
| commit | c9cf6e20c6988a7e510cfe788b1b2cfe4d0d04a7 (patch) | |
| tree | e85959002942a5ae2bf83aaf38e833538cf96776 /gdb/gdbarch.h | |
| parent | 4de0562a4c69fef4952aa7e19d7bda359f02e8b4 (diff) | |
| download | gdb-c9cf6e20c6988a7e510cfe788b1b2cfe4d0d04a7.zip gdb-c9cf6e20c6988a7e510cfe788b1b2cfe4d0d04a7.tar.gz gdb-c9cf6e20c6988a7e510cfe788b1b2cfe4d0d04a7.tar.bz2 | |
Rename in_function_epilogue_p to stack_frame_destroyed_p
We concluded that gdbarch_in_function_epilogue_p is misnamed, since it
returns true if the given PC is one instruction after the one that
destroyed the stack (which isn't necessarily inside an epilogue),
therefore it should be renamed to stack_frame_destroyed_p.
I also took the liberty of renaming the arch-specific implementations to
*_stack_frame_destroyed_p as well for consistency.
gdb:
2015-05-26 Martin Galvan <martin.galvan@tallertechnologies.com>
* amd64-tdep.c: Replace in_function_epilogue_p with
stack_frame_destroyed_p throughout.
* arch-utils.c: Ditto.
* arch-utils.h: Ditto.
* arm-tdep.c: Ditto.
* breakpoint.c: Ditto.
* gdbarch.sh: Ditto.
* hppa-tdep.c: Ditto.
* i386-tdep.c: Ditto.
* mips-tdep.c: Ditto.
* nios2-tdep.c: Ditto.
* rs6000-tdep.c: Ditto.
* s390-linux-tdep.c: Ditto.
* score-tdep.c: Ditto.
* sh-tdep.c: Ditto.
* sparc-tdep.c: Ditto.
* sparc-tdep.h: Ditto.
* sparc64-tdep.c: Ditto.
* spu-tdep.c: Ditto.
* tic6x-tdep.c: Ditto.
* tilegx-tdep.c: Ditto.
* xstormy16-tdep.c: Ditto.
* gdbarch.c, gdbarch.h: Re-generated.
Diffstat (limited to 'gdb/gdbarch.h')
| -rw-r--r-- | gdb/gdbarch.h | 8 |
1 files changed, 4 insertions, 4 deletions
diff --git a/gdb/gdbarch.h b/gdb/gdbarch.h index c94c19c..6f9e844 100644 --- a/gdb/gdbarch.h +++ b/gdb/gdbarch.h @@ -685,7 +685,7 @@ extern void set_gdbarch_in_solib_return_trampoline (struct gdbarch *gdbarch, gdb /* A target might have problems with watchpoints as soon as the stack frame of the current function has been destroyed. This mostly happens - as the first action in a funtion's epilogue. in_function_epilogue_p() + as the first action in a function's epilogue. stack_frame_destroyed_p() is defined to return a non-zero value if either the given addr is one instruction after the stack destroying instruction up to the trailing return instruction or if we can figure out that the stack frame has @@ -693,9 +693,9 @@ extern void set_gdbarch_in_solib_return_trampoline (struct gdbarch *gdbarch, gdb which don't suffer from that problem could just let this functionality untouched. */ -typedef int (gdbarch_in_function_epilogue_p_ftype) (struct gdbarch *gdbarch, CORE_ADDR addr); -extern int gdbarch_in_function_epilogue_p (struct gdbarch *gdbarch, CORE_ADDR addr); -extern void set_gdbarch_in_function_epilogue_p (struct gdbarch *gdbarch, gdbarch_in_function_epilogue_p_ftype *in_function_epilogue_p); +typedef int (gdbarch_stack_frame_destroyed_p_ftype) (struct gdbarch *gdbarch, CORE_ADDR addr); +extern int gdbarch_stack_frame_destroyed_p (struct gdbarch *gdbarch, CORE_ADDR addr); +extern void set_gdbarch_stack_frame_destroyed_p (struct gdbarch *gdbarch, gdbarch_stack_frame_destroyed_p_ftype *stack_frame_destroyed_p); /* Process an ELF symbol in the minimal symbol table in a backend-specific way. Normally this hook is supposed to do nothing, however if required, |