mbox series

[00/19] Basic gdbserver for POWER8

Message ID 20180829015047.7355-1-rashmica.g@gmail.com
Headers show
Series Basic gdbserver for POWER8 | expand

Message

Rashmica Gupta Aug. 29, 2018, 1:50 a.m. UTC 
I have rebased Alistair's gdbserver on master and done a few cleanups.
I have been using Amitay's patch "main: Add P8 kernel devicetree" when
running on a BMC.

This should let you do basic things through gdb like examine the
registers, read and write to kernel memory, and step through the
kernel. There is obviously a lot more to be done, but it would be nice
to get some of this upstream so I don't have to keep rebasing as often :)

Currently this is only designed to work on kernel addresses (as the
translation to real addresses is trivial). Any thoughts on how we
could/should go about dealing with address translations are welcome.
It would be nice if we could attempt to deal with kernel virtual
addresses and skiboot addresses.


Alistair Popple (2):
  pdbg/gdbserver: Add in basic skeleton for a gdbserver on p8
  pdbg/gdbserver: Make ragel optional

Rashmica Gupta (17):
  pdbg: Fix function call for putnia command
  libpdbg: Print the name of the instruction when erroring
  libpdbg: Add in getxer and putxer functions
  pdbg: Add getxer & putxer commands
  libpdbg: Make getcr actually get all of the Condition Register
  libpdbg: Add in mtocrf and putcr function
  pdbg: Add getcr and putcr options
  libpdbg: Check if scom controllers are exposed
  pdbg: Make return codes consistent for get/put registers
  libpdbg: Remove unused error code
  pdbg: Add in parser for uint16_t
  libpdbg: Add in enable_attn function for p8
  pdbg/gdbserver: Make gdbserver optional
  pdbg/gdbserver: Add in other functions for gdb info registers
  pdbg/gdbserver: Detach from client
  libpdbg: Release adu lock when erroring out
  README: Add some gdbserver info

 .gitignore                  |   1 +
 Makefile.am                 |  34 ++-
 README.md                   |  26 +++
 configure.ac                |  10 +
 libpdbg/adu.c               |   1 +
 libpdbg/chip.c              | 109 +++++++---
 libpdbg/chip.h              |  24 ++
 libpdbg/host.c              |  10 +-
 libpdbg/libpdbg.h           |   7 +-
 libpdbg/operations.h        |  10 +-
 libpdbg/p8chip.c            | 127 +++++++++++
 libpdbg/p9chip.c            |  31 ++-
 libpdbg/target.c            |  16 ++
 libpdbg/target.h            |   6 +
 src/gdb_parser.rl           | 146 +++++++++++++
 src/gdb_parser_precompile.c | 410 ++++++++++++++++++++++++++++++++++
 src/main.c                  |  12 +-
 src/parsers.c               |  18 ++
 src/parsers.h               |   2 +
 src/pdbgproxy.c             | 519 ++++++++++++++++++++++++++++++++++++++++++++
 src/pdbgproxy.h             |  13 ++
 src/reg.c                   |  48 +++-
 22 files changed, 1529 insertions(+), 51 deletions(-)
 create mode 100644 libpdbg/chip.h
 create mode 100644 src/gdb_parser.rl
 create mode 100644 src/gdb_parser_precompile.c
 create mode 100644 src/pdbgproxy.c
 create mode 100644 src/pdbgproxy.h

Comments

Nicholas Piggin Aug. 29, 2018, 8:49 a.m. UTC | #1 
On Wed, 29 Aug 2018 11:50:28 +1000
Rashmica Gupta <rashmica.g@gmail.com> wrote:

> I have rebased Alistair's gdbserver on master and done a few cleanups.
> I have been using Amitay's patch "main: Add P8 kernel devicetree" when
> running on a BMC.
> 
> This should let you do basic things through gdb like examine the
> registers, read and write to kernel memory, and step through the
> kernel. There is obviously a lot more to be done, but it would be nice
> to get some of this upstream so I don't have to keep rebasing as often :)
> 
> Currently this is only designed to work on kernel addresses (as the
> translation to real addresses is trivial). Any thoughts on how we
> could/should go about dealing with address translations are welcome.
> It would be nice if we could attempt to deal with kernel virtual
> addresses and skiboot addresses.

Yeah, I think we'll have to walk Linux page tables for this, because
doing HPT translations is horrific, and the hash table doesn't keep
all xlates around anyway.

I would say start with radix, because we can find and walk the page
tables architecturally so that will work nicely.

I'd say maybe we could just treat all addresses below 0x4... as un
translated and then we can just use straight skiboot (and other host
real) addresses. Do we really care about user memory from pdbg? I'd
say host real would be more useful.

Other option might be to use some high bit like 0x1... for host real
but that would mean you can't cut and paste addresses and I'm quite
lazy.

Thanks,
Nick