aboutsummaryrefslogtreecommitdiff
path: root/zlib
diff options
context:
space:
mode:
authorSimon Marchi <simon.marchi@efficios.com>2020-06-29 11:27:40 -0400
committerSimon Marchi <simon.marchi@efficios.com>2020-06-29 11:27:46 -0400
commit19b187a978c5229578ca20627c23eb2b3553f24b (patch)
tree6cedff92eafa97785f8ca9b14f37c51d6b09e9bf /zlib
parentdf5b8876083ec8c7bfb44ecb91b516c864edebfd (diff)
downloadgdb-19b187a978c5229578ca20627c23eb2b3553f24b.zip
gdb-19b187a978c5229578ca20627c23eb2b3553f24b.tar.gz
gdb-19b187a978c5229578ca20627c23eb2b3553f24b.tar.bz2
gdb: fix documentation of gdbarch_displaced_step_copy_insn
I spotted something that looks wrong in the doc of gdbarch_displaced_step_copy_insn. It says that if the function returns NULL, it means that it has emulated the behavior of the instruction and written the result to REGS. However, it says below that the function may return NULL to indicate that the instruction can't be single-stepped out-of-line, in which case the core steps the instruction in-line. The two are contradictory. The right one is the latter, if the function returns NULL, the core falls back to in-line stepping. I checked all the implementations of this function and they all agree with this. gdb/ChangeLog: * gdbarch.sh (displaced_step_copy_insn): Update doc. * gdbarch.h: Re-generate. Change-Id: I98163cdd38970cde4c77680e249b10f5d2d5bf9b
Diffstat (limited to 'zlib')
0 files changed, 0 insertions, 0 deletions