GCC 6 Release Candiate
Hello, I updated the RTEMS 4.12 RSB tool chain to use the GCC 6.1 release candidate. https://gcc.gnu.org/ml/gcc/2016-04/msg00109.html -- 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] score: Add Chain_Iterator
Add a chain iterator for safe iteration of chains with concurrent node
extraction.
---
cpukit/score/include/rtems/score/chainimpl.h | 239 +++
testsuites/sptests/spchain/init.c| 119 +
testsuites/sptests/spchain/spchain.doc | 6 +
testsuites/sptests/spchain/spchain.scn | 5 +-
4 files changed, 367 insertions(+), 2 deletions(-)
diff --git a/cpukit/score/include/rtems/score/chainimpl.h
b/cpukit/score/include/rtems/score/chainimpl.h
index ff66d46..f78f2d6 100644
--- a/cpukit/score/include/rtems/score/chainimpl.h
+++ b/cpukit/score/include/rtems/score/chainimpl.h
@@ -800,6 +800,245 @@ RTEMS_INLINE_ROUTINE void
_Chain_Insert_ordered_unprotected(
_Chain_Insert_unprotected( _Chain_Previous( next ), to_insert );
}
+/**
+ * @brief The chain iterator direction.
+ */
+typedef enum {
+ /**
+ * @brief Iteration from head to tail.
+ */
+ CHAIN_ITERATOR_FORWARD,
+
+ /**
+ * @brief Iteration from tail to head.
+ */
+ CHAIN_ITERATOR_BACKWARD
+} Chain_Iterator_direction;
+
+/**
+ * @brief A chain iterator which is updated during node extraction if it is
+ * properly registered.
+ *
+ * @see _Chain_Iterator_initialize().
+ */
+typedef struct {
+ /**
+ * @brief Node for registration.
+ *
+ * Used during _Chain_Iterator_initialize() and _Chain_Iterator_destroy().
+ */
+ Chain_Node Registry_node;
+
+ /**
+ * @brief The direction of this iterator.
+ *
+ * Immutable after initialization via _Chain_Iterator_initialize().
+ */
+ Chain_Iterator_direction direction;
+
+ /**
+ * @brief The current position of this iterator.
+ *
+ * The position is initialized via _Chain_Iterator_initialize(). It must be
+ * explicitly set after one valid iteration step, e.g. in case a next node in
+ * the iterator direction existed. It is updated through the registration in
+ * case a node is extracted via _Chain_Iterator_registry_update().
+ */
+ Chain_Node *position;
+} Chain_Iterator;
+
+/**
+ * @brief A registry for chain iterators.
+ *
+ * Should be attached to a chain control to enable safe iteration through a
+ * chain in case of concurrent node extractions.
+ */
+typedef struct {
+ Chain_Control Iterators;
+} Chain_Iterator_registry;
+
+/**
+ * @brief Chain iterator registry initializer for static initialization.
+ *
+ * @param name The designator of the chain iterator registry.
+ */
+#define CHAIN_ITERATOR_REGISTRY_INITIALIZER( name ) \
+ { CHAIN_INITIALIZER_EMPTY( name.Iterators ) }
+
+/**
+ * @brief Initializes a chain iterator registry.
+ */
+RTEMS_INLINE_ROUTINE void _Chain_Iterator_registry_initialize(
+ Chain_Iterator_registry *the_registry
+)
+{
+ _Chain_Initialize_empty( &the_registry->Iterators );
+}
+
+/**
+ * @brief Updates all iterators present in the chain iterator registry in case
+ * of a node extraction.
+ *
+ * Must be called before _Chain_Extract_unprotected().
+ *
+ * @warning This function will look at all registered chain iterators to
+ * determine if an update is necessary.
+ */
+RTEMS_INLINE_ROUTINE void _Chain_Iterator_registry_update(
+ Chain_Iterator_registry *the_registry,
+ Chain_Node *the_node_to_extract
+)
+{
+ Chain_Node *iter_node;
+ Chain_Node *iter_tail;
+
+ iter_node = _Chain_Head( &the_registry->Iterators );
+ iter_tail = _Chain_Tail( &the_registry->Iterators );
+
+ while ( ( iter_node = _Chain_Next( iter_node ) ) != iter_tail ) {
+Chain_Iterator *iter;
+
+iter = (Chain_Iterator *) iter_node;
+
+if ( iter->position == the_node_to_extract ) {
+ if ( iter->direction == CHAIN_ITERATOR_FORWARD ) {
+iter->position = _Chain_Previous( the_node_to_extract );
+ } else {
+iter->position = _Chain_Next( the_node_to_extract );
+ }
+}
+ }
+}
+
+/**
+ * @brief Initializes the chain iterator.
+ *
+ * In the following example nodes inserted during the iteration are visited in
+ * case they are inserted after the current position in iteration order.
+ *
+ * @code
+ * #include
+ * #include
+ *
+ * typedef struct {
+ * Chain_Control Chain;
+ * Chain_Iterator_registry Iterators;
+ * ISR_LOCK_MEMBER(Lock )
+ * } Some_Control;
+ *
+ * void iterate(
+ * Some_Control *the_some,
+ * void ( *visitor )( Chain_Node * )
+ * )
+ * {
+ * ISR_lock_Context lock_context;
+ * Chain_Iteratoriter;
+ * Chain_Node *node;
+ * const Chain_Node *end;
+ *
+ * end = _Chain_Immutable_tail( &the_some->Chain );
+ *
+ * _ISR_lock_ISR_disable_and_acquire( &the_some->Lock, &lock_context );
+ *
+ * _Chain_Iterator_initialize(
+ * &the_some->Chain,
+ * &the_some->Iterators,
+ * &iter,
+ * CHAIN_ITERATOR_FORWARD
+ * );
+ *
+ * while ( ( node = _Chain_Iterator_next( &iter ) ) != end ) {
+ * _Chain_Iterator_set_position( &iter, node );
+ * _ISR_lock_Release_and_ISR_enable( &the_some->Lock, &lock_context );
+ * ( *visitor )( node );
+ * _ISR_lock_ISR_disable_and_acquir
Re: GCC 6 Release Candiate
Hello Sebastian and others, On Monday 18 of April 2016 12:49:33 Sebastian Huber wrote: > Hello, > > I updated the RTEMS 4.12 RSB tool chain to use the GCC 6.1 release > candidate. > > https://gcc.gnu.org/ml/gcc/2016-04/msg00109.html only for information, I have updated my local toolchain build to GCC 6.1 RC and tested current RTEMS mainline with i386 QEMU, LPC178x and TMS570 boards and all targets have workend well. But testing has been only basic till now but included LPC178x with RTEMS integrated TCP/IP stack and TMS570 with LwIP. Best wishes, Pavel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GCC 6 Release Candiate
Using my rtems.org email this time so the entire list sees this. On Mon, Apr 18, 2016 at 9:01 AM, Pavel Pisa wrote: > Hello Sebastian and others, > > On Monday 18 of April 2016 12:49:33 Sebastian Huber wrote: > > Hello, > > > > I updated the RTEMS 4.12 RSB tool chain to use the GCC 6.1 release > > candidate. > > > > https://gcc.gnu.org/ml/gcc/2016-04/msg00109.html > > only for information, I have updated my local > toolchain build to GCC 6.1 RC and tested current > RTEMS mainline with i386 QEMU, LPC178x and TMS570 > boards and all targets have workend well. > But testing has been only basic till now > but included LPC178x with RTEMS integrated TCP/IP > stack and TMS570 with LwIP. > > Thanks for the testing Pavel! I will get my moxie fix on the branch so hopefully the next snapshot will let us link C++ moxie programs. Did anyone see this thread about SH atomics? https://gcc.gnu.org/ml/gcc/2016-04/msg00112.html Do we want to try to fix this on the 6.1 branch? --joel > Best wishes, > > Pavel > > > ___ > 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: RSB Git modified status
I didn't quite follow. Is this to determine whether RSB should do something? I guess this is caused by some bootstrap or configure that creates untracked files in a repo? What does it matter? On Sun, Apr 17, 2016 at 7:55 PM, Chris Johns wrote: > Hi, > > At the moment the RSB says untracked files in a git repo is modified. > > Is this valid or this is a distraction? For example if I have 'x' as a file > in the repo it is seen as untracked and so modified and nothing in the RSB > has been changed. > > I am currently leaning to not modified. > > 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 v2] score: Add Chain_Iterator
OK thanks for the updates.
On Mon, Apr 18, 2016 at 9:37 AM, Sebastian Huber
wrote:
> Add a chain iterator for safe iteration of chains with concurrent node
> extraction.
> ---
> cpukit/score/include/rtems/score/chainimpl.h | 239
> +++
> testsuites/sptests/spchain/init.c| 119 +
> testsuites/sptests/spchain/spchain.doc | 6 +
> testsuites/sptests/spchain/spchain.scn | 5 +-
> 4 files changed, 367 insertions(+), 2 deletions(-)
>
> diff --git a/cpukit/score/include/rtems/score/chainimpl.h
> b/cpukit/score/include/rtems/score/chainimpl.h
> index ff66d46..f78f2d6 100644
> --- a/cpukit/score/include/rtems/score/chainimpl.h
> +++ b/cpukit/score/include/rtems/score/chainimpl.h
> @@ -800,6 +800,245 @@ RTEMS_INLINE_ROUTINE void
> _Chain_Insert_ordered_unprotected(
>_Chain_Insert_unprotected( _Chain_Previous( next ), to_insert );
> }
>
> +/**
> + * @brief The chain iterator direction.
> + */
> +typedef enum {
> + /**
> + * @brief Iteration from head to tail.
> + */
> + CHAIN_ITERATOR_FORWARD,
> +
> + /**
> + * @brief Iteration from tail to head.
> + */
> + CHAIN_ITERATOR_BACKWARD
> +} Chain_Iterator_direction;
> +
> +/**
> + * @brief A chain iterator which is updated during node extraction if it is
> + * properly registered.
> + *
> + * @see _Chain_Iterator_initialize().
> + */
> +typedef struct {
> + /**
> + * @brief Node for registration.
> + *
> + * Used during _Chain_Iterator_initialize() and _Chain_Iterator_destroy().
> + */
> + Chain_Node Registry_node;
> +
> + /**
> + * @brief The direction of this iterator.
> + *
> + * Immutable after initialization via _Chain_Iterator_initialize().
> + */
> + Chain_Iterator_direction direction;
> +
> + /**
> + * @brief The current position of this iterator.
> + *
> + * The position is initialized via _Chain_Iterator_initialize(). It must
> be
> + * explicitly set after one valid iteration step, e.g. in case a next node
> in
> + * the iterator direction existed. It is updated through the registration
> in
> + * case a node is extracted via _Chain_Iterator_registry_update().
> + */
> + Chain_Node *position;
> +} Chain_Iterator;
> +
> +/**
> + * @brief A registry for chain iterators.
> + *
> + * Should be attached to a chain control to enable safe iteration through a
> + * chain in case of concurrent node extractions.
> + */
> +typedef struct {
> + Chain_Control Iterators;
> +} Chain_Iterator_registry;
> +
> +/**
> + * @brief Chain iterator registry initializer for static initialization.
> + *
> + * @param name The designator of the chain iterator registry.
> + */
> +#define CHAIN_ITERATOR_REGISTRY_INITIALIZER( name ) \
> + { CHAIN_INITIALIZER_EMPTY( name.Iterators ) }
> +
> +/**
> + * @brief Initializes a chain iterator registry.
> + */
> +RTEMS_INLINE_ROUTINE void _Chain_Iterator_registry_initialize(
> + Chain_Iterator_registry *the_registry
> +)
> +{
> + _Chain_Initialize_empty( &the_registry->Iterators );
> +}
> +
> +/**
> + * @brief Updates all iterators present in the chain iterator registry in
> case
> + * of a node extraction.
> + *
> + * Must be called before _Chain_Extract_unprotected().
> + *
> + * @warning This function will look at all registered chain iterators to
> + * determine if an update is necessary.
> + */
> +RTEMS_INLINE_ROUTINE void _Chain_Iterator_registry_update(
> + Chain_Iterator_registry *the_registry,
> + Chain_Node *the_node_to_extract
> +)
> +{
> + Chain_Node *iter_node;
> + Chain_Node *iter_tail;
> +
> + iter_node = _Chain_Head( &the_registry->Iterators );
> + iter_tail = _Chain_Tail( &the_registry->Iterators );
> +
> + while ( ( iter_node = _Chain_Next( iter_node ) ) != iter_tail ) {
> +Chain_Iterator *iter;
> +
> +iter = (Chain_Iterator *) iter_node;
> +
> +if ( iter->position == the_node_to_extract ) {
> + if ( iter->direction == CHAIN_ITERATOR_FORWARD ) {
> +iter->position = _Chain_Previous( the_node_to_extract );
> + } else {
> +iter->position = _Chain_Next( the_node_to_extract );
> + }
> +}
> + }
> +}
> +
> +/**
> + * @brief Initializes the chain iterator.
> + *
> + * In the following example nodes inserted during the iteration are visited
> in
> + * case they are inserted after the current position in iteration order.
> + *
> + * @code
> + * #include
> + * #include
> + *
> + * typedef struct {
> + * Chain_Control Chain;
> + * Chain_Iterator_registry Iterators;
> + * ISR_LOCK_MEMBER(Lock )
> + * } Some_Control;
> + *
> + * void iterate(
> + * Some_Control *the_some,
> + * void ( *visitor )( Chain_Node * )
> + * )
> + * {
> + * ISR_lock_Context lock_context;
> + * Chain_Iteratoriter;
> + * Chain_Node *node;
> + * const Chain_Node *end;
> + *
> + * end = _Chain_Immutable_tail( &the_some->Chain );
> + *
> + * _ISR_lock_ISR_disable_and_acquire( &the_some->Lock, &lock_context );
>
Re: RSB Git modified status
On 19/04/2016 02:34, Gedare Bloom wrote: I didn't quite follow. Is this to determine whether RSB should do something? I am sorry, I should have provided more of a context. I guess this is caused by some bootstrap or configure that creates untracked files in a repo? Yes. What does it matter? It is used to create the version message, for example gcc ... $ i386-rtems4.12-gcc --version i386-rtems4.12-gcc (GCC) 6.0.0 20160327 (RTEMS 4.12, RSB 6843e47ce33961e5a705285f3af7a78cae0c2891-modified, Newlib 2.4.0) This lets us know if the repo is clean or dirty and if changes have been made. It helps us support users and it can be part of the evidence in an audit. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
moxie C++ GCC PR and patch
Hi Just a note that I have a patch for the moxie and a ticket filed with GCC https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70720 The issue goes back at least to 4.9. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RSB Git modified status
On 19/04/2016 08:11, Gedare Bloom wrote: On Mon, Apr 18, 2016 at 5:31 PM, Chris Johns wrote: This lets us know if the repo is clean or dirty and if changes have been made. It helps us support users and it can be part of the evidence in an audit. For this specific use, I would not call it modified, because it is useful to differentiate between a tree that has actually been modified by a user, and a build that is "vanilla" with only modifications introduced by auto-gen files. Any untracked files present should only affect the build if the user also modifies tracked files (short of a user hacking Makefile.in and configure files, too). This is what I also think. The RSB is unique because you can add a new file or a few files and use those but they would tend to result in different version numbers showing up in other parts. I will push a patch. Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RSB Git modified status
On Mon, Apr 18, 2016 at 5:31 PM, Chris Johns wrote: > On 19/04/2016 02:34, Gedare Bloom wrote: >> >> I didn't quite follow. Is this to determine whether RSB should do >> something? > > > I am sorry, I should have provided more of a context. > >> I guess this is caused by some bootstrap or configure that >> creates untracked files in a repo? > > > Yes. > >> >> What does it matter? >> > > It is used to create the version message, for example gcc ... > > $ i386-rtems4.12-gcc --version > i386-rtems4.12-gcc (GCC) 6.0.0 20160327 (RTEMS 4.12, RSB > 6843e47ce33961e5a705285f3af7a78cae0c2891-modified, Newlib 2.4.0) > > This lets us know if the repo is clean or dirty and if changes have been > made. It helps us support users and it can be part of the evidence in an > audit. > For this specific use, I would not call it modified, because it is useful to differentiate between a tree that has actually been modified by a user, and a build that is "vanilla" with only modifications introduced by auto-gen files. Any untracked files present should only affect the build if the user also modifies tracked files (short of a user hacking Makefile.in and configure files, too). ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
