It turns out I had already modified the offsets in nuttx_header when I took a quick stab at this a few months back. I guess it has been so long that I forgot. Thank you very much for pointing me in the right direction on this Alan.

I will definitely be giving your new gdb script a try Masayuki. Thank you for all of your work on NuttX debugging!

- John

On 8/27/20 8:16 PM, Masayuki Ishikawa wrote:
Hi Alan and all,

Alan's comment is right.

Because openocd-nuttx needs to know about tcb_s members in NuttX to access
them.
and both values must be the same. Otherwise, openocd-nuttx does not work
correctly.

However, this procedure is sometimes annoying (even for me) if we are
debugging
multiple targets having different configurations.

So, I implemented .nuttx-gdbinit which is a gdb script and it does not rely
on openocd-nuttx.
Actually, we can do thread-aware debugging for the NuttX simulator on
x86_64 for
which we can not use openocd.

Of course, we can do thread-aware debugging for the NuttX for Cortex-M
boards
with **normal** openocd as well.

The script is still experimental and not merged into the NuttX upstream and
it has to
be used with gdb supporting python. For Arm environment, we have to use
arm-none-eabi-gdb-py
instead of arm-none-eabi-gdb. Actually I'm using the following gdb to debug
Cortex-M boards.

$ arm-none-eabi-gdb-py --version

GNU gdb (GNU Tools for Arm Embedded Processors 9-2019-q4-major)
8.3.0.20190709-git

So if you are interested in the script. Please try the following git.

$ git clone -b gdbinit_for_nuttx
https://github.com/masayuki2009/incubator-nuttx

On Fri, Aug 28, 2020 at 6:59 AM Alan Carvalho de Assis <acas...@gmail.com>
wrote:

Hi John,

If the tcb_s values returned are the same from openocd header, then
you don't need to do anything. If they are different you need to
update, otherwise it will not work reliably.

BR,

Alan

On 8/27/20, John Rippetoe <jrippe...@roboticresearch.com> wrote:
Alan,

Thanks for sending this! Gustavo's suggestion of adding the '-rtos
nuttx' flag to my config did the trick, so maybe this process isn't
needed anymore?

- John

On 8/27/20 5:29 PM, Alan Carvalho de Assis wrote:
Hi John,

On 8/27/20, John Rippetoe <jrippe...@roboticresearch.com> wrote:
Hi everyone,

I recently jumped back into working on the FDCAN driver for the STM32H7
and have something working which I would like to test further. In doing
so, I was hoping to easily debug with GDB through OpenOCD, but am
having
some issues with the necessary setup. So far I have compiled and tested
the upstream master of OpenOCD, master of the Sony OpenOCD fork, and a
third build that merged the latest upstream OpenOCD commits into the
Sony fork. With all three, I am only ever able to see the currently
running thread (nearly always IDLE) when running the "info threads"
command.

So my question is, does anyone have any experience getting this
working?
I looked through the mailing list and saw a few messages regarding this
very thing for different architectures. I've also dug around on the
internet to help me piece together what needed to be done to get this
working. I initially got the impression that as long as OpenOCD
supports
your chip, thread aware-debugging should be possible, but now I'm not
so
sure. I modified nuttx_header.h within OpenOCD with the correct offset
values as noted here

https://micro-ros.github.io/docs/tutorials/advanced/nuttx/debugging/

That didn't change anything, unfortunately. I also thought it was
possible this step was no longer needed based on the Sony fork's wiki
page

https://github.com/sony/openocd-nuttx/wiki

The monitor commands listed there gave me "invalid command name" errors
when loading my nuttx binary.

Any help on this would be greatly appreciated.

I tested it some years ago and Masayuki gave me some important
instructions:

1) You need to include "-rtos nuttx" in the target create line of the
/usr/local/share/openocd/scripts/target/stm32f4x.cfg to use with
stm32f4discovery board:

target create $_TARGETNAME cortex_m -endian $_ENDIAN -dap
$_CHIPNAME.dap -rtos nuttx

2) Add this code to your .gdbinit

define print-offset
    print /x &((struct tcb_s *)(0))->pid
    print /x &((struct tcb_s *)(0))->xcp.regs
    print /x &((struct tcb_s *)(0))->task_state
    print /x &((struct tcb_s *)(0))->name
    print /x sizeof(((struct tcb_s *)(0))->name)
end

Then start gdb with nuttx to load the symbol.

$ arm-none-eabi-gdb ./nuttx

Before connecting to the target, obtain the symbol offsets in tcb.

(gdb) print-offset
$1 = 0xc
$2 = 0x80
$3 = 0x1a
$4 = 0xcc
$5 = 0x20
(gdb)

Then you need to put those value inside the header file:
openocd/src/rtos/nuttx_header.h replacing the existing value:

/* default offset */
#define PID  0xc
#define XCPREG  0x70
#define STATE 0x19
#define NAME 0xb8
#define NAME_SIZE 32

Compile and install again openocd with the right values.

I hope it help you!

BR,

Alan
CONFIDENTIALITY NOTICE: This communication may contain private,
confidential
and privileged material for the sole use of the intended recipient. If
you
are not the intended recipient, please delete this e-mail and any
attachments permanently.


CONFIDENTIALITY NOTICE: This communication may contain private, confidential 
and privileged material for the sole use of the intended recipient. If you are 
not the intended recipient, please delete this e-mail and any attachments 
permanently.

Reply via email to