Re: [rtems-test] powerpc/qoriq_e500: smp, legacy-net: Passed:607 Failed:1 Timeout:4 Invalid:0 Wrong:0
On 22/11/17 6:53 pm, sebastian.hu...@embedded-brains.de wrote: > Testing time : 1:55:37.467070 > Average test time: 0:00:11.189463 > > Host > > Linux-4.4.92-18.36-default-x86_64-with-SuSE-42.2-x86_64 (Linux huber-nb-linux > 4.4.92-18.36-default #1 SMP Tue Oct 24 15:20:18 UTC 2017 (3f3cfaa) x86_64 > x86_64) > > Configuration > = > Version: 5.0.0.44c5b1c38093c005864c972000e8450a485bd8e5 > Build : smp,legacy-net > Tools : 7.2.0 20170814 (RTEMS 5, RSB > d1e6dfcb1e14d2f9d42c79e1137ddca6d8fc67d5, Newlib 2.5.0.20170922) > > Summary > === > > Passed:607 > Failed: 1 > User Input: 5 > Expected Fail: 0 > Indeterminate: 0 > Benchmark: 3 > Timeout: 4 > Invalid: 0 > Wrong Version: 0 > Wrong Build: 0 > Wrong Tools: 0 > -- > Total: 620 > Thank you for the test results. This arch and BSP can be added to tier 1. Chris ps The imx7 can be as well. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-test] powerpc/qoriq_e500: smp, legacy-net: Passed:607 Failed:1 Timeout:4 Invalid:0 Wrong:0
On 22/11/17 09:31, Chris Johns wrote: On 22/11/17 6:53 pm, sebastian.hu...@embedded-brains.de wrote: Testing time : 1:55:37.467070 Average test time: 0:00:11.189463 Host Linux-4.4.92-18.36-default-x86_64-with-SuSE-42.2-x86_64 (Linux huber-nb-linux 4.4.92-18.36-default #1 SMP Tue Oct 24 15:20:18 UTC 2017 (3f3cfaa) x86_64 x86_64) Configuration = Version: 5.0.0.44c5b1c38093c005864c972000e8450a485bd8e5 Build : smp,legacy-net Tools : 7.2.0 20170814 (RTEMS 5, RSB d1e6dfcb1e14d2f9d42c79e1137ddca6d8fc67d5, Newlib 2.5.0.20170922) Summary === Passed:607 Failed: 1 User Input: 5 Expected Fail: 0 Indeterminate: 0 Benchmark: 3 Timeout: 4 Invalid: 0 Wrong Version: 0 Wrong Build: 0 Wrong Tools: 0 -- Total: 620 Thank you for the test results. This arch and BSP can be added to tier 1. Chris ps The imx7 can be as well. How can I do this? With this? diff --git a/tester/rtems/rtems-bsps-tiers.ini b/tester/rtems/rtems-bsps-tiers.ini index cc611cb..74360e1 100644 --- a/tester/rtems/rtems-bsps-tiers.ini +++ b/tester/rtems/rtems-bsps-tiers.ini @@ -21,9 +21,10 @@ # Tier 1: no build errors and no unexpected tests failures on hardware. # [tier-1] -archs = arm, i386 -bsps_arm = beagleboneblack, xilinx_zynq_zedboard +archs = arm, i386, powerpc +bsps_arm = beagleboneblack, imx7, xilinx_zynq_zedboard bsps_i386 = pc686 +bsps_powerpc = qoriq_e500 # # Tier 2: no build errors and no unexpected tests failures on hardware and @@ -44,7 +45,6 @@ bsps_arm = altcycv_devkit, altcycv_devkit_smp, edb7312, kit637_v6, gumstix, - imx7, lm3s3749, lm3s6965, lm3s6965_qemu, lm4f120, lpc1768_mbed, lpc1768_mbed_ahb_ram, lpc1768_mbed_ahb_ram_eth, lpc17xx_ea_ram, lpc17xx_ea_rom_int, lpc17xx_plx800_ram, @@ -104,7 +104,7 @@ bsps_powerpc = beatnik, pm520_cr825, pm520_ze30, psim, qemuppc, qemuprep, qemuprep-altivec, - qoriq_core_0, qoriq_core_1, qoriq_e500, qoriq_e6500_32, qoriq_e6500_64 + qoriq_core_0, qoriq_core_1, qoriq_e6500_32, qoriq_e6500_64 ss555, t32mppc, tqm8xx_stk8xx -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-test] powerpc/qoriq_e500: smp, legacy-net: Passed:607 Failed:1 Timeout:4 Invalid:0 Wrong:0
On 22/11/17 8:07 pm, Sebastian Huber wrote: > On 22/11/17 09:31, Chris Johns wrote: >> On 22/11/17 6:53 pm, sebastian.hu...@embedded-brains.de wrote: >>> Testing time : 1:55:37.467070 >>> Average test time: 0:00:11.189463 >>> >>> Host >>> >>> Linux-4.4.92-18.36-default-x86_64-with-SuSE-42.2-x86_64 (Linux >>> huber-nb-linux >>> 4.4.92-18.36-default #1 SMP Tue Oct 24 15:20:18 UTC 2017 (3f3cfaa) x86_64 >>> x86_64) >>> >>> Configuration >>> = >>> Version: 5.0.0.44c5b1c38093c005864c972000e8450a485bd8e5 >>> Build : smp,legacy-net >>> Tools : 7.2.0 20170814 (RTEMS 5, RSB >>> d1e6dfcb1e14d2f9d42c79e1137ddca6d8fc67d5, Newlib 2.5.0.20170922) >>> >>> Summary >>> === >>> >>> Passed: 607 >>> Failed: 1 >>> User Input: 5 >>> Expected Fail: 0 >>> Indeterminate: 0 >>> Benchmark: 3 >>> Timeout: 4 >>> Invalid: 0 >>> Wrong Version: 0 >>> Wrong Build: 0 >>> Wrong Tools: 0 >>> -- >>> Total: 620 >>> >> Thank you for the test results. >> >> This arch and BSP can be added to tier 1. >> >> Chris >> >> ps The imx7 can be as well. > > How can I do this? With this? > Yes. Sorry, I should have been more specific. In the middle of cooking some food. OK to push. Thanks. Chris > diff --git a/tester/rtems/rtems-bsps-tiers.ini > b/tester/rtems/rtems-bsps-tiers.ini > index cc611cb..74360e1 100644 > --- a/tester/rtems/rtems-bsps-tiers.ini > +++ b/tester/rtems/rtems-bsps-tiers.ini > @@ -21,9 +21,10 @@ > # Tier 1: no build errors and no unexpected tests failures on hardware. > # > [tier-1] > -archs = arm, i386 > -bsps_arm = beagleboneblack, xilinx_zynq_zedboard > +archs = arm, i386, powerpc > +bsps_arm = beagleboneblack, imx7, xilinx_zynq_zedboard > bsps_i386 = pc686 > +bsps_powerpc = qoriq_e500 > > # > # Tier 2: no build errors and no unexpected tests failures on hardware and > @@ -44,7 +45,6 @@ bsps_arm = altcycv_devkit, altcycv_devkit_smp, > edb7312, > kit637_v6, > gumstix, > - imx7, > lm3s3749, lm3s6965, lm3s6965_qemu, lm4f120, > lpc1768_mbed, lpc1768_mbed_ahb_ram, lpc1768_mbed_ahb_ram_eth, > lpc17xx_ea_ram, lpc17xx_ea_rom_int, lpc17xx_plx800_ram, > @@ -104,7 +104,7 @@ bsps_powerpc = beatnik, > pm520_cr825, pm520_ze30, > psim, > qemuppc, qemuprep, qemuprep-altivec, > - qoriq_core_0, qoriq_core_1, qoriq_e500, qoriq_e6500_32, qoriq_e6500_64 > + qoriq_core_0, qoriq_core_1, qoriq_e6500_32, qoriq_e6500_64 > ss555, > t32mppc, > tqm8xx_stk8xx > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] c-user: Document global construction
Close #3243.
---
c-user/fatal_error.rst| 5
c-user/initialization.rst | 60 +++
2 files changed, 60 insertions(+), 5 deletions(-)
diff --git a/c-user/fatal_error.rst b/c-user/fatal_error.rst
index 320227b..090850d 100644
--- a/c-user/fatal_error.rst
+++ b/c-user/fatal_error.rst
@@ -239,11 +239,6 @@ INTERNAL_ERROR_RTEMS_INIT_TASK_ENTRY_IS_NULL (26)
occur during system initialization. It is an application configuration
error.
-INTERNAL_ERROR_POSIX_INIT_THREAD_ENTRY_IS_NULL (27)
-A POSIX initialization thread entry function is NULL. This fatal error may
-occur during system initialization. It is an application configuration
-error.
-
INTERNAL_ERROR_THREAD_QUEUE_DEADLOCK (28)
A deadlock was detected during a thread queue enqueue operation.
diff --git a/c-user/initialization.rst b/c-user/initialization.rst
index 6c30a2d..935a61e 100644
--- a/c-user/initialization.rst
+++ b/c-user/initialization.rst
@@ -294,6 +294,66 @@ Many of RTEMS actions during initialization are based upon
the contents of the
Configuration Table. For more information regarding the format and contents of
this table, please refer to the chapter :ref:`Configuring a System`.
+Global Construction
+---
+
+The global construction is carried out by the first Classic API initialization
+task. If no Classic API initialization task exists, then it is carried out by
+the first POSIX API initialization thread. If no initialization task or thread
+exists, then no global construction is performed, see for example
+:ref:`Specify Idle Task Performs Application Initialization`.
+
+Global constructors are C++ global object constructors or functions with the
+constructor attribute. For example, the following test program
+
+.. code-block:: c
+
+#include
+#include
+
+class A {
+ public:
+A()
+{
+ puts( "A:A()" );
+}
+};
+
+static A a;
+
+static thread_local int i;
+
+static thread_local int j;
+
+static __attribute__((__constructor__)) void b( void )
+{
+ i = 1;
+ puts( "b()" );
+}
+
+static __attribute__((__constructor__(1000))) void c( void )
+{
+ puts( "c()" );
+}
+
+int main(void)
+{
+ assert(i == 1);
+ assert(j == 0);
+ return 0;
+}
+
+should output:
+
+.. code-block:: shell
+
+c()
+b()
+A:A()
+
+Thread-local objects or POSIX key values created during global construction are
+accessible by the corresponding initialization task or thread.
+
Directives
==
--
2.12.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] c-user: Document rtems_panic()
Close #3244. --- c-user/fatal_error.rst | 46 ++ 1 file changed, 42 insertions(+), 4 deletions(-) diff --git a/c-user/fatal_error.rst b/c-user/fatal_error.rst index 090850d..d8566f0 100644 --- a/c-user/fatal_error.rst +++ b/c-user/fatal_error.rst @@ -21,6 +21,8 @@ provided by the fatal error manager are: - rtems_fatal_ - Invoke the fatal error handler +- rtems_panic_ - Print a message and invoke the fatal error handler + - rtems_shutdown_executive_ - Shutdown RTEMS - rtems_exception_frame_print_ - Print the CPU exception frame @@ -122,6 +124,9 @@ RTEMS_FATAL_SOURCE_EXCEPTION (9) RTEMS_FATAL_SOURCE_SMP (10) Fatal source of SMP domain. See :c:type:`SMP_Fatal_code`. +RTEMS_FATAL_SOURCE_PANIC (11) +Fatal source of :c:func:`rtems_panic`, see :ref:`rtems_panic`. + .. _internal_errors: Internal Error Codes @@ -453,15 +458,15 @@ sequence, related constants, usage, and status codes. .. _rtems_fatal: -FATAL - Invoke the fatal error --- +FATAL - Invoke the fatal error handler +-- CALLING SEQUENCE: .. code-block:: c void rtems_fatal( - rtems_fatal_source fatal_source, - rtems_fatal_code error_code + rtems_fatal_source fatal_source, + rtems_fatal_code error_code ) RTEMS_NO_RETURN; DIRECTIVE STATUS CODES: @@ -478,6 +483,39 @@ NOTE: \clearpage +.. index:: panic +.. index:: rtems_panic + +.. _rtems_panic: + +PANIC - Print a message and invoke the fatal error handler +-- + +CALLING SEQUENCE: +.. code-block:: c + +void rtems_panic( + const char *fmt, + ... +) RTEMS_NO_RETURN RTEMS_PRINTFLIKE( 1, 2 ); + +DIRECTIVE STATUS CODES: +NONE - This function will not return to the caller. + +DESCRIPTION: +This directive prints a message via :c:func:`printk` specified by the +format and optional parameters and then terminates the system with the +:c:macro:`RTEMS_FATAL_SOURCE_PANIC` fatal source. The fatal code is set to +the format string address. + +NOTE: +Registered :c:func:`atexit()` or :c:func:`on_exit()` handlers are not +called. Use :c:func:`exit()` in case these handlers should be invoked. + +.. raw:: latex + + \clearpage + .. index:: shutdown RTEMS .. index:: rtems_shutdown_executive -- 2.12.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] source-builder/sb/bootstrap.py: Do not reference bsp_specs to find BSPs
Updates #3520.
---
source-builder/sb/bootstrap.py | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/source-builder/sb/bootstrap.py b/source-builder/sb/bootstrap.py
index 9095f3c..8fda3b8 100644
--- a/source-builder/sb/bootstrap.py
+++ b/source-builder/sb/bootstrap.py
@@ -34,6 +34,14 @@ import options
import path
import version
+def _collect_dirs(path_, dir):
+confs = []
+for root, dirs, files in os.walk(path.host(path_), topdown = True):
+for f in dirs:
+if f == dir:
+confs += [path.shell(path.join(root, f))]
+return confs
+
def _collect(path_, file):
confs = []
for root, dirs, files in os.walk(path.host(path_), topdown = True):
@@ -130,7 +138,7 @@ class autoreconf:
def bspopts(self):
if _grep(self.configure, 'RTEMS_CHECK_BSPDIR'):
-bsp_specs = _collect(self.cwd, 'bsp_specs')
+bsps = _collect_dirs(self.cwd, 'custom')
try:
acinclude = path.join(self.cwd, 'acinclude.m4')
b = open(path.host(acinclude), 'w')
@@ -138,8 +146,9 @@ class autoreconf:
b.write('AC_DEFUN([RTEMS_CHECK_BSPDIR],' + os.linesep)
b.write('[' + os.linesep)
b.write(' case "$1" in' + os.linesep)
-for bs in sorted(bsp_specs):
+for bs in sorted(bsps):
dir = path.dirname(bs)[len(self.cwd) + 1:]
+dir = os.path.dirname(dir)
b.write(' %s )%s' % (dir, os.linesep))
b.write('AC_CONFIG_SUBDIRS([%s]);;%s' % (dir,
os.linesep))
b.write(' *)' + os.linesep)
--
1.8.3.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] c-user: Document global construction
On 22/11/2017 23:42, Sebastian Huber wrote: > +Global Construction > +--- > + > +The global construction is carried out by the first Classic API > initialization > +task. If no Classic API initialization task exists, then it is carried out > by > +the first POSIX API initialization thread. If no initialization task or > thread > +exists, then no global construction is performed, see for example > +:ref:`Specify Idle Task Performs Application Initialization`. What sort of context do the constructors run in? What impact does the context have on the configuration of what ever context is being used, eg stack size, priority, ...? What services in RTEMS can be used from global constructors? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] source-builder/sb/bootstrap.py: Do not reference bsp_specs to find BSPs
On 23/11/2017 02:33, Joel Sherrill wrote:
> Updates #3520.
> ---
> source-builder/sb/bootstrap.py | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/source-builder/sb/bootstrap.py b/source-builder/sb/bootstrap.py
> index 9095f3c..8fda3b8 100644
> --- a/source-builder/sb/bootstrap.py
> +++ b/source-builder/sb/bootstrap.py
> @@ -34,6 +34,14 @@ import options
> import path
> import version
>
> +def _collect_dirs(path_, dir):
> +confs = []
> +for root, dirs, files in os.walk(path.host(path_), topdown = True):
> +for f in dirs:
> +if f == dir:
> +confs += [path.shell(path.join(root, f))]
> +return confs
> +
> def _collect(path_, file):
> confs = []
> for root, dirs, files in os.walk(path.host(path_), topdown = True):
> @@ -130,7 +138,7 @@ class autoreconf:
>
> def bspopts(self):
> if _grep(self.configure, 'RTEMS_CHECK_BSPDIR'):
> -bsp_specs = _collect(self.cwd, 'bsp_specs')
> +bsps = _collect_dirs(self.cwd, 'custom')
> try:
> acinclude = path.join(self.cwd, 'acinclude.m4')
> b = open(path.host(acinclude), 'w')
> @@ -138,8 +146,9 @@ class autoreconf:
> b.write('AC_DEFUN([RTEMS_CHECK_BSPDIR],' + os.linesep)
> b.write('[' + os.linesep)
> b.write(' case "$1" in' + os.linesep)
> -for bs in sorted(bsp_specs):
> +for bs in sorted(bsps):
> dir = path.dirname(bs)[len(self.cwd) + 1:]
> +dir = os.path.dirname(dir)
I think this should be the wrapped `path` call `path.dirname()`.
Chris
> b.write(' %s )%s' % (dir, os.linesep))
> b.write('AC_CONFIG_SUBDIRS([%s]);;%s' % (dir,
> os.linesep))
> b.write(' *)' + os.linesep)
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] c-user: Document global construction
On Wed, Nov 22, 2017 at 3:31 PM, Chris Johns wrote: > On 22/11/2017 23:42, Sebastian Huber wrote: > > +Global Construction > > +--- > > + > > +The global construction is carried out by the first Classic API > initialization > > +task. If no Classic API initialization task exists, then it is carried > out by > > +the first POSIX API initialization thread. If no initialization task > or thread > > +exists, then no global construction is performed, see for example > > +:ref:`Specify Idle Task Performs Application Initialization`. > > What sort of context do the constructors run in? > They run in the context of the first user thread that runs. This means that technically it varies based on user initialization task/thread configuration. > > What impact does the context have on the configuration of what ever > context is > being used, eg stack size, priority, ...? > They use stack space. So they would have to be accounted for in the usage of the thread they will run in. Which leads to the next issue... priority and which init thread runs them is a bit challenging I think if you constructed an example with like both_hello and gave the Classic API initialization task a lower priority than the POSIX Initialization thread, that you would see the constructors run from the POSIX Initialization thread since it would run first. isn't the rule that these are executed by the first thread to execute? > > What services in RTEMS can be used from global constructors? > Likely everything except services explicitly started like networking, mounted filesystems, etc. There is also the issue that these could perform blocking operations and that could potentially lead to some weird situations. If you only have one initialization task/thread, it would introduce a possibly unexpected delay in the time until the application is really alive. If the constructors create threads/tasks, there are scenarios where they could execute before the entire set of constructors is completed. That could lead to unfortunate situations. All of this needs to be documented. My response is simply based on my understanding of where in the initialization sequence these are executed and what I think could occur. --joel > > Chris > ___ > 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
Re: [PATCH] source-builder/sb/bootstrap.py: Do not reference bsp_specs to find BSPs
On Wed, Nov 22, 2017 at 3:38 PM, Chris Johns wrote:
> On 23/11/2017 02:33, Joel Sherrill wrote:
> > Updates #3520.
> > ---
> > source-builder/sb/bootstrap.py | 13 +++--
> > 1 file changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/source-builder/sb/bootstrap.py
> b/source-builder/sb/bootstrap.py
> > index 9095f3c..8fda3b8 100644
> > --- a/source-builder/sb/bootstrap.py
> > +++ b/source-builder/sb/bootstrap.py
> > @@ -34,6 +34,14 @@ import options
> > import path
> > import version
> >
> > +def _collect_dirs(path_, dir):
> > +confs = []
> > +for root, dirs, files in os.walk(path.host(path_), topdown = True):
> > +for f in dirs:
> > +if f == dir:
> > +confs += [path.shell(path.join(root, f))]
> > +return confs
> > +
> > def _collect(path_, file):
> > confs = []
> > for root, dirs, files in os.walk(path.host(path_), topdown = True):
> > @@ -130,7 +138,7 @@ class autoreconf:
> >
> > def bspopts(self):
> > if _grep(self.configure, 'RTEMS_CHECK_BSPDIR'):
> > -bsp_specs = _collect(self.cwd, 'bsp_specs')
> > +bsps = _collect_dirs(self.cwd, 'custom')
> > try:
> > acinclude = path.join(self.cwd, 'acinclude.m4')
> > b = open(path.host(acinclude), 'w')
> > @@ -138,8 +146,9 @@ class autoreconf:
> > b.write('AC_DEFUN([RTEMS_CHECK_BSPDIR],' + os.linesep)
> > b.write('[' + os.linesep)
> > b.write(' case "$1" in' + os.linesep)
> > -for bs in sorted(bsp_specs):
> > +for bs in sorted(bsps):
> > dir = path.dirname(bs)[len(self.cwd) + 1:]
> > +dir = os.path.dirname(dir)
>
> I think this should be the wrapped `path` call `path.dirname()`.
>
OK. That works and is now pushed.
I am just glad I didn't get a complete failing grade on my first Python
patch. :)
Any comments on the patches to the autotools infrastructure? Nibbling on
bsp_specs
--joel
>
> Chris
>
> > b.write(' %s )%s' % (dir, os.linesep))
> > b.write('AC_CONFIG_SUBDIRS([%s]);;%s' % (dir,
> os.linesep))
> > b.write(' *)' + os.linesep)
> >
> ___
> 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
Re: [PATCH] source-builder/sb/bootstrap.py: Do not reference bsp_specs to find BSPs
On 23/11/2017 08:45, Joel Sherrill wrote: > > OK. That works and is now pushed. > Nice. > I am just glad I didn't get a complete failing grade on my first Python > patch. :) 100% pass, however I should not be grading anyone on Python. > > Any comments on the patches to the autotools infrastructure? Nibbling on > bsp_specs > They look good. One thing I was wondering about is detecting gcc as a compiler and then optionally adding bsp_specs to the CC command line? If we detect gcc or clang we can control the option mix. I suspect this would need a gcc-clang.m4 for each layer's aclocal directory. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] source-builder/sb/bootstrap.py: Do not reference bsp_specs to find BSPs
On Wed, Nov 22, 2017 at 3:57 PM, Chris Johns wrote: > On 23/11/2017 08:45, Joel Sherrill wrote: > > > > OK. That works and is now pushed. > > > > Nice. > > > I am just glad I didn't get a complete failing grade on my first Python > patch. :) > > 100% pass, however I should not be grading anyone on Python. > > > > > Any comments on the patches to the autotools infrastructure? Nibbling on > bsp_specs > > > > They look good. > > One thing I was wondering about is detecting gcc as a compiler and then > optionally adding bsp_specs to the CC command line? If we detect gcc or > clang we > can control the option mix. I suspect this would need a gcc-clang.m4 for > each > layer's aclocal directory. > > This could work but ... Give me some time to pick at the bsp_specs. I have started a sweep to reduce differences. There were spurious differences like spacing and some typos. There are other issues to discuss that I want to discuss on the list. For example, "-e entry" and "-u undefined" are used in many bsp_specs. If we made a sweep to move them all to the linkcmds, then that would be a good thing IMO. On the PowerPC, we have rtems_crt[in].o and I don't know why we don't have crt[in].o from gcc to use. That seems like something isn't right. A number of relatively straightforward issues like that rapidly reduce what happens in the bsp_specs which makes it even easier to eliminate them. --joel > Chris > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] source-builder/sb/bootstrap.py: Do not reference bsp_specs to find BSPs
On 22/11/17 23:18, Joel Sherrill wrote: On the PowerPC, we have rtems_crt[in].o and I don't know why we don't have crt[in].o from gcc to use. That seems like something isn't right. We have to fix the GCC crt[in].o for PowerPC. This hack in the PowerPC bsp_specs is necessary at the moment. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Website and RTEMS 5
In the "Releases and Active Development" box is now a stray "<" and "/li>". -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH v2] c-user: Document global construction
Close #3243.
---
c-user/fatal_error.rst| 5
c-user/initialization.rst | 74 +++
2 files changed, 74 insertions(+), 5 deletions(-)
diff --git a/c-user/fatal_error.rst b/c-user/fatal_error.rst
index b2fe4e1..d8566f0 100644
--- a/c-user/fatal_error.rst
+++ b/c-user/fatal_error.rst
@@ -244,11 +244,6 @@ INTERNAL_ERROR_RTEMS_INIT_TASK_ENTRY_IS_NULL (26)
occur during system initialization. It is an application configuration
error.
-INTERNAL_ERROR_POSIX_INIT_THREAD_ENTRY_IS_NULL (27)
-A POSIX initialization thread entry function is NULL. This fatal error may
-occur during system initialization. It is an application configuration
-error.
-
INTERNAL_ERROR_THREAD_QUEUE_DEADLOCK (28)
A deadlock was detected during a thread queue enqueue operation.
diff --git a/c-user/initialization.rst b/c-user/initialization.rst
index 2bbd166..7718b58 100644
--- a/c-user/initialization.rst
+++ b/c-user/initialization.rst
@@ -278,6 +278,80 @@ Many of RTEMS actions during initialization are based upon
the contents of the
Configuration Table. For more information regarding the format and contents of
this table, please refer to the chapter :ref:`Configuring a System`.
+Global Construction
+---
+
+The global construction is carried out by the first Classic API initialization
+task (first is defined by index zero in the Classic API initialization task
+configuration table). If no Classic API initialization task exists, then it is
+carried out by the first POSIX API initialization thread. If no initialization
+task or thread exists, then no global construction is performed, see for
+example :ref:`Specify Idle Task Performs Application Initialization`. The
+Classic API task or POSIX API thread which carries out global construction is
+called the main thread.
+
+Global construction runs before the entry function of the main thread. The
+configuration of the main thread must take the global construction into
+account. In particular, the main thread stack size, priority, attributes and
+initial modes must be set accordingly. Thread-local objects or POSIX key
+values created during global construction are accessible by the main thread.
+If other initialization tasks are configured, and one of them has a higher
+priority than the main thread and the main thread is preemptible, this task
+executes before the global construction. In case the main thread blocks during
+global construction, then other tasks may run. In SMP configurations, other
+initialization tasks may run in parallel with global construction. Tasks
+created during global construction may preempt the main thread or run in
+parallel in SMP configurations. All RTEMS services allowed in task context are
+allowed during global construction.
+
+Global constructors are C++ global object constructors or functions with the
+constructor attribute. For example, the following test program
+
+.. code-block:: c
+
+#include
+#include
+
+class A {
+ public:
+A()
+{
+ puts( "A:A()" );
+}
+};
+
+static A a;
+
+static thread_local int i;
+
+static thread_local int j;
+
+static __attribute__((__constructor__)) void b( void )
+{
+ i = 1;
+ puts( "b()" );
+}
+
+static __attribute__((__constructor__(1000))) void c( void )
+{
+ puts( "c()" );
+}
+
+int main(void)
+{
+ assert(i == 1);
+ assert(j == 0);
+ return 0;
+}
+
+should output:
+
+.. code-block:: shell
+
+c()
+b()
+A:A()
+
Directives
==
--
2.12.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
