open-ocd zephyr rtos awarness, not supported

[manoj153]

Zephyr RTOS awareness not available, zephyr's developer mentioned their open-ocd build support such awareness, so I am concluding that the issue/limitation is from cortex-debug

attach the issue explaining the problem :

https://github.com/zephyrproject-rtos/openocd/issues/42

[haneefdm]

RTOS awareness is always enabled in cortex-debug.

However, you need to enable RTOS awareness in your gdb-server. In your case, your gdb-server is OpenOCD. You can do it two ways

In launch.json, you can specify rtos option. That does not always work depending on the chip vendor. A better way is to use the rtos option in your openocd config files.

Another caveat is to use the proper variant on OpenOCD. Too many forks. There are many bugs in OpenOCD as well, so your mileage may vary. OpenOCD does not follow the gdb protocol properly.

Have you tried pyocd instead?

[manoj153]

The following RTOS values are supported by OpenOCD: eCos ThreadX FreeRTOS ChibiOS embKernel mqx uCOS-III auto

Based on the above, zephyr is not even listed in the list. Will that be an issue?

[manoj153]

I think that message is not coming from openOCD, suspect from cortex-debug available command option for rtos Please correct me if there's any wrong

[haneefdm]

Yes, that is an issue. Zephyr has their own fork. OpenOCD is so fragmented

https://github.com/zephyrproject-rtos/openocd

Look at the OpenOCD log to see if it recognized the RTOS

[Marus]

Yes, this is also an issue with OpenOCD an how fragmented it is; I don't think there is any reason why we couldn't add support for it in the values we allow in the cortex-debug configuration - just with the caveat that it is actually only supported if you are using the Zephyr fork of OpenOCD. Will look at this sometime this week or next weekend.

[manoj153]

Yes, this is also an issue with OpenOCD an how fragmented it is; I don't think there is any reason why we couldn't add support for it in the values we allow in the cortex-debug configuration - just with the caveat that it is actually only supported if you are using the Zephyr fork of OpenOCD. Will look at this sometime this week or next weekend.

thanks, @Marus , is this something I can easily edit a central JSON like a file, to add the support and try on my end? Meanwhile, I will try to get my hands on manual GDB commands to test OpenOCD itself

[haneefdm]

I must have fixed half a dozen bugs in Cypress fork of OpenOCD. Even a single step did not work -- would cause an infinite loop. You can get a bogus stack trace in threaded mode at reset. Disconnect does not work properly.

[Marus]

The valid values for validation of the configuration is in the OPENOCD_VALID_RTOS constant of the src/frontend/configprovider.ts file - I would just need to know the value that you'd pass to OpenOCD after the -rtos argument.

But as @haneefdm warned - we've found the reliability of the debugger in RTOS mode to be... flakey at best; with somewhat erratic behaviour/result from GDB. So while I can easily enable it for you to try - I can't give you any guarantees on how well it will behave (in particular behaviour seems to go off the rails if you at any point have a breakpoint before the OS is fully initialized - as we try to read task information at that point to populate the UI - and if the OS isn't initialized you can get into very weird states - sometimes breaking the GDB session entirely)

[Marus]

Also - if you have a mini example project for Zephyr OS you could share that would be useful - just for me to try things out a little bit - ideally something targeting something from the STM32 line (just because I have a wide variety of STM32 boards). Always good to have sample projects to exercise different functionality of the extension.

[manoj153]

Hi @Marus , if your board is supported by zephyr(high likely) pretty easy to run their example, need to pass board argument to their build helper called (west)

All supported board are listed here: https://docs.zephyrproject.org/latest/boards/index.html

A basic example is: https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/hello_world

Let me know if you need any additional info to get you up to speed.

https://docs.zephyrproject.org/latest/guides/west/build-flash-debug.html

[manoj153]

've found the reliability of the debugger in RTOS mode to be... flakey at best; with somewhat erratic behaviour/result from GDB. So while I can easily enable it for you to try - I can't give you any guarantees on how well it will behave (in particular behaviour seems to go off the rails if you at any point have a breakpoint before the OS is fully initialized - as we try to read task information at that point to populate the UI - and if the OS isn't initialized you can get into very weird states - sometimes breaking the GDB session entirely)

Thanks for the warning, yeah I think with the warning, I don't mind testing, hopefully, can think of a solution as well. no harm to test I feel.

[Marus]

I'll try to get something up and running later this week and make a test build with the support enabled in the extension - then you can try it out and see how it works

[manuargue]

I added Zephyr to the configprovider.ts OpenOCD list and setup my launch.json to use the version patched by Zephyr project as below:

          "serverpath": "/opt/zephyr-sdk-0.11.4/sysroots/x86_64-pokysdk-linux/usr/bin/openocd",
          "rtos": "Zephyr",

I added CONFIG_OPENOCD_SUPPORT=y to the prj.conf in the zephyr/sample/hello_world project as instructed here prior building. I'm not sure what to expect but I can see the internal Zephyr variables by using the watch view, e.g.:

[Marus]

Well, if the RTOS awareness is working then when execution is halted for a breakpoint (or you just paused) then the stack area should show the stack frames for all tasks in the RTOS - not just for the currently executing task.

[manuargue]

That seems to be working fine, stack frames are shown for all the threads. Also I'm able to run thread-related commands on the debug console (such as info threads, thread apply and the like). But seems that setting breakpoints with Cortex-debug before the kernel is fully initialized may break the debug sessions sometimes, so I would not recommend to do so.

[Marus]

Yeah, in general GDB and/or the GDB sever can get messed up if you do certain things before the kernel is fully initialized - that unfortunately isn’t Zephyr specific. But looks like it is working as well as the RTOS aware debugging does in general (that is to say nicely when it works but temperamental at times).

I’ll include this with the 0.3.11 release in the next day or so.

[haneefdm]

Btw, setting breakpoints before the RTOS is initialized is just fine as they are based on actual addresses in your program. However, you will see a weird/untrustworthy stack at launch until the RTOS has completely initialized and it looks even better after tasks/threads have been created

Closing this as 0.3.11/12 had been released a while ago,

Cleaning up issues that are either stale or already resolved.