Re: waf bsp_defaults appears to be broken
Hello Joel, Am 03.10.21 um 18:06 schrieb Joel Sherrill: Hi No BSP was successfully built in the build sweep Friday. All have failures like this: $ ./waf bsp_defaults --rtems-bsps=powerpc/psim I just tested this command and everything seems to work fine. I get a default config for the BSP. There is no top-level group with UID '/grp' in the specification Maybe something cache related? The whole build specification files are parsed and put into a cache as a first step. If that doesn't work correctly, it might lead to odd results. The script fetches the BSP's defaults and then changes settings for enable tests, etc. Do you use a fresh checkout or an update from a previous one? Best regards Christian Anyone else see this? --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- embedded brains GmbH Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: waf bsp_defaults appears to be broken
On Mon, Oct 4, 2021 at 2:32 AM Christian MAUDERER wrote: > > Hello Joel, > > Am 03.10.21 um 18:06 schrieb Joel Sherrill: > > Hi > > > > No BSP was successfully built in the build sweep Friday. All have > > failures like this: > > > > $ ./waf bsp_defaults --rtems-bsps=powerpc/psim > > I just tested this command and everything seems to work fine. I get a > default config for the BSP. > > > There is no top-level group with UID '/grp' in the specification > > > > Maybe something cache related? The whole build specification files are > parsed and put into a cache as a first step. If that doesn't work > correctly, it might lead to odd results. This must be it. I suppose I should delete the build/ subdirectory as part of setting up for a sweep. > > The script fetches the BSP's defaults and then changes settings for > > enable tests, etc. > > Do you use a fresh checkout or an update from a previous one? It's an update to minimize what needs to be done. If the RSB changed, tools and RTEMS are built. If only RTEMS changed, only RTEMS BSPs are built. If nothing changed (rare in a week), then nothing is done. I ended up recloning rtems this time and it seems ok now. Thanks. --joel > Best regards > > Christian > > > > > Anyone else see this? > > > > --joel > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > > > > -- > > embedded brains GmbH > Herr Christian MAUDERER > Dornierstr. 4 > 82178 Puchheim > Germany > email: christian.maude...@embedded-brains.de > phone: +49-89-18 94 741 - 18 > fax: +49-89-18 94 741 - 08 > > Registergericht: Amtsgericht München > Registernummer: HRB 157899 > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler > Unsere Datenschutzerklärung finden Sie hier: > https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: waf bsp_defaults appears to be broken
Am 04.10.21 um 15:51 schrieb Joel Sherrill: On Mon, Oct 4, 2021 at 2:32 AM Christian MAUDERER wrote: Hello Joel, Am 03.10.21 um 18:06 schrieb Joel Sherrill: Hi No BSP was successfully built in the build sweep Friday. All have failures like this: $ ./waf bsp_defaults --rtems-bsps=powerpc/psim I just tested this command and everything seems to work fine. I get a default config for the BSP. There is no top-level group with UID '/grp' in the specification Maybe something cache related? The whole build specification files are parsed and put into a cache as a first step. If that doesn't work correctly, it might lead to odd results. This must be it. I suppose I should delete the build/ subdirectory as part of setting up for a sweep. If you want to get a clean repository again, you could also use a "git clean -dxf". But be very careful with that command. It doesn't ask before deleting anything that is not versioned. The script fetches the BSP's defaults and then changes settings for enable tests, etc. Do you use a fresh checkout or an update from a previous one? It's an update to minimize what needs to be done. If the RSB changed, tools and RTEMS are built. If only RTEMS changed, only RTEMS BSPs are built. If nothing changed (rare in a week), then nothing is done. I ended up recloning rtems this time and it seems ok now. If you get the error again, it would be interesting to find out what caused it. That sounds like something that shouldn't happen. It seems that the wscript uses a simple file modification time to find out whether the cache has to be re-generated. So if your system time changed backward, that might could lead to such errors. Best regards Christian Thanks. --joel Best regards Christian Anyone else see this? --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- embedded brains GmbH Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ -- embedded brains GmbH Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: waf bsp_defaults appears to be broken
On Mon, Oct 4, 2021 at 9:13 AM Christian MAUDERER wrote: > > Am 04.10.21 um 15:51 schrieb Joel Sherrill: > > On Mon, Oct 4, 2021 at 2:32 AM Christian MAUDERER > > wrote: > >> > >> Hello Joel, > >> > >> Am 03.10.21 um 18:06 schrieb Joel Sherrill: > >>> Hi > >>> > >>> No BSP was successfully built in the build sweep Friday. All have > >>> failures like this: > >>> > >>> $ ./waf bsp_defaults --rtems-bsps=powerpc/psim > >> > >> I just tested this command and everything seems to work fine. I get a > >> default config for the BSP. > >> > >>> There is no top-level group with UID '/grp' in the specification > >>> > >> > >> Maybe something cache related? The whole build specification files are > >> parsed and put into a cache as a first step. If that doesn't work > >> correctly, it might lead to odd results. > > > > This must be it. I suppose I should delete the build/ subdirectory as part > > of setting up for a sweep. > > If you want to get a clean repository again, you could also use a "git > clean -dxf". But be very careful with that command. It doesn't ask > before deleting anything that is not versioned. That might be ok here because this is a directory only used for the cron driven build sweeps. Nothing should ever be edited here. > >>> The script fetches the BSP's defaults and then changes settings for > >>> enable tests, etc. > >> > >> Do you use a fresh checkout or an update from a previous one? > > > > It's an update to minimize what needs to be done. If the RSB changed, tools > > and RTEMS are built. If only RTEMS changed, only RTEMS BSPs are built. > > If nothing changed (rare in a week), then nothing is done. > > > > I ended up recloning rtems this time and it seems ok now. > > If you get the error again, it would be interesting to find out what > caused it. That sounds like something that shouldn't happen. It seems > that the wscript uses a simple file modification time to find out > whether the cache has to be re-generated. So if your system time changed > backward, that might could lead to such errors. Possible but unlikely. The build sweep for 6 starts at 445pm on Fridays. The directory should be untouched until the next Friday unless something happens and I poke around like this morning. Hopefully removing build/ will help keep things clean. --joel > Best regards > > Christian > > > > > Thanks. > > > > --joel > > > >> Best regards > >> > >> Christian > >> > >>> > >>> Anyone else see this? > >>> > >>> --joel > >>> ___ > >>> devel mailing list > >>> devel@rtems.org > >>> http://lists.rtems.org/mailman/listinfo/devel > >>> > >> > >> -- > >> > >> embedded brains GmbH > >> Herr Christian MAUDERER > >> Dornierstr. 4 > >> 82178 Puchheim > >> Germany > >> email: christian.maude...@embedded-brains.de > >> phone: +49-89-18 94 741 - 18 > >> fax: +49-89-18 94 741 - 08 > >> > >> Registergericht: Amtsgericht München > >> Registernummer: HRB 157899 > >> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler > >> Unsere Datenschutzerklärung finden Sie hier: > >> https://embedded-brains.de/datenschutzerklaerung/ > > -- > > embedded brains GmbH > Herr Christian MAUDERER > Dornierstr. 4 > 82178 Puchheim > Germany > email: christian.maude...@embedded-brains.de > phone: +49-89-18 94 741 - 18 > fax: +49-89-18 94 741 - 08 > > Registergericht: Amtsgericht München > Registernummer: HRB 157899 > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler > Unsere Datenschutzerklärung finden Sie hier: > https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[RTEMS 5] Add support for IDLE Thread stack allocator
Add a stack allocator hook specifically for allocation of IDLE thread stacks. This allows the user to decide if IDLE thread stacks are statically allocated or handled by the same custom allocator mechanism as other thread stacks. Closes #4520. --- cpukit/include/rtems/confdefs/percpu.h| 20 +++- cpukit/include/rtems/confdefs/wkspace.h | 13 +++ cpukit/include/rtems/config.h | 3 + cpukit/include/rtems/score/stack.h| 24 + cpukit/score/src/stackallocator.c | 3 + cpukit/score/src/threadcreateidle.c | 18 +++- testsuites/sptests/spstkalloc03/init.c| 98 +++ .../sptests/spstkalloc03/spstkalloc03.doc | 19 .../sptests/spstkalloc03/spstkalloc03.scn | 2 + 9 files changed, 192 insertions(+), 8 deletions(-) create mode 100644 testsuites/sptests/spstkalloc03/init.c create mode 100644 testsuites/sptests/spstkalloc03/spstkalloc03.doc create mode 100644 testsuites/sptests/spstkalloc03/spstkalloc03.scn diff --git a/cpukit/include/rtems/confdefs/percpu.h b/cpukit/include/rtems/confdefs/percpu.h index f3a9a4f3e7..a6ba4fece0 100644 --- a/cpukit/include/rtems/confdefs/percpu.h +++ b/cpukit/include/rtems/confdefs/percpu.h @@ -133,11 +133,21 @@ RTEMS_DEFINE_GLOBAL_SYMBOL( const size_t _Thread_Idle_stack_size = CONFIGURE_IDLE_TASK_STACK_SIZE; -char _Thread_Idle_stacks[ - _CONFIGURE_MAXIMUM_PROCESSORS -* ( CONFIGURE_IDLE_TASK_STACK_SIZE + CPU_IDLE_TASK_IS_FP * CONTEXT_FP_SIZE ) -] RTEMS_ALIGNED( CPU_INTERRUPT_STACK_ALIGNMENT ) -RTEMS_SECTION( ".rtemsstack.idle" ); +/* + * If the user provides a custom idle stack allocator, then we do not need + * memory reserved for the stacks but the symbol is still referenced in + * threadcreateidle.c. The code path just never uses it. Make it minimal + * size to proceed. + */ + char _Thread_Idle_stacks[ +#ifdef CONFIGURE_TASK_STACK_ALLOCATOR_FOR_IDLE +1 +#else +_CONFIGURE_MAXIMUM_PROCESSORS + * ( CONFIGURE_IDLE_TASK_STACK_SIZE + CPU_IDLE_TASK_IS_FP * CONTEXT_FP_SIZE ) +#endif + ] RTEMS_ALIGNED( CPU_INTERRUPT_STACK_ALIGNMENT ) + RTEMS_SECTION( ".rtemsstack.idle" ); #if defined(CONFIGURE_IDLE_TASK_INITIALIZES_APPLICATION) && \ !defined(CONFIGURE_IDLE_TASK_BODY) diff --git a/cpukit/include/rtems/confdefs/wkspace.h b/cpukit/include/rtems/confdefs/wkspace.h index 484dde20ea..abe4cd50af 100644 --- a/cpukit/include/rtems/confdefs/wkspace.h +++ b/cpukit/include/rtems/confdefs/wkspace.h @@ -132,12 +132,14 @@ const uintptr_t _Stack_Space_size = _CONFIGURE_STACK_SPACE_SIZE; #if defined(CONFIGURE_TASK_STACK_ALLOCATOR) \ && defined(CONFIGURE_TASK_STACK_DEALLOCATOR) + /* Custom allocator may or may not use the work space. */ #ifdef CONFIGURE_TASK_STACK_ALLOCATOR_AVOIDS_WORK_SPACE const bool _Stack_Allocator_avoids_workspace = true; #else const bool _Stack_Allocator_avoids_workspace = false; #endif + /* Custom allocator may or may not need initialization. */ #ifdef CONFIGURE_TASK_STACK_ALLOCATOR_INIT const Stack_Allocator_initialize _Stack_Allocator_initialize = CONFIGURE_TASK_STACK_ALLOCATOR_INIT; @@ -145,11 +147,22 @@ const uintptr_t _Stack_Space_size = _CONFIGURE_STACK_SPACE_SIZE; const Stack_Allocator_initialize _Stack_Allocator_initialize = NULL; #endif + /* Custom allocator must include allocate and free */ const Stack_Allocator_allocate _Stack_Allocator_allocate = CONFIGURE_TASK_STACK_ALLOCATOR; const Stack_Allocator_free _Stack_Allocator_free = CONFIGURE_TASK_STACK_DEALLOCATOR; + + /* Custom allocator MAY include allocate IDLE thread stacks */ + #ifdef CONFIGURE_TASK_STACK_ALLOCATOR_FOR_IDLE +const Stack_Allocator_allocate_for_idle _Stack_Allocator_allocate_for_idle = + CONFIGURE_TASK_STACK_ALLOCATOR_FOR_IDLE; + #else +const Stack_Allocator_allocate_for_idle _Stack_Allocator_allocate_for_idle = + NULL; + #endif + #elif defined(CONFIGURE_TASK_STACK_ALLOCATOR) \ || defined(CONFIGURE_TASK_STACK_DEALLOCATOR) #error "CONFIGURE_TASK_STACK_ALLOCATOR and CONFIGURE_TASK_STACK_DEALLOCATOR must be both defined or both undefined" diff --git a/cpukit/include/rtems/config.h b/cpukit/include/rtems/config.h index e82c7abf11..a826581658 100644 --- a/cpukit/include/rtems/config.h +++ b/cpukit/include/rtems/config.h @@ -129,6 +129,9 @@ uint32_t rtems_configuration_get_maximum_extensions( void ); #define rtems_configuration_get_stack_free_hook() \ (_Stack_Allocator_free) +#define rtems_configuration_get_stack_allocate_for_idle_hook() \ + (_Stack_Allocator_allocate_for_idle) + /** * This macro assists in accessing the field which indicates whether * RTEMS is responsible for zeroing the Executive Workspace. diff --git a/cpukit/include/rtems/score/stack.h b/cpukit/include/rtems/score/stack.h index df1df74867..9c60b4f15e 100644 --- a/cpukit/include/rtems/score/stack.h +++ b/cpukit/include/rtems/score/stack.h @@ -81,6 +81,23 @@ typedef void *( *Stack_Al
Re: [PATCH v2 5/6] cpukit: Add signal mapping support
On 02/10/2021 01:44, Chris Johns wrote: The fatal extensions have a well defined order (position in the table). The user has the full control over the initial extensions table. Is it backwards compatible when this new mode is enabled? When you enable a new feature you get new behaviour. I am not sure what you mean with backward compatible in this case. If you don't enable the exception to signal mapping (default), then nothing changes. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [RTEMS 5] Add support for IDLE Thread stack allocator
On 04/10/2021 18:11, Joel Sherrill wrote: Add a stack allocator hook specifically for allocation of IDLE thread stacks. This allows the user to decide if IDLE thread stacks are statically allocated or handled by the same custom allocator mechanism as other thread stacks. Closes #4520. --- cpukit/include/rtems/confdefs/percpu.h| 20 +++- cpukit/include/rtems/confdefs/wkspace.h | 13 +++ cpukit/include/rtems/config.h | 3 + cpukit/include/rtems/score/stack.h| 24 + cpukit/score/src/stackallocator.c | 3 + cpukit/score/src/threadcreateidle.c | 18 +++- testsuites/sptests/spstkalloc03/init.c| 98 +++ .../sptests/spstkalloc03/spstkalloc03.doc | 19 .../sptests/spstkalloc03/spstkalloc03.scn | 2 + 9 files changed, 192 insertions(+), 8 deletions(-) create mode 100644 testsuites/sptests/spstkalloc03/init.c create mode 100644 testsuites/sptests/spstkalloc03/spstkalloc03.doc create mode 100644 testsuites/sptests/spstkalloc03/spstkalloc03.scn diff --git a/cpukit/include/rtems/confdefs/percpu.h b/cpukit/include/rtems/confdefs/percpu.h index f3a9a4f3e7..a6ba4fece0 100644 --- a/cpukit/include/rtems/confdefs/percpu.h +++ b/cpukit/include/rtems/confdefs/percpu.h @@ -133,11 +133,21 @@ RTEMS_DEFINE_GLOBAL_SYMBOL( const size_t _Thread_Idle_stack_size = CONFIGURE_IDLE_TASK_STACK_SIZE; -char _Thread_Idle_stacks[ - _CONFIGURE_MAXIMUM_PROCESSORS -* ( CONFIGURE_IDLE_TASK_STACK_SIZE + CPU_IDLE_TASK_IS_FP * CONTEXT_FP_SIZE ) -] RTEMS_ALIGNED( CPU_INTERRUPT_STACK_ALIGNMENT ) -RTEMS_SECTION( ".rtemsstack.idle" ); +/* + * If the user provides a custom idle stack allocator, then we do not need + * memory reserved for the stacks but the symbol is still referenced in + * threadcreateidle.c. The code path just never uses it. Make it minimal + * size to proceed. + */ + char _Thread_Idle_stacks[ +#ifdef CONFIGURE_TASK_STACK_ALLOCATOR_FOR_IDLE Maybe name the option CONFIGURE_IDLE_TASK_STACK_ALLOCATOR similar to CONFIGURE_IDLE_TASK_STACK_SIZE, CONFIGURE_IDLE_TASK_BODY, and CONFIGURE_IDLE_TASK_INITIALIZES_APPLICATION. +1 You don't need this, see below. +#else +_CONFIGURE_MAXIMUM_PROCESSORS + * ( CONFIGURE_IDLE_TASK_STACK_SIZE + CPU_IDLE_TASK_IS_FP * CONTEXT_FP_SIZE ) +#endif + ] RTEMS_ALIGNED( CPU_INTERRUPT_STACK_ALIGNMENT ) + RTEMS_SECTION( ".rtemsstack.idle" ); #if defined(CONFIGURE_IDLE_TASK_INITIALIZES_APPLICATION) && \ !defined(CONFIGURE_IDLE_TASK_BODY) diff --git a/cpukit/include/rtems/confdefs/wkspace.h b/cpukit/include/rtems/confdefs/wkspace.h index 484dde20ea..abe4cd50af 100644 --- a/cpukit/include/rtems/confdefs/wkspace.h +++ b/cpukit/include/rtems/confdefs/wkspace.h @@ -132,12 +132,14 @@ const uintptr_t _Stack_Space_size = _CONFIGURE_STACK_SPACE_SIZE; #if defined(CONFIGURE_TASK_STACK_ALLOCATOR) \ && defined(CONFIGURE_TASK_STACK_DEALLOCATOR) + /* Custom allocator may or may not use the work space. */ #ifdef CONFIGURE_TASK_STACK_ALLOCATOR_AVOIDS_WORK_SPACE const bool _Stack_Allocator_avoids_workspace = true; #else const bool _Stack_Allocator_avoids_workspace = false; #endif + /* Custom allocator may or may not need initialization. */ #ifdef CONFIGURE_TASK_STACK_ALLOCATOR_INIT const Stack_Allocator_initialize _Stack_Allocator_initialize = CONFIGURE_TASK_STACK_ALLOCATOR_INIT; @@ -145,11 +147,22 @@ const uintptr_t _Stack_Space_size = _CONFIGURE_STACK_SPACE_SIZE; const Stack_Allocator_initialize _Stack_Allocator_initialize = NULL; #endif + /* Custom allocator must include allocate and free */ const Stack_Allocator_allocate _Stack_Allocator_allocate = CONFIGURE_TASK_STACK_ALLOCATOR; const Stack_Allocator_free _Stack_Allocator_free = CONFIGURE_TASK_STACK_DEALLOCATOR; + + /* Custom allocator MAY include allocate IDLE thread stacks */ + #ifdef CONFIGURE_TASK_STACK_ALLOCATOR_FOR_IDLE +const Stack_Allocator_allocate_for_idle _Stack_Allocator_allocate_for_idle = + CONFIGURE_TASK_STACK_ALLOCATOR_FOR_IDLE; + #else +const Stack_Allocator_allocate_for_idle _Stack_Allocator_allocate_for_idle = + NULL; Use _Stack_Allocator_allocate_for_idle_default instead of NULL + #endif + #elif defined(CONFIGURE_TASK_STACK_ALLOCATOR) \ || defined(CONFIGURE_TASK_STACK_DEALLOCATOR) #error "CONFIGURE_TASK_STACK_ALLOCATOR and CONFIGURE_TASK_STACK_DEALLOCATOR must be both defined or both undefined" diff --git a/cpukit/include/rtems/config.h b/cpukit/include/rtems/config.h index e82c7abf11..a826581658 100644 --- a/cpukit/include/rtems/config.h +++ b/cpukit/include/rtems/config.h @@ -129,6 +129,9 @@ uint32_t rtems_configuration_get_maximum_extensions( void ); #define rtems_configuration_get_stack_free_hook() \ (_Stack_Allocator_free) +#define rtems_configuration_get_stack_allocate_for_idle_hook() \ + (_Stack_Allocator_allocate_for_idle) + /**
Re: [PATCH v2 2/6] cpukit: Add Exception Manager
On 01/10/2021 21:39, Kinsey Moore wrote:
Sebastian,
Could you be more specific about which parts of the
architecture-dependent interface still seem tied to the AArch64 port? I
thought I had made them sufficiently abstract by relying on
architecture-specific functions to manipulate and take action on the
exception frame. The signal mapping code written on top of this should
work for any architecture that implements those functions and contains
no reliance on architecture that I can see. The set of exception classes
in particular includes exceptions that don't exist on AArch64, but were
added because they're known to be present on SPARC and need to be
handled. I'm only really familiar with ARM and AArch64, so that could be
why I'm missing it.
I would provide a new CPU feature flag
#define CPU_HAS_EXCEPTION_TO_SIGNAL_MAPPING TRUE|FALSE
If it is TRUE, then the CPU port shall provide:
/**
* @retval -1 There is no signal associated with the exception.
* @retval SIGSEGV, SIGFPE, ...
*/
int _CPU_Exception_frame_get_signal( const CPU_Exception_frame *frame );
RTEMS_NO_RETURN _CPU_Exception_resume( CPU_Exception_frame *frame );
The architecture-independent part just needs to provide a fatal extension:
_Thread_local Thread_Action _Exception_Raise_signal_action;
void _Exception_Raise_signal( source, true, code )
{
int sig;
if ( source != RTEMS_FATAL_SOURCE_EXCEPTION ) {
return;
}
sig = _CPU_Exception_frame_get_signal( code );
switch ( sig ) {
case SIGSEGV:
handler = _Exception_Raise_sigsegv;
break;
default:
return;
}
_Thread_Prepend_post_switch_action( executing,
&_Exception_Raise_signal_action, handler );
_CPU_Exception_resume( code );
}
Using a post-switch extension has the benefit that you don't have to
call the complicated raise() function in the exception context. It is
called in thread context.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Certificate validation issue when trying to build qemu
Hi, I'm trying to build qemu, but I keep getting this error message. RTEMS Source Builder - Set Builder, 6 (3950b1e2d857) Build Set: devel/qemu Build Set: devel/autotools-internal.bset config: devel/autoconf-2.69-1.cfg package: autoconf-2.69-x86_64-freebsd13.0-1 download: https://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz -> sources/autoconf-2.69.tar.gz download: https://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz: error: https://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz: all paths have failed, giving up Build FAILED See error report: rsb-report-autoconf-2.69-x86_64-freebsd13.0-1.txt error: downloading https://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz: all paths have failed, giving up Build Set: Time 0:00:00.807563 error: downloading https://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz: all paths have failed, giving up Build Set: Time 0:00:00.809688 Build FAILED I am able to download it with a browser, but wget and curl won't work. Wget will work if I use the "-no-check-certificate" flag. Curl doesn't tell me of a flag that could bypass this. Does anyone know why this is failing? Thanks, Ryan ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RE: Certificate validation issue when trying to build qemu
Actually, I was only able to download it on my Linux VM. My FreeBSD 13 VM won't let me download it from the browser. I was using Firefox for both. -Original Message- From: devel On Behalf Of Ryan Long Sent: Monday, October 4, 2021 2:40 PM To: devel@rtems.org Subject: Certificate validation issue when trying to build qemu Hi, I'm trying to build qemu, but I keep getting this error message. RTEMS Source Builder - Set Builder, 6 (3950b1e2d857) Build Set: devel/qemu Build Set: devel/autotools-internal.bset config: devel/autoconf-2.69-1.cfg package: autoconf-2.69-x86_64-freebsd13.0-1 download: https://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz -> sources/autoconf-2.69.tar.gz download: https://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz: error: https://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz: all paths have failed, giving up Build FAILED See error report: rsb-report-autoconf-2.69-x86_64-freebsd13.0-1.txt error: downloading https://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz: all paths have failed, giving up Build Set: Time 0:00:00.807563 error: downloading https://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz: all paths have failed, giving up Build Set: Time 0:00:00.809688 Build FAILED I am able to download it with a browser, but wget and curl won't work. Wget will work if I use the "-no-check-certificate" flag. Curl doesn't tell me of a flag that could bypass this. Does anyone know why this is failing? Thanks, Ryan ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
libbsd: Conditional compilation of tests
Currently debugger01 is the only user of the test-if-library in libbsd and it doesn't seem to work as expected. The configure step that detects libdebugger occurs and succeeds as it should for the zynq a9 qemu BSP, but debugger01.exe never gets compiled. I found this behavior while working on the implementation for libdebugger for AArch64. Is there some configuration that I'm missing to actually enable that test? Changing it to an unconditional test yields a successfully compiled debugger01.exe. Perhaps someone that has more familiarity with the waf configure scripts can tell me what I'm missing. Thanks, Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: waf bsp_defaults appears to be broken
On 4/10/21 3:06 am, Joel Sherrill wrote: > No BSP was successfully built in the build sweep Friday. All have > failures like this: > > $ ./waf bsp_defaults --rtems-bsps=powerpc/psim > There is no top-level group with UID '/grp' in the specification > > The script fetches the BSP's defaults and then changes settings for > enable tests, etc. > > Anyone else see this? I would not use the the bsp_defaults approach to handle BSP testing. The BSP defaults build target should only be used as a means to find and examine any options a BSP may have you wish to override. Capturing defaults is counter to the notion of defaults, ie defaults change? If you wish to use the defaults then this is all you need: $ echo "[powerpc/psim]" > config $ ./waf distclean configure build If you what to build the tests, POSIX API and debug on: $ echo "[powerpc/psim]" > config $ echo "RTEMS_DEBUG = True" >> config $ echo "RTEMS_POSIX_API = True" >> config $ echo "BUILD_TESTS = True" >> config $ ./waf distclean configure build In regards to removing build directories and others things in the lengthy thread attached to the email, user beware. The recommended solution is: ./waf distclean Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 5/6] cpukit: Add signal mapping support
On 5/10/21 4:29 am, Sebastian Huber wrote: > On 02/10/2021 01:44, Chris Johns wrote: >>> The fatal extensions have a well defined order (position in the >>> table). The user has the full control over the initial extensions table. >> Is it backwards compatible when this new mode is enabled? > > When you enable a new feature you get new behaviour. I am not sure what you > mean > with backward compatible in this case. If you don't enable the exception to > signal mapping (default), then nothing changes. "The user has the full control over the initial extensions table." Does this option change that? Is this feature mutually exclusive or additive to any "current control" a user has? In other words, it is not clear to me if I can add this option and still maintain any existing controls I may have. If it is not and users need to make changes the user code becomes a mess of version defines. Is that what we want? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 5/6] cpukit: Add signal mapping support
On 05/10/2021 03:51, Chris Johns wrote: On 5/10/21 4:29 am, Sebastian Huber wrote: On 02/10/2021 01:44, Chris Johns wrote: The fatal extensions have a well defined order (position in the table). The user has the full control over the initial extensions table. Is it backwards compatible when this new mode is enabled? When you enable a new feature you get new behaviour. I am not sure what you mean with backward compatible in this case. If you don't enable the exception to signal mapping (default), then nothing changes. "The user has the full control over the initial extensions table." Does this option change that? Is this feature mutually exclusive or additive to any "current control" a user has? In other words, it is not clear to me if I can add this option and still maintain any existing controls I may have. If it is not and users need to make changes the user code becomes a mess of version defines. Is that what we want? If you add the new option similar to the stack checker option #ifdef CONFIGURE_STACK_CHECKER_ENABLED RTEMS_STACK_CHECKER_EXTENSION, #endif then you can either use the application configuration option to enable the extension at the recommended position or you can use the extension define in your CONFIGURE_INITIAL_EXTENSIONS exactly where you want it. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
