My idea is to pick up g_statenames symbol, as nuttx-gdbinit does. However, I couldn't find a way to do this since it is a static array of character arrays, which requires knowledge of each entry length to be used. I guess there should be a way to do it but I couldn't figure it out.
Best, Matias On Mon, Nov 23, 2020, at 16:02, Abdelatif Guettouche wrote: > The state names is an enumeration from the NuttX side. I'm not sure > if we can use the same technique to retrieve it. > > When adding the Xtensa/ESP32 stack info, I did some re-organisation > which should ease adding a new architecture. But that code will need > to wait for the next release before it will go to Espressif's fork in > Github (maybe a few days). > > On Mon, Nov 23, 2020 at 4:54 PM Matias N. <mat...@imap.cc> wrote: > > > > Nevermind, I thought I needed to correct register offsets and I only messed > > them up. > > I added the commands to my gdb startup and now works as expected. Maybe we > > could do the same > > to pass register addresses for other architectures and to set the array of > > state names? > > > > On Mon, Nov 23, 2020, at 14:12, Abdelatif Guettouche wrote: > > > Can you see that NuttX was detected and the offsets are correct from > > > OpenOCD? > > > Do you have this in your OpenOCD config file: $_TARGETNAME configure > > > -rtos nuttx > > > > > > I do this with an STM32F4 > > > > > > source [find target/stm32f4x.cfg] > > > > > > $_TARGETNAME configure -rtos nuttx > > > > > > On Mon, Nov 23, 2020 at 4:00 PM Matias N. <mat...@imap.cc> wrote: > > > > > > > > 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 > > > > > > >>>> > > > > > > > > >
