Hi, sorry for mixing up the discussions. Also, maybe I wasn't clear from my last email, what I did was to try my second suggestion about adding symbols to NuttX to store the offsets of the required elements of the tcb. 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.
I think this could also be applied to register offsets. This way, each architecture can provide the offsets for its register set and have all architectures working reliably with openocd, regardless of any configuration which may affect the offsets. Regarding the original topic, we can leave the configs with NAME == 0 if you think it is better. Regarding adding an extra debug config, I think that we would be adding a lot of configurations and this adds overhead when testing releases and having to keep configs in sync. I think the approach of using kconfig-tweak to quickly enable/disable debug values is better. This is actually already documented. Best, Matias On Mon, Nov 23, 2020, at 10:29, 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 > >>> > > >
