Re: [PATCH] build: Use build context for custom commands
On 13/9/2023 4:18 pm, Sebastian Huber wrote:
>
>
> On 13.09.23 03:12, Chris Johns wrote:
>> On 12/9/2023 5:55 pm, Sebastian Huber wrote:
>>> On 12.09.23 09:43, Chris Johns wrote:
>>> Setting OPTIMIZATION_FLAGS and TEST_OPTIMIZATION_FLAGS through the
>>> configuration
>>> file always worked.
>> Great. I am seeing:
>>
>> OPTIMIZATION_FLAGS = -O2 -g -fdata-sections -ffunction-sections
>>
>> and data sections is an optimisation however does it complicates things
>> for the
>> user if they play with with just -O2?
>>
>> 1. -g is debug info and not optimisation
>>
>> 2. we recommend building RTEMS with -fdata-sections -ffunction-sections
>> so I
>> guess removing them would not be good
> We can easily split up the OPTIMIZATION_FLAGS and add more options. For
> example:
>
> DEBUG_FLAGS = -g
>
> OPTIMIZATION_FLAGS = -O2 -fdata-sections -ffunction-sections
>
I think it will help.
As an idea what about DEBUGGING_OPTIONS and OPTIMIZATION_OPTIONS then
OPTIMIZATION_FLAGS is "${OPTIMIZATION_OPTIONS} ${DEBUGGING_OPTIONS}" so it
follows the gcc naming of its option grouping [1] ?
Chris
[1]https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html
>>> Yes, using OPTIONS instead of FLAGS is more in line with the GCC
>>> documentation,
>>> however, we currently use FLAGS for this stuff:
>>>
>>> grep -r -o -h '\w*FLAGS' spec | sort -u
>>> ABI_FLAGS
>>> ARFLAGS
>>> ASFLAGS
>>> BSP_CFLAGS
>>> BSP_OPTIMIZATION_FLAGS
>>> CC_WARNING_FLAGS
>>> CFLAGS
>>> COVERAGE_COMPILER_FLAGS
>>> COVERAGE_LINKER_FLAGS
>>> CPPFLAGS
>>> CPUKIT_OPTIMIZATION_FLAGS
>>> CPU_CFLAGS
>>> CXXFLAGS
>>> CXX_WARNING_FLAGS
>>> LDFLAGS
>>> LINKFLAGS
>>> MPC55XX_BOOTFLAGS
>>> OPTIMIZATION_FLAGS
>>> PKGCONFIG_LDFLAGS
>>> TEST_DL01_CPPFLAGS
>>> TEST_DL02_CPPFLAGS
>>> TEST_DL04_CPPFLAGS
>>> TEST_DL05_CPPFLAGS
>>> TEST_DL06_CPPFLAGS
>>> TEST_DL07_CPPFLAGS
>>> TEST_DL08_CPPFLAGS
>>> TEST_DL09_CPPFLAGS
>>> TEST_DL10_CPPFLAGS
>>> TEST_DL11_CPPFLAGS
>>> TEST_OPTIMIZATION_FLAGS
>>> TEST_TAR01_CPPFLAGS
>>> TEST_TAR02_CPPFLAGS
>>> TEST_psxftw01_CPPFLAGS
>>> TMS570_LINKFLAGS
>>> WARNING_FLAGS
>>> XCFLAGS
>>>
>>> I guess it is derived from CFLAGS, etc.
>> Yes. The thinking is OPTIONS is user focused and can be a set of options from
>> that section of the gcc manual while FLAGS are build system focused? We need
>> FLAGS like OPTIMIZATION_FLAGS and we make the distinction that user can
>> change
>> OPTIONS and if you touch FLAGS you need to be more careful. We keep the ABI
>> machine flags away from OPTIONS and in FLAGS.
>
> I think it is too late to introduce a new naming here. There may be already
> configuration files which use OPTIMIZATION_FLAGS. I would just split this
> option
> into OPTIMIZATION_FLAGS and DEBUGGING_FLAGS.
We have not released any of this however after that it is too late if we want or
need to change.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Use build context for custom commands
On 13.09.23 09:20, Chris Johns wrote:
On 13/9/2023 4:18 pm, Sebastian Huber wrote:
On 13.09.23 03:12, Chris Johns wrote:
On 12/9/2023 5:55 pm, Sebastian Huber wrote:
On 12.09.23 09:43, Chris Johns wrote:
Setting OPTIMIZATION_FLAGS and TEST_OPTIMIZATION_FLAGS through the
configuration
file always worked.
Great. I am seeing:
OPTIMIZATION_FLAGS = -O2 -g -fdata-sections -ffunction-sections
and data sections is an optimisation however does it complicates things
for the
user if they play with with just -O2?
1. -g is debug info and not optimisation
2. we recommend building RTEMS with -fdata-sections -ffunction-sections so I
guess removing them would not be good
We can easily split up the OPTIMIZATION_FLAGS and add more options. For
example:
DEBUG_FLAGS = -g
OPTIMIZATION_FLAGS = -O2 -fdata-sections -ffunction-sections
I think it will help.
As an idea what about DEBUGGING_OPTIONS and OPTIMIZATION_OPTIONS then
OPTIMIZATION_FLAGS is "${OPTIMIZATION_OPTIONS} ${DEBUGGING_OPTIONS}" so it
follows the gcc naming of its option grouping [1] ?
Chris
[1]https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html
Yes, using OPTIONS instead of FLAGS is more in line with the GCC documentation,
however, we currently use FLAGS for this stuff:
grep -r -o -h '\w*FLAGS' spec | sort -u
ABI_FLAGS
ARFLAGS
ASFLAGS
BSP_CFLAGS
BSP_OPTIMIZATION_FLAGS
CC_WARNING_FLAGS
CFLAGS
COVERAGE_COMPILER_FLAGS
COVERAGE_LINKER_FLAGS
CPPFLAGS
CPUKIT_OPTIMIZATION_FLAGS
CPU_CFLAGS
CXXFLAGS
CXX_WARNING_FLAGS
LDFLAGS
LINKFLAGS
MPC55XX_BOOTFLAGS
OPTIMIZATION_FLAGS
PKGCONFIG_LDFLAGS
TEST_DL01_CPPFLAGS
TEST_DL02_CPPFLAGS
TEST_DL04_CPPFLAGS
TEST_DL05_CPPFLAGS
TEST_DL06_CPPFLAGS
TEST_DL07_CPPFLAGS
TEST_DL08_CPPFLAGS
TEST_DL09_CPPFLAGS
TEST_DL10_CPPFLAGS
TEST_DL11_CPPFLAGS
TEST_OPTIMIZATION_FLAGS
TEST_TAR01_CPPFLAGS
TEST_TAR02_CPPFLAGS
TEST_psxftw01_CPPFLAGS
TMS570_LINKFLAGS
WARNING_FLAGS
XCFLAGS
I guess it is derived from CFLAGS, etc.
Yes. The thinking is OPTIONS is user focused and can be a set of options from
that section of the gcc manual while FLAGS are build system focused? We need
FLAGS like OPTIMIZATION_FLAGS and we make the distinction that user can change
OPTIONS and if you touch FLAGS you need to be more careful. We keep the ABI
machine flags away from OPTIONS and in FLAGS.
I think it is too late to introduce a new naming here. There may be already
configuration files which use OPTIMIZATION_FLAGS. I would just split this option
into OPTIMIZATION_FLAGS and DEBUGGING_FLAGS.
We have not released any of this however after that it is too late if we want or
need to change.
I am not against a big overhaul of the build options, but then we should
document the patterns and review all options.
--
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: [PATCH] doxygen: Replace and move main page
On 03.08.23 09:38, Sebastian Huber wrote: Hello Joel, On 28.07.23 16:37, Sebastian Huber wrote: Replace the main page with a high level description of the RTEMS feature set similar to: https://docs.rtems.org/branches/master/user/overview/index.html#features The replaced content can be found in the RTEMS Classic API Guide: https://docs.rtems.org/branches/master/c-user/overview.html https://docs.rtems.org/branches/master/c-user/key_concepts.html Update #3705. --- v2: * Add OAR copyright. * Move to cpukit/doxygen/mainpage.h * Not not install what about this version of the patch? Ping. -- 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: Outdated list of BSPs in rtems-tools/config
> On Jul 25, 2023, at 10:14 , Joel Sherrill wrote: > > Most of those are recent and from a lot of different people. GSoC, Kinsey, > you, Vijay or Chris, Karel, etc. But I wonder about that phycore_mpc5554. I > think it has been around a LONG time. > I'm cleaning my in-box, and I missed a reference to te Phycore-MPC5554 BSP in July. I am the one who added the Phycore-mpc5554 as a minor refinement to the Freescale MPC55xx embedded board BSPs developed by "eb". It *is* time to retire the Phytec board as that board is no longer available. But, I hope we can keep it around for a while as I now need to work on a follow-up to that BSP. One of my clients uses the Phycore-MPC5554. They missed the end-of life announcement for that board. They need to quickly update to something very compatible, and a BSP based on the PHYTEC MPC5674F will work, the MPC5674F has all the functionality they require without software changes. I'd like to keep the Phycore-MPC5554 BSP alive and kicking while I develop equivalent MPC5674F support. A related question. I think "eb" has a "gwlcfm" target that uses this NXP architecture in one of their products. "eb", are you planning another "gwlcfm", or are you done with that, and what platform would you move to? I'd like to learn about an architecture that works as well as the old Motorola architecture does without custom FPGA programming. If I leave the old Motorola PowerPC's architecture targeted at engine control, I will miss how the ADC DMA chain works together with the eTPU and also schedules the output so cleanly do background motor control, and other timing intensive applications, so that the main CPU is free to e.g. run RTEMS (and in my case position servo control). Peter - Peter Dufault HD Associates, Inc. Software and System Engineering signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Use build context for custom commands
On 13/9/2023 6:52 pm, Sebastian Huber wrote:
> On 13.09.23 09:20, Chris Johns wrote:
>> On 13/9/2023 4:18 pm, Sebastian Huber wrote:
>>>
>>> On 13.09.23 03:12, Chris Johns wrote:
On 12/9/2023 5:55 pm, Sebastian Huber wrote:
> On 12.09.23 09:43, Chris Johns wrote:
> Setting OPTIMIZATION_FLAGS and TEST_OPTIMIZATION_FLAGS through the
> configuration
> file always worked.
Great. I am seeing:
OPTIMIZATION_FLAGS = -O2 -g -fdata-sections -ffunction-sections
and data sections is an optimisation however does it complicates things
for the
user if they play with with just -O2?
1. -g is debug info and not optimisation
2. we recommend building RTEMS with -fdata-sections -ffunction-sections
so I
guess removing them would not be good
>>> We can easily split up the OPTIMIZATION_FLAGS and add more options. For
>>> example:
>>>
>>> DEBUG_FLAGS = -g
>>>
>>> OPTIMIZATION_FLAGS = -O2 -fdata-sections -ffunction-sections
>>>
>> I think it will help.
>>
>> As an idea what about DEBUGGING_OPTIONS and OPTIMIZATION_OPTIONS then
>> OPTIMIZATION_FLAGS is "${OPTIMIZATION_OPTIONS} ${DEBUGGING_OPTIONS}" so
>> it
>> follows the gcc naming of its option grouping [1] ?
>>
>> Chris
>>
>> [1]https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html
> Yes, using OPTIONS instead of FLAGS is more in line with the GCC
> documentation,
> however, we currently use FLAGS for this stuff:
>
> grep -r -o -h '\w*FLAGS' spec | sort -u
> ABI_FLAGS
> ARFLAGS
> ASFLAGS
> BSP_CFLAGS
> BSP_OPTIMIZATION_FLAGS
> CC_WARNING_FLAGS
> CFLAGS
> COVERAGE_COMPILER_FLAGS
> COVERAGE_LINKER_FLAGS
> CPPFLAGS
> CPUKIT_OPTIMIZATION_FLAGS
> CPU_CFLAGS
> CXXFLAGS
> CXX_WARNING_FLAGS
> LDFLAGS
> LINKFLAGS
> MPC55XX_BOOTFLAGS
> OPTIMIZATION_FLAGS
> PKGCONFIG_LDFLAGS
> TEST_DL01_CPPFLAGS
> TEST_DL02_CPPFLAGS
> TEST_DL04_CPPFLAGS
> TEST_DL05_CPPFLAGS
> TEST_DL06_CPPFLAGS
> TEST_DL07_CPPFLAGS
> TEST_DL08_CPPFLAGS
> TEST_DL09_CPPFLAGS
> TEST_DL10_CPPFLAGS
> TEST_DL11_CPPFLAGS
> TEST_OPTIMIZATION_FLAGS
> TEST_TAR01_CPPFLAGS
> TEST_TAR02_CPPFLAGS
> TEST_psxftw01_CPPFLAGS
> TMS570_LINKFLAGS
> WARNING_FLAGS
> XCFLAGS
>
> I guess it is derived from CFLAGS, etc.
Yes. The thinking is OPTIONS is user focused and can be a set of options
from
that section of the gcc manual while FLAGS are build system focused? We
need
FLAGS like OPTIMIZATION_FLAGS and we make the distinction that user can
change
OPTIONS and if you touch FLAGS you need to be more careful. We keep the ABI
machine flags away from OPTIONS and in FLAGS.
>>> I think it is too late to introduce a new naming here. There may be already
>>> configuration files which use OPTIMIZATION_FLAGS. I would just split this
>>> option
>>> into OPTIMIZATION_FLAGS and DEBUGGING_FLAGS.
>> We have not released any of this however after that it is too late if we
>> want or
>> need to change.
>
> I am not against a big overhaul of the build options, but then we should
> document the patterns and review all options.
Great and yes. When?
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] libdl: Add support to import base image TLS symbols
This seems to break the mips build: cpukit/libdl/rtl-tls.c:104:2: error: #error unsupported architecture 104 | #error unsupported architecture | ^ -- 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 commit] libdl: Add support to import base image TLS symbols
On 14.09.23 08:34, Sebastian Huber wrote: This seems to break the mips build: cpukit/libdl/rtl-tls.c:104:2: error: #error unsupported architecture 104 | #error unsupported architecture | ^ Also the moxie and 64-bit powerpc (qoriq_e6500_64) no longer build with the error above. -- 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
[PATCH] score: Fix TLS support for some code models
Store symbols with an arbitrary absolute address such as _TLS_Size,
_TLS_Alignment, _TLS_Data_size, and _TLS_BSS_size in an object to avoid issues
with some code models.
Update #4953.
---
cpukit/include/rtems/score/tls.h | 120 +-
cpukit/score/src/tlsallocsize.c | 43 +--
testsuites/sptests/sptls01/init.c | 4 +-
3 files changed, 108 insertions(+), 59 deletions(-)
diff --git a/cpukit/include/rtems/score/tls.h b/cpukit/include/rtems/score/tls.h
index fa3ee0afa2..8716c5230c 100644
--- a/cpukit/include/rtems/score/tls.h
+++ b/cpukit/include/rtems/score/tls.h
@@ -10,7 +10,7 @@
*/
/*
- * Copyright (C) 2014, 2022 embedded brains GmbH & Co. KG
+ * Copyright (C) 2014, 2023 embedded brains GmbH & Co. KG
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
@@ -59,31 +59,51 @@ extern "C" {
* @{
*/
-extern char _TLS_Data_begin[];
-
-extern char _TLS_Data_end[];
+/**
+ * @brief Represents the TLS configuration.
+ */
+typedef struct {
+ /**
+ * @brief This member is initialized to _TLS_Data_begin.
+ */
+ const char *data_begin;
-extern char _TLS_Data_size[];
+ /**
+ * @brief This member is initialized to _TLS_Data_size.
+ */
+ const char *data_size;
-extern char _TLS_BSS_begin[];
+ /**
+ * @brief This member is initialized to _TLS_BSS_begin.
+ */
+ const char *bss_begin;
-extern char _TLS_BSS_end[];
+ /**
+ * @brief This member is initialized to _TLS_BSS_size.
+ */
+ const char *bss_size;
-extern char _TLS_BSS_size[];
+ /**
+ * @brief This member is initialized to _TLS_Size.
+ */
+ const char *size;
-extern char _TLS_Size[];
+ /**
+ * @brief This member is initialized to _TLS_Alignment.
+ */
+ const char *alignment;
+} TLS_Configuration;
/**
- * @brief The TLS section alignment.
+ * @brief Provides the TLS configuration.
*
- * This symbol is provided by the linker command file as the maximum alignment
- * of the .tdata and .tbss sections. The linker ensures that the first TLS
- * output section is aligned to the maximum alignment of all TLS output
- * sections, see function _bfd_elf_tls_setup() in bfd/elflink.c of the GNU
- * Binutils sources. The linker command file must take into account the case
- * that the .tdata section is empty and the .tbss section is non-empty.
+ * Directly using symbols with an arbitrary absolute address such as
+ * _TLS_Alignment may not work with all code models (for example the AArch64
+ * tiny and small code models). Store the addresses in a read-only object.
+ * Using the volatile qualifier ensures that the compiler actually loads the
+ * address from the object.
*/
-extern char _TLS_Alignment[];
+extern const volatile TLS_Configuration _TLS_Configuration;
typedef struct {
/*
@@ -115,39 +135,25 @@ typedef struct {
uintptr_t offset;
} TLS_Index;
-/**
- * @brief Gets the size of the thread-local storage data in bytes.
- *
- * @return Returns the size of the thread-local storage data in bytes.
- */
-static inline uintptr_t _TLS_Get_size( void )
-{
- uintptr_t size;
-
- /*
- * We must be careful with using _TLS_Size here since this could lead GCC to
- * assume that this symbol is not 0 and the tests for 0 will be optimized
- * away.
- */
- size = (uintptr_t) _TLS_Size;
- RTEMS_OBFUSCATE_VARIABLE( size );
- return size;
-}
-
/**
* @brief Gets the size of the thread control block area in bytes.
*
+ * @param config is the TLS configuration.
+ *
* @return Returns the size of the thread control block area in bytes.
*/
-static inline uintptr_t _TLS_Get_thread_control_block_area_size( void )
+static inline uintptr_t _TLS_Get_thread_control_block_area_size(
+ const volatile TLS_Configuration *config
+)
{
#if CPU_THREAD_LOCAL_STORAGE_VARIANT == 11
uintptr_t alignment;
- alignment = (uintptr_t) _TLS_Alignment;
+ alignment = (uintptr_t) config->alignment;
return RTEMS_ALIGN_UP( sizeof( TLS_Thread_control_block ), alignment );
#else
+ (void) config;
return sizeof( TLS_Thread_control_block );
#endif
}
@@ -163,17 +169,23 @@ uintptr_t _TLS_Get_allocation_size( void );
/**
* @brief Initializes the thread-local storage data.
*
+ * @param config is the TLS configuration.
+ *
* @param[out] tls_data is the thread-local storage data to initialize.
*/
-static inline void _TLS_Copy_and_clear( void *tls_data )
+static inline void _TLS_Copy_and_clear(
+ const volatile TLS_Configuration *config,
+ void *tls_data
+)
{
- tls_data = memcpy( tls_data, _TLS_Data_begin, (uintptr_t) _TLS_Data_size );
+ tls_data =
+memcpy( tls_data, config->data_begin, (uintptr_t) config->data_size );
memset(
(char *) tls_data +
- (uintptr_t) _TLS_BSS_begin - (uintptr_t) _TLS_Data_begin,
+ (uintptr_t) config->bss_begin - (uintptr_t) config->data_begin,
0,
-(uintptr_t) _TLS_BSS_size
+(uintptr_t) config->bss_si
