Re: [PATCH RTEMS] spec: Add -mstrict-align to mvme2100 default build
On 11/8/2023 1:17 pm, Vijay Kumar Banerjee wrote:
> On Wed, Aug 9, 2023 at 8:04 PM Chris Johns wrote:
>>
>> On 10/8/2023 2:41 am, Joel Sherrill wrote:
>>> Reading the EPICS discussion, I wonder if this should be added for all
>>> motorola_powerpc BSP variants.
>>>
>>> Gedare/Chris/anyone with another board in the family? What do you think?
>>
>> Michael asked if the setting is present when building libc, libm etc in the
>> EPICS core devs meeting today and I could not answer the question?
>
> I just built the tools for powerpc and it looks like libc, libm are
> not built with the -mstrict-align flag.
Is it a problem to not have option? I am do not know enough about this area of
the PowerPC to know.
>> Is it
>> exported in the .pc or Makefile.inc flags?
>>
> This flag is exported in ${RTEMS_BSP}.cfg file in RTEMS, which gets
> included by EPICS though CONFIG.Common.RTEMS:
> https://github.com/epics-base/epics-base/blob/7.0/configure/os/CONFIG.Common.RTEMS#L38
>
> The `RTEMS_CUSTOM` variable is defined in Makefile.inc, and it points
> to the ${RTEMS_BSP}.cfg file
RTEMS has not needed this flag and libc and libm do not have it on so I am
confused why code in EPICS has triggering something that needs this option? I
would have thought it is needed everywhere or not at all?
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] cpukit/score/aarch64: Use correct MAIR index
The MAIR index currently assigned (1) for uncached memory segments is
not configured properly for this purpose. Instead, this switches
uncached memory segment flags to MAIR index 2 which is properly
configured for uncached inner and outer shareable domains.
---
cpukit/score/cpu/aarch64/include/libcpu/mmu-vmsav8-64.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cpukit/score/cpu/aarch64/include/libcpu/mmu-vmsav8-64.h
b/cpukit/score/cpu/aarch64/include/libcpu/mmu-vmsav8-64.h
index 0d65004f88..ca9b60e6d1 100644
--- a/cpukit/score/cpu/aarch64/include/libcpu/mmu-vmsav8-64.h
+++ b/cpukit/score/cpu/aarch64/include/libcpu/mmu-vmsav8-64.h
@@ -70,7 +70,7 @@ extern "C" {
#define AARCH64_MMU_CODE_RW_CACHED AARCH64_MMU_DATA_RW_CACHED
#define AARCH64_MMU_DATA_RO \
- ( AARCH64_MMU_FLAGS_BASE | MMU_DESC_MAIR_ATTR( 1 ) | MMU_DESC_WRITE_DISABLE )
+ ( AARCH64_MMU_FLAGS_BASE | MMU_DESC_MAIR_ATTR( 2 ) | MMU_DESC_WRITE_DISABLE )
#define AARCH64_MMU_CODE AARCH64_MMU_DATA_RO
#define AARCH64_MMU_CODE_RW AARCH64_MMU_DATA_RW
@@ -78,7 +78,7 @@ extern "C" {
#define AARCH64_MMU_DATA_RW_CACHED \
( AARCH64_MMU_FLAGS_BASE | MMU_DESC_MAIR_ATTR( 3 ) )
#define AARCH64_MMU_DATA_RW \
- ( AARCH64_MMU_FLAGS_BASE | MMU_DESC_MAIR_ATTR( 1 ) )
+ ( AARCH64_MMU_FLAGS_BASE | MMU_DESC_MAIR_ATTR( 2 ) )
#define AARCH64_MMU_DEVICE ( AARCH64_MMU_FLAGS_BASE | MMU_DESC_MAIR_ATTR( 0 ) )
rtems_status_code aarch64_mmu_map(
--
2.39.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Make gzip archives reproducible
On 12.08.23 18:29, Joel Sherrill wrote: This looks ok. Thanks. Piling on Chris' comments about where is the requirement for this. This is a topic which must be addressed in the Software Engineering Guide and accepted before it can be put into practices. A software development process of any quality cannot be changed on a whim without discussion and modifying all the artifacts necessary. Sorry, it was not my intention to open another can of worms. This reproducible builds stuff appeared to be some small thing to do. -- 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] build: Make gzip archives reproducible
On 14/8/2023 4:24 pm, Sebastian Huber wrote: > On 12.08.23 18:29, Joel Sherrill wrote: >> Piling on Chris' comments about where is the requirement for this. This is a >> topic which must be addressed in the Software Engineering Guide and accepted >> before it can be put into practices. A software development process of any >> quality cannot be changed on a whim without discussion and modifying all the >> artifacts necessary. > > Sorry, it was not my intention to open another can of worms. This reproducible > builds stuff appeared to be some small thing to do. I think it would be good to understand what you intend and why? At the moment we are wondering or guessing based on some patches and that is never good. Our main focus is the long term liability change have for us. Anything you can add to explain things helps. I think reproducible builds is a great thing to attempt but in the past there have been issues. For example at one point the register allocator in gcc for the m68k used the libc sort and Windows and Linux differed when sorting "all the elements are the same" so the code built on Windows did not match the code built on Linux even though it was equivalent code, ie register ordering for push and pops differed. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
