Re: [RSB 1/3] 6/7: Update Newlib
On 21/7/2022 3:21 pm, Sebastian Huber wrote: > On 20.07.22 22:52, Chris Johns wrote: >> On 20/7/2022 6:20 pm, Sebastian Huber wrote: >>> On 20/07/2022 10:11, Chris Johns wrote: >> Are these TLS allocations in newlib based on a single use of a newlib >> call >> that >> brings in the reent stuff? How does that work? > No, each TLS object is defined in the translation unit which uses the > object. > The goal is to get only those objects linked in which are needed. > Currently, the > Newlib thread delete hook pulls in some objects, however, this dependency > will > go away once the TLS destructors are implemented. If I have task A and it opens a file and writes something to a file system will it pull in the TLS support for files? >>> >>> Yes. >>> Given the TLS support is static does this mean all threads in the A app allocate the newlib file TLS variables even if they never use newlib? >>> >>> Yes. >>> My understanding of the existing reent support is tasks that do not use newlib it never allocate a reent struct? >>> >>> No, the struct _reent is allocated for all tasks if you don't use >>> CONFIGURE_DISABLE_NEWLIB_REENTRANCY (which is not recommended). How would >>> you >>> know if a task doesn't use Newlib? >> >> I thought the get would do a check and then allocate on first use. It has >> been >> many years since I looked at the implementation. >> >> I think this change is a good one because it will reduce the needed memory to >> the amount used and it will have better performance. >> >> I think option you post is a good thing to add, maybe as >> --enable-newlib-reent-tls. What will be the default? > > You mean a proper sb-set-builder option and not just a --with-newlib-tls? Not an sb option rather something using the --wtih/--without flags. I just renamed yours as `thread-local` may not be as well know as TLS. > I > would make it the default for the targets with known to work TLS support: > aarch64, arm, nios2, powerpc, riscv, and sparc. Sure it can be the default for the archs that can support it but a --without-newlib-tls option might be useful to someone using libdl if this change breaks their usage, ie linking from archives on the target. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] score: Remove PRIORITY_PSEUDO_ISR thread priority
Hello Gedare and Joel, On 15.07.22 10:43, Sebastian Huber wrote: The uniprocessor schedulers had some special case logic for the PRIORITY_PSEUDO_ISR priority. Tasks with a priority of PRIORITY_PSEUDO_ISR were allowed to preempt a not preemptible task. If other higher priority task are made ready while a PRIORITY_PSEUDO_ISR task preempts a not preemptible task, then the other tasks run before the not preemptible task. This made the RTEMS_NO_PREEMPT mode ineffective. Remove the PRIORITY_PSEUDO_ISR special case logic. This simplifies the uniprocessor schedulers. Move the uniprocessor-specific scheduler support to the new header file . Close #2365. what is your opinion with respect to this change? It is the second last item on my score TODO list. The last item is: https://lists.rtems.org/pipermail/devel/2022-July/072534.html -- 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 v2] build: Add TLS_MODEL_FLAGS
Update #4560. --- v2: * Do not use -ftls-model=local-exec for targets without TLS support. spec/build/bsps/bspopts.yml | 2 ++ spec/build/bsps/opttlsmodelflags.yml | 28 2 files changed, 30 insertions(+) create mode 100644 spec/build/bsps/opttlsmodelflags.yml diff --git a/spec/build/bsps/bspopts.yml b/spec/build/bsps/bspopts.yml index 4a4c06d321..330be27a83 100644 --- a/spec/build/bsps/bspopts.yml +++ b/spec/build/bsps/bspopts.yml @@ -13,6 +13,8 @@ links: uid: optcpukitoptflags - role: build-dependency uid: opttestoptflags +- role: build-dependency + uid: opttlsmodelflags - role: build-dependency uid: optabi - role: build-dependency diff --git a/spec/build/bsps/opttlsmodelflags.yml b/spec/build/bsps/opttlsmodelflags.yml new file mode 100644 index 00..7d910276b1 --- /dev/null +++ b/spec/build/bsps/opttlsmodelflags.yml @@ -0,0 +1,28 @@ +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause +actions: +- get-string: null +- split: null +- env-append: ABI_FLAGS +build-type: option +copyrights: +- Copyright (C) 2022 embedded brains GmbH (http://www.embedded-brains.de) +default: +- -ftls-model=local-exec +default-by-variant: +- value: null + variants: + - bfin/.* + - lm32/.* + - mips/.* + - moxie/.* + - or1k/.* + - sh/.* + - sparc64/.* + - v850/.* +description: | + Defines the compiler flags setting the thread-local storage (TLS) model. The + flags are added to the ABI_FLAGS. +enabled-by: true +links: [] +name: TLS_MODEL_FLAGS +type: build -- 2.35.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] build: Add TLS_MODEL_FLAGS
Update #4560. --- spec/build/bsps/bspopts.yml | 2 ++ spec/build/bsps/opttlsmodelflags.yml | 17 + 2 files changed, 19 insertions(+) create mode 100644 spec/build/bsps/opttlsmodelflags.yml diff --git a/spec/build/bsps/bspopts.yml b/spec/build/bsps/bspopts.yml index 4a4c06d321..330be27a83 100644 --- a/spec/build/bsps/bspopts.yml +++ b/spec/build/bsps/bspopts.yml @@ -13,6 +13,8 @@ links: uid: optcpukitoptflags - role: build-dependency uid: opttestoptflags +- role: build-dependency + uid: opttlsmodelflags - role: build-dependency uid: optabi - role: build-dependency diff --git a/spec/build/bsps/opttlsmodelflags.yml b/spec/build/bsps/opttlsmodelflags.yml new file mode 100644 index 00..d61afaa1f2 --- /dev/null +++ b/spec/build/bsps/opttlsmodelflags.yml @@ -0,0 +1,17 @@ +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause +actions: +- get-string: null +- split: null +- env-append: ABI_FLAGS +build-type: option +copyrights: +- Copyright (C) 2022 embedded brains GmbH (http://www.embedded-brains.de) +default: +- -ftls-model=local-exec +default-by-variant: [] +description: | + Defines the compiler flags setting the thread-local storage (TLS) model. +enabled-by: true +links: [] +name: TLS_MODEL_FLAGS +type: build -- 2.35.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [RSB 1/3] 6/7: Update Newlib
On 20.07.22 22:52, Chris Johns wrote: On 20/7/2022 6:20 pm, Sebastian Huber wrote: On 20/07/2022 10:11, Chris Johns wrote: Are these TLS allocations in newlib based on a single use of a newlib call that brings in the reent stuff? How does that work? No, each TLS object is defined in the translation unit which uses the object. The goal is to get only those objects linked in which are needed. Currently, the Newlib thread delete hook pulls in some objects, however, this dependency will go away once the TLS destructors are implemented. If I have task A and it opens a file and writes something to a file system will it pull in the TLS support for files? Yes. Given the TLS support is static does this mean all threads in the A app allocate the newlib file TLS variables even if they never use newlib? Yes. My understanding of the existing reent support is tasks that do not use newlib it never allocate a reent struct? No, the struct _reent is allocated for all tasks if you don't use CONFIGURE_DISABLE_NEWLIB_REENTRANCY (which is not recommended). How would you know if a task doesn't use Newlib? I thought the get would do a check and then allocate on first use. It has been many years since I looked at the implementation. I think this change is a good one because it will reduce the needed memory to the amount used and it will have better performance. I think option you post is a good thing to add, maybe as --enable-newlib-reent-tls. What will be the default? You mean a proper sb-set-builder option and not just a --with-newlib-tls? I would make it the default for the targets with known to work TLS support: aarch64, arm, nios2, powerpc, riscv, and sparc. For m68k we have a GCC code generation issue currently. -- 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 v2] aarch64: Use page table level 0
On 20.07.22 15:43, Kinsey Moore wrote: This alters the AArch64 page table generation and mapping code and MMU configuration to use page table level 0 in addition to levels 1, 2, and 3. This allows the mapping of up to 48 bits of memory space and is the maximum that can be mapped without relying on additional processor extensions. Mappings are restricted based on the number of physical address bits that the CPU supports. Looks good. -- 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 v1 0/5] Add AArch64 support to libdl
On 21/7/2022 7:36 am, Ryan Long wrote: > This series of patches adds support for AArch64 in libdl and makes some small > tweaks to get the dynamic loader tests working. Thank you for this contribution. It is great to see this arch being supported. It is close. I have posted some questions about the aarch64 back end. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v1 3/5] cpukit/libdl: Add support for AArch64
On 21/7/2022 7:36 am, Ryan Long wrote: > rtl-mdreloc-aarch64.c and elf_machdep.h came from NetBSD. > > Updates #4682 > --- > cpukit/libdl/rtl-mdreloc-aarch64.c| 598 ++ > .../cpu/aarch64/include/machine/elf_machdep.h | 256 > spec/build/cpukit/objdl.yml | 2 + > spec/build/cpukit/objdlaarch64.yml| 15 + > spec/build/cpukit/optlibdl.yml| 1 + > 5 files changed, 872 insertions(+) > create mode 100644 cpukit/libdl/rtl-mdreloc-aarch64.c > create mode 100644 cpukit/score/cpu/aarch64/include/machine/elf_machdep.h > create mode 100644 spec/build/cpukit/objdlaarch64.yml > > diff --git a/cpukit/libdl/rtl-mdreloc-aarch64.c > b/cpukit/libdl/rtl-mdreloc-aarch64.c > new file mode 100644 > index 00..ded73ad46b > --- /dev/null > +++ b/cpukit/libdl/rtl-mdreloc-aarch64.c > @@ -0,0 +1,598 @@ > +/* > + * Taken from NetBSD and stripped of the relocations not needed on RTEMS. > + */ > + > +/* $NetBSD: mdreloc.c,v 1.14 2020/06/16 21:01:30 joerg Exp $ */ > + > +/*- > + * Copyright (c) 2014 The NetBSD Foundation, Inc. > + * All rights reserved. > + * > + * This code is derived from software contributed to The NetBSD Foundation > + * by Matt Thomas of 3am Software Foundry. > + * > + * Redistribution and use in source and binary forms, with or without > + * modification, are permitted provided that the following conditions > + * are met: > + * 1. Redistributions of source code must retain the above copyright > + *notice, this list of conditions and the following disclaimer. > + * 2. Redistributions in binary form must reproduce the above copyright > + *notice, this list of conditions and the following disclaimer in the > + *documentation and/or other materials provided with the distribution. > + * > + * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS > + * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT > LIMITED > + * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > + * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS > + * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN > + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) > + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE > + * POSSIBILITY OF SUCH DAMAGE. > + */ > + > +/*- > + * Copyright (c) 2014-2015 The FreeBSD Foundation > + * All rights reserved. > + * > + * Portions of this software were developed by Andrew Turner > + * under sponsorship from the FreeBSD Foundation. > + * > + * Redistribution and use in source and binary forms, with or without > + * modification, are permitted provided that the following conditions > + * are met: > + * 1. Redistributions of source code must retain the above copyright > + *notice, this list of conditions and the following disclaimer. > + * 2. Redistributions in binary form must reproduce the above copyright > + *notice, this list of conditions and the following disclaimer in the > + *documentation and/or other materials provided with the distribution. > + * > + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND > + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE > + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE > + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL > + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS > + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) > + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT > + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY > + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF > + * SUCH DAMAGE. > + */ > + > +#include > +#ifndef lint > +__RCSID("$NetBSD: mdreloc.c,v 1.14 2020/06/16 21:01:30 joerg Exp $"); > +#endif /* not lint */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include "rtl-elf.h" > +#include "rtl-error.h" > +#include > +#include "rtl-unwind.h" > + > +typedef unsigned _Unwind_Word __attribute__((__mode__(__word__))); > +typedef _Unwind_Word _uw; > + > +struct tls_data { > + size_t td_tlsindex; > + Elf_Addrtd_tlsoffs; > +}; > + > +rtems_rtl_elf_rel_status > +rtems_rtl_elf_reloc_rela ( > + rtems_rtl_obj*obj, > + const Elf_Rela* rela, > + const rtems_rtl_obj_sect* sect, > + const char* symname, > + const Elf_Byte
[PATCH v1 3/5] cpukit/libdl: Add support for AArch64
rtl-mdreloc-aarch64.c and elf_machdep.h came from NetBSD. Updates #4682 --- cpukit/libdl/rtl-mdreloc-aarch64.c| 598 ++ .../cpu/aarch64/include/machine/elf_machdep.h | 256 spec/build/cpukit/objdl.yml | 2 + spec/build/cpukit/objdlaarch64.yml| 15 + spec/build/cpukit/optlibdl.yml| 1 + 5 files changed, 872 insertions(+) create mode 100644 cpukit/libdl/rtl-mdreloc-aarch64.c create mode 100644 cpukit/score/cpu/aarch64/include/machine/elf_machdep.h create mode 100644 spec/build/cpukit/objdlaarch64.yml diff --git a/cpukit/libdl/rtl-mdreloc-aarch64.c b/cpukit/libdl/rtl-mdreloc-aarch64.c new file mode 100644 index 00..ded73ad46b --- /dev/null +++ b/cpukit/libdl/rtl-mdreloc-aarch64.c @@ -0,0 +1,598 @@ +/* + * Taken from NetBSD and stripped of the relocations not needed on RTEMS. + */ + +/* $NetBSD: mdreloc.c,v 1.14 2020/06/16 21:01:30 joerg Exp $ */ + +/*- + * Copyright (c) 2014 The NetBSD Foundation, Inc. + * All rights reserved. + * + * This code is derived from software contributed to The NetBSD Foundation + * by Matt Thomas of 3am Software Foundry. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + *notice, this list of conditions and the following disclaimer in the + *documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS + * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED + * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR + * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS + * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE + * POSSIBILITY OF SUCH DAMAGE. + */ + +/*- + * Copyright (c) 2014-2015 The FreeBSD Foundation + * All rights reserved. + * + * Portions of this software were developed by Andrew Turner + * under sponsorship from the FreeBSD Foundation. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + *notice, this list of conditions and the following disclaimer in the + *documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +#ifndef lint +__RCSID("$NetBSD: mdreloc.c,v 1.14 2020/06/16 21:01:30 joerg Exp $"); +#endif /* not lint */ + +#include +#include +#include +#include +#include +#include +#include + +#include +#include "rtl-elf.h" +#include "rtl-error.h" +#include +#include "rtl-unwind.h" + +typedef unsigned _Unwind_Word __attribute__((__mode__(__word__))); +typedef _Unwind_Word _uw; + +struct tls_data { + size_t td_tlsindex; + Elf_Addrtd_tlsoffs; +}; + +rtems_rtl_elf_rel_status +rtems_rtl_elf_reloc_rela ( + rtems_rtl_obj*obj, + const Elf_Rela* rela, + const rtems_rtl_obj_sect* sect, + const char* symname, + const Elf_Bytesyminfo, + const Elf_Wordsymvalue, + const boolparsing +); + +#define __BITS(hi,lo)((~((~(Elf_Addr)0)<<((hi)+1)))&((~(Elf_Addr)0)<<(lo))) +#define WIDTHMASK(w) (0xUL >> (64 - (w))) + +static inline bool +checkoverflow(E
[PATCH v1 5/5] cpukit/libdl/rtl-sym.c: Fix increment of variable
In rtems_rtl_symbol_global_add() the loop that gets to the end of the symbol table used "unsigned long" to increment the index for the table. For most architectures this resulted in 4, but with AArch64, it results in 8. This resulted in the symbols being read in wrong. Changing this to void* along with changing the RISC-V specific code for 8 byte pointers in rtems-tools to work independent of the architecture. Updates #4673 Closes #4682 --- cpukit/libdl/rtl-sym.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cpukit/libdl/rtl-sym.c b/cpukit/libdl/rtl-sym.c index c29c8c49d6..5c9c3981df 100644 --- a/cpukit/libdl/rtl-sym.c +++ b/cpukit/libdl/rtl-sym.c @@ -124,7 +124,7 @@ rtems_rtl_symbol_global_add (rtems_rtl_obj* obj, return false; } ++count; -s += l + sizeof (unsigned long) + 1; +s += l + sizeof (void *) + 1; } /* -- 2.30.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH v1 1/5] sys/exec_elf.h: Bring in newer file
Updated this file with the newer version in NetBSD. Updates #4682 --- cpukit/include/sys/exec_elf.h | 840 -- 1 file changed, 608 insertions(+), 232 deletions(-) diff --git a/cpukit/include/sys/exec_elf.h b/cpukit/include/sys/exec_elf.h index 4242415f54..b50da6b272 100644 --- a/cpukit/include/sys/exec_elf.h +++ b/cpukit/include/sys/exec_elf.h @@ -1,4 +1,4 @@ -/* $NetBSD: exec_elf.h,v 1.102 2010/03/01 11:27:29 skrll Exp $ */ +/* $NetBSD: exec_elf.h,v 1.168 2020/10/19 19:33:02 christos Exp $ */ /*- * Copyright (c) 1994 The NetBSD Foundation, Inc. @@ -44,6 +44,7 @@ #include #else #include +#include #endif /* _KERNEL || _STANDALONE */ #if defined(ELFSIZE) @@ -60,49 +61,41 @@ #include #endif -typedefuint8_t Elf_Byte; - -typedefuint32_tElf32_Addr; -#defineELF32_FSZ_ADDR 4 -typedefuint32_tElf32_Off; -typedefint32_t Elf32_SOff; -#defineELF32_FSZ_OFF 4 -typedefint32_t Elf32_Sword; -#defineELF32_FSZ_SWORD 4 -typedefuint32_tElf32_Word; -#defineELF32_FSZ_WORD 4 -typedefuint16_tElf32_Half; -#defineELF32_FSZ_HALF 2 -typedefuint64_tElf32_Lword; -#defineELF32_FSZ_LWORD 8 - -typedefuint64_tElf64_Addr; -#defineELF64_FSZ_ADDR 8 -typedefuint64_tElf64_Off; -typedefint64_t Elf64_SOff; -#defineELF64_FSZ_OFF 8 -typedefint32_t Elf64_Shalf; -#defineELF64_FSZ_SHALF 4 - -#ifndef ELF64_FSZ_SWORD -typedefint32_t Elf64_Sword; -#defineELF64_FSZ_SWORD 4 -#endif /* ELF64_FSZ_SWORD */ -#ifndef ELF64_FSZ_WORD -typedefuint32_tElf64_Word; -#defineELF64_FSZ_WORD 4 -#endif /* ELF64_FSZ_WORD */ - -typedefint64_t Elf64_Sxword; -#defineELF64_FSZ_SXWORD 8 -typedefuint64_tElf64_Xword; -#defineELF64_FSZ_XWORD 8 -typedefuint64_tElf64_Lword; -#defineELF64_FSZ_LWORD 8 -typedefuint32_tElf64_Half; -#defineELF64_FSZ_HALF 4 -typedefuint16_tElf64_Quarter; -#defineELF64_FSZ_QUARTER 2 +typedef uint8_tElf_Byte; + +typedef uint32_t Elf32_Addr; +#define ELF32_FSZ_ADDR 4 +typedef uint32_t Elf32_Off; +typedef int32_tElf32_SOff; +#define ELF32_FSZ_OFF 4 +typedef int32_tElf32_Sword; +#define ELF32_FSZ_SWORD 4 +typedef uint32_t Elf32_Word; +#define ELF32_FSZ_WORD 4 +typedef uint16_t Elf32_Half; +#define ELF32_FSZ_HALF 2 +typedef uint64_t Elf32_Lword; +#define ELF32_FSZ_LWORD 8 + +typedef uint64_t Elf64_Addr; +#define ELF64_FSZ_ADDR 8 +typedef uint64_t Elf64_Off; +typedef int64_tElf64_SOff; +#define ELF64_FSZ_OFF 8 + +typedef int32_tElf64_Sword; +#define ELF64_FSZ_SWORD 4 +typedef uint32_t Elf64_Word; +#define ELF64_FSZ_WORD 4 + +typedef int64_tElf64_Sxword; +#define ELF64_FSZ_SXWORD 8 +typedef uint64_t Elf64_Xword; +#define ELF64_FSZ_XWORD 8 +typedef uint64_t Elf64_Lword; +#define ELF64_FSZ_LWORD 8 +typedef uint16_t Elf64_Half; +#define ELF64_FSZ_HALF 2 /* * ELF Header @@ -118,29 +111,29 @@ typedef struct { Elf32_Off e_phoff;/* Program hdr offset */ Elf32_Off e_shoff;/* Section hdr offset */ Elf32_Word e_flags;/* Processor flags */ - Elf32_Half e_ehsize; /* sizeof ehdr */ - Elf32_Half e_phentsize;/* Program header entry size */ - Elf32_Half e_phnum;/* Number of program headers */ - Elf32_Half e_shentsize;/* Section header entry size */ - Elf32_Half e_shnum;/* Number of section headers */ - Elf32_Half e_shstrndx; /* String table index */ + Elf32_Half e_ehsize; /* sizeof ehdr */ + Elf32_Half e_phentsize;/* Program header entry size */ + Elf32_Half e_phnum;/* Number of program headers */ + Elf32_Half e_shentsize;/* Section header entry size */ + Elf32_Half e_shnum;/* Number of section headers */ + Elf32_Half e_shstrndx; /* String table index */ } Elf32_Ehdr; typedef struct { unsigned char e_ident[ELF_NIDENT];/* Id bytes */ - Elf64_Quarter e_type; /* file type */ - Elf64_Quarter e_machine; /* machine type */ - Elf64_Half e_version; /* version number */ + Elf64_Half e_type; /* file type */ + Elf64_Half e_machine; /* machine type */ + Elf64_Word e_version; /* version numbe
[PATCH v1 0/5] Add AArch64 support to libdl
Hi, This series of patches adds support for AArch64 in libdl and makes some small tweaks to get the dynamic loader tests working. Thanks, Ryan Ryan Long (5): sys/exec_elf.h: Bring in newer file libdl/rtl-elf.h: Fix aarch64 define cpukit/libdl: Add support for AArch64 libtests/dl*: Bump up the size of CONFIGURE_INIT_TASK_STACK_SIZE cpukit/libdl/rtl-sym.c: Fix increment of variable cpukit/include/sys/exec_elf.h | 840 +- cpukit/libdl/rtl-elf.h| 2 +- cpukit/libdl/rtl-mdreloc-aarch64.c| 598 + cpukit/libdl/rtl-sym.c| 2 +- .../cpu/aarch64/include/machine/elf_machdep.h | 256 ++ spec/build/cpukit/objdl.yml | 2 + spec/build/cpukit/objdlaarch64.yml| 15 + spec/build/cpukit/optlibdl.yml| 1 + testsuites/libtests/dl01/init.c | 2 +- testsuites/libtests/dl02/init.c | 2 +- testsuites/libtests/dl03/init.c | 2 +- testsuites/libtests/dl04/init.c | 2 +- testsuites/libtests/dl05/init.c | 2 +- testsuites/libtests/dl06/initimpl.h | 2 +- testsuites/libtests/dl07/init.c | 2 +- testsuites/libtests/dl08/init.c | 2 +- testsuites/libtests/dl09/init.c | 2 +- testsuites/libtests/dl10/init.c | 2 +- 18 files changed, 1492 insertions(+), 244 deletions(-) create mode 100644 cpukit/libdl/rtl-mdreloc-aarch64.c create mode 100644 cpukit/score/cpu/aarch64/include/machine/elf_machdep.h create mode 100644 spec/build/cpukit/objdlaarch64.yml -- 2.30.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH v1 2/5] libdl/rtl-elf.h: Fix aarch64 define
The aarch64 define was incorrect. This was causing the libdl tests to not work correctly. Updates #4682 --- cpukit/libdl/rtl-elf.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cpukit/libdl/rtl-elf.h b/cpukit/libdl/rtl-elf.h index c7c17c525a..0476c1ecd7 100644 --- a/cpukit/libdl/rtl-elf.h +++ b/cpukit/libdl/rtl-elf.h @@ -51,7 +51,7 @@ extern "C" { /* * Do not add '()'. Leave plain. */ -#if defined(__powerpc64__) || defined(__arch64__) || (__riscv_xlen == 64) +#if defined(__powerpc64__) || defined(__aarch64__) || (__riscv_xlen == 64) #define ELFSIZE 64 #else #define ELFSIZE 32 -- 2.30.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH v1 4/5] libtests/dl*: Bump up the size of CONFIGURE_INIT_TASK_STACK_SIZE
Updates #4682 --- testsuites/libtests/dl01/init.c | 2 +- testsuites/libtests/dl02/init.c | 2 +- testsuites/libtests/dl03/init.c | 2 +- testsuites/libtests/dl04/init.c | 2 +- testsuites/libtests/dl05/init.c | 2 +- testsuites/libtests/dl06/initimpl.h | 2 +- testsuites/libtests/dl07/init.c | 2 +- testsuites/libtests/dl08/init.c | 2 +- testsuites/libtests/dl09/init.c | 2 +- testsuites/libtests/dl10/init.c | 2 +- 10 files changed, 10 insertions(+), 10 deletions(-) diff --git a/testsuites/libtests/dl01/init.c b/testsuites/libtests/dl01/init.c index 59cf3147f0..06fa8004b8 100644 --- a/testsuites/libtests/dl01/init.c +++ b/testsuites/libtests/dl01/init.c @@ -94,7 +94,7 @@ static void Init(rtems_task_argument arg) #define CONFIGURE_RTEMS_INIT_TASKS_TABLE -#define CONFIGURE_INIT_TASK_STACK_SIZE (8U * 1024U) +#define CONFIGURE_INIT_TASK_STACK_SIZE (CONFIGURE_MINIMUM_TASK_STACK_SIZE + (4U * 1024U)) #define CONFIGURE_INIT_TASK_ATTRIBUTES RTEMS_FLOATING_POINT diff --git a/testsuites/libtests/dl02/init.c b/testsuites/libtests/dl02/init.c index 19563e9093..495a58d287 100644 --- a/testsuites/libtests/dl02/init.c +++ b/testsuites/libtests/dl02/init.c @@ -94,7 +94,7 @@ static void Init(rtems_task_argument arg) #define CONFIGURE_RTEMS_INIT_TASKS_TABLE -#define CONFIGURE_INIT_TASK_STACK_SIZE (8U * 1024U) +#define CONFIGURE_INIT_TASK_STACK_SIZE (CONFIGURE_MINIMUM_TASK_STACK_SIZE + (4U * 1024U)) #define CONFIGURE_INIT_TASK_ATTRIBUTES (RTEMS_DEFAULT_ATTRIBUTES | RTEMS_FLOATING_POINT) diff --git a/testsuites/libtests/dl03/init.c b/testsuites/libtests/dl03/init.c index 5080323c05..e953f1a4c6 100644 --- a/testsuites/libtests/dl03/init.c +++ b/testsuites/libtests/dl03/init.c @@ -80,7 +80,7 @@ static void Init(rtems_task_argument arg) #define CONFIGURE_RTEMS_INIT_TASKS_TABLE -#define CONFIGURE_INIT_TASK_STACK_SIZE (8U * 1024U) +#define CONFIGURE_INIT_TASK_STACK_SIZE (CONFIGURE_MINIMUM_TASK_STACK_SIZE + (4U * 1024U)) #define CONFIGURE_INIT_TASK_ATTRIBUTES (RTEMS_DEFAULT_ATTRIBUTES | RTEMS_FLOATING_POINT) diff --git a/testsuites/libtests/dl04/init.c b/testsuites/libtests/dl04/init.c index a733d9da14..54a852800d 100644 --- a/testsuites/libtests/dl04/init.c +++ b/testsuites/libtests/dl04/init.c @@ -94,7 +94,7 @@ static void Init(rtems_task_argument arg) #define CONFIGURE_RTEMS_INIT_TASKS_TABLE -#define CONFIGURE_INIT_TASK_STACK_SIZE (8U * 1024U) +#define CONFIGURE_INIT_TASK_STACK_SIZE (CONFIGURE_MINIMUM_TASK_STACK_SIZE + (4U * 1024U)) #define CONFIGURE_INIT_TASK_ATTRIBUTES RTEMS_FLOATING_POINT diff --git a/testsuites/libtests/dl05/init.c b/testsuites/libtests/dl05/init.c index 93d69578f7..7e34af757d 100644 --- a/testsuites/libtests/dl05/init.c +++ b/testsuites/libtests/dl05/init.c @@ -96,7 +96,7 @@ static void Init(rtems_task_argument arg) #define CONFIGURE_RTEMS_INIT_TASKS_TABLE -#define CONFIGURE_INIT_TASK_STACK_SIZE (32U * 1024U) +#define CONFIGURE_INIT_TASK_STACK_SIZE (36U * 1024U) #define CONFIGURE_INIT_TASK_ATTRIBUTES RTEMS_FLOATING_POINT diff --git a/testsuites/libtests/dl06/initimpl.h b/testsuites/libtests/dl06/initimpl.h index 66e503b156..0d3987983d 100644 --- a/testsuites/libtests/dl06/initimpl.h +++ b/testsuites/libtests/dl06/initimpl.h @@ -98,7 +98,7 @@ static void Init(rtems_task_argument arg) #define CONFIGURE_RTEMS_INIT_TASKS_TABLE -#define CONFIGURE_INIT_TASK_STACK_SIZE (8U * 1024U) +#define CONFIGURE_INIT_TASK_STACK_SIZE (CONFIGURE_MINIMUM_TASK_STACK_SIZE + (4U * 1024U)) #define CONFIGURE_INIT_TASK_ATTRIBUTES (RTEMS_DEFAULT_ATTRIBUTES | RTEMS_FLOATING_POINT) diff --git a/testsuites/libtests/dl07/init.c b/testsuites/libtests/dl07/init.c index 42b3bed3fc..8db106ba29 100644 --- a/testsuites/libtests/dl07/init.c +++ b/testsuites/libtests/dl07/init.c @@ -100,7 +100,7 @@ static void Init(rtems_task_argument arg) #define CONFIGURE_RTEMS_INIT_TASKS_TABLE -#define CONFIGURE_INIT_TASK_STACK_SIZE (8U * 1024U) +#define CONFIGURE_INIT_TASK_STACK_SIZE (CONFIGURE_MINIMUM_TASK_STACK_SIZE + (4U * 1024U)) #define CONFIGURE_INIT_TASK_ATTRIBUTES (RTEMS_DEFAULT_ATTRIBUTES | RTEMS_FLOATING_POINT) diff --git a/testsuites/libtests/dl08/init.c b/testsuites/libtests/dl08/init.c index 02f999e0c6..23ebe41d63 100644 --- a/testsuites/libtests/dl08/init.c +++ b/testsuites/libtests/dl08/init.c @@ -100,7 +100,7 @@ static void Init(rtems_task_argument arg) #define CONFIGURE_RTEMS_INIT_TASKS_TABLE -#define CONFIGURE_INIT_TASK_STACK_SIZE (8U * 1024U) +#define CONFIGURE_INIT_TASK_STACK_SIZE (CONFIGURE_MINIMUM_TASK_STACK_SIZE + (4U * 1024U)) #define CONFIGURE_INIT_TASK_ATTRIBUTES (RTEMS_DEFAULT_ATTRIBUTES | RTEMS_FLOATING_POINT) diff --git a/testsuites/libtests/dl09/init.c b/testsuites/libtests/dl09/init.c index e8caf9b6e8..b375fe3f38 100644 --- a/testsuites/libtests/dl09/init.c +++ b/testsuites/libtests/dl09/init.c @@ -100,7 +100,7 @@ static void Init(rtems_task_argument arg) #define CONFIGURE_RTEMS_INIT_TA
Re: [PATCH rtems-docs v2] zynqmp: Add commentary about lwIP usage
This is much clearer. I now understand the limitation. OK to push. Thanks Chris On 20/7/2022 11:34 pm, Kinsey Moore wrote: > --- > user/bsps/aarch64/xilinx-zynqmp.rst | 12 > 1 file changed, 12 insertions(+) > > diff --git a/user/bsps/aarch64/xilinx-zynqmp.rst > b/user/bsps/aarch64/xilinx-zynqmp.rst > index 78bff12..239ebe4 100644 > --- a/user/bsps/aarch64/xilinx-zynqmp.rst > +++ b/user/bsps/aarch64/xilinx-zynqmp.rst > @@ -244,6 +244,18 @@ Cadence GEM instances present on all ZynqMP hardware > variants. All interfaces > are enabled by default, but only interfaces with operational MII busses will > be > recognized and usable in RTEMS. Most ZynqMP dev boards use CGEM3. > > +When used with lwIP from the rtems-lwip integration repository, these BSP > +variants support networking via CGEM0 and one of the other CGEM* instances > +simultaneously. This is a limitation of the Xilinx driver, specifically > +in code referring directly to XPAR_XEMACPS_0_BASEADDR. Attempting to use more > +than two interfaces simultaneously may cause unexpected behavior. Attempting > to > +use a set of two interfaces that does not include CGEM0 may cause unexpected > +behavior. > + > +The interfaces will not come up by default under lwIP and must be configured > +manually. There are examples of this in the start_networking() implementation > +in netstart.c as used by the network tests. > + > Running Executables on QEMU > --- > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [RSB 1/3] 6/7: Update Newlib
On 20/7/2022 6:20 pm, Sebastian Huber wrote: > On 20/07/2022 10:11, Chris Johns wrote: Are these TLS allocations in newlib based on a single use of a newlib call that brings in the reent stuff? How does that work? >>> No, each TLS object is defined in the translation unit which uses the >>> object. >>> The goal is to get only those objects linked in which are needed. >>> Currently, the >>> Newlib thread delete hook pulls in some objects, however, this dependency >>> will >>> go away once the TLS destructors are implemented. >> If I have task A and it opens a file and writes something to a file system >> will >> it pull in the TLS support for files? > > Yes. > >> Given the TLS support is static does this mean all threads in the A app >> allocate >> the newlib file TLS variables even if they never use newlib? > > Yes. > >> >> My understanding of the existing reent support is tasks that do not use >> newlib >> it never allocate a reent struct? > > No, the struct _reent is allocated for all tasks if you don't use > CONFIGURE_DISABLE_NEWLIB_REENTRANCY (which is not recommended). How would you > know if a task doesn't use Newlib? I thought the get would do a check and then allocate on first use. It has been many years since I looked at the implementation. I think this change is a good one because it will reduce the needed memory to the amount used and it will have better performance. I think option you post is a good thing to add, maybe as --enable-newlib-reent-tls. What will be the default? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH v2] aarch64: Use page table level 0
This alters the AArch64 page table generation and mapping code and MMU configuration to use page table level 0 in addition to levels 1, 2, and 3. This allows the mapping of up to 48 bits of memory space and is the maximum that can be mapped without relying on additional processor extensions. Mappings are restricted based on the number of physical address bits that the CPU supports. --- bsps/aarch64/include/bsp/aarch64-mmu.h| 65 +++ bsps/aarch64/shared/mmu/vmsav8-64.c | 7 +- bsps/include/bsp/fatal.h | 1 + .../aarch64/include/libcpu/mmu-vmsav8-64.h| 1 - 4 files changed, 58 insertions(+), 16 deletions(-) diff --git a/bsps/aarch64/include/bsp/aarch64-mmu.h b/bsps/aarch64/include/bsp/aarch64-mmu.h index 35fc79d73a..1287c67016 100644 --- a/bsps/aarch64/include/bsp/aarch64-mmu.h +++ b/bsps/aarch64/include/bsp/aarch64-mmu.h @@ -37,17 +37,21 @@ #ifndef LIBBSP_AARCH64_SHARED_AARCH64_MMU_H #define LIBBSP_AARCH64_SHARED_AARCH64_MMU_H -#include +#include #include -#include -#include +#include #include +#include #include +#include #ifdef __cplusplus extern "C" { #endif /* __cplusplus */ +/* AArch64 uses levels 0, 1, 2, and 3 */ +#define MMU_MAX_SUBTABLE_PAGE_BITS ( 3 * MMU_BITS_PER_LEVEL + MMU_PAGE_BITS ) + typedef struct { uintptr_t begin; uintptr_t end; @@ -216,15 +220,15 @@ aarch64_mmu_get_sub_table( BSP_START_TEXT_SECTION static inline rtems_status_code aarch64_mmu_map_block( uint64_t *page_table, - uintptr_t root_address, - uintptr_t addr, + uint64_t root_address, + uint64_t addr, uint64_t size, - uint32_t level, + int8_t level, uint64_t flags ) { uint32_t shift = ( 2 - level ) * MMU_BITS_PER_LEVEL + MMU_PAGE_BITS; - uintptr_t granularity = 1 << shift; + uint64_t granularity = 1LLU << shift; uint64_t page_flag = 0; if ( level == 2 ) { @@ -233,7 +237,7 @@ BSP_START_TEXT_SECTION static inline rtems_status_code aarch64_mmu_map_block( while ( size > 0 ) { uintptr_t index = aarch64_mmu_get_index( root_address, addr, shift ); -uintptr_t block_bottom = RTEMS_ALIGN_DOWN( addr, granularity ); +uint64_t block_bottom = RTEMS_ALIGN_DOWN( addr, granularity ); uint64_t chunk_size = granularity; /* check for perfect block match */ @@ -270,7 +274,7 @@ BSP_START_TEXT_SECTION static inline rtems_status_code aarch64_mmu_map_block( } /* Deal with any subtable modification */ -uintptr_t new_root_address = root_address + index * granularity; +uint64_t new_root_address = root_address + index * granularity; uint64_t *sub_table = NULL; rtems_status_code sc; @@ -311,6 +315,33 @@ BSP_START_DATA_SECTION extern const aarch64_mmu_config_entry BSP_START_DATA_SECTION extern const size_t aarch64_mmu_config_table_size; +/* Get the maximum number of bits supported by this hardware */ +BSP_START_TEXT_SECTION static inline uint64_t +aarch64_mmu_get_cpu_pa_bits( void ) +{ + uint64_t id_reg = _AArch64_Read_id_aa64mmfr0_el1(); + + switch ( AARCH64_ID_AA64MMFR0_EL1_PARANGE_GET( id_reg ) ) { + case 0: + return 32; + case 1: + return 36; + case 2: + return 40; + case 3: + return 42; + case 4: + return 44; + case 5: + return 48; + case 6: + return 52; + default: + return 48; + } + return 48; +} + BSP_START_TEXT_SECTION static inline void aarch64_mmu_set_translation_table_entries( uint64_t *ttb, @@ -320,14 +351,19 @@ aarch64_mmu_set_translation_table_entries( /* Force alignemnt to 4k page size */ uintptr_t begin = RTEMS_ALIGN_DOWN( config->begin, MMU_PAGE_SIZE ); uintptr_t end = RTEMS_ALIGN_UP( config->end, MMU_PAGE_SIZE ); + uint64_t max_mappable = 1LLU << aarch64_mmu_get_cpu_pa_bits(); rtems_status_code sc; + if ( begin >= max_mappable || end > max_mappable ) { +bsp_fatal( BSP_FATAL_MMU_ADDRESS_INVALID ); + } + sc = aarch64_mmu_map_block( ttb, 0x0, begin, end - begin, -0, +-1, config->flags ); @@ -347,7 +383,7 @@ BSP_START_TEXT_SECTION static inline void aarch64_mmu_setup_translation_table( aarch64_mmu_page_table_set_blocks( ttb, (uintptr_t) NULL, -MMU_TOP_LEVEL_PAGE_BITS, +MMU_MAX_SUBTABLE_PAGE_BITS, 0 ); @@ -390,10 +426,11 @@ aarch64_mmu_disable( void ) BSP_START_TEXT_SECTION static inline void aarch64_mmu_setup( void ) { /* Set TCR */ - /* 128GB/36 bits mappable (64-0x1c) */ + /* 256TB/48 bits mappable (64-0x10) */ _AArch64_Write_tcr_el1( -AARCH64_TCR_EL1_T0SZ( 0x1c ) | AARCH64_TCR_EL1_IRGN0( 0x1 ) | -AARCH64_TCR_EL1_ORGN0( 0x1 ) | AARCH64_TCR_EL1_SH0( 0x3 ) | AARCH64_TCR_EL1_TG0( 0x0 ) +AARCH64_TCR_EL1_T0SZ( 0x10 ) | AARCH64_TCR_EL1_IRGN0( 0x1 ) | +AARCH64_TCR_EL1_ORGN0( 0x1 ) | AARCH64_TCR_EL1_SH0( 0x3 ) | +AARCH64_TCR_EL1_TG0( 0x0 ) | AARCH64_TCR_EL1_IPS( 0x5ULL ) ); /* Set MAIR */ diff --git a/bsps/aarch64/shared/mmu/vmsav8-64.c b/bsps/aa
[PATCH rtems-docs v2] zynqmp: Add commentary about lwIP usage
--- user/bsps/aarch64/xilinx-zynqmp.rst | 12 1 file changed, 12 insertions(+) diff --git a/user/bsps/aarch64/xilinx-zynqmp.rst b/user/bsps/aarch64/xilinx-zynqmp.rst index 78bff12..239ebe4 100644 --- a/user/bsps/aarch64/xilinx-zynqmp.rst +++ b/user/bsps/aarch64/xilinx-zynqmp.rst @@ -244,6 +244,18 @@ Cadence GEM instances present on all ZynqMP hardware variants. All interfaces are enabled by default, but only interfaces with operational MII busses will be recognized and usable in RTEMS. Most ZynqMP dev boards use CGEM3. +When used with lwIP from the rtems-lwip integration repository, these BSP +variants support networking via CGEM0 and one of the other CGEM* instances +simultaneously. This is a limitation of the Xilinx driver, specifically +in code referring directly to XPAR_XEMACPS_0_BASEADDR. Attempting to use more +than two interfaces simultaneously may cause unexpected behavior. Attempting to +use a set of two interfaces that does not include CGEM0 may cause unexpected +behavior. + +The interfaces will not come up by default under lwIP and must be configured +manually. There are examples of this in the start_networking() implementation +in netstart.c as used by the network tests. + Running Executables on QEMU --- -- 2.30.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-docs] zynqmp: Add commentary about lwIP usage
On 7/19/2022 16:22, Chris Johns wrote: On 20/7/2022 5:42 am, Kinsey Moore wrote: --- user/bsps/aarch64/xilinx-zynqmp.rst | 9 + 1 file changed, 9 insertions(+) diff --git a/user/bsps/aarch64/xilinx-zynqmp.rst b/user/bsps/aarch64/xilinx-zynqmp.rst index 78bff12..58954d6 100644 --- a/user/bsps/aarch64/xilinx-zynqmp.rst +++ b/user/bsps/aarch64/xilinx-zynqmp.rst @@ -244,6 +244,15 @@ Cadence GEM instances present on all ZynqMP hardware variants. All interfaces are enabled by default, but only interfaces with operational MII busses will be recognized and usable in RTEMS. Most ZynqMP dev boards use CGEM3. +When used with lwIP from the rtems-lwip integration repository, these BSP +variants support networking via the 0th and any one other of the Cadence GEM +instances simultaneously. Is there a simpler way to word this? English may not be a user's first language. When used with lwIP from the rtems-lwip integration repository, these BSP variants support networking using the Cadence GEM interfaces labelled ``CGEM0`` to ``CGEM3``. Multiple interfaces can be used at the same time. ? Chris Unfortunately, it's not quite that simple, but I'll reword it in more direct terms. Thanks, Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] sptls04: Test an external TLS object
--- spec/build/testsuites/sptests/sptls04.yml | 1 + testsuites/sptests/sptls04/init.c | 9 +++-- testsuites/sptests/sptls04/sptls04.h | 41 +++ testsuites/sptests/sptls04/tls.c | 34 +++ 4 files changed, 82 insertions(+), 3 deletions(-) create mode 100644 testsuites/sptests/sptls04/sptls04.h create mode 100644 testsuites/sptests/sptls04/tls.c diff --git a/spec/build/testsuites/sptests/sptls04.yml b/spec/build/testsuites/sptests/sptls04.yml index 8243fb81b9..ed2cf1c3e1 100644 --- a/spec/build/testsuites/sptests/sptls04.yml +++ b/spec/build/testsuites/sptests/sptls04.yml @@ -12,6 +12,7 @@ ldflags: [] links: [] source: - testsuites/sptests/sptls04/init.c +- testsuites/sptests/sptls04/tls.c stlib: [] target: testsuites/sptests/sptls04.exe type: build diff --git a/testsuites/sptests/sptls04/init.c b/testsuites/sptests/sptls04/init.c index fad919f8ac..79ab5a5a9a 100644 --- a/testsuites/sptests/sptls04/init.c +++ b/testsuites/sptests/sptls04/init.c @@ -9,7 +9,7 @@ /* * This test program runs also on GNU/Linux and FreeBSD. Use * - * cc init.c && ./a.out + * cc init.c tls.c && ./a.out * * to run it. */ @@ -18,6 +18,8 @@ #include "config.h" #endif +#include "sptls04.h" + #ifdef __rtems__ #include @@ -30,9 +32,9 @@ #endif /* __rtems__ */ -static __thread int i; +static _Thread_local int i; -static __thread int j; +static _Thread_local int j; static __attribute__((__constructor__)) void con(void) { @@ -43,6 +45,7 @@ static void test(void) { rtems_test_assert(i == 1); rtems_test_assert(j == 0); + rtems_test_assert(k == 2); } #ifdef __rtems__ diff --git a/testsuites/sptests/sptls04/sptls04.h b/testsuites/sptests/sptls04/sptls04.h new file mode 100644 index 00..9aa737ecb0 --- /dev/null +++ b/testsuites/sptests/sptls04/sptls04.h @@ -0,0 +1,41 @@ +/* SPDX-License-Identifier: BSD-2-Clause */ + +/* + * Copyright (C) 2022 embedded brains GmbH + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + *notice, this list of conditions and the following disclaimer in the + *documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE + * POSSIBILITY OF SUCH DAMAGE. + */ + +#ifndef _SPTLS01_H +#define _SPTLS01_H + +#ifdef __cplusplus +extern "C" { +#endif + +extern _Thread_local int k; + +#ifdef __cplusplus +} +#endif + +#endif /* _SPTLS01_H */ diff --git a/testsuites/sptests/sptls04/tls.c b/testsuites/sptests/sptls04/tls.c new file mode 100644 index 00..ce91518fd0 --- /dev/null +++ b/testsuites/sptests/sptls04/tls.c @@ -0,0 +1,34 @@ +/* SPDX-License-Identifier: BSD-2-Clause */ + +/* + * Copyright (C) 2022 embedded brains GmbH + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + *notice, this list of conditions and the following disclaimer in the + *documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) +
Re: [RSB 1/3] 6/7: Update Newlib
On 20/07/2022 10:11, Chris Johns wrote: There seems to be an issue with i386: 08:09:56 runner ['/opt/rtems/6/bin/rtems-ld', '-C', '/opt/rtems/6/bin/i386-rtems6-gcc', '-c', '-MMD -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -mtune=pentiumpro -march=pentium', '-O', 'rap', '-b', '/tmp/sh/b-rtems/i386/pc686/testsuites/libtests/dl06/dl06.pre', '-e', 'rtems_main', '-s', '-o', '/tmp/sh/b-rtems/i386/pc686/testsuites/libtests/dl06/dl06.rap', '/tmp/sh/b-rtems/i386/pc686/testsuites/libtests/dl06/dl06-o1.o', '/tmp/sh/b-rtems/i386/pc686/testsuites/libtests/dl06/dl06-o2.o', '-lm'] error: libc.a:libc_a-lcong48.o@922544: symbol not found:_GLOBAL_OFFSET_TABLE_> I will remove i386 from the patch. Good idea. We should only move those we know work. This error surfaced a GCC configuration issue for RTEMS. The problem is that the default TLS model should be local-exec for RTEMS. In this case, the GOT is not used. I have to check how this can be done in GCC. -- 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: [RSB 1/3] 6/7: Update Newlib
On 20/07/2022 10:11, Chris Johns wrote: Are these TLS allocations in newlib based on a single use of a newlib call that brings in the reent stuff? How does that work? No, each TLS object is defined in the translation unit which uses the object. The goal is to get only those objects linked in which are needed. Currently, the Newlib thread delete hook pulls in some objects, however, this dependency will go away once the TLS destructors are implemented. If I have task A and it opens a file and writes something to a file system will it pull in the TLS support for files? Yes. Given the TLS support is static does this mean all threads in the A app allocate the newlib file TLS variables even if they never use newlib? Yes. My understanding of the existing reent support is tasks that do not use newlib it never allocate a reent struct? No, the struct _reent is allocated for all tasks if you don't use CONFIGURE_DISABLE_NEWLIB_REENTRANCY (which is not recommended). How would you know if a task doesn't use Newlib? -- 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: [RSB 1/3] 6/7: Update Newlib
On 20/7/2022 5:03 pm, Sebastian Huber wrote: > On 20/07/2022 02:24, Chris Johns wrote: >> On 19/7/2022 5:18 pm, Sebastian Huber wrote: >>> On 13/07/2022 11:24, Sebastian Huber wrote: This makes the --enable-newlib-reent-thread-local (_REENT_THREAD_LOCAL_STORAGE) Newlib configuration option available. >>> >>> Any comments with respect to using the Newlib thread-local storage >>> configuration >>> option for arm, i386, microblaze, nios2, powerpc, riscv, and sparc? >> >> Do these archs have working TLS support? It seems Microblaze has issues which >> our tests are not picking up. It would be good to know why our tests are not >> picking up the reported problem. > > There seems to be an issue with i386: > > 08:09:56 runner ['/opt/rtems/6/bin/rtems-ld', '-C', > '/opt/rtems/6/bin/i386-rtems6-gcc', '-c', '-MMD -Wall -Wmissing-prototypes > -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs > -mtune=pentiumpro -march=pentium', '-O', 'rap', '-b', > '/tmp/sh/b-rtems/i386/pc686/testsuites/libtests/dl06/dl06.pre', '-e', > 'rtems_main', '-s', '-o', > '/tmp/sh/b-rtems/i386/pc686/testsuites/libtests/dl06/dl06.rap', > '/tmp/sh/b-rtems/i386/pc686/testsuites/libtests/dl06/dl06-o1.o', > '/tmp/sh/b-rtems/i386/pc686/testsuites/libtests/dl06/dl06-o2.o', '-lm'] > error: libc.a:libc_a-lcong48.o@922544: symbol not found: > _GLOBAL_OFFSET_TABLE_> > I will remove i386 from the patch. Good idea. We should only move those we know work. > I can't say much about the microblaze. I suggest we leave that one out unless Joel says otherwise. >> Which archs in the list have you run the testsuite on? > > I did test runs with simulators on aarch64, arm, powerpc, riscv, and sparc. Thanks. It helps knowing this list if someone needs to track down an issue. >> Has any of newlib's tests been run? Can we run newlib tests? > > Are there Newlib tests? We added a newlib01 test which tests some Newlib > details. https://github.com/RTEMS/sourceware-mirror-newlib-cygwin/tree/master/newlib/testsuite I have never looked at them but I thought it was worth asking. >> Did the switch to TLS exceptions end up on 6? I cannot see anything in the >> RSB >> commit history mentioning it. > > No, I wait for your feedback. Here is a back port from GCC 13 to GCC 12: > > https://lists.rtems.org/pipermail/devel/2022-July/072555.html Thanks. I had mistakenly though you had and I apologise for not following up. I have put it on my list. >> Are these TLS allocations in newlib based on a single use of a newlib call >> that >> brings in the reent stuff? How does that work? > > No, each TLS object is defined in the translation unit which uses the object. > The goal is to get only those objects linked in which are needed. Currently, > the > Newlib thread delete hook pulls in some objects, however, this dependency will > go away once the TLS destructors are implemented. If I have task A and it opens a file and writes something to a file system will it pull in the TLS support for files? Given the TLS support is static does this mean all threads in the A app allocate the newlib file TLS variables even if they never use newlib? My understanding of the existing reent support is tasks that do not use newlib it never allocate a reent struct? >> Does this change effect libdl users? TLS has not been implemented in libdl >> and >> the current reent model still works for those users dependent on libdl > > It could affect libdl users. Can you load parts of libc.a with libdl? The > libdl > users could add TLS support or disable the Newlib configuration option. To > disable the options, we probably need an RSB --without-newlib-tls support or > use > something like --with-newlib-tls=yes or --with-newlib-tls=no. > > On powerpc/psim for example I get an error like this in dl06: > > ] load: /dl06.rap > ] dlopen failed: global symbol not found: _tls_rand48_add Oh that is interesting and nice. It means yes this change does require libdl TLS support and that is a more complex topic than this one. In dl06 rtems-td is linking into the RAP image the dependent pieces of newlib's libm which ends up pulling in rand48 and the TLS variable it must contain. This is a hard one to decide on because dl08 is a test for archive linking and a user could make libc.a, libm.a and libgcc.a available to link from at runtime and expose the problem. Forcing all relevant pieces into the base is a design constraint I have deliberately wanted to avoid because it is a workround used else where. I think we should discuss the part of this thread on TLS resources before we come back to this part. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Time to promote lwip git repo
Hi, just for the records: I also gratly appreciate this happening. The freeBDS networking capabilities have grwon bigger and bigger, increasing the need for a reduced functionality network stack. Having lwip available allows the user to choose, which package is right for his application. Thank you all for getting this done! wkr, Thomas. Am 19.07.22 um 16:40 schrieb Gedare Bloom: On Wed, Jul 13, 2022 at 11:27 PM Christian MAUDERER wrote: Am 13.07.22 um 04:51 schrieb Chris Johns: On 13/7/2022 10:08 am, Joel Sherrill wrote: Vijay and Kinsey have made great progress in addressing the issues that were raised about the lwip tcpip stack that needed to be addressed before it became an official top level repository. Thanks to both of them. Well done. Great effort. I think it's time to promote the repo. Hopefully just a couple of core developers agreeing is sufficient to get this moving. I support this happening. It is great to see this networking option for small devices become available. I haven't tested the lwip repository yet, but I agree that a stack for small targets is great. So I would support that too. I'm glad to see this happening and support the promotion. Christian -- embedded brains GmbH Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 mobile: +49-176-152 206 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- embedded brains GmbH Herr Thomas DOERFLER Dornierstr. 4 82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de phone: +49-89-18 94 741 - 12 fax: +49-89-18 94 741 - 09 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: [RSB 1/3] 6/7: Update Newlib
On 20/07/2022 02:24, Chris Johns wrote: On 19/7/2022 5:18 pm, Sebastian Huber wrote: On 13/07/2022 11:24, Sebastian Huber wrote: This makes the --enable-newlib-reent-thread-local (_REENT_THREAD_LOCAL_STORAGE) Newlib configuration option available. Any comments with respect to using the Newlib thread-local storage configuration option for arm, i386, microblaze, nios2, powerpc, riscv, and sparc? Do these archs have working TLS support? It seems Microblaze has issues which our tests are not picking up. It would be good to know why our tests are not picking up the reported problem. There seems to be an issue with i386: 08:09:56 runner ['/opt/rtems/6/bin/rtems-ld', '-C', '/opt/rtems/6/bin/i386-rtems6-gcc', '-c', '-MMD -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -mtune=pentiumpro -march=pentium', '-O', 'rap', '-b', '/tmp/sh/b-rtems/i386/pc686/testsuites/libtests/dl06/dl06.pre', '-e', 'rtems_main', '-s', '-o', '/tmp/sh/b-rtems/i386/pc686/testsuites/libtests/dl06/dl06.rap', '/tmp/sh/b-rtems/i386/pc686/testsuites/libtests/dl06/dl06-o1.o', '/tmp/sh/b-rtems/i386/pc686/testsuites/libtests/dl06/dl06-o2.o', '-lm'] error: libc.a:libc_a-lcong48.o@922544: symbol not found: _GLOBAL_OFFSET_TABLE_ I will remove i386 from the patch. I can't say much about the microblaze. Which archs in the list have you run the testsuite on? I did test runs with simulators on aarch64, arm, powerpc, riscv, and sparc. Has any of newlib's tests been run? Can we run newlib tests? Are there Newlib tests? We added a newlib01 test which tests some Newlib details. Did the switch to TLS exceptions end up on 6? I cannot see anything in the RSB commit history mentioning it. No, I wait for your feedback. Here is a back port from GCC 13 to GCC 12: https://lists.rtems.org/pipermail/devel/2022-July/072555.html Are these TLS allocations in newlib based on a single use of a newlib call that brings in the reent stuff? How does that work? No, each TLS object is defined in the translation unit which uses the object. The goal is to get only those objects linked in which are needed. Currently, the Newlib thread delete hook pulls in some objects, however, this dependency will go away once the TLS destructors are implemented. Does this change effect libdl users? TLS has not been implemented in libdl and the current reent model still works for those users dependent on libdl It could affect libdl users. Can you load parts of libc.a with libdl? The libdl users could add TLS support or disable the Newlib configuration option. To disable the options, we probably need an RSB --without-newlib-tls support or use something like --with-newlib-tls=yes or --with-newlib-tls=no. On powerpc/psim for example I get an error like this in dl06: ] load: /dl06.rap ] dlopen failed: global symbol not found: _tls_rand48_add -- 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