public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
* [RFC][PATCH 0/7] Patching new code in a binary
@ 2020-05-14 14:08 paul-naert
  2020-05-14 14:08 ` [RFC][PATCH 1/7] Add addr argument to infcall_mmap paul-naert
                   ` (7 more replies)
  0 siblings, 8 replies; 13+ messages in thread
From: paul-naert @ 2020-05-14 14:08 UTC (permalink / raw)
  To: gdb-patches; +Cc: Paul Naert

From: Paul Naert <paul_naert@hotmail.fr>

Hi,
I'm looking for input on a series of patches that I wrote to extend the compile command. At the moment, this commands lets the user type in C/C++ code that is compiled by GCC and then executed in the context of the program.
The idea of the new 'patch' command is to inject the code generated by the compile command directly in the binary instead of executing it once. This makes it possible to dynamically instrument code, either for tracing, checking the behavior of a modification/bug fix without recompiling everything, or creating verification tools based on GDB.

The injection of the code is done in a similar fashion to GDB tracepoints, by replacing the original instruction with a JUMP instruction to a trampoline.
The trampoline :
 - saves the registers
 - loads the register argument of the gdb_expr() function into memory. The gdb_expr() function is the instrumentation code compiled by GCC (I've re-used the infrastructure of the compile command to compile and load the code into memory)
 - Restores the registers
 - Executes the displaced original instruction
 - Jumps to the next instruction.

I have implemented this functionality on the x86_64 architecture. I have tried putting code in the proper files, but I am not exactly sure for everything.
In this series of patches I introduced new commands, but I did not fully comply with the contribution checklist as this is a RFC.
If there is interest in the commands, I will work on the documentation and test cases.

Known issues :
- Vector registers. Even when we ask GCC not to use the vector registers, they are still affected sometimes by the isntrumentation code. This means that we need to save and restore them every time, which brings a performance cost. In this series of patches, saving and restoring vector registers is not included.
- Red zone handling. This complicates the trampoline. I believe that this issue was fixed by the manipulation I did in the trampoline, but this seems to be absent from the GDB tracepoints. Is there something I missed or is this a bug of fast tracepoints?
- Since we save and restore all registers, some instrumentation code may not be able to properly modify variable values.
- In this series of patches, only instructions >= 5 bytes can be instrumented, as is the case with fast tracepoints.

Future work :
If the community is interested in this functionnality, I have also worked on making it more usable by getting rid of the 5 byte limitation using instruction punning. This series of patches works, but is not compliant yet with the GDB standards.

Thanks for your feedback,
Paul NAERT

Paul Naert (1):
  Add the patch command to dynamically inject code in the inferior

paul-naert (6):
  Add addr argument to infcall_mmap
  Change memory protection for compile arguments to RW
  Make create_sals_from_location_default non static
  Add address argument to compile_to_object
  Add the option to defer register storage for compiled object loading. 
  Convert short jumps to long ones in amd64_relocate_instruction    


 gdb/Makefile.in                   |   3 +-
 gdb/amd64-tdep.c                  | 231 ++++++++++++++++++++++++++-
 gdb/arch-utils.c                  |   2 +-
 gdb/arch-utils.h                  |   2 +-
 gdb/breakpoint.c                  |  10 +-
 gdb/breakpoint.h                  |   5 +
 gdb/compile/compile-c-support.c   |   5 +
 gdb/compile/compile-internal.h    |  18 +++
 gdb/compile/compile-object-load.c |  61 +++++---
 gdb/compile/compile-object-load.h |   7 +
 gdb/compile/compile-object-run.c  |   6 +
 gdb/compile/compile-patch.c       | 322 ++++++++++++++++++++++++++++++++++++++
 gdb/compile/compile.c             |  24 ++-
 gdb/defs.h                        |   3 +
 gdb/gdbarch.c                     |  86 +++++++++-
 gdb/gdbarch.h                     |  17 +-
 gdb/gdbarch.sh                    |   3 +-
 gdb/linux-tdep.c                  |   4 +-
 18 files changed, 762 insertions(+), 47 deletions(-)
 create mode 100644 gdb/compile/compile-patch.c

-- 
2.7.4


^ permalink raw reply	[flat|nested] 13+ messages in thread
end of thread, other threads:[~2020-05-22 19:57 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-14 14:08 [RFC][PATCH 0/7] Patching new code in a binary paul-naert
2020-05-14 14:08 ` [RFC][PATCH 1/7] Add addr argument to infcall_mmap paul-naert
2020-05-14 14:08 ` [RFC][PATCH 2/7] Change memory protection for compile arguments to RW paul-naert
2020-05-22 19:18   ` Tom Tromey
2020-05-14 14:08 ` [RFC][PATCH 3/7] Make create_sals_from_location_default non static paul-naert
2020-05-14 14:08 ` [RFC][PATCH 4/7] Add address argument to compile_to_object paul-naert
2020-05-14 14:08 ` [RFC][PATCH 5/7] Add the option to defer register storage for compiled object loading paul-naert
2020-05-22 19:39   ` Tom Tromey
2020-05-14 14:08 ` [RFC][PATCH 6/7] Convert short jumps to long ones in amd64_relocate_instruction paul-naert
2020-05-22 19:41   ` Tom Tromey
2020-05-14 14:08 ` [RFC][PATCH 7/7] Add the patch command to dynamically inject code in the inferior paul-naert
2020-05-22 19:50   ` Tom Tromey
2020-05-22 19:57 ` [RFC][PATCH 0/7] Patching new code in a binary Tom Tromey

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).