RE: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not set
> From: Gregory Nutt [mailto:spudan...@gmail.com] > I just configured a new computer and I am having problems with MSYS2. I > can't even create the "symbolic" links needed at start up. I am not > sure why. Probably some priveleges issues. I activate Windows 10 Developer Mode, and create an environment variable named "MSYS" with value "winsymlinks:nativestrict". That's it. > But I did verify the build on Cygwin and it was about the same as > always. About 7 minutes using configuration stm32f4discovery with > realtime virus checking off. [That is disappointing to me because I > just built hot new Rizen 5 PC and expected better]. It's more than half an hour here with an (older) I7-3770. I will have a look today. Johannes
Re: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not set
I'm currently updating MSYS2, and will then repeat the build. Then I'll test on another computer. And when it's happening there as well, I'll try to narrow down the reason. I just configured a new computer and I am having problems with MSYS2. I can't even create the "symbolic" links needed at start up. I am not sure why. Probably some priveleges issues. But I did verify the build on Cygwin and it was about the same as always. About 7 minutes using configuration stm32f4discovery with realtime virus checking off. [That is disappointing to me because I just built hot new Rizen 5 PC and expected better]. Windows WSL is only a little faster. If fast build turn-around time is what you need, you can't beat Linux. I am seeing build times in the 30 second range there. I used to get about 10-15 seconds in the past, I think the ARM Embedded Toolchain is a lot slower these days. I have heard people in the past who got the build time down to 7 seconds in the past. For me, I can live with 7 minutes for the convenience of using my Windows desktop.
RE: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not set
> -Original Message- > From: Gregory Nutt [mailto:spudan...@gmail.com] > Sent: Tuesday, May 26, 2020 4:20 PM > To: dev@nuttx.apache.org > Subject: Re: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED > not set > > > Today I had time to return to nuttx and rebased to master. > > But after doing a distclean and configuration, the build process on MSYS2 is > extremely slow. It takes hours for a build with "make -j8 V=1". > > I already had my company admin disable antivirus. Had there been a > change in the process? > > I use both MSYS2 and Cygwin (really both Cygwin) and have not noticed > any slowdown using Cygwin ... still minutes, certainly not hours. I > haven't used MSYS2 in some time. > > Perhaps you could do a git bisect and see if there is some particular > commit that introduced the MSYS2 problem > I'm currently updating MSYS2, and will then repeat the build. Then I'll test on another computer. And when it's happening there as well, I'll try to narrow down the reason.
RE: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not set
Thanks a lot for the fixes. Yes I know that I won't have stdio in this configuration. I followed the README of stm32f429i-disco concerning CDC/ACM console, and it's for testing/playing anyway. Today I had time to return to nuttx and rebased to master. But after doing a distclean and configuration, the build process on MSYS2 is extremely slow. It takes hours for a build with "make -j8 V=1". I already had my company admin disable antivirus. Had there been a change in the process? Regards, Johannes > -Original Message- > From: Gregory Nutt [mailto:spudan...@gmail.com] > Sent: Saturday, May 23, 2020 5:02 PM > To: dev@nuttx.apache.org > Subject: Re: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED > not set > > > > PR #1105 should eliminate the primary cause of the error: fs_fdopen() > > will not longer set the errno variable. The secondary error, the > > uninitialized stack description, is still a problem. > Since the errno value was only set before fs_fdopen() failed, this means > that you system will still not work. It should not crash but it should > not work either. Now the fs_fdopen() calls will silently and > mysteriously fail, perhaps with the only symptom being no standard I/O > in the started tasks.
Re: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not set
PR #1105 should eliminate the primary cause of the error: fs_fdopen() will not longer set the errno variable. The secondary error, the uninitialized stack description, is still a problem. Since the errno value was only set before fs_fdopen() failed, this means that you system will still not work. It should not crash but it should not work either. Now the fs_fdopen() calls will silently and mysteriously fail, perhaps with the only symptom being no standard I/O in the started tasks.
Re: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not set
PR #1105 should eliminate the primary cause of the error: fs_fdopen() will not longer set the errno variable. The secondary error, the uninitialized stack description, is still a problem. On 5/22/2020 10:19 PM, Gregory Nutt wrote: The new implementation of set_errno require all thread(include IDLE) initialize the stack related fields in tcb_s correctly. But many chipset forget to setup them for IDLE thread. TODO contain an item described this: ... snip ... Hello, I think there's a problem with set_errno() in nx_start(), when CONFIG_TLS_ALIGNED is not set: I disabled SERIAL_CONSOLE and DEV_CONSOLE, because I wanted to test CDCACM_CONSOLE. Now calling fs_fdopen() in group_setupstreams() leads to a call of set_errno(). In addition, nothing within the OS should ever set the errno value. So the first bug is the fs_fdopen() should not call set_errno(); It is a secondary problem that the stack data is not initialized. It should never be needed for the purpose errno access since no logic in the OS should ever access the errno. Greg
Re: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not set
The new implementation of set_errno require all thread(include IDLE) initialize the stack related fields in tcb_s correctly. But many chipset forget to setup them for IDLE thread. TODO contain an item described this: ... snip ... Hello, I think there's a problem with set_errno() in nx_start(), when CONFIG_TLS_ALIGNED is not set: I disabled SERIAL_CONSOLE and DEV_CONSOLE, because I wanted to test CDCACM_CONSOLE. Now calling fs_fdopen() in group_setupstreams() leads to a call of set_errno(). In addition, nothing within the OS should ever set the errno value. So the first bug is the fs_fdopen() should not call set_errno(); It is a secondary problem that the stack data is not initialized. It should never be needed for the purpose errno access since no logic in the OS should ever access the errno. Greg
Re: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not set
In the pass, the stack info for IDLE thread is just used for debugging purpose, so the priority is low, but we need boost this to high priority since TLS(errno) depend on it now On Fri, May 22, 2020 at 8:25 PM David Sidrane wrote: > > This is super confusing to me. > > The todo list says. > > Status: Open > Priority:Low. Things are working OK the way they are. But the > design >could be improved and made a little more efficient with > this >change. > > So it sounds like no big deal. Hardfaulting on set_errno() it is a big > deal. > > > Did we destroy active acrhs with a partial implementation and not realize > it? TLS(errno) implementation is fully completed, it's an arch problem not the core OS issue. > > Why was this work not done on a branch and tested? > This work initially do on a branch and merge into master after finish. > Where is the process? Where is the PMC agreeing on these sweeping changes? PR follow the process, the contributor sumbit the path, PMC review the code and approve. Here is the email: https://lists.apache.org/thread.html/r76ac7aa434cf982acd4c7227ede7221ad7a09b9235a99c188f716199%40%3Cdev.nuttx.apache.org%3E > > David > > > > -Original Message- > From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com] > Sent: Friday, May 22, 2020 4:51 AM > To: dev@nuttx.apache.org > Subject: Re: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not > set > > The new implementation of set_errno require all thread(include IDLE) > initialize the stack related fields in tcb_s correctly. But many > chipset forget to setup them for IDLE thread. TODO contain an item > described this: > Task:IDLE THREAD TCB SETUP > Description: There are issues with setting IDLE thread stacks: > >1. One problem is stack-related data in the IDLE threads TCB. > A solution might be to standardize the use of > g_idle_topstack. > That you could add initialization like this in nx_start: > > @@ -344,6 +347,11 @@ void nx_start(void) > g_idleargv[1] = NULL; > g_idletcb.argv = g_idleargv; > > + /* Set the IDLE task stack size */ > + > + g_idletcb.cmn.adj_stack_size = > CONFIG_IDLETHREAD_STACKSIZE; > + g_idletcb.cmn.stack_alloc_ptr = (void > *)(g_idle_topstack - CONFIG_IDLETHREAD_STACKSIZE); > + > /* Then add the idle task's TCB to the head of > the ready to run list */ > > dq_addfirst((FAR dq_entry_t *)_idletcb, (FAR > dq_queue_t *)_readytorun); > > The g_idle_topstack variable is available for almost > all architectures: > > $ find . -name *.h | xargs grep g_idle_top > ./arm/src/common/up_internal.h:EXTERN const uint32_t > g_idle_topstack; > ./avr/src/avr/avr.h:extern uint16_t g_idle_topstack; > ./avr/src/avr32/avr32.h:extern uint32_t g_idle_topstack; > ./hc/src/common/up_internal.h:extern uint16_t > g_idle_topstack; > ./mips/src/common/up_internal.h:extern uint32_t > g_idle_topstack; > ./misoc/src/lm32/lm32.h:extern uint32_t g_idle_topstack; > ./renesas/src/common/up_internal.h:extern uint32_t > g_idle_topstack; > ./renesas/src/m16c/chip.h:extern uint32_t > g_idle_topstack; /* Start of the heap */ > ./risc-v/src/common/up_internal.h:EXTERN uint32_t > g_idle_topstack; > ./x86/src/common/up_internal.h:extern uint32_t > g_idle_topstack; > > That omits these architectures: sh1, sim, xtensa, z16, > z80, > ez80, and z8. All would have to support this common > global variable. > > Also, the stack itself may be 8-, 16-, or 32-bits wide, > depending upon the architecture and do have differing > alignment requirements. > >2. Another problem is colorizing that stack to use with > stack usage monitoring logic. There is logic in some > start functions to do this in a function called > go_nx_start. > It is available in these architectures: > > ./arm/src/efm32/efm32_start.c:static void > go_nx_start(void *pv, unsigned int nbytes) > ./arm/src/kinetis/kinetis_start.c:static void > go_nx_start(void *pv, unsigned int nbytes) > ./arm/src/sam34/sam_start.c:static void > go_nx_start(void *pv, unsigned int nbytes) > ./arm/src/samv7/sam_start.c:static void > go_nx_start(void *pv, unsigned int nbytes) > ./arm/src/stm32/stm32_start.c:static void > go_nx_start(void *pv, unsigned int nbytes) >
RE: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not set
I implemented the change in nx_start.c with a quick and dirty extern const uintptr_t g_idle_topstack; just to see if it's working. It works. But since nx_start.c is not architecture specific and (according to the TODO) g_idle_topstack is not available in all architectures, this is no solution. > But many chipset forget to setup them for IDLE thread. If I understand correctly all(?) chipsets use nx_start, so the idle task tls seems to be never initialized. What about changing the call to nx_start(idle_stack_ptr, idle_stack_size)? Regards, Johannes > -Original Message- > From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com] > Sent: Friday, May 22, 2020 1:51 PM > To: dev@nuttx.apache.org > Subject: Re: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED > not set > > The new implementation of set_errno require all thread(include IDLE) > initialize the stack related fields in tcb_s correctly. But many > chipset forget to setup them for IDLE thread. TODO contain an item > described this: > Task:IDLE THREAD TCB SETUP > Description: There are issues with setting IDLE thread stacks: > >1. One problem is stack-related data in the IDLE threads TCB. > A solution might be to standardize the use of > g_idle_topstack. > That you could add initialization like this in nx_start: > > @@ -344,6 +347,11 @@ void nx_start(void) > g_idleargv[1] = NULL; > g_idletcb.argv = g_idleargv; > > + /* Set the IDLE task stack size */ > + > + g_idletcb.cmn.adj_stack_size = > CONFIG_IDLETHREAD_STACKSIZE; > + g_idletcb.cmn.stack_alloc_ptr = (void > *)(g_idle_topstack - CONFIG_IDLETHREAD_STACKSIZE); > + > /* Then add the idle task's TCB to the head of > the ready to run list */ > > dq_addfirst((FAR dq_entry_t *)_idletcb, (FAR > dq_queue_t *)_readytorun); > > The g_idle_topstack variable is available for almost > all architectures: > > $ find . -name *.h | xargs grep g_idle_top > ./arm/src/common/up_internal.h:EXTERN const uint32_t > g_idle_topstack; > ./avr/src/avr/avr.h:extern uint16_t g_idle_topstack; > ./avr/src/avr32/avr32.h:extern uint32_t g_idle_topstack; > ./hc/src/common/up_internal.h:extern uint16_t > g_idle_topstack; > ./mips/src/common/up_internal.h:extern uint32_t > g_idle_topstack; > ./misoc/src/lm32/lm32.h:extern uint32_t g_idle_topstack; > ./renesas/src/common/up_internal.h:extern uint32_t > g_idle_topstack; > ./renesas/src/m16c/chip.h:extern uint32_t > g_idle_topstack; /* Start of the heap */ > ./risc-v/src/common/up_internal.h:EXTERN uint32_t > g_idle_topstack; > ./x86/src/common/up_internal.h:extern uint32_t > g_idle_topstack; > > That omits these architectures: sh1, sim, xtensa, z16, z80, > ez80, and z8. All would have to support this common > global variable. > > Also, the stack itself may be 8-, 16-, or 32-bits wide, > depending upon the architecture and do have differing > alignment requirements. > >2. Another problem is colorizing that stack to use with > stack usage monitoring logic. There is logic in some > start functions to do this in a function called go_nx_start. > It is available in these architectures: > > ./arm/src/efm32/efm32_start.c:static void > go_nx_start(void *pv, unsigned int nbytes) > ./arm/src/kinetis/kinetis_start.c:static void > go_nx_start(void *pv, unsigned int nbytes) > ./arm/src/sam34/sam_start.c:static void > go_nx_start(void *pv, unsigned int nbytes) > ./arm/src/samv7/sam_start.c:static void > go_nx_start(void *pv, unsigned int nbytes) > ./arm/src/stm32/stm32_start.c:static void > go_nx_start(void *pv, unsigned int nbytes) > ./arm/src/stm32f7/stm32_start.c:static void > go_nx_start(void *pv, unsigned int nbytes) > ./arm/src/stm32l4/stm32l4_start.c:static void > go_nx_start(void *pv, unsigned int nbytes) > ./arm/src/tms570/tms570_boot.c:static void > go_nx_start(void *pv, unsigned int nbytes) > ./arm/src/xmc4/xmc4_start.c:static void > go_nx_start(void *pv, unsigned int nbytes) > So, it become a block issue and need immedately fix now. > > On Fri, May 22, 2020 at 7:40 PM Schock, Johannes - NIVUS GmbH > wrote: > > > > Hello, > > I think there's a problem with set_errno() in nx_start(), when > CONFIG_TLS_ALIGNED is not set: > > I disabled SERIAL_CONSOLE and
RE: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not set
This is super confusing to me. The todo list says. Status: Open Priority:Low. Things are working OK the way they are. But the design could be improved and made a little more efficient with this change. So it sounds like no big deal. Hardfaulting on set_errno() it is a big deal. Did we destroy active acrhs with a partial implementation and not realize it? Why was this work not done on a branch and tested? Where is the process? Where is the PMC agreeing on these sweeping changes? David -Original Message- From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com] Sent: Friday, May 22, 2020 4:51 AM To: dev@nuttx.apache.org Subject: Re: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not set The new implementation of set_errno require all thread(include IDLE) initialize the stack related fields in tcb_s correctly. But many chipset forget to setup them for IDLE thread. TODO contain an item described this: Task:IDLE THREAD TCB SETUP Description: There are issues with setting IDLE thread stacks: 1. One problem is stack-related data in the IDLE threads TCB. A solution might be to standardize the use of g_idle_topstack. That you could add initialization like this in nx_start: @@ -344,6 +347,11 @@ void nx_start(void) g_idleargv[1] = NULL; g_idletcb.argv = g_idleargv; + /* Set the IDLE task stack size */ + + g_idletcb.cmn.adj_stack_size = CONFIG_IDLETHREAD_STACKSIZE; + g_idletcb.cmn.stack_alloc_ptr = (void *)(g_idle_topstack - CONFIG_IDLETHREAD_STACKSIZE); + /* Then add the idle task's TCB to the head of the ready to run list */ dq_addfirst((FAR dq_entry_t *)_idletcb, (FAR dq_queue_t *)_readytorun); The g_idle_topstack variable is available for almost all architectures: $ find . -name *.h | xargs grep g_idle_top ./arm/src/common/up_internal.h:EXTERN const uint32_t g_idle_topstack; ./avr/src/avr/avr.h:extern uint16_t g_idle_topstack; ./avr/src/avr32/avr32.h:extern uint32_t g_idle_topstack; ./hc/src/common/up_internal.h:extern uint16_t g_idle_topstack; ./mips/src/common/up_internal.h:extern uint32_t g_idle_topstack; ./misoc/src/lm32/lm32.h:extern uint32_t g_idle_topstack; ./renesas/src/common/up_internal.h:extern uint32_t g_idle_topstack; ./renesas/src/m16c/chip.h:extern uint32_t g_idle_topstack; /* Start of the heap */ ./risc-v/src/common/up_internal.h:EXTERN uint32_t g_idle_topstack; ./x86/src/common/up_internal.h:extern uint32_t g_idle_topstack; That omits these architectures: sh1, sim, xtensa, z16, z80, ez80, and z8. All would have to support this common global variable. Also, the stack itself may be 8-, 16-, or 32-bits wide, depending upon the architecture and do have differing alignment requirements. 2. Another problem is colorizing that stack to use with stack usage monitoring logic. There is logic in some start functions to do this in a function called go_nx_start. It is available in these architectures: ./arm/src/efm32/efm32_start.c:static void go_nx_start(void *pv, unsigned int nbytes) ./arm/src/kinetis/kinetis_start.c:static void go_nx_start(void *pv, unsigned int nbytes) ./arm/src/sam34/sam_start.c:static void go_nx_start(void *pv, unsigned int nbytes) ./arm/src/samv7/sam_start.c:static void go_nx_start(void *pv, unsigned int nbytes) ./arm/src/stm32/stm32_start.c:static void go_nx_start(void *pv, unsigned int nbytes) ./arm/src/stm32f7/stm32_start.c:static void go_nx_start(void *pv, unsigned int nbytes) ./arm/src/stm32l4/stm32l4_start.c:static void go_nx_start(void *pv, unsigned int nbytes) ./arm/src/tms570/tms570_boot.c:static void go_nx_start(void *pv, unsigned int nbytes) ./arm/src/xmc4/xmc4_start.c:static void go_nx_start(void *pv, unsigned int nbytes) So, it become a block issue and need immedately fix now. On Fri, May 22, 2020 at 7:40 PM Schock, Johannes - NIVUS GmbH wrote: > > Hello, > I think there's a problem with set_errno() in nx_start(), when > CONFIG_TLS_ALIGNED is not set: > I disabled SERIAL_CONSOLE and DEV_CONSOLE, because I wanted to test > CDCACM_CONSOLE. Now calling fs_fdopen() in group_setupstreams() leads to a > call of set_errno(). > But since tls_get_info() returns NULL pointer for
Re: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not set
The new implementation of set_errno require all thread(include IDLE) initialize the stack related fields in tcb_s correctly. But many chipset forget to setup them for IDLE thread. TODO contain an item described this: Task:IDLE THREAD TCB SETUP Description: There are issues with setting IDLE thread stacks: 1. One problem is stack-related data in the IDLE threads TCB. A solution might be to standardize the use of g_idle_topstack. That you could add initialization like this in nx_start: @@ -344,6 +347,11 @@ void nx_start(void) g_idleargv[1] = NULL; g_idletcb.argv = g_idleargv; + /* Set the IDLE task stack size */ + + g_idletcb.cmn.adj_stack_size = CONFIG_IDLETHREAD_STACKSIZE; + g_idletcb.cmn.stack_alloc_ptr = (void *)(g_idle_topstack - CONFIG_IDLETHREAD_STACKSIZE); + /* Then add the idle task's TCB to the head of the ready to run list */ dq_addfirst((FAR dq_entry_t *)_idletcb, (FAR dq_queue_t *)_readytorun); The g_idle_topstack variable is available for almost all architectures: $ find . -name *.h | xargs grep g_idle_top ./arm/src/common/up_internal.h:EXTERN const uint32_t g_idle_topstack; ./avr/src/avr/avr.h:extern uint16_t g_idle_topstack; ./avr/src/avr32/avr32.h:extern uint32_t g_idle_topstack; ./hc/src/common/up_internal.h:extern uint16_t g_idle_topstack; ./mips/src/common/up_internal.h:extern uint32_t g_idle_topstack; ./misoc/src/lm32/lm32.h:extern uint32_t g_idle_topstack; ./renesas/src/common/up_internal.h:extern uint32_t g_idle_topstack; ./renesas/src/m16c/chip.h:extern uint32_t g_idle_topstack; /* Start of the heap */ ./risc-v/src/common/up_internal.h:EXTERN uint32_t g_idle_topstack; ./x86/src/common/up_internal.h:extern uint32_t g_idle_topstack; That omits these architectures: sh1, sim, xtensa, z16, z80, ez80, and z8. All would have to support this common global variable. Also, the stack itself may be 8-, 16-, or 32-bits wide, depending upon the architecture and do have differing alignment requirements. 2. Another problem is colorizing that stack to use with stack usage monitoring logic. There is logic in some start functions to do this in a function called go_nx_start. It is available in these architectures: ./arm/src/efm32/efm32_start.c:static void go_nx_start(void *pv, unsigned int nbytes) ./arm/src/kinetis/kinetis_start.c:static void go_nx_start(void *pv, unsigned int nbytes) ./arm/src/sam34/sam_start.c:static void go_nx_start(void *pv, unsigned int nbytes) ./arm/src/samv7/sam_start.c:static void go_nx_start(void *pv, unsigned int nbytes) ./arm/src/stm32/stm32_start.c:static void go_nx_start(void *pv, unsigned int nbytes) ./arm/src/stm32f7/stm32_start.c:static void go_nx_start(void *pv, unsigned int nbytes) ./arm/src/stm32l4/stm32l4_start.c:static void go_nx_start(void *pv, unsigned int nbytes) ./arm/src/tms570/tms570_boot.c:static void go_nx_start(void *pv, unsigned int nbytes) ./arm/src/xmc4/xmc4_start.c:static void go_nx_start(void *pv, unsigned int nbytes) So, it become a block issue and need immedately fix now. On Fri, May 22, 2020 at 7:40 PM Schock, Johannes - NIVUS GmbH wrote: > > Hello, > I think there's a problem with set_errno() in nx_start(), when > CONFIG_TLS_ALIGNED is not set: > I disabled SERIAL_CONSOLE and DEV_CONSOLE, because I wanted to test > CDCACM_CONSOLE. Now calling fs_fdopen() in group_setupstreams() leads to a > call of set_errno(). > But since tls_get_info() returns NULL pointer for stack_alloc_ptr the board > goes into hardfault. > For the CONFIG_TLS_ALIGNED case it would return the actual stack pointer from > arm_getsp() which accesses the stack pointer directly. > I think thread local storage for nx_start() should be handled differently, or > the stack_alloc_ptr should be set to a sane value. > I attach my config for reference, perhaps I'm missing something. > > Regards, Johannes > >
RE: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not set
Another try with ".txt" extension. > -Original Message- > From: Schock, Johannes - NIVUS GmbH > [mailto:johannes.sch...@nivus.com] > Sent: Friday, May 22, 2020 1:40 PM > To: 'dev@nuttx.apache.org' > Subject: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not > set > > Hello, > I think there's a problem with set_errno() in nx_start(), when > CONFIG_TLS_ALIGNED is not set: > I disabled SERIAL_CONSOLE and DEV_CONSOLE, because I wanted to test > CDCACM_CONSOLE. Now calling fs_fdopen() in group_setupstreams() leads > to a call of set_errno(). > But since tls_get_info() returns NULL pointer for stack_alloc_ptr the board > goes into hardfault. > For the CONFIG_TLS_ALIGNED case it would return the actual stack pointer > from arm_getsp() which accesses the stack pointer directly. > I think thread local storage for nx_start() should be handled differently, or > the stack_alloc_ptr should be set to a sane value. > I attach my config for reference, perhaps I'm missing something. > > Regards, Johannes > # # Automatically generated file; DO NOT EDIT. # Nuttx/x86_64 Configuration # # # Build Setup # # CONFIG_EXPERIMENTAL is not set # CONFIG_DEFAULT_SMALL is not set CONFIG_DEFAULT_TASK_STACKSIZE=4096 CONFIG_HOST_LINUX=y # CONFIG_HOST_MACOS is not set # CONFIG_HOST_WINDOWS is not set # CONFIG_HOST_OTHER is not set # # Build Configuration # CONFIG_APPS_DIR="../apps" CONFIG_BUILD_FLAT=y # CONFIG_BUILD_2PASS is not set # # Binary Output Formats # CONFIG_INTELHEX_BINARY=y # CONFIG_MOTOROLA_SREC is not set CONFIG_RAW_BINARY=y # CONFIG_UBOOT_UIMAGE is not set # CONFIG_DFU_BINARY is not set # # Customize Header Files # # CONFIG_ARCH_HAVE_STDINT_H is not set # CONFIG_ARCH_HAVE_STDBOOL_H is not set # CONFIG_ARCH_HAVE_MATH_H is not set # CONFIG_ARCH_FLOAT_H is not set CONFIG_ARCH_HAVE_STDARG_H=y # CONFIG_ARCH_STDARG_H is not set CONFIG_ARCH_HAVE_SETJMP=y # CONFIG_ARCH_SETJMP_H is not set # CONFIG_ARCH_DEBUG_H is not set # # Debug Options # CONFIG_DEBUG_ALERT=y CONFIG_DEBUG_FEATURES=y # # Debug SYSLOG Output Controls # # CONFIG_DEBUG_ERROR is not set # CONFIG_DEBUG_ASSERTIONS is not set # # Subsystem Debug Options # # CONFIG_DEBUG_BINFMT is not set # CONFIG_DEBUG_FS is not set # CONFIG_DEBUG_GRAPHICS is not set # CONFIG_DEBUG_LIB is not set # CONFIG_DEBUG_MM is not set # CONFIG_DEBUG_POWER is not set # CONFIG_DEBUG_SCHED is not set # # OS Function Debug Options # # CONFIG_DEBUG_IRQ is not set # # Driver Debug Options # # CONFIG_DEBUG_LEDS is not set # CONFIG_DEBUG_GPIO is not set # CONFIG_DEBUG_MEMCARD is not set # CONFIG_DEBUG_SPI is not set # CONFIG_DEBUG_TIMER is not set # CONFIG_DEBUG_USB is not set CONFIG_ARCH_HAVE_STACKCHECK=y # CONFIG_STACK_COLORATION is not set # CONFIG_ARCH_HAVE_HEAPCHECK is not set CONFIG_DEBUG_SYMBOLS=y CONFIG_ARCH_HAVE_CUSTOMOPT=y CONFIG_DEBUG_NOOPT=y # CONFIG_DEBUG_CUSTOMOPT is not set # CONFIG_DEBUG_FULLOPT is not set # # System Type # CONFIG_ARCH_ARM=y # CONFIG_ARCH_AVR is not set # CONFIG_ARCH_HC is not set # CONFIG_ARCH_MIPS is not set # CONFIG_ARCH_MISOC is not set # CONFIG_ARCH_RENESAS is not set # CONFIG_ARCH_RISCV is not set # CONFIG_ARCH_SIM is not set # CONFIG_ARCH_X86 is not set # CONFIG_ARCH_X86_64 is not set # CONFIG_ARCH_XTENSA is not set # CONFIG_ARCH_Z16 is not set # CONFIG_ARCH_Z80 is not set # CONFIG_ARCH_OR1K is not set CONFIG_ARCH="arm" # # ARM Options # # CONFIG_ARCH_CHIP_A1X is not set # CONFIG_ARCH_CHIP_AM335X is not set # CONFIG_ARCH_CHIP_C5471 is not set # CONFIG_ARCH_CHIP_DM320 is not set # CONFIG_ARCH_CHIP_EFM32 is not set # CONFIG_ARCH_CHIP_IMX1 is not set # CONFIG_ARCH_CHIP_IMX6 is not set # CONFIG_ARCH_CHIP_IMXRT is not set CONFIG_ARCH_CHIP_KINETIS=y # CONFIG_ARCH_CHIP_KL is not set # CONFIG_ARCH_CHIP_LC823450 is not set # CONFIG_ARCH_CHIP_LM is not set # CONFIG_ARCH_CHIP_LPC17XX_40XX is not set # CONFIG_ARCH_CHIP_LPC214X is not set # CONFIG_ARCH_CHIP_LPC2378 is not set # CONFIG_ARCH_CHIP_LPC31XX is not set # CONFIG_ARCH_CHIP_LPC43XX is not set # CONFIG_ARCH_CHIP_LPC54XX is not set # CONFIG_ARCH_CHIP_MAX326XX is not set # CONFIG_ARCH_CHIP_MOXART is not set # CONFIG_ARCH_CHIP_NRF52 is not set # CONFIG_ARCH_CHIP_NUC1XX is not set # CONFIG_ARCH_CHIP_S32K1XX is not set # CONFIG_ARCH_CHIP_SAMA5 is not set # CONFIG_ARCH_CHIP_SAMD2X is not set # CONFIG_ARCH_CHIP_SAML2X is not set # CONFIG_ARCH_CHIP_SAMD5X is not set # CONFIG_ARCH_CHIP_SAME5X is not set # CONFIG_ARCH_CHIP_SAM34 is not set # CONFIG_ARCH_CHIP_SAMV7 is not set # CONFIG_ARCH_CHIP_STM32 is not set # CONFIG_ARCH_CHIP_STM32F0 is not set # CONFIG_ARCH_CHIP_STM32L0 is not set # CONFIG_ARCH_CHIP_STM32G0 is not set # CONFIG_ARCH_CHIP_STM32F7 is not set # CONFIG_ARCH_CHIP_STM32H7 is not set # CONFIG_ARCH_CHIP_STM32L4 is not set # CONFIG_ARCH_CHIP_STR71X is not set # CONFIG_ARCH_CHIP_TMS570 is not set # CONFIG_ARCH_CHIP_TIVA is not set # CONFIG_ARCH_CHIP_XMC4 is not set # CONFIG_ARCH_CHIP_CXD56XX is not set # CONFIG_ARCH_ARM7TDMI is not set # CONFIG_ARCH_ARM920T is not set #
