Ahh, I didn't know what you were refering to by "post file". I understand now. This should really be documented somewhere in our own docs, as I understand this should work with mainline openocd.
Maybe this approach could be extended so that the number of tasks states is also obtained and does not have to be matched against openocd config. I'm still trying to find why I'm getting strange output of thread information. While stopped at NSH's cmd_pwd, I get this: ~" 2 Thread 536871672 (Name: Idle Task, pid:0, READYTORUN) 0x200014f4 in ?? ()\n" >~"* 5 Thread 536876144 (Name: init, pid:1, RUNNING) cmd_pwd (vtbl=0x20001fb0, >argc=1, argv=0x20001e3c) at nsh_envcmds.c:333\n" If I just stopped randomly I get this: >~"* 2 Thread 536871672 (Name: Idle Task, pid:0, RUNNING) 0x000074a0 in up_idle >() at chip/nrf52_idle.c:191\n" >~" 5 Thread 536876144 (Name: init, pid:1, WAIT_SEM) 0x2000037c in g_idletcb >()\n" So for some reason the PC of the active task is not read correctly. On Mon, Nov 23, 2020, at 13:47, Abdelatif Guettouche wrote: > > This is what I tried and works. This is much better than being forced > > to use a specific configuration to get the offsets right or having to > > rebuild openocd each time. > > I will polish the approach and open a draft PR to show how it works. > > > As I said above, you don't have to do that. The OpenOCD support > relies on post file hooks to retrieve these information. > https://github.com/sony/openocd-nuttx/wiki > > > On Mon, Nov 23, 2020 at 3:08 PM Gregory Nutt <spudan...@gmail.com> wrote: > > > > I wonder if we could automate that? Instead of separate debug vs > > production configurations, could not configure.sh/c just create a debug > > configuration by disabling optimization, enabling symbols, enabling > > debug features, assertions, basic error and warning output? > > > > Of course specialize configurations like a networking configure would > > need more (like network debug), but changes like that to configure.sh/c > > would get you 90% there. > > > > On 11/23/2020 7:29 AM, David Sidrane wrote: > > > Perfect! Let's do this as time permits. > > > > > > -----Original Message----- > > > From: Alan Carvalho de Assis [mailto:acas...@gmail.com] > > > Sent: Monday, November 23, 2020 5:09 AM > > > To: dev@nuttx.apache.org > > > Subject: Re: Should TASK_NAME_SIZE be changed in most configs? > > > > > > Yes, I think nsh-debug will make its intention clear. > > > > > > On 11/23/20, Gregory Nutt <spudan...@gmail.com> wrote: > > >> It has always been the policy to disable debug features in all shipped > > >> configurations. They were considered production configurations not > > >> debug configurations. > > >> > > >> Configurations that have debug enable could, perhaps, be named like > > >> nsh-debug. > > >> > > >> On 11/23/2020 5:38 AM, Alan Carvalho de Assis wrote: > > >>> I think we need to have a good compromise between features and size. > > >>> > > >>> For instance, the default "nsh" demo should be small, basically just > > >>> the terminal and minimum support to its commands to work, like the > > >>> PROCFS to get 'free' working. > > >>> > > >>> Also keep in mind that for debugging purpose we need to "Suppress > > >>> Optimization" that also will increase its size. > > >>> > > >>> So, I think it could be a good idea to have a predefined config for > > >>> debug purpose, instead forcing the "nsh" to be debugging enabled ready > > >>> by default, that will increase its size and send a wrong message for > > >>> people testing NuttX for the very first time. > > >>> > > >>> See the mbedOS for example: > > >>> > > >>> https://os.mbed.com/blog/entry/Optimizing-memory-usage-in-mbed-OS-52/ > > >>> > > >>> They went into 'rabbit's hole' to solve an issue that we don't have > > >>> yet, but if nobody keep an eye on it soon we will have. > > >>> > > >>> BR, > > >>> > > >>> Alan > > >>> > > >>> On 11/23/20, David Sidrane <david.sidr...@nscdg.com> wrote: > > >>>>> Do you think this is due to the.... > > >>>> I would say so. > > >>>> > > >>>> I agree better debugging out of the box is a good way to go. We have to > > >>>> weigh that against the past goal of: Minimum size image. It was a first > > >>>> impression thing. This was why debug had to be tuned off in all > > >>>> Kconfig. > > >>>> > > >>>> The first question to ask is do we as a group feel still that the size > > >>>> of > > >>>> the canned config built images should be as small as possible to > > >>>> showcase > > >>>> NuttX ability to be small? > > >>>> > > >>>> > > >>>> David > > >>>> > > >>>> > > >>>> -----Original Message----- > > >>>> From: Matias N. [mailto:mat...@imap.cc] > > >>>> Sent: Sunday, November 22, 2020 5:18 PM > > >>>> To: dev@nuttx.apache.org > > >>>> Subject: Should TASK_NAME_SIZE be changed in most configs? > > >>>> > > >>>> While trying the integration of openocd with NuttX it was complaining > > >>>> due > > >>>> to "name" not being defined, which happens when CONFIG_TASK_NAME_SIZE > > >>>> == > > >>>> 0. Looking at sched/Kconfig the default for this symbol is 31, yet many > > >>>> configs have this set to zero. Do you think this is due to the default > > >>>> having changed at some point or is this done to minimize memory use in > > >>>> all > > >>>> these boards? If the latter, maybe we need to make the default depend > > >>>> on > > >>>> CONFIG_DEFAULT_SMALL and update all configs that do not have this set. > > >>>> > > >>>> Best, > > >>>> Matias > > >>>> >
