Go to file
Andrew Burgess 6d84a385ed gdb: more debug output for displaced stepping
While investigating a displaced stepping issue I wanted an easy way to
see what GDB thought the original instruction was, and what
instruction GDB replaced that with when performing the displaced step.

We do print out the address that is being stepped, so I can track down
the original instruction, I just need to go find the information
myself.

And we do print out the bytes of the new instruction, so I can figure
out what the replacement instruction was, but it's not really easy.

Also, the code that prints the bytes of the replacement instruction
only prints 4 bytes, which clearly isn't always going to be correct.

In this commit I remove the existing code that prints the bytes of the
replacement instruction, and add two new blocks of code to
displaced_step_prepare_throw.  This new code prints the original
instruction, and the replacement instruction.  In each case we print
both the bytes that make up the instruction and the completely
disassembled instruction.

Here's an example of what the output looks like on x86-64 (this is
with 'set debug displaced on').  The two interesting lines contain the
strings 'original insn' and 'replacement insn':

  (gdb) step
  [displaced] displaced_step_prepare_throw: displaced-stepping 2892655.2892655.0 now
  [displaced] displaced_step_prepare_throw: original insn 0x401030: ff 25 e2 2f 00 00	jmp    *0x2fe2(%rip)        # 0x404018 <puts@got.plt>
  [displaced] prepare: selected buffer at 0x401052
  [displaced] prepare: saved 0x401052: 1e fa 31 ed 49 89 d1 5e 48 89 e2 48 83 e4 f0 50
  [displaced] fixup_riprel: %rip-relative addressing used.
  [displaced] fixup_riprel: using temp reg 2, old value 0x7ffff7f8a578, new value 0x401036
  [displaced] amd64_displaced_step_copy_insn: copy 0x401030->0x401052: ff a1 e2 2f 00 00 68 00 00 00 00 e9 e0 ff ff ff
  [displaced] displaced_step_prepare_throw: prepared successfully thread=2892655.2892655.0, original_pc=0x401030, displaced_pc=0x401052
  [displaced] displaced_step_prepare_throw: replacement insn 0x401052: ff a1 e2 2f 00 00	jmp    *0x2fe2(%rcx)
  [displaced] finish: restored 2892655.2892655.0 0x401052
  [displaced] amd64_displaced_step_fixup: fixup (0x401030, 0x401052), insn = 0xff 0xa1 ...
  [displaced] amd64_displaced_step_fixup: restoring reg 2 to 0x7ffff7f8a578
  0x00007ffff7e402c0 in puts () from /lib64/libc.so.6
  (gdb)

One final note.  For many targets that support displaced stepping (in
fact all targets except ARM) the replacement instruction is always a
single instruction.  But on ARM the replacement could actually be a
series of instructions.

The debug code tries to handle this by disassembling the entire
displaced stepping buffer.  Obviously this might actually print more
than is necessary, but there's (currently) no easy way to know how
many instructions to disassemble; that knowledge is all locked in the
architecture specific code.  Still I don't think it really hurts, if
someone is looking at this debug then hopefully they known what to
expect.

Obviously we can imagine schemes where the architecture specific
displaced stepping code could communicate back how many bytes its
replacement sequence was, and then our debug print code could use this
to limit the disassembly.  But this seems like a lot of effort just to
save printing a few additional instructions in some debug output.

I'm not proposing to do anything about this issue for now.

Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-29 08:57:10 +01:00
bfd Sanity check section size in bfd_init_section_compress_status 2023-03-29 12:56:46 +10:30
binutils
config
contrib
cpu
elfcpp
etc
gas Avoid undefined behaviour in m68hc11 md_begin 2023-03-28 21:04:30 +10:30
gdb gdb: more debug output for displaced stepping 2023-03-29 08:57:10 +01:00
gdbserver
gdbsupport
gnulib
gold
gprof
gprofng gprofng: 30089 [display text] Invalid number of threads 2023-03-27 11:47:52 -07:00
include
intl
ld ld testsuite CFLAGS_FOR_TARGET 2023-03-29 12:56:46 +10:30
libbacktrace
libctf
libdecnumber
libiberty
libsframe
opcodes
readline
sim
texinfo
zlib
.cvsignore
.editorconfig
.gitattributes
.gitignore
ar-lib
ChangeLog
compile
config-ml.in
config.guess
config.rpath
config.sub
configure
configure.ac
COPYING
COPYING3
COPYING3.LIB
COPYING.LIB
COPYING.LIBGLOSS
COPYING.NEWLIB
depcomp
djunpack.bat
install-sh
libtool.m4
lt~obsolete.m4
ltgcc.m4
ltmain.sh
ltoptions.m4
ltsugar.m4
ltversion.m4
MAINTAINERS
Makefile.def
Makefile.in
Makefile.tpl
makefile.vms
missing
mkdep
mkinstalldirs
move-if-change
multilib.am
README
README-maintainer-mode
setup.com
src-release.sh
symlink-tree
test-driver
ylwrap

		   README for GNU development tools

This directory contains various GNU compilers, assemblers, linkers, 
debuggers, etc., plus their support routines, definitions, and documentation.

If you are receiving this as part of a GDB release, see the file gdb/README.
If with a binutils release, see binutils/README;  if with a libg++ release,
see libg++/README, etc.  That'll give you info about this
package -- supported targets, how to use it, how to report bugs, etc.

It is now possible to automatically configure and build a variety of
tools with one command.  To build all of the tools contained herein,
run the ``configure'' script here, e.g.:

	./configure 
	make

To install them (by default in /usr/local/bin, /usr/local/lib, etc),
then do:
	make install

(If the configure script can't determine your type of computer, give it
the name as an argument, for instance ``./configure sun4''.  You can
use the script ``config.sub'' to test whether a name is recognized; if
it is, config.sub translates it to a triplet specifying CPU, vendor,
and OS.)

If you have more than one compiler on your system, it is often best to
explicitly set CC in the environment before running configure, and to
also set CC when running make.  For example (assuming sh/bash/ksh):

	CC=gcc ./configure
	make

A similar example using csh:

	setenv CC gcc
	./configure
	make

Much of the code and documentation enclosed is copyright by
the Free Software Foundation, Inc.  See the file COPYING or
COPYING.LIB in the various directories, for a description of the
GNU General Public License terms under which you can copy the files.

REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info
on where and how to report problems.