Re: [PATCH] build: Use -frandom-seed=0
On 29.02.24 00:29, Chris Johns wrote: On 28/2/2024 6:24 pm, Sebastian Huber wrote: On 28.02.24 06:34, Chris Johns wrote: The manual says: The string can either be a number (decimal, octal or hex) or an arbitrary string (in which case it’s converted to a number by computing CRC32). The string should be different for every file you compile. I take this to mean the option `-frandom-seed=0` uses `0` as a number however it is the same for every file and the manual clearly says it must be different? Using -frandom-seed=0 seems to be quite common on the internet. The random seed is rarely used in GCC. The only use case in RTEMS I found is related to the gcov code coverage instrumentation. There are lots of things that are common on the internet I ignore Is this a bug in the documentation? From my point of view this random seed is a gray area in the compiler. The cases in which it is used should not matter for the RTEMS build (except for the code coverage): https://gcc.gnu.org/pipermail/gcc-help/2024-February/143324.html I will try to add it only to the coverage flags. -- embedded brains GmbH & Co. KG 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 Tools 1/4] linkers: Avoid void pointer arithmetic
OK too all and thanks
Chris
On 26/2/2024 8:41 pm, Sebastian Huber wrote:
> ---
> linkers/rtems-syms.cpp | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/linkers/rtems-syms.cpp b/linkers/rtems-syms.cpp
> index f0ac2bb..9fe552e 100644
> --- a/linkers/rtems-syms.cpp
> +++ b/linkers/rtems-syms.cpp
> @@ -322,9 +322,9 @@ output_sym::operator ()(const
> rld::symbols::symtab::value_type& value)
>if (sym.type () == STT_TLS) {
> c.write_line ("#define RTEMS_TLS_INDEX_" + sym.name () + " " +
> std::to_string(index));
> c.write_line ("static size_t rtems_rtl_tls_" + sym.name () + "(void)
> {");
> -c.write_line (" extern __thread void* " + sym.name () + ";");
> -c.write_line (" const void* tls_base = rtems_rtl_tls_get_base ();");
> -c.write_line (" const void* tls_addr = (void*) &" + sym.name () +
> ";");
> +c.write_line (" extern __thread char " + sym.name () + "[];");
> +c.write_line (" size_t tls_base = (size_t) rtems_rtl_tls_get_base
> ();");
> +c.write_line (" size_t tls_addr = (size_t) " + sym.name () + ";");
> c.write_line (" return tls_addr - tls_base;");
> c.write_line ("}");
> c.write_line ("");
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Use -frandom-seed=0
On 28/2/2024 6:24 pm, Sebastian Huber wrote: > On 28.02.24 06:34, Chris Johns wrote: >> The manual says: >> >> The string can either be a number (decimal, octal or hex) or >> an arbitrary string (in which case it’s converted to a number by >> computing CRC32). >> >> The string should be different for every file you compile. >> >> I take this to mean the option `-frandom-seed=0` uses `0` as a number >> however it >> is the same for every file and the manual clearly says it must be different? > > Using -frandom-seed=0 seems to be quite common on the internet. The random > seed > is rarely used in GCC. The only use case in RTEMS I found is related to the > gcov > code coverage instrumentation. There are lots of things that are common on the internet I ignore ;) Is this a bug in the documentation? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [RFC] libdl: Make Elf_Sym::st_other available
On 27/2/2024 6:46 pm, Sebastian Huber wrote: > The 64-bit PowerPC ELFv2 relocation support needs access to the > Elf_Sym::st_other symbol information. The machine-specific relocation handler > had only access to the Elf_Sym::st_info symbol information. This change > extends the 8-bit syminfo parameter to 16-bit and uses the additional > 8-bits to provide Elf_Sym::st_other. Another approach could be to pass > a pointer to an Elf_Sym object instead of symname, syminfo, and > symvalue. I think symname and symvalue have to stay or the code needed to support them moves out to all reloc handlers [1]. I agree there is a limit to the number args to keep adding. If there is a need for more fields then it may pay to pass in Elf_Sym* or rtems_rtl_obj_sym* which is the symbol table reference? Chris [1] https://git.rtems.org/rtems/tree/cpukit/libdl/rtl-elf.c#n429 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [Tools] add libiberty/argv.c for mingw32 build
OK Thanks Chris On 28/2/2024 7:25 pm, Sebastian Huber wrote: > From: zhengxiaojun > > Signed-off-by: zhengxiaojun > > Close #4974. > --- > rtemstoolkit/wscript | 10 -- > 1 file changed, 4 insertions(+), 6 deletions(-) > > diff --git a/rtemstoolkit/wscript b/rtemstoolkit/wscript > index 20b1047..0611e2e 100644 > --- a/rtemstoolkit/wscript > +++ b/rtemstoolkit/wscript > @@ -399,9 +399,9 @@ def conf_libiberty(conf): > def bld_libiberty(bld, conf): > defines = ['HAVE_CONFIG_H=1'] > if bld.env.DEST_OS == 'win32': > -pex_host = 'libiberty/pex-win32.c' > +pex_host = ['libiberty/pex-win32.c','libiberty/argv.c'] > else: > -pex_host = 'libiberty/pex-unix.c' > +pex_host = ['libiberty/pex-unix.c'] > if bld.env.DEST_OS == 'darwin': > defines += ['HAVE_SPAWN_H=1', 'HAVE_POSIX_SPAWN=1', > 'HAVE_POSIX_SPAWNP=1'] > bld.stlib(target = 'iberty', > @@ -410,8 +410,7 @@ def bld_libiberty(bld, conf): >includes = ['libiberty'], >cflags = conf['cflags'], >defines = defines, > - source =['libiberty/argv.c', > - 'libiberty/concat.c', > + source =['libiberty/concat.c', > 'libiberty/cplus-dem.c', > 'libiberty/cp-demangle.c', > 'libiberty/d-demangle.c', > @@ -426,8 +425,7 @@ def bld_libiberty(bld, conf): > 'libiberty/xmalloc.c', > 'libiberty/xmemdup.c', > 'libiberty/xstrdup.c', > - 'libiberty/xstrerror.c', > - pex_host]) > + 'libiberty/xstrerror.c'] + pex_host) > > # > # The doxy command. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 4/6] build: Add support to make bootloader images
On 28/2/2024 6:44 pm, Sebastian Huber wrote:
> On 28.02.24 06:48, Chris Johns wrote:
>> Hi,
>>
>> Is this to allow BSP ready output to be created from the build system?
>
> Yes, this is the goal.
Nice and thanks for looking into this.
>> If it is will the details be exported in the pkgconfig file and made
>> available
>> for users building applications in a consistent and easy to use way?
>
> Application build systems can query the tool using the RTEMS_MKIMAGE package
> configuration varible, for example:
>
> pkg-config --variable=RTEMS_MKIMAGE
> ${prefix}/lib/pkgconfig/${ARCH}-${BSP_NAME}.pc
Nice. This is my preferred way of handling this.
> If the BSP does not provide a tool, then the variable RTEMS_MKIMAGE is set to
> "false".
So the process has to be a single command?
> It could help to export also EXEEXT and BOOT_IMAGE_EXTENSION in the package
> configuration file. For RTEMS 6, we should have a look how our package
> configuration support can be used to build applications on some commonly used
> build systems. We are currently not able to produce build images.
Yes we should. I also wonder if base addresses and other values that get used
should be prov
>> Is this output created along side the ELF file?
>
> Yes.
+1
>> Does this approach handle all BSPs that need this?
>
> The BSP can use Python, so I would say yes.
I am sorry I do not follow.
>> Will you be converting all BSPs that need this type of support?
>
> I will add support for the BSPs using U-Boot.
Could you please provide the high level view of how this is to be handled? I
have not reviewed all the detail in the patches to understand this and even then
I may get things wrong.
Should we create a GSoC project to review and support the other BSPs?
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-lwip] rtemslwip: Add gethostbyname wrapper
Applications and libraries compiled without the benefit of the lwIP
headers may require gethostbyname() instead of lwip_gethostbyname().
This wrapper allows those applicationns and libraries to link properly.
---
rtemslwip/common/network_compat.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/rtemslwip/common/network_compat.c
b/rtemslwip/common/network_compat.c
index c072d54..d99204c 100644
--- a/rtemslwip/common/network_compat.c
+++ b/rtemslwip/common/network_compat.c
@@ -58,6 +58,12 @@ uint16_t htons(uint16_t x)
return lwip_htons(x);
}
+#undef gethostbyname
+struct hostent *gethostbyname(const char *name)
+{
+ return lwip_gethostbyname(name);
+}
+
int
getnameinfo(const struct sockaddr *sa, socklen_t salen, char *node,
size_t nodelen, char *service, size_t servicelen, int flags)
--
2.39.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Patch with modified hello world
Hi Seif, Could you also provide a screenshot of the example running? This is part of the requirements as per https://devel.rtems.org/wiki/GSoC Thanks, Kinsey On Mon, Feb 26, 2024 at 12:26 PM Seif Alrahman Ahmed Mohamed Alfakharany < seifelfakharany011434...@gmail.com> wrote: > > ___ > 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
[PATCH 1/2] cpukit/libtest: Remove unused variable
This unused variable causes a warning. It is never set or used.
---
cpukit/libtest/testgcovdumpinfo.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/cpukit/libtest/testgcovdumpinfo.c
b/cpukit/libtest/testgcovdumpinfo.c
index 1f32ceafcb..9687280e21 100644
--- a/cpukit/libtest/testgcovdumpinfo.c
+++ b/cpukit/libtest/testgcovdumpinfo.c
@@ -68,7 +68,6 @@ void rtems_test_gcov_dump_info( void )
if ( !gcov_dump_done ) {
Hash_Control result;
-uint8_t byte;
gcov_dump_done = true;
--
2.39.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 2/2] testsuites/dhrystone: Initialize before use
This resovles a warning where a variable could be used before it is
initialized in some code paths.
---
testsuites/benchmarks/dhrystone/dhry_1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/testsuites/benchmarks/dhrystone/dhry_1.c
b/testsuites/benchmarks/dhrystone/dhry_1.c
index 3ad2e7f204..e493f86a15 100644
--- a/testsuites/benchmarks/dhrystone/dhry_1.c
+++ b/testsuites/benchmarks/dhrystone/dhry_1.c
@@ -80,7 +80,7 @@ int main (int argc, char **argv)
/* main program, corresponds to procedures*/
/* Main and Proc_0 in the Ada version */
{
-One_Fifty Int_1_Loc;
+One_Fifty Int_1_Loc = 0;
REG One_Fifty Int_2_Loc;
One_Fifty Int_3_Loc;
REG charCh_Index;
--
2.39.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 0/2] GSOC: Hello World exercise
Thanks for taking this step toward participating in GSoC! I took a look at the images in the binary patch and they look good. If you need to send more images in the future, please use a link instead of sharing them in a binary patch. Kinsey On Wed, Feb 28, 2024 at 2:33 AM Ning Yang wrote: > Hello, My name is Yang Ning, a computer science master's student at China > Yanshan University.My research chiefly focuses on RTEMS. > > This is my first contact with operating system-related projects. I have > been study RTEMS on RPi4 for half year. During the half year,I configured > and builded RTEMS and RTEMS-libbsd for RPi4. > I also ported btstack( https://github.com/bluekitchen/btstack ) to RTEMS. > It works well. > Then I have been working on RPi4 BSP.I debugged the issue of > set_attributes().( > https://discord.com/channels/82045382112799/85822508908585/1180421668502511706)( > I commented a few lines directly.Does not conform to the data sheet, but it > can works.) > > I'm still reading the existing RPi4 BSP code.And I'm interested in porting > USB3.0.Freebsd already supports usb3.0 of RPi4 ( > https://reviews.freebsd.org/D25068 ). I just need to integrate it into > libbsd. > > discord: @yangn0 > github: https://github.com/yangn0 > blog: https://blog.csdn.net/qq_41058067 > > Ning Yang (2): > hello world exercise > helloworld & gdb screen snapshot > > hello/gdb.png | Bin 0 -> 414373 bytes > hello/hello.c | 2 +- > hello/hello.png | Bin 0 -> 37259 bytes > 3 files changed, 1 insertion(+), 1 deletion(-) > create mode 100644 hello/gdb.png > create mode 100644 hello/hello.png > > -- > 2.34.1 > > ___ > 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
[PATCH rtems-libbsd] freebsd/mmcsd: Disable on-device cache usage
This disables any usage of the on-device R/W cache since all device cache maintenance functions are compiled out under RTEMS leaving no way to flush the cache before system reset and making data loss possible. --- freebsd/sys/dev/mmc/mmcsd.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/freebsd/sys/dev/mmc/mmcsd.c b/freebsd/sys/dev/mmc/mmcsd.c index 11cf945f..ff517abc 100644 --- a/freebsd/sys/dev/mmc/mmcsd.c +++ b/freebsd/sys/dev/mmc/mmcsd.c @@ -546,6 +546,11 @@ mmcsd_attach(device_t dev) */ rev = ext_csd[EXT_CSD_REV]; +/* + * Cache flush functions are currently not available. Use of on-device cache can + * cause data loss. + */ +#ifndef __rtems__ /* * With revision 1.5 (MMC v4.5, EXT_CSD_REV == 6) and later, take * advantage of the device R/W cache if present and useage is not @@ -567,6 +572,7 @@ mmcsd_attach(device_t dev) sc->flags |= MMCSD_FLUSH_CACHE; } } +#endif /* * Ignore user-creatable enhanced user data area and general purpose -- 2.39.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 0/2] GSOC: Hello World exercise
Hello, My name is Yang Ning, a computer science master's student at China Yanshan University.My research chiefly focuses on RTEMS. This is my first contact with operating system-related projects. I have been study RTEMS on RPi4 for half year. During the half year,I configured and builded RTEMS and RTEMS-libbsd for RPi4. I also ported btstack( https://github.com/bluekitchen/btstack ) to RTEMS. It works well. Then I have been working on RPi4 BSP.I debugged the issue of set_attributes().(https://discord.com/channels/82045382112799/85822508908585/1180421668502511706)( I commented a few lines directly.Does not conform to the data sheet, but it can works.) I'm still reading the existing RPi4 BSP code.And I'm interested in porting USB3.0.Freebsd already supports usb3.0 of RPi4 ( https://reviews.freebsd.org/D25068 ). I just need to integrate it into libbsd. discord: @yangn0 github: https://github.com/yangn0 blog: https://blog.csdn.net/qq_41058067 Ning Yang (2): hello world exercise helloworld & gdb screen snapshot hello/gdb.png | Bin 0 -> 414373 bytes hello/hello.c | 2 +- hello/hello.png | Bin 0 -> 37259 bytes 3 files changed, 1 insertion(+), 1 deletion(-) create mode 100644 hello/gdb.png create mode 100644 hello/hello.png -- 2.34.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/2] hello world exercise
---
hello/hello.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hello/hello.c b/hello/hello.c
index d2321d8..e074563 100644
--- a/hello/hello.c
+++ b/hello/hello.c
@@ -8,6 +8,6 @@
rtems_task Init(
rtems_task_argument ignored)
{
- puts("hello, world!");
+ puts("Hello, My name is Yang Ning. I am a master's student at China Yanshan
University.My research chiefly focuses on RTEMS.");
exit(0);
}
--
2.34.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[Tools] add libiberty/argv.c for mingw32 build
From: zhengxiaojun Signed-off-by: zhengxiaojun Close #4974. --- rtemstoolkit/wscript | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/rtemstoolkit/wscript b/rtemstoolkit/wscript index 20b1047..0611e2e 100644 --- a/rtemstoolkit/wscript +++ b/rtemstoolkit/wscript @@ -399,9 +399,9 @@ def conf_libiberty(conf): def bld_libiberty(bld, conf): defines = ['HAVE_CONFIG_H=1'] if bld.env.DEST_OS == 'win32': -pex_host = 'libiberty/pex-win32.c' +pex_host = ['libiberty/pex-win32.c','libiberty/argv.c'] else: -pex_host = 'libiberty/pex-unix.c' +pex_host = ['libiberty/pex-unix.c'] if bld.env.DEST_OS == 'darwin': defines += ['HAVE_SPAWN_H=1', 'HAVE_POSIX_SPAWN=1', 'HAVE_POSIX_SPAWNP=1'] bld.stlib(target = 'iberty', @@ -410,8 +410,7 @@ def bld_libiberty(bld, conf): includes = ['libiberty'], cflags = conf['cflags'], defines = defines, - source =['libiberty/argv.c', - 'libiberty/concat.c', + source =['libiberty/concat.c', 'libiberty/cplus-dem.c', 'libiberty/cp-demangle.c', 'libiberty/d-demangle.c', @@ -426,8 +425,7 @@ def bld_libiberty(bld, conf): 'libiberty/xmalloc.c', 'libiberty/xmemdup.c', 'libiberty/xstrdup.c', - 'libiberty/xstrerror.c', - pex_host]) + 'libiberty/xstrerror.c'] + pex_host) # # The doxy command. -- 2.35.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [Tools] rtemstoolkit/libierty: Add missing file
On 28.02.24 08:20, zhengxiaojun wrote: The patch close #4974. Sorry, I didn't notice this ticket. I will rebase your patch to the current master since the build system part is an improvement. -- embedded brains GmbH & Co. KG 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
