xtensa: GDB: Unable to debug

[SebastianBoe]

Hi,

I am trying to debug an xtensa application, but when running gdb I get the below error message.

Affects: qemu_xtensa
Does not affect: qemu_cortex_m3, qemu_x86, qemu_riscv32, qemu_nios2

Remote 'g' packet reply is too long: 000000500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000feda80c2474d06211f000000000000000000000000000000000000002800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Some system information:

sebo@mach:~/workspace_zephyr$ printenv | grep zephyr
ZEPHYR_SDK_INSTALL_DIR=/home/sebo/zephyr-sdk
ZEPHYR_BASE=/home/sebo/zephyr
PWD=/home/sebo/workspace_zephyr
ZEPHYR_GCC_VARIANT=zephyr
PREBUILT_HOST_TOOLS=/home/sebo/workspace_zephyr/.build

sebo@mach:~/workspace_zephyr/zephyr/tests/kernel/common$ cat /home/sebo/zephyr-sdk/sdk_version
0.9.1

sebo@mach:~/workspace_zephyr/zephyr/tests/kernel/common$ git log -1 | head --lines=3
commit 4fbf721
Author: Robert Chou [email protected]
Date: Mon Sep 18 14:13:06 2017 +0800

[SebastianBoe]

@nashif : I tried upgrading the SDK from 0.9.1 to 0.9.2-rc5 in case that fixed the problem,
but then I immediately got the symptoms from

#1510

back

EDIT: No longer able to reproduce this particular observation.

[SebastianBoe]

The gdb-multiarch workaround of #4312 does not resolve this issue, so presumably this is not a duplicate of #4312

[nashif]

which gdb did you use?

[nashif]

re #1510, what exactly are you getting?

[SebastianBoe]

which gdb did you use?

I've tried with 3 GDB clients.

Ubuntu's gdb.

gdb --version
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1

Ubuntu's gdb-multiarch

sebo@mach:~ / workspace_zephyr$ gdb-multiarch --version
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1

SDK 0.9.1's xtensa gdb client

sebo@mach:~/workspace_zephyr$ /home/sebo/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/xtensa-zephyr-elf/xtensa-zephyr-elf-gdb --version
GNU gdb (GDB) 7.11.0.20160511-git

I get the same result with all of them.

[SebastianBoe]

re #1510, what exactly are you getting?

Sorry, I don't know how I got this result:

I tried upgrading the SDK from 0.9.1 to 0.9.2-rc5 in case that fixed the problem,
but then I immediately got the symptoms from

#1510

back

Upgrading to 0.9.2-rc5 now gives the same error as 0.9.1.

[SebastianBoe]

I get the same error with qemu_riscv32, but not with

qemu_cortex_m3, qemu_nios2, qemu_x86

[SebastianBoe]

IMHO this issue is critical.

Not being able to debug a platform makes it impossible to make changes to the
core of Zephyr (Unless you are lucky and can debug without gdb).

This issue blocks #4296

[MaureenHelm]

@SebastianBoe Is this still an issue?

[SebastianBoe]

Yes.

Reproduced again with 43bc304

sebo@mach:~/zephyr/samples/hello_world$ ninja -C b/ debugserver

sebo@mach:~/zephyr/samples/hello_world$ /home/sebo/zephyr-sdk-0.9.2-rc5/sysroots/x86_64-pokysdk-linux/usr/bin/xtensa-zephyr-elf/xtensa-zephyr-elf-gdb ~/zephyr/samples/hello_world/b/zephyr/zephyr.elf 
GNU gdb (GDB) 7.11.0.20160511-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-pokysdk-linux --target=xtensa-zephyr-elf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/sebo/zephyr/samples/hello_world/b/zephyr/zephyr.elf...done.
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
Remote 'g' packet reply is too long: 000000500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000feda80c2474d06211f000000000000000000000000000000000000002800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
(gdb) c
The program is not being run.

[MaureenHelm]

@rgundi @SavinayDharmappa Any update on this issue?

[nashif]

@jcmvbkbc any idea what is going on here? This sounds like an issue with the toolchain itself.

[jcmvbkbc]

@nashif I agree, that sounds like discrepancy between qemu view of registers (it provides both privileged and unprivileged registers through its gdb server) and gdb view of registers (by default it only expects unprivileged registers). So far I used to modify xtensa configuration overlay applied to gdb source to mark all registers as unprivileged. But probably a better solution is to fix xtensa gdb and make it accept both privileged and unprivileged registers when it's configured for xtensa*-*-elf.

[jcmvbkbc]

I've added the following patch to the top of the zephyr SDK: jcmvbkbc/meta-zephyr-sdk@42be8b4 and rebuilt SDK.
I was able to run qemu-system-xtensa -M sim -cpu sample_controller -nographic -s -S and connect to it from the new xtensa-zephyr-elf-gdb. I can confirm that without that patch xtensa-zephyr-elf-gdb cannot connect to qemu-system-xtensa gdbserver.

[nashif]

thanks @jcmvbkbc , lowering priority since this is an SDK issue.

[andrewboie]

I think this still needs to be high priority, this issue wastes a tremendous amount of expensive developer time

[nashif]

@rgundi please verify the fix above: see https://github.com/zephyrproject-rtos/meta-zephyr-sdk/releases/tag/0.9.3-rc3

[rgundi]

@nashif , verified the fix. It is working. thanks @jcmvbkbc.

[nashif]

fixed in latest SDK