coreboot-kgpe-d16/payloads/libpayload/gdb/transport.c

253 lines
6.5 KiB
C
Raw Normal View History

libpayload: Add remote GDB support This patch adds the ability to attach a GDB host through the UART to a running payload. Libpayload implements a small stub that can parse and respond to the GDB remote protocol and provide the required primitives (reading/writing registers/memory, etc.) to allow GDB to control execution. The goal of this implementation is to be as small and uninvasive as possible. It implements only the minimum amount of primitives required, and relies on GDB's impressive workaround capabilities (such as emulating breakpoints by temporarily replacing instructions) for the more complicated features. This way, a relatively tiny amount of code on the firmware side opens a vast range of capabilities to the user, not just in debugging but also in remote-controlling the firmware to change its behavior (e.g. through GDBs ability to modify variables and call functions). By default, a system with the REMOTEGDB Kconfig will only trap into GDB when executing halt() (including the calls from die_if(), assert(), and exception handlers). In addition, payloads can manually call gdb_enter() if desired. It will print a final "Ready for GDB connection." on the serial, detach the normal serial output driver and wait for the commands that GDB starts sending on attach. Based on original implementation by Gabe Black <gabeblack@chromium.org>. BUG=chrome-os-partner:18390 TEST=Boot a GDB enabled image in recovery mode (or get it to hit a halt()), close your terminal, execute '<toolchain>-gdb --symbols /build/<board>/firmware/depthcharge_gdb/depthcharge.elf --directory ~/trunk/src/third_party/coreboot/payloads/libpayload --directory ~/trunk/src/platform/depthcharge --directory ~/trunk/src/platform/vboot_reference --ex "target remote <cpu_uart_pty>"' and behold the magic. (You can also SIGSTOP your terminal's parent shell and the terminal itself, and SIGCONT them in reverse order after GDB exits. More convenient wrapper tools to do all this automatically coming soon.) Original-Change-Id: Ib440d1804126cdfdac4a8801f5015b4487e25269 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/202563 Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> (cherry picked from commit 9c4a642c7be2faf122fef39bdfaddd64aec68b77) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I9238b4eb19d3ab2c98e4e1c5946cd7d252ca3c3b Reviewed-on: http://review.coreboot.org/8119 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-05-15 20:57:38 +02:00
/*
* Copyright 2014 Google Inc.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
* the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but without any warranty; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
Remove address from GPLv2 headers As per discussion with lawyers[tm], it's not a good idea to shorten the license header too much - not for legal reasons but because there are tools that look for them, and giving them a standard pattern simplifies things. However, we got confirmation that we don't have to update every file ever added to coreboot whenever the FSF gets a new lease, but can drop the address instead. util/kconfig is excluded because that's imported code that we may want to synchronize every now and then. $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} + $ find * -type f -a \! -name \*.patch \ -a \! -name \*_shipped \ -a \! -name LICENSE_GPL \ -a \! -name LGPL.txt \ -a \! -name COPYING \ -a \! -name DISCLAIMER \ -exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} + Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9233 Tested-by: build bot (Jenkins) Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-03-26 15:17:45 +01:00
* Foundation, Inc.
libpayload: Add remote GDB support This patch adds the ability to attach a GDB host through the UART to a running payload. Libpayload implements a small stub that can parse and respond to the GDB remote protocol and provide the required primitives (reading/writing registers/memory, etc.) to allow GDB to control execution. The goal of this implementation is to be as small and uninvasive as possible. It implements only the minimum amount of primitives required, and relies on GDB's impressive workaround capabilities (such as emulating breakpoints by temporarily replacing instructions) for the more complicated features. This way, a relatively tiny amount of code on the firmware side opens a vast range of capabilities to the user, not just in debugging but also in remote-controlling the firmware to change its behavior (e.g. through GDBs ability to modify variables and call functions). By default, a system with the REMOTEGDB Kconfig will only trap into GDB when executing halt() (including the calls from die_if(), assert(), and exception handlers). In addition, payloads can manually call gdb_enter() if desired. It will print a final "Ready for GDB connection." on the serial, detach the normal serial output driver and wait for the commands that GDB starts sending on attach. Based on original implementation by Gabe Black <gabeblack@chromium.org>. BUG=chrome-os-partner:18390 TEST=Boot a GDB enabled image in recovery mode (or get it to hit a halt()), close your terminal, execute '<toolchain>-gdb --symbols /build/<board>/firmware/depthcharge_gdb/depthcharge.elf --directory ~/trunk/src/third_party/coreboot/payloads/libpayload --directory ~/trunk/src/platform/depthcharge --directory ~/trunk/src/platform/vboot_reference --ex "target remote <cpu_uart_pty>"' and behold the magic. (You can also SIGSTOP your terminal's parent shell and the terminal itself, and SIGCONT them in reverse order after GDB exits. More convenient wrapper tools to do all this automatically coming soon.) Original-Change-Id: Ib440d1804126cdfdac4a8801f5015b4487e25269 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/202563 Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> (cherry picked from commit 9c4a642c7be2faf122fef39bdfaddd64aec68b77) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I9238b4eb19d3ab2c98e4e1c5946cd7d252ca3c3b Reviewed-on: http://review.coreboot.org/8119 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-05-15 20:57:38 +02:00
*/
#include <endian.h>
libpayload: Add remote GDB support This patch adds the ability to attach a GDB host through the UART to a running payload. Libpayload implements a small stub that can parse and respond to the GDB remote protocol and provide the required primitives (reading/writing registers/memory, etc.) to allow GDB to control execution. The goal of this implementation is to be as small and uninvasive as possible. It implements only the minimum amount of primitives required, and relies on GDB's impressive workaround capabilities (such as emulating breakpoints by temporarily replacing instructions) for the more complicated features. This way, a relatively tiny amount of code on the firmware side opens a vast range of capabilities to the user, not just in debugging but also in remote-controlling the firmware to change its behavior (e.g. through GDBs ability to modify variables and call functions). By default, a system with the REMOTEGDB Kconfig will only trap into GDB when executing halt() (including the calls from die_if(), assert(), and exception handlers). In addition, payloads can manually call gdb_enter() if desired. It will print a final "Ready for GDB connection." on the serial, detach the normal serial output driver and wait for the commands that GDB starts sending on attach. Based on original implementation by Gabe Black <gabeblack@chromium.org>. BUG=chrome-os-partner:18390 TEST=Boot a GDB enabled image in recovery mode (or get it to hit a halt()), close your terminal, execute '<toolchain>-gdb --symbols /build/<board>/firmware/depthcharge_gdb/depthcharge.elf --directory ~/trunk/src/third_party/coreboot/payloads/libpayload --directory ~/trunk/src/platform/depthcharge --directory ~/trunk/src/platform/vboot_reference --ex "target remote <cpu_uart_pty>"' and behold the magic. (You can also SIGSTOP your terminal's parent shell and the terminal itself, and SIGCONT them in reverse order after GDB exits. More convenient wrapper tools to do all this automatically coming soon.) Original-Change-Id: Ib440d1804126cdfdac4a8801f5015b4487e25269 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/202563 Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> (cherry picked from commit 9c4a642c7be2faf122fef39bdfaddd64aec68b77) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I9238b4eb19d3ab2c98e4e1c5946cd7d252ca3c3b Reviewed-on: http://review.coreboot.org/8119 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-05-15 20:57:38 +02:00
#include <gdb.h>
#include <libpayload.h>
/* MMIO word size is not standardized, but *usually* 32 (even on ARM64) */
typedef u32 mmio_word_t;
libpayload: Add remote GDB support This patch adds the ability to attach a GDB host through the UART to a running payload. Libpayload implements a small stub that can parse and respond to the GDB remote protocol and provide the required primitives (reading/writing registers/memory, etc.) to allow GDB to control execution. The goal of this implementation is to be as small and uninvasive as possible. It implements only the minimum amount of primitives required, and relies on GDB's impressive workaround capabilities (such as emulating breakpoints by temporarily replacing instructions) for the more complicated features. This way, a relatively tiny amount of code on the firmware side opens a vast range of capabilities to the user, not just in debugging but also in remote-controlling the firmware to change its behavior (e.g. through GDBs ability to modify variables and call functions). By default, a system with the REMOTEGDB Kconfig will only trap into GDB when executing halt() (including the calls from die_if(), assert(), and exception handlers). In addition, payloads can manually call gdb_enter() if desired. It will print a final "Ready for GDB connection." on the serial, detach the normal serial output driver and wait for the commands that GDB starts sending on attach. Based on original implementation by Gabe Black <gabeblack@chromium.org>. BUG=chrome-os-partner:18390 TEST=Boot a GDB enabled image in recovery mode (or get it to hit a halt()), close your terminal, execute '<toolchain>-gdb --symbols /build/<board>/firmware/depthcharge_gdb/depthcharge.elf --directory ~/trunk/src/third_party/coreboot/payloads/libpayload --directory ~/trunk/src/platform/depthcharge --directory ~/trunk/src/platform/vboot_reference --ex "target remote <cpu_uart_pty>"' and behold the magic. (You can also SIGSTOP your terminal's parent shell and the terminal itself, and SIGCONT them in reverse order after GDB exits. More convenient wrapper tools to do all this automatically coming soon.) Original-Change-Id: Ib440d1804126cdfdac4a8801f5015b4487e25269 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/202563 Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> (cherry picked from commit 9c4a642c7be2faf122fef39bdfaddd64aec68b77) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I9238b4eb19d3ab2c98e4e1c5946cd7d252ca3c3b Reviewed-on: http://review.coreboot.org/8119 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-05-15 20:57:38 +02:00
static const int timeout_us = 100 * 1000;
static const char output_overrun[] = "GDB output buffer overrun (try "
"increasing reply.size)!\n";
static const char input_underrun[] = "GDB input message truncated (bug or "
"communication problem)?\n";
/* Serial-specific glue code... add more transport layers here when desired. */
static void gdb_raw_putchar(u8 c)
{
serial_putchar(c);
}
static int gdb_raw_getchar(void)
{
u64 start = timer_us(0);
while (!serial_havechar())
if (timer_us(start) > timeout_us)
return -1;
return serial_getchar();
}
void gdb_transport_init(void)
{
console_remove_output_driver(serial_putchar);
}
void gdb_transport_teardown(void)
{
serial_console_init();
}
/* Hex digit character <-> number conversion (illegal chars undefined!). */
static u8 from_hex(unsigned char c)
libpayload: Add remote GDB support This patch adds the ability to attach a GDB host through the UART to a running payload. Libpayload implements a small stub that can parse and respond to the GDB remote protocol and provide the required primitives (reading/writing registers/memory, etc.) to allow GDB to control execution. The goal of this implementation is to be as small and uninvasive as possible. It implements only the minimum amount of primitives required, and relies on GDB's impressive workaround capabilities (such as emulating breakpoints by temporarily replacing instructions) for the more complicated features. This way, a relatively tiny amount of code on the firmware side opens a vast range of capabilities to the user, not just in debugging but also in remote-controlling the firmware to change its behavior (e.g. through GDBs ability to modify variables and call functions). By default, a system with the REMOTEGDB Kconfig will only trap into GDB when executing halt() (including the calls from die_if(), assert(), and exception handlers). In addition, payloads can manually call gdb_enter() if desired. It will print a final "Ready for GDB connection." on the serial, detach the normal serial output driver and wait for the commands that GDB starts sending on attach. Based on original implementation by Gabe Black <gabeblack@chromium.org>. BUG=chrome-os-partner:18390 TEST=Boot a GDB enabled image in recovery mode (or get it to hit a halt()), close your terminal, execute '<toolchain>-gdb --symbols /build/<board>/firmware/depthcharge_gdb/depthcharge.elf --directory ~/trunk/src/third_party/coreboot/payloads/libpayload --directory ~/trunk/src/platform/depthcharge --directory ~/trunk/src/platform/vboot_reference --ex "target remote <cpu_uart_pty>"' and behold the magic. (You can also SIGSTOP your terminal's parent shell and the terminal itself, and SIGCONT them in reverse order after GDB exits. More convenient wrapper tools to do all this automatically coming soon.) Original-Change-Id: Ib440d1804126cdfdac4a8801f5015b4487e25269 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/202563 Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> (cherry picked from commit 9c4a642c7be2faf122fef39bdfaddd64aec68b77) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I9238b4eb19d3ab2c98e4e1c5946cd7d252ca3c3b Reviewed-on: http://review.coreboot.org/8119 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-05-15 20:57:38 +02:00
{
static const s8 values[] = {
-1, 10, 11, 12, 13, 14, 15, -1,
-1, -1, -1, -1, -1, -1, -1, -1,
0, 1, 2, 3, 4, 5, 6, 7,
8, 9, -1, -1, -1, -1, -1, -1,
};
return values[c & 0x1f];
}
static char to_hex(u8 v)
{
static const char digits[] = "0123456789abcdef";
return digits[v & 0xf];
}
/* Message encode/decode functions (must access whole aligned words for MMIO) */
libpayload: Add remote GDB support This patch adds the ability to attach a GDB host through the UART to a running payload. Libpayload implements a small stub that can parse and respond to the GDB remote protocol and provide the required primitives (reading/writing registers/memory, etc.) to allow GDB to control execution. The goal of this implementation is to be as small and uninvasive as possible. It implements only the minimum amount of primitives required, and relies on GDB's impressive workaround capabilities (such as emulating breakpoints by temporarily replacing instructions) for the more complicated features. This way, a relatively tiny amount of code on the firmware side opens a vast range of capabilities to the user, not just in debugging but also in remote-controlling the firmware to change its behavior (e.g. through GDBs ability to modify variables and call functions). By default, a system with the REMOTEGDB Kconfig will only trap into GDB when executing halt() (including the calls from die_if(), assert(), and exception handlers). In addition, payloads can manually call gdb_enter() if desired. It will print a final "Ready for GDB connection." on the serial, detach the normal serial output driver and wait for the commands that GDB starts sending on attach. Based on original implementation by Gabe Black <gabeblack@chromium.org>. BUG=chrome-os-partner:18390 TEST=Boot a GDB enabled image in recovery mode (or get it to hit a halt()), close your terminal, execute '<toolchain>-gdb --symbols /build/<board>/firmware/depthcharge_gdb/depthcharge.elf --directory ~/trunk/src/third_party/coreboot/payloads/libpayload --directory ~/trunk/src/platform/depthcharge --directory ~/trunk/src/platform/vboot_reference --ex "target remote <cpu_uart_pty>"' and behold the magic. (You can also SIGSTOP your terminal's parent shell and the terminal itself, and SIGCONT them in reverse order after GDB exits. More convenient wrapper tools to do all this automatically coming soon.) Original-Change-Id: Ib440d1804126cdfdac4a8801f5015b4487e25269 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/202563 Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> (cherry picked from commit 9c4a642c7be2faf122fef39bdfaddd64aec68b77) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I9238b4eb19d3ab2c98e4e1c5946cd7d252ca3c3b Reviewed-on: http://review.coreboot.org/8119 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-05-15 20:57:38 +02:00
void gdb_message_encode_bytes(struct gdb_message *message, const void *data,
int length)
{
die_if(message->used + length * 2 > message->size, output_overrun);
const mmio_word_t *aligned =
(mmio_word_t *)ALIGN_DOWN((uintptr_t)data, sizeof(*aligned));
mmio_word_t word = be32toh(readl(aligned++));
libpayload: Add remote GDB support This patch adds the ability to attach a GDB host through the UART to a running payload. Libpayload implements a small stub that can parse and respond to the GDB remote protocol and provide the required primitives (reading/writing registers/memory, etc.) to allow GDB to control execution. The goal of this implementation is to be as small and uninvasive as possible. It implements only the minimum amount of primitives required, and relies on GDB's impressive workaround capabilities (such as emulating breakpoints by temporarily replacing instructions) for the more complicated features. This way, a relatively tiny amount of code on the firmware side opens a vast range of capabilities to the user, not just in debugging but also in remote-controlling the firmware to change its behavior (e.g. through GDBs ability to modify variables and call functions). By default, a system with the REMOTEGDB Kconfig will only trap into GDB when executing halt() (including the calls from die_if(), assert(), and exception handlers). In addition, payloads can manually call gdb_enter() if desired. It will print a final "Ready for GDB connection." on the serial, detach the normal serial output driver and wait for the commands that GDB starts sending on attach. Based on original implementation by Gabe Black <gabeblack@chromium.org>. BUG=chrome-os-partner:18390 TEST=Boot a GDB enabled image in recovery mode (or get it to hit a halt()), close your terminal, execute '<toolchain>-gdb --symbols /build/<board>/firmware/depthcharge_gdb/depthcharge.elf --directory ~/trunk/src/third_party/coreboot/payloads/libpayload --directory ~/trunk/src/platform/depthcharge --directory ~/trunk/src/platform/vboot_reference --ex "target remote <cpu_uart_pty>"' and behold the magic. (You can also SIGSTOP your terminal's parent shell and the terminal itself, and SIGCONT them in reverse order after GDB exits. More convenient wrapper tools to do all this automatically coming soon.) Original-Change-Id: Ib440d1804126cdfdac4a8801f5015b4487e25269 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/202563 Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> (cherry picked from commit 9c4a642c7be2faf122fef39bdfaddd64aec68b77) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I9238b4eb19d3ab2c98e4e1c5946cd7d252ca3c3b Reviewed-on: http://review.coreboot.org/8119 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-05-15 20:57:38 +02:00
while (length--) {
u8 byte = (word >> ((((void *)aligned - data) - 1) * 8));
message->buf[message->used++] = to_hex(byte >> 4);
message->buf[message->used++] = to_hex(byte & 0xf);
if (length && ++data == (void *)aligned)
word = be32toh(readl(aligned++));
libpayload: Add remote GDB support This patch adds the ability to attach a GDB host through the UART to a running payload. Libpayload implements a small stub that can parse and respond to the GDB remote protocol and provide the required primitives (reading/writing registers/memory, etc.) to allow GDB to control execution. The goal of this implementation is to be as small and uninvasive as possible. It implements only the minimum amount of primitives required, and relies on GDB's impressive workaround capabilities (such as emulating breakpoints by temporarily replacing instructions) for the more complicated features. This way, a relatively tiny amount of code on the firmware side opens a vast range of capabilities to the user, not just in debugging but also in remote-controlling the firmware to change its behavior (e.g. through GDBs ability to modify variables and call functions). By default, a system with the REMOTEGDB Kconfig will only trap into GDB when executing halt() (including the calls from die_if(), assert(), and exception handlers). In addition, payloads can manually call gdb_enter() if desired. It will print a final "Ready for GDB connection." on the serial, detach the normal serial output driver and wait for the commands that GDB starts sending on attach. Based on original implementation by Gabe Black <gabeblack@chromium.org>. BUG=chrome-os-partner:18390 TEST=Boot a GDB enabled image in recovery mode (or get it to hit a halt()), close your terminal, execute '<toolchain>-gdb --symbols /build/<board>/firmware/depthcharge_gdb/depthcharge.elf --directory ~/trunk/src/third_party/coreboot/payloads/libpayload --directory ~/trunk/src/platform/depthcharge --directory ~/trunk/src/platform/vboot_reference --ex "target remote <cpu_uart_pty>"' and behold the magic. (You can also SIGSTOP your terminal's parent shell and the terminal itself, and SIGCONT them in reverse order after GDB exits. More convenient wrapper tools to do all this automatically coming soon.) Original-Change-Id: Ib440d1804126cdfdac4a8801f5015b4487e25269 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/202563 Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> (cherry picked from commit 9c4a642c7be2faf122fef39bdfaddd64aec68b77) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I9238b4eb19d3ab2c98e4e1c5946cd7d252ca3c3b Reviewed-on: http://review.coreboot.org/8119 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-05-15 20:57:38 +02:00
}
}
void gdb_message_decode_bytes(const struct gdb_message *message, int offset,
void *data, int length)
{
die_if(offset + 2 * length > message->used, "Decode overrun in GDB "
"message: %.*s", message->used, message->buf);
mmio_word_t *aligned =
(mmio_word_t *)ALIGN_DOWN((uintptr_t)data, sizeof(*aligned));
int shift = ((void *)(aligned + 1) - data) * 8;
mmio_word_t word = be32toh(readl(aligned)) >> shift;
libpayload: Add remote GDB support This patch adds the ability to attach a GDB host through the UART to a running payload. Libpayload implements a small stub that can parse and respond to the GDB remote protocol and provide the required primitives (reading/writing registers/memory, etc.) to allow GDB to control execution. The goal of this implementation is to be as small and uninvasive as possible. It implements only the minimum amount of primitives required, and relies on GDB's impressive workaround capabilities (such as emulating breakpoints by temporarily replacing instructions) for the more complicated features. This way, a relatively tiny amount of code on the firmware side opens a vast range of capabilities to the user, not just in debugging but also in remote-controlling the firmware to change its behavior (e.g. through GDBs ability to modify variables and call functions). By default, a system with the REMOTEGDB Kconfig will only trap into GDB when executing halt() (including the calls from die_if(), assert(), and exception handlers). In addition, payloads can manually call gdb_enter() if desired. It will print a final "Ready for GDB connection." on the serial, detach the normal serial output driver and wait for the commands that GDB starts sending on attach. Based on original implementation by Gabe Black <gabeblack@chromium.org>. BUG=chrome-os-partner:18390 TEST=Boot a GDB enabled image in recovery mode (or get it to hit a halt()), close your terminal, execute '<toolchain>-gdb --symbols /build/<board>/firmware/depthcharge_gdb/depthcharge.elf --directory ~/trunk/src/third_party/coreboot/payloads/libpayload --directory ~/trunk/src/platform/depthcharge --directory ~/trunk/src/platform/vboot_reference --ex "target remote <cpu_uart_pty>"' and behold the magic. (You can also SIGSTOP your terminal's parent shell and the terminal itself, and SIGCONT them in reverse order after GDB exits. More convenient wrapper tools to do all this automatically coming soon.) Original-Change-Id: Ib440d1804126cdfdac4a8801f5015b4487e25269 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/202563 Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> (cherry picked from commit 9c4a642c7be2faf122fef39bdfaddd64aec68b77) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I9238b4eb19d3ab2c98e4e1c5946cd7d252ca3c3b Reviewed-on: http://review.coreboot.org/8119 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-05-15 20:57:38 +02:00
while (length--) {
word <<= 8;
word |= from_hex(message->buf[offset++]) << 4;
word |= from_hex(message->buf[offset++]);
if (++data - (void *)aligned == sizeof(*aligned))
writel(htobe32(word), aligned++);
}
if (data != (void *)aligned) {
shift = ((void *)(aligned + 1) - data) * 8;
clrsetbits_be32(aligned, ~((1 << shift) - 1), word << shift);
libpayload: Add remote GDB support This patch adds the ability to attach a GDB host through the UART to a running payload. Libpayload implements a small stub that can parse and respond to the GDB remote protocol and provide the required primitives (reading/writing registers/memory, etc.) to allow GDB to control execution. The goal of this implementation is to be as small and uninvasive as possible. It implements only the minimum amount of primitives required, and relies on GDB's impressive workaround capabilities (such as emulating breakpoints by temporarily replacing instructions) for the more complicated features. This way, a relatively tiny amount of code on the firmware side opens a vast range of capabilities to the user, not just in debugging but also in remote-controlling the firmware to change its behavior (e.g. through GDBs ability to modify variables and call functions). By default, a system with the REMOTEGDB Kconfig will only trap into GDB when executing halt() (including the calls from die_if(), assert(), and exception handlers). In addition, payloads can manually call gdb_enter() if desired. It will print a final "Ready for GDB connection." on the serial, detach the normal serial output driver and wait for the commands that GDB starts sending on attach. Based on original implementation by Gabe Black <gabeblack@chromium.org>. BUG=chrome-os-partner:18390 TEST=Boot a GDB enabled image in recovery mode (or get it to hit a halt()), close your terminal, execute '<toolchain>-gdb --symbols /build/<board>/firmware/depthcharge_gdb/depthcharge.elf --directory ~/trunk/src/third_party/coreboot/payloads/libpayload --directory ~/trunk/src/platform/depthcharge --directory ~/trunk/src/platform/vboot_reference --ex "target remote <cpu_uart_pty>"' and behold the magic. (You can also SIGSTOP your terminal's parent shell and the terminal itself, and SIGCONT them in reverse order after GDB exits. More convenient wrapper tools to do all this automatically coming soon.) Original-Change-Id: Ib440d1804126cdfdac4a8801f5015b4487e25269 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/202563 Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> (cherry picked from commit 9c4a642c7be2faf122fef39bdfaddd64aec68b77) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I9238b4eb19d3ab2c98e4e1c5946cd7d252ca3c3b Reviewed-on: http://review.coreboot.org/8119 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-05-15 20:57:38 +02:00
}
}
void gdb_message_encode_zero_bytes(struct gdb_message *message, int length)
{
die_if(message->used + length * 2 > message->size, output_overrun);
memset(message->buf + message->used, '0', length * 2);
message->used += length * 2;
}
void gdb_message_add_string(struct gdb_message *message, const char *string)
{
message->used += strlcpy((char *)message->buf + message->used,
string, message->size - message->used);
/* Check >= instead of > to account for strlcpy's trailing '\0'. */
die_if(message->used >= message->size, output_overrun);
}
void gdb_message_encode_int(struct gdb_message *message, uintptr_t val)
{
int length = sizeof(uintptr_t) * 2 - __builtin_clz(val) / 4;
die_if(message->used + length > message->size, output_overrun);
while (length--)
message->buf[message->used++] =
to_hex((val >> length * 4) & 0xf);
}
uintptr_t gdb_message_decode_int(const struct gdb_message *message, int offset,
int length)
{
uintptr_t val = 0;
die_if(length > sizeof(uintptr_t) * 2, "GDB decoding invalid number: "
"%.*s", message->used, message->buf);
while (length--) {
val <<= 4;
val |= from_hex(message->buf[offset++]);
}
return val;
}
/* Like strtok/strsep: writes back offset argument, returns original offset. */
int gdb_message_tokenize(const struct gdb_message *message, int *offset)
{
int token = *offset;
while (!strchr(",;:", message->buf[(*offset)++]))
die_if(*offset >= message->used, "Undelimited token in GDB "
"message at offset %d: %.*s",
token, message->used, message->buf);
return token;
}
/* High-level send/receive functions. */
void gdb_get_command(struct gdb_message *command)
{
enum command_state {
STATE_WAITING,
STATE_COMMAND,
STATE_CHECKSUM0,
STATE_CHECKSUM1,
};
u8 checksum = 0;
u8 running_checksum = 0;
enum command_state state = STATE_WAITING;
while (1) {
int c = gdb_raw_getchar();
if (c < 0) {
/*
* Timeout waiting for a byte. Reset the
* state machine.
*/
state = STATE_WAITING;
continue;
}
switch (state) {
case STATE_WAITING:
if (c == '$') {
running_checksum = 0;
command->used = 0;
state = STATE_COMMAND;
}
break;
case STATE_COMMAND:
if (c == '#') {
state = STATE_CHECKSUM0;
break;
}
die_if(command->used >= command->size, "GDB input buf"
"fer overrun (try increasing command.size)!\n");
command->buf[command->used++] = c;
running_checksum += c;
break;
case STATE_CHECKSUM0:
checksum = from_hex(c) << 4;
state = STATE_CHECKSUM1;
break;
case STATE_CHECKSUM1:
checksum += from_hex(c);
if (running_checksum == checksum) {
gdb_raw_putchar('+');
return;
} else {
state = STATE_WAITING;
gdb_raw_putchar('-');
}
break;
}
}
}
void gdb_send_reply(const struct gdb_message *reply)
{
int i;
int retries = 1 * 1000 * 1000 / timeout_us;
u8 checksum = 0;
for (i = 0; i < reply->used; i++)
checksum += reply->buf[i];
do {
gdb_raw_putchar('$');
for (i = 0; i < reply->used; i++)
gdb_raw_putchar(reply->buf[i]);
gdb_raw_putchar('#');
gdb_raw_putchar(to_hex(checksum >> 4));
gdb_raw_putchar(to_hex(checksum & 0xf));
} while (gdb_raw_getchar() != '+' && retries--);
}