On Sun, Nov 22, 2020, at 22:25, Brennan Ashton wrote:
> I generally agree at least for the larger ARM platforms where there is
> overhead.  We have some examples that are intentionally small, but for most
> of the reference examples I think we should be making the debugging better
> out of the box.

Yes, that is my thinking.

> 
> I also usually reset this to the default when I'm debugging using the
> nuttx-gdbinit script.

I'm actually trying opencd support for NuttX as QtCreator integrates better 
with it
compared to the nuttx-gdbinit script. 

Just now trying with nrf52832-mdk:nsh, after changing TASK_NAME_SIZE, it seems 
the
offset for "xcp" does not match the offset in openocd (master). Looking at 
tcb_s, these
variables that openocd looks for are dispersed in tcb_s, with other variables 
that are optionally
built, which means offsets will often change.

I'm thinking of two ways that we could have more solid support for this:
* Reorder these variables so that they are all together inside the struct (a 
bit intrusive, but harmless?)
* Define some (optional) global struct in NuttX which can hold these offsets 
as constant variables. Something like:

struct tcb_offsets_s
{
  void *pid;
  void *xcp;
  void *task_state;
  void *name;
  size_t name_size;
};

const static struct tcb_offsets_s g_tcb_offsets =
{
  .pid = (void*)&((struct tcb_s *)(0))->pid;
  .xcp = (void*)&((struct tcb_s *)(0))->xcp.regs;
  .task_state = (void*)&((struct tcb_s *)(0))->task_state;
  .name = (void*)&((struct tcb_s *)(0))->name;
  .name_size = sizeof(((struct tcb_s *)(0))->name);
};

and then have openocd look for this first to get the offsets. I haven't tried 
this and not really familiar with openocd internals but I guess it should be 
possible.

What do you think?

Best,
Matias

> 
> On Sun, Nov 22, 2020, 5:18 PM Matias N. <mat...@imap.cc> wrote:
> 
> > 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
> 

Reply via email to