Re: [PATCH 2/5] rtems-fdt.c: Fix Resource leak (CID #1437645)

2021-03-16 Thread Niteesh G. S. 
On Tue, 16 Mar 2021, 1:37 am Gedare Bloom,  wrote:

> This one looks ok to me, Niteesh?
>
+1

The below question is not related to this patch.

Out of interest, I started going through the code  and I am a bit confused
in the following statement

https://git.rtems.org/rtems/tree/cpukit/libmisc/rtems-fdt/rtems-fdt.c#n574

This else block is reached when the FDT blob is not compressed, in this
case the size variable is set to the file size since this is raw data.

In the while loop, we are looping on size, but we never modify the size. I
think, line 583 should be
size -= r;
Instead of
r -= size;
Is this a bug??
Or am I missing something?

PS: I am really sorry, If the formatting looks off I wrote this mail using
my mobile.

Thanks
Niteesh


> On Fri, Mar 12, 2021 at 8:19 AM Ryan Long  wrote:
> >
> > CID 1437645: Resource leak in rtems_fdt_load().
> >
> > Closes #4297
> > ---
> >  cpukit/libmisc/rtems-fdt/rtems-fdt.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/cpukit/libmisc/rtems-fdt/rtems-fdt.c
> b/cpukit/libmisc/rtems-fdt/rtems-fdt.c
> > index 0ea3653..5bb7ce0 100644
> > --- a/cpukit/libmisc/rtems-fdt/rtems-fdt.c
> > +++ b/cpukit/libmisc/rtems-fdt/rtems-fdt.c
> > @@ -611,6 +611,7 @@ rtems_fdt_load (const char* filename,
> rtems_fdt_handle* handle)
> >  return fe;
> >}
> >
> > +  close (bf);
> >return 0;
> >  }
> >
> > --
> > 1.8.3.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

Re: [PATCH 0/4] Import and Port Beagle pinmux driver

2021-03-16 Thread Christian MAUDERER 

Hello Gedare,

moving the pinmux driver from libbsd to RTEMS is a good direction. It 
avoids the double initialization of the pins that we currently have for 
that BSP.


I planned to test the patches in the next few days.

Best regards

Christian

Am 15.03.21 um 21:04 schrieb Gedare Bloom:

Christian,

Can you please provide comments on this patch series and the TI pinmux
removal from libbsd?

thanks

On Sat, Mar 13, 2021 at 4:02 AM G S Niteesh Babu  wrote:


The following series of patches import and port the beagle
pinmux driver from FreeBSD to RTEMS.

Porting this driver will avoid double initialization of
pin multiplexers once during RTEMS initialization and second
time during libBSD initialization.

UPDATE #3782

G S Niteesh Babu (4):
   bsps/shared/ofw: Add rtems_ofw_is_node_compatible
   bsp/beagle: Import Beagle pinmux from FreeBSD
   bsps/beagle: Added SOC detection using FDT
   bsp/beagle: Ported Beagle pinmux driver to RTEMS

  bsps/arm/beagle/start/bsp-soc-detect.c|  55 ++
  bsps/arm/beagle/start/bsp-soc-detect.h|  38 ++
  bsps/arm/beagle/start/bspstart.c  |  54 +-
  .../arm/ti/am335x/am335x_scm_padconf.h|  47 ++
  bsps/include/arm/ti/ti_cpuid.h|  48 ++
  bsps/include/arm/ti/ti_pinmux.h   |  87 +++
  bsps/include/ofw/ofw.h|  17 +
  .../sys/arm/ti/am335x/am335x_scm_padconf.c| 307 ++
  bsps/shared/freebsd/sys/arm/ti/ti_pinmux.c| 574 ++
  bsps/shared/ofw/ofw.c |  12 +
  spec/build/bsps/arm/beagle/obj.yml|   1 +
  spec/build/bsps/obj.yml   |   6 +
  12 files changed, 1240 insertions(+), 6 deletions(-)
  create mode 100644 bsps/arm/beagle/start/bsp-soc-detect.c
  create mode 100644 bsps/arm/beagle/start/bsp-soc-detect.h
  create mode 100644 bsps/include/arm/ti/am335x/am335x_scm_padconf.h
  create mode 100644 bsps/include/arm/ti/ti_cpuid.h
  create mode 100644 bsps/include/arm/ti/ti_pinmux.h
  create mode 100644 bsps/shared/freebsd/sys/arm/ti/am335x/am335x_scm_padconf.c
  create mode 100644 bsps/shared/freebsd/sys/arm/ti/ti_pinmux.c

--
2.17.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
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 rtems-docs v2 2/6] rtems-docs: Update command for offline download

2021-03-16 Thread Ida Delphine 
Changed command from ../source-builder/sb-set-builder --source-only-download 
5/rtems-sparc to ../source-builder/sb-set-builder --source-only-download 
6/rtems-sparc.
Updated sample output as well
---
 user/start/sources.rst | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/user/start/sources.rst b/user/start/sources.rst
index 8c40aa0..f4cb8ae 100644
--- a/user/start/sources.rst
+++ b/user/start/sources.rst
@@ -10,7 +10,7 @@ Obtain the Sources
 ==
 
 You have considered and chosen a suitable installation prefix in the previous
-section.  We have chosen :file:`$HOME/quick-start/rtems/5` as the installation
+section.  We have chosen :file:`$HOME/quick-start/rtems/6` as the installation
 prefix. We will show how to use a released version of RTEMS and then as an
 alternative we will show you using the :ref:`RSB Git repository
 `. Consider using a Git clone if you wish to make
@@ -114,17 +114,17 @@ the sources to build the ERC 32 BSP before building run 
the following commands:
 .. code-block:: none
 
 cd $HOME/quick-start/src/rsb/rtems
-../source-builder/sb-set-builder --source-only-download 5/rtems-sparc
+../source-builder/sb-set-builder --source-only-download 6/rtems-sparc
 
 This command should output something like this (omitted lines are denoted by
 ``...``):
 
 .. code-block:: none
 
-RTEMS Source Builder - Set Builder, 5.1.0
-Build Set: 5/rtems-sparc
+RTEMS Source Builder - Set Builder, 6
+Build Set: 6/rtems-sparc
 ...
-download: 
https://ftp.rtems.org/pub/rtems/releases/5/5.1.0/5.1.0/sources/gcc-7.5.0.tar.xz 
-> sources/gcc-7.5.0.tar.xz
+download: https://gcc.gnu.org/pub/gcc/infrastructure/gmp-6.1.0.tar.bz2 -> 
sources/gmp-6.1.0.tar.bz2
 ...
 Build Sizes: usage: 0.000B total: 143.814MB (sources: 143.793MB, patches: 
21.348KB, installed 0.000B)
 Build Set: Time 0:05:52.617958
-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH rtems-docs v2 3/6] rtems-docs: Edit command to install toolsuite

2021-03-16 Thread Ida Delphine 
Edit edit sample output of tool suite installation.
Edit command to check if C cross compiler works and sample output of this 
command.
---
 user/start/tools.rst | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/user/start/tools.rst b/user/start/tools.rst
index baa2387..9a915ab 100644
--- a/user/start/tools.rst
+++ b/user/start/tools.rst
@@ -12,7 +12,7 @@ Install the Tool Suite
 
 You have chosen an installation prefix, the BSP to build, the tool's
 architecure and prepared the source for the RSB in the previous sections.  We
-have chosen :file:`$HOME/quick-start/rtems/5` as the installation prefix, the
+have chosen :file:`$HOME/quick-start/rtems/6` as the installation prefix, the
 ``erc32`` BSP and the SPARC architecture name of ``sparc-rtems5``, and unpacked
 the RSB source in :file:`$HOME/quick-start/src`.
 
@@ -25,7 +25,7 @@ Build and install the tool suite:
 .. code-block:: none
 
 cd $HOME/quick-start/src/rsb/rtems
-../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/5 
5/rtems-sparc
+../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6 
6/rtems-sparc
 
 This command should output something like this (omitted lines are denoted by
 ...). The build host appears as part of the name of the package being
@@ -33,19 +33,19 @@ built. The name you see may vary depending on the host you 
are using:
 
 .. code-block:: none
 
-RTEMS Source Builder - Set Builder, 5.1.0
-Build Set: 5/rtems-sparc
+RTEMS Source Builder - Set Builder, 6
+Build Set: 6/rtems-sparc
 ...
 config: tools/rtems-binutils-2.34.cfg
-package: sparc-rtems5-binutils-2.34-x86_64-freebsd12.1-1
-building: sparc-rtems5-binutils-2.34-x86_64-freebsd12.1-1
-sizes: sparc-rtems5-binutils-2.34-x86_64-freebsd12.1-1: 305.866MB 
(installed: 29.966MB)
-cleaning: sparc-rtems5-binutils-2.34-x86_64-freebsd12.1-1
+package: sparc-rtems6=-binutils-2.34-x86_64-freebsd12.1-1
+building: sparc-rtems6-binutils-2.34-x86_64-freebsd12.1-1
+sizes: sparc-rtems6-binutils-2.34-x86_64-freebsd12.1-1: 305.866MB 
(installed: 29.966MB)
+cleaning: sparc-rtems6-binutils-2.34-x86_64-freebsd12.1-1
 reporting: tools/rtems-binutils-2.34.cfg -> 
sparc-rtems5-binutils-2.34-x86_64-freebsd12.1-1.txt
 reporting: tools/rtems-binutils-2.34.cfg -> 
sparc-rtems5-binutils-2.34-x86_64-freebsd12.1-1.xml
 config: tools/rtems-gcc-7.5.0-newlib-fbaa096.cfg
-package: sparc-rtems5-gcc-7.5.0-newlib-fbaa096-x86_64-freebsd12.1-1
-building: sparc-rtems5-gcc-7.5.0-newlib-fbaa096-x86_64-freebsd12.1-1
+package: sparc-rtems6-gcc-7.5.0-newlib-fbaa096-x86_64-freebsd12.1-1
+building: sparc-rtems6-gcc-7.5.0-newlib-fbaa096-x86_64-freebsd12.1-1
 
 Build Sizes: usage: 5.684GB total: 1.112GB (sources: 143.803MB, patches: 
21.348KB, installed 995.188MB)
 Build Set: Time 0:21:35.626294
@@ -55,7 +55,7 @@ works with the following command:
 
 .. code-block:: none
 
-$HOME/quick-start/rtems/5/bin/sparc-rtems5-gcc --version
+$HOME/quick-start/rtems/6/bin/sparc-rtems6-gcc --version
 
 This command should output something like below.  The version informtion helps
 you to identify the exact sources used to build the cross compiler of your
@@ -69,8 +69,8 @@ source code used.
 
 .. code-block:: none
 
-sparc-rtems5-gcc (GCC) 7.5.0 20191114 (RTEMS 5, RSB 5.1.0, Newlib fbaa096)
-Copyright (C) 2017 Free Software Foundation, Inc.
+sparc-rtems6-gcc (GCC) 10.2.1 20210309 (RTEMS 6, RSB 
5e449fb5c2cb6812a238f9f9764fd339cbbf05c2, Newlib d10d0d9)
+Copyright (C) 2020 Free Software Foundation, Inc.
 This is free software; see the source for copying conditions.  There is NO
 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 
-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH rtems-docs v2 1/6] rtems-docs: Update installation prefix

2021-03-16 Thread Ida Delphine 
---
 user/start/prefixes.rst | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/user/start/prefixes.rst b/user/start/prefixes.rst
index 67255d0..826ce85 100644
--- a/user/start/prefixes.rst
+++ b/user/start/prefixes.rst
@@ -40,7 +40,7 @@ applications and systems.
 You build and install the tool suite with the :ref:`RTEMS Source Builder (RSB)
 `.  By default, the RSB will start the prefix path with a host operating
 system specific path plus :file:`rtems`, and the RTEMS version, e.g.
-:file:`/opt/rtems/5` on Linux, and :file:`/usr/local/rtems/5` on FreeBSD and
+:file:`/opt/rtems/6` on Linux, and :file:`/usr/local/rtems/6` on FreeBSD and
 macOS. Placing the RTEMS version number in the path lets you manage and
 migrate RTEMS versions as they are released.
 
@@ -50,10 +50,10 @@ make sure that your normal user has sufficient privileges 
to create files and
 directories under the prefix.  For example, you can create a directory
 :file:`/opt/rtems` and give it to a developer group with read, write, and
 execute permissions.  Alternatively, you can choose a prefix in your home
-directory, e.g. :file:`$HOME/rtems/5` or with a project-specific component
-:file:`$HOME/project-x/rtems/5`.  For more ideas, see the :ref:`project
+directory, e.g. :file:`$HOME/rtems/6` or with a project-specific component
+:file:`$HOME/project-x/rtems/6`.  For more ideas, see the :ref:`project
 sandboxing ` section.  In this quick start chapter, we will
-choose :file:`$HOME/quick-start/rtems/5` for the RTEMS tool suite prefix.
+choose :file:`$HOME/quick-start/rtems/6` for the RTEMS tool suite prefix.
 
 .. warning::
 
-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH rtems-docs v2 5/6] rtems-docs: Edit command to test BSP and sample output

2021-03-16 Thread Ida Delphine 
---
 user/start/bsp-test.rst | 49 +++--
 1 file changed, 27 insertions(+), 22 deletions(-)

diff --git a/user/start/bsp-test.rst b/user/start/bsp-test.rst
index 9243f5d..cad6f23 100644
--- a/user/start/bsp-test.rst
+++ b/user/start/bsp-test.rst
@@ -30,37 +30,42 @@ by ``$BASE``.
 .. code-block:: none
 
 RTEMS Testing - Tester, 5.1.0
- Command Line: $BASE/rtems/5/bin/rtems-test --rtems-bsp=erc32-sis 
build/sparc/erc32
- Python: 2.7.15 (default, Jan 10 2019, 01:14:47) [GCC 4.2.1 Compatible 
FreeBSD Clang 6.0.1 (tags/RELEASE_601/final 335540)]
+ Command Line: $BASE/rtems/6/bin/rtems-test --rtems-bsp=erc32-sis 
build/sparc/erc32
+ Python: 3.8.5 (default, Jan 27 2021, 15:41:15) [GCC 9.3.0]
 Host: FreeBSD-12.0-RELEASE-p2-amd64-64bit-ELF (FreeBSD Build_FreeBSD12 
12.0-RELEASE-p2 FreeBSD 12.0-RELEASE-p2 GENERIC amd64 amd64)
-[  1/589] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   | 
sparc/erc32: dhrystone.exe
+[  1/570] p:0   f:0   u:0   e:0   I:0   B:0   t:0   L:0   i:0   W:0   | 
sparc/erc32: dhrystone.exe
 ...
-[589/589] p:574 f:0   u:5   e:0   I:0   B:3   t:0   i:0   W:0   | 
sparc/erc32: tmtimer01.exe
+[570/570] p:554 f:2   u:6   e:1   I:0   B:3   t:0   L:0   i:0   W:0   | 
sparc/erc32: ts-validation-1.exe
 
-Passed:580
-Failed:  0
-User Input:  5
-Expected Fail:   0
+Passed:558
+Failed:  2
+User Input:  6
+Expected Fail:   1
 Indeterminate:   0
 Benchmark:   3
-Timeout: 1
+Timeout: 0
+Test too long:   0
 Invalid: 0
 Wrong Version:   0
 Wrong Build: 0
 Wrong Tools: 0
 --
-Total: 589
+Total: 570
+Failures:
+dl06.exe
+minimum.exe
 User Input:
- monitor.exe
- termios.exe
- top.exe
- fileio.exe
- capture.exe
+dl10.exe
+monitor.exe
+termios.exe
+top.exe
+capture.exe
+fileio.exe
+Expected Fail:
+psxfenv01.exe
 Benchmark:
- whetstone.exe
- linpack.exe
- dhrystone.exe
-Timeouts:
- pppd.exe
-Average test time: 0:00:00.437773
-Testing time : 0:04:17.848557
+dhrystone.exe
+linpack.exe
+whetstone.exe
+Average test time: 0:00:00.371256
+Testing time : 0:03:31.616055
-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH rtems-docs v2 4/6] rtems-docs: Edit command to build BSP and

2021-03-16 Thread Ida Delphine 
Edit sample output output as well substituting "5" with "6"
with regards to the current branch.

---
 user/start/bsp-build.rst | 74 
 1 file changed, 37 insertions(+), 37 deletions(-)

diff --git a/user/start/bsp-build.rst b/user/start/bsp-build.rst
index 137b3ab..c4d6db6 100644
--- a/user/start/bsp-build.rst
+++ b/user/start/bsp-build.rst
@@ -11,7 +11,7 @@ Build a Board Support Package (BSP)
 You installed the tool suite in your installation prefix, made ready the source
 for two RTEMS source packages and if you are using a Git clone bootstrapped the
 RTEMS sources in the previous sections.  We installed the tool suite in
-:file:`$HOME/quick-start/rtems/5` and unpacked the source in
+:file:`$HOME/quick-start/rtems/6` and unpacked the source in
 :file:`$HOME/quick-start/src`.
 
 You are now able to build :ref:`Board Support Packages (BSPs) ` for all
@@ -44,24 +44,24 @@ To build the BSP with all the tests run this command:
 .. code-block:: none
 
 cd $HOME/quick-start/src/rsb/rtems
-../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/5 \
---target=sparc-rtems5 --with-rtems-bsp=erc32 --with-rtems-tests=yes 
5/rtems-kernel
+../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6 \
+--target=sparc-rtems6 --with-rtems-bsp=erc32 --with-rtems-tests=yes 
6/rtems-kernel
 
 This command should output something like this:
 
 .. code-block:: none
 
-RTEMS Source Builder - Set Builder, 5.1.0
-Build Set: 5/rtems-kernel
+RTEMS Source Builder - Set Builder, 6
+Build Set: 6/rtems-kernel
 config: tools/rtems-kernel-5.cfg
-package: sparc-rtems5-kernel-erc32-1
-building: sparc-rtems5-kernel-erc32-1
-sizes: sparc-rtems5-kernel-erc32-1: 2.279GB (installed: 44.612MB)
-cleaning: sparc-rtems5-kernel-erc32-1
-reporting: tools/rtems-kernel-5.cfg -> sparc-rtems5-kernel-erc32-1.txt
-reporting: tools/rtems-kernel-5.cfg -> sparc-rtems5-kernel-erc32-1.xml
-installing: sparc-rtems5-kernel-erc32-1 -> $BASE/
-cleaning: sparc-rtems5-kernel-erc32-1
+package: sparc-rtems6-kernel-erc32-1
+building: sparc-rtems6-kernel-erc32-1
+sizes: sparc-rtems6-kernel-erc32-1: 2.279GB (installed: 44.612MB)
+cleaning: sparc-rtems6-kernel-erc32-1
+reporting: tools/rtems-kernel-5.cfg -> sparc-rtems6-kernel-erc32-1.txt
+reporting: tools/rtems-kernel-5.cfg -> sparc-rtems6-kernel-erc32-1.xml
+installing: sparc-rtems6-kernel-erc32-1 -> $BASE/
+cleaning: sparc-rtems6-kernel-erc32-1
 Build Set: Time 0:03:09.896961
 
 The RSB BSP build can be customised with following RSB command line options:
@@ -112,13 +112,13 @@ directory to your ``$PATH`` throughout the remaining 
steps. Run the command:
 
 .. code-block:: none
 
-export PATH=$HOME/quick-start/rtems/5/bin:"$PATH"
+export PATH=$HOME/quick-start/rtems/6/bin:"$PATH"
 
 Check your installed tools can be found by running:
 
 .. code-block:: none
 
-command -v sparc-rtems5-gcc && echo "found" || echo "not found"
+command -v sparc-rtems6-gcc && echo "found" || echo "not found"
 
 The output should be:
 
@@ -128,7 +128,7 @@ The output should be:
 
 If ``not found`` is printed the tools are not correctly installed or the path
 has not been correctly set. Check the contents of the path
-:file:`$HOME/quick-start/rtems/5/bin` manually and if :file:`sparc-rtems5-gcc`
+:file:`$HOME/quick-start/rtems/6/bin` manually and if :file:`sparc-rtems6-gcc`
 is present the path is wrong. If the file cannot be found return to
 :ref:`QuickStartTools` and install the tools again.
 
@@ -145,7 +145,7 @@ everything else.  For detailed information about the BSP 
build system, see
 cd $HOME/quick-start/src/rtems
 echo "[sparc/erc32]" > config.ini
 echo "BUILD_TESTS = True" >> config.ini
-./waf configure --prefix=$HOME/quick-start/rtems/5
+./waf configure --prefix=$HOME/quick-start/rtems/6
 
 The first invocation of ``./waf`` needs a bit of time (e.g. 10 seconds) since 
an
 internal cache file is populated.  This command should output something like
@@ -158,24 +158,24 @@ by ``$BASE``.
 Setting out to   : $BASE/src/rtems/build
 Regenerate build specification cache (needs a couple of seconds)...
 Configure board support package (BSP): sparc/erc32
-Checking for program 'sparc-rtems5-gcc'  : 
$BASE/rtems/5/bin/sparc-rtems5-gcc
-Checking for program 'sparc-rtems5-g++'  : 
$BASE/rtems/5/bin/sparc-rtems5-g++
-Checking for program 'sparc-rtems5-ar'   : 
$BASE/rtems/5/bin/sparc-rtems5-ar
-Checking for program 'sparc-rtems5-ld'   : 
$BASE/rtems/5/bin/sparc-rtems5-ld
-Checking for program 'ar': 
$BASE/rtems/5/bin/sparc-rtems5-ar
-Checking for program 'g++, c++'  : 
$BASE/rtems/5/bin/sparc-rtems5-g++
-Checking for program 'ar': 
$BASE/rtems/5/bin/sparc-rtems5-ar
-Checking for program 'gas, gcc'  : 
$BASE/rtems/5/bin/sparc-rtems5

[PATCH rtems-docs v2 6/6] rtems-docs: Edit commands to build first app

2021-03-16 Thread Ida Delphine 
---
 user/start/app.rst | 110 ++---
 1 file changed, 55 insertions(+), 55 deletions(-)

diff --git a/user/start/app.rst b/user/start/app.rst
index 8900f78..8cbf6fc 100644
--- a/user/start/app.rst
+++ b/user/start/app.rst
@@ -8,7 +8,7 @@ Build Your Application
 ==
 
 You tested a BSP in the previous section.  We built the ``erc32`` BSP
-and it is installed under :file:`$HOME/quick-start/rtems/5`.
+and it is installed under :file:`$HOME/quick-start/rtems/6`.
 
 We will now create a simple Hello World application with a Git
 repository and using the `Waf `_ build system.
@@ -107,7 +107,7 @@ and copy the Waf script:
 #
 from __future__ import print_function
 
-rtems_version = "5"
+rtems_version = "6"
 
 try:
 import rtems_waf.rtems as rtems
@@ -142,52 +142,52 @@ Configure the application using Waf's ``configure`` 
command:
 
 .. code-block:: none
 
-./waf configure --rtems=$HOME/quick-start/rtems/5 --rtems-bsp=sparc/erc32
+./waf configure --rtems=$HOME/quick-start/rtems/6 --rtems-bsp=sparc/erc32 
--rtems-version=6
 
 The output will be something close to:
 
 .. code-block:: none
 
- Setting top to   : $BASE/app/hello
- Setting out to   : $BASE/app/hello/build
- RTEMS Version: 5
- Architectures: sparc-rtems5
- Board Support Package (BSP)  : sparc-rtems5-erc32
- Show commands: no
- Long commands: no
- Checking for program 'sparc-rtems5-gcc'  : 
$BASE/rtems/5/bin/sparc-rtems5-gcc
- Checking for program 'sparc-rtems5-g++'  : 
$BASE/rtems/5/bin/sparc-rtems5-g++
- Checking for program 'sparc-rtems5-gcc'  : 
$BASE/rtems/5/bin/sparc-rtems5-gcc
- Checking for program 'sparc-rtems5-ld'   : 
$BASE/rtems/5/bin/sparc-rtems5-ld
- Checking for program 'sparc-rtems5-ar'   : 
$BASE/rtems/5/bin/sparc-rtems5-ar
- Checking for program 'sparc-rtems5-nm'   : 
$BASE/rtems/5/bin/sparc-rtems5-nm
- Checking for program 'sparc-rtems5-objdump' : 
$BASE/rtems/5/bin/sparc-rtems5-objdump
- Checking for program 'sparc-rtems5-objcopy' : 
$BASE/rtems/5/bin/sparc-rtems5-objcopy
- Checking for program 'sparc-rtems5-readelf' : 
$BASE/rtems/5/bin/sparc-rtems5-readelf
- Checking for program 'sparc-rtems5-strip'   : 
$BASE/rtems/5/bin/sparc-rtems5-strip
- Checking for program 'sparc-rtems5-ranlib'  : 
$BASE/rtems/5/bin/sparc-rtems5-ranlib
- Checking for program 'rtems-ld' : $BASE/rtems/5/bin/rtems-ld
- Checking for program 'rtems-tld': $BASE/rtems/5/bin/rtems-tld
- Checking for program 'rtems-syms'   : $BASE/rtems/5/bin/rtems-syms
- Checking for program 'rtems-bin2c'  : 
$BASE/rtems/5/bin/rtems-bin2c
- Checking for program 'tar'  : /usr/bin/tar
- Checking for program 'gcc, cc'  : 
$BASE/rtems/5/bin/sparc-rtems5-gcc
- Checking for program 'ar'   : 
$BASE/rtems/5/bin/sparc-rtems5-ar
- Checking for program 'g++, c++' : 
$BASE/rtems/5/bin/sparc-rtems5-g++
- Checking for program 'ar'   : 
$BASE/rtems/5/bin/sparc-rtems5-ar
- Checking for program 'gas, gcc' : 
$BASE/rtems/5/bin/sparc-rtems5-gcc
- Checking for program 'ar'   : 
$BASE/rtems/5/bin/sparc-rtems5-ar
- Checking for c flags '-MMD' : yes
- Checking for cxx flags '-MMD'   : yes
- Compiler version (sparc-rtems5-gcc) : 7.5.0 20191114 (RTEMS 5, 
RSB 5.1.0, Newlib fbaa096)
- Checking for a valid RTEMS BSP installation : yes
- Checking for RTEMS_DEBUG: no
- Checking for RTEMS_MULTIPROCESSING  : no
- Checking for RTEMS_NEWLIB   : yes
- Checking for RTEMS_POSIX_API: yes
- Checking for RTEMS_SMP  : no
- Checking for RTEMS_NETWORKING   : no
- 'configure' finished successfully (0.686s)
+Setting top to   : $BASE/app/hello 
+Setting out to   : $BASE/app/hello/build 
+RTEMS Version: 6 
+Architectures: sparc-rtems6 
+Board Support Package (BSP)  : sparc-rtems6-erc32 
+Show commands: no 
+Long commands: no 
+Checking for program 'sparc-rtems6-gcc'  : 
$BASE/rtems/6/bin/sparc-rtems6-gcc 
+Checking for program 'sparc-rtems6-g++'  : 
$BASE/rtems/6/bin/sparc-rtems6-g++ 
+Checking for program 'sparc-rtems6-gcc'  : 
$BASE/rtems/6/bin/sparc-rtems6-gcc 
+Checking for program 'sparc-rtems6-ld'   : 
$BASE/rtems/6/bin/sparc-rtems6-ld 
+Checking for program 'sparc-rtems6-ar'   : 
$BASE/rtems/6/bin/sparc-rtems6-a

Re: [PATCH 6/6] rtems-docs: Edit commands to build first app

2021-03-16 Thread Ida Delphine 
Regarding the patch to add instructions on how to set up a  patch message
in which file should I create this patch or make changes?

On Mon, Mar 15, 2021 at 8:57 PM Gedare Bloom  wrote:

> Hi Ida,
>
> On Mon, Mar 15, 2021 at 1:50 PM Gedare Bloom  wrote:
> >
> > Hi Ida,
> >
> > did you send the same set of patches twice, or are there changes
> > between the two sets?
> >
>
> Since I'm not quite sure what to look at here, please do me a favor
> and send a new patchset with a -v2 indicator [1], and also set the
> patch message to specify rtems-docs. git format patch supports to set
> the prefix with:
>  git format-patch HEAD^ --subject-prefix="PATCH rtems-docs"
> You can also create an alias to make this simpler [2]. In fact, if you
> can send a patch to add instructions how to set up patch message with
> the repo name to the text at [1] that would be another nice
> contribution :)
>
> [1]
> https://docs.rtems.org/branches/master/eng/vc-users.html#creating-a-patch
> [2] https://lists.rtems.org/pipermail/devel/2020-April/059308.html
>
> Thank you,
> Gedare
>
> > On Sun, Mar 14, 2021 at 8:26 PM Ida Delphine  wrote:
> > >
> > > ---
> > >  user/start/app.rst | 104 ++---
> > >  1 file changed, 52 insertions(+), 52 deletions(-)
> > >
> > > diff --git a/user/start/app.rst b/user/start/app.rst
> > > index 8900f78..c343551 100644
> > > --- a/user/start/app.rst
> > > +++ b/user/start/app.rst
> > > @@ -8,7 +8,7 @@ Build Your Application
> > >  ==
> > >
> > >  You tested a BSP in the previous section.  We built the ``erc32`` BSP
> > > -and it is installed under :file:`$HOME/quick-start/rtems/5`.
> > > +and it is installed under :file:`$HOME/quick-start/rtems/6`.
> > >
> > >  We will now create a simple Hello World application with a Git
> > >  repository and using the `Waf `_ build system.
> > > @@ -107,7 +107,7 @@ and copy the Waf script:
> > >  #
> > >  from __future__ import print_function
> > >
> > > -rtems_version = "5"
> > > +rtems_version = "6"
> > >
> > >  try:
> > >  import rtems_waf.rtems as rtems
> > > @@ -142,52 +142,52 @@ Configure the application using Waf's
> ``configure`` command:
> > >
> > >  .. code-block:: none
> > >
> > > -./waf configure --rtems=$HOME/quick-start/rtems/5
> --rtems-bsp=sparc/erc32
> > > +./waf configure --rtems=$HOME/quick-start/rtems/6
> --rtems-bsp=sparc/erc32 --rtems-version=6
> > >
> > >  The output will be something close to:
> > >
> > >  .. code-block:: none
> > >
> > > - Setting top to   : $BASE/app/hello
> > > - Setting out to   : $BASE/app/hello/build
> > > - RTEMS Version: 5
> > > - Architectures: sparc-rtems5
> > > - Board Support Package (BSP)  : sparc-rtems5-erc32
> > > - Show commands: no
> > > - Long commands: no
> > > - Checking for program 'sparc-rtems5-gcc'  :
> $BASE/rtems/5/bin/sparc-rtems5-gcc
> > > - Checking for program 'sparc-rtems5-g++'  :
> $BASE/rtems/5/bin/sparc-rtems5-g++
> > > - Checking for program 'sparc-rtems5-gcc'  :
> $BASE/rtems/5/bin/sparc-rtems5-gcc
> > > - Checking for program 'sparc-rtems5-ld'   :
> $BASE/rtems/5/bin/sparc-rtems5-ld
> > > - Checking for program 'sparc-rtems5-ar'   :
> $BASE/rtems/5/bin/sparc-rtems5-ar
> > > - Checking for program 'sparc-rtems5-nm'   :
> $BASE/rtems/5/bin/sparc-rtems5-nm
> > > - Checking for program 'sparc-rtems5-objdump' :
> $BASE/rtems/5/bin/sparc-rtems5-objdump
> > > - Checking for program 'sparc-rtems5-objcopy' :
> $BASE/rtems/5/bin/sparc-rtems5-objcopy
> > > - Checking for program 'sparc-rtems5-readelf' :
> $BASE/rtems/5/bin/sparc-rtems5-readelf
> > > - Checking for program 'sparc-rtems5-strip'   :
> $BASE/rtems/5/bin/sparc-rtems5-strip
> > > - Checking for program 'sparc-rtems5-ranlib'  :
> $BASE/rtems/5/bin/sparc-rtems5-ranlib
> > > - Checking for program 'rtems-ld' :
> $BASE/rtems/5/bin/rtems-ld
> > > - Checking for program 'rtems-tld':
> $BASE/rtems/5/bin/rtems-tld
> > > - Checking for program 'rtems-syms'   :
> $BASE/rtems/5/bin/rtems-syms
> > > - Checking for program 'rtems-bin2c'  :
> $BASE/rtems/5/bin/rtems-bin2c
> > > - Checking for program 'tar'  : /usr/bin/tar
> > > - Checking for program 'gcc, cc'  :
> $BASE/rtems/5/bin/sparc-rtems5-gcc
> > > - Checking for program 'ar'   :
> $BASE/rtems/5/bin/sparc-rtems5-ar
> > > - Checking for program 'g++, c++' :
> $BASE/rtems/5/bin/sparc-rtems5-g++
> > > - Checking for program 'ar'   :
> $BASE/rtems/5/bin/sparc-rtems5-ar
> > > - Checking for program 'gas, gcc' :
> $BASE/rtems/5/bin/sparc-rtems5-gcc
> > > - Checking for program 'ar'

[PATCH] sp14: Fix for SMP or robust thread dispatch

2021-03-16 Thread Sebastian Huber 
Close #4343.
---
 testsuites/sptests/sp14/task1.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/testsuites/sptests/sp14/task1.c b/testsuites/sptests/sp14/task1.c
index e1b80c71b4..07657272dc 100644
--- a/testsuites/sptests/sp14/task1.c
+++ b/testsuites/sptests/sp14/task1.c
@@ -36,8 +36,13 @@ rtems_task Task_1(
   rtems_modeprevious_mode;
   rtems_status_code status;
 
+#if defined(RTEMS_SMP) || CPU_ENABLE_ROBUST_THREAD_DISPATCH == TRUE
+  puts( "TA1 - rtems_signal_catch - RTEMS_INTERRUPT_LEVEL( 0 )" );
+  status = rtems_signal_catch( Process_asr, RTEMS_INTERRUPT_LEVEL(0) );
+#else
   puts( "TA1 - rtems_signal_catch - RTEMS_INTERRUPT_LEVEL( 3 )" );
   status = rtems_signal_catch( Process_asr, RTEMS_INTERRUPT_LEVEL(3) );
+#endif
   directive_failed( status, "rtems_signal_catch" );
 
   puts( "TA1 - rtems_signal_send - RTEMS_SIGNAL_16 to self" );
-- 
2.26.2

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems commit] pwdgrp.c: Fix Unchecked return value from library ( CID #1255518)

2021-03-16 Thread Sebastian Huber 

On 08/03/2021 21:56, Joel Sherrill wrote:


Module:rtems
Branch:master
Commit:55ba229d228d1b7372256978828c573dd0af56d4
Changeset:http://git.rtems.org/rtems/commit/?id=55ba229d228d1b7372256978828c573dd0af56d4

Author:Ryan Long
Date:  Tue Mar  2 11:46:02 2021 -0500

pwdgrp.c: Fix Unchecked return value from library (CID #1255518)

CID 1255518: Unchecked return value from library in pwdgrp_init().

Closes #4282


I get an assertion in the tests with RTEMS_DEBUG enabled:

    test start: PWDGRP 1

    *** BEGIN OF TEST PWDGRP 1 ***

    *** TEST VERSION: 6.0.0.ca801609a7100804520809d1407174f465befee5

    *** TEST STATE: EXPECTED_PASS

    *** TEST BUILD: RTEMS_DEBUG RTEMS_NETWORKING RTEMS_POSIX_API

    *** TEST TOOLS: 10.2.1 20210315 (RTEMS 6, RSB 
62363ba982213588ef5d8bc8c4ff3acc28075f3f,

    Newlib d10d0d9)

    assertion "(sc) == (0)" failed: file 
"/home/EB/sebastian_h/src/rtems/cpukit/libcsupport/src/pwdgrp.c",

    line 72, function: pwdgrp_init

--
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] pwdgrp.c: Fix Unchecked return value from library ( CID #1255518)

2021-03-16 Thread Sebastian Huber 

On 16/03/2021 12:30, Sebastian Huber wrote:


On 08/03/2021 21:56, Joel Sherrill wrote:


Module:    rtems
Branch:    master
Commit:    55ba229d228d1b7372256978828c573dd0af56d4
Changeset:http://git.rtems.org/rtems/commit/?id=55ba229d228d1b7372256978828c573dd0af56d4 



Author:    Ryan Long
Date:  Tue Mar  2 11:46:02 2021 -0500

pwdgrp.c: Fix Unchecked return value from library (CID #1255518)

CID 1255518: Unchecked return value from library in pwdgrp_init().

Closes #4282


I get an assertion in the tests with RTEMS_DEBUG enabled:

    test start: PWDGRP 1

    *** BEGIN OF TEST PWDGRP 1 ***

    *** TEST VERSION: 6.0.0.ca801609a7100804520809d1407174f465befee5

    *** TEST STATE: EXPECTED_PASS

    *** TEST BUILD: RTEMS_DEBUG RTEMS_NETWORKING RTEMS_POSIX_API

    *** TEST TOOLS: 10.2.1 20210315 (RTEMS 6, RSB 
62363ba982213588ef5d8bc8c4ff3acc28075f3f,

    Newlib d10d0d9)

    assertion "(sc) == (0)" failed: file 
"/home/EB/sebastian_h/src/rtems/cpukit/libcsupport/src/pwdgrp.c",

    line 72, function: pwdgrp_init


Also these tests:

    test start: PSXPASSWD 2

    *** BEGIN OF TEST PSXPASSWD 2 ***

    *** TEST VERSION: 6.0.0.ca801609a7100804520809d1407174f465befee5

    *** TEST STATE: EXPECTED_PASS

    *** TEST BUILD: RTEMS_DEBUG RTEMS_NETWORKING RTEMS_POSIX_API

    *** TEST TOOLS: 10.2.1 20210315 (RTEMS 6, RSB 
62363ba982213588ef5d8bc8c4ff3acc28075f3f,

    Newlib d10d0d9)

    Init - Creating /etc

    Init - Creating /etc/passwd

    Init - Creating /etc/group

    Init - setpwent() -- OK

    assertion "(sc) == (0)" failed: file 
"/home/EB/sebastian_h/src/rtems/cpukit/libcsupport/src/pwdgrp.c",


    line 72, function: pwdgrp_init


    test start: SHELL 1

    *** BEGIN OF TEST SHELL 1 ***

    *** TEST VERSION: 6.0.0.ca801609a7100804520809d1407174f465befee5

    *** TEST STATE: EXPECTED_PASS

    *** TEST BUILD: RTEMS_DEBUG RTEMS_NETWORKING RTEMS_POSIX_API

    *** TEST TOOLS: 10.2.1 20210315 (RTEMS 6, RSB 
62363ba982213588ef5d8bc8c4ff3acc28075f3f,

    Newlib d10d0d9)

    assertion "(sc) == (0)" failed: file 
"/home/EB/sebastian_h/src/rtems/cpukit/libcsupport/src/pwdgrp.c",

    line 72, function: pwdgrp_init

--
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: All (18) RSB tool failures on rtems6 (details on m68k)

2021-03-16 Thread Sebastian Huber 

Hello Joel,

I updated the tools today. Maybe the error disappeared. It builds fine 
using openSUSE Leap 15.2.


--
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] sp14: Fix for SMP or robust thread dispatch

2021-03-16 Thread Kinsey Moore 
This fixes the issues on AArch64 and ARM, thanks!

Kinsey

-Original Message-
From: devel  On Behalf Of Sebastian Huber
Sent: Tuesday, March 16, 2021 06:20
To: devel@rtems.org
Subject: [PATCH] sp14: Fix for SMP or robust thread dispatch

Close #4343.
---
 testsuites/sptests/sp14/task1.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/testsuites/sptests/sp14/task1.c b/testsuites/sptests/sp14/task1.c
index e1b80c71b4..07657272dc 100644
--- a/testsuites/sptests/sp14/task1.c
+++ b/testsuites/sptests/sp14/task1.c
@@ -36,8 +36,13 @@ rtems_task Task_1(
   rtems_modeprevious_mode;
   rtems_status_code status;
 
+#if defined(RTEMS_SMP) || CPU_ENABLE_ROBUST_THREAD_DISPATCH == TRUE
+  puts( "TA1 - rtems_signal_catch - RTEMS_INTERRUPT_LEVEL( 0 )" );
+  status = rtems_signal_catch( Process_asr, RTEMS_INTERRUPT_LEVEL(0) );
+#else
   puts( "TA1 - rtems_signal_catch - RTEMS_INTERRUPT_LEVEL( 3 )" );
   status = rtems_signal_catch( Process_asr, RTEMS_INTERRUPT_LEVEL(3) );
+#endif
   directive_failed( status, "rtems_signal_catch" );
 
   puts( "TA1 - rtems_signal_send - RTEMS_SIGNAL_16 to self" );
-- 
2.26.2

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH v2] user/bsps: Mention fixed console baud rate for zynq

2021-03-16 Thread Jan.Sommer 
Thanks. Pushed to master.

> -Original Message-
> From: Gedare Bloom 
> Sent: Monday, March 15, 2021 11:08 PM
> To: Joel Sherrill 
> Cc: Sommer, Jan ; rtems-de...@rtems.org
> 
> Subject: Re: [PATCH v2] user/bsps: Mention fixed console baud rate for zynq
> 
> Yeah go ahead, thanks Jan.
> 
> On Mon, Mar 15, 2021 at 6:58 AM Joel Sherrill  wrote:
> >
> > If this matches the state of the got master, then ok.
> >
> > On Mon, Mar 15, 2021, 7:55 AM  wrote:
> >>
> >> Could someone please have a look at this patch?
> >>
> >> > -Original Message-
> >> > From: Sommer, Jan
> >> > Sent: Friday, March 5, 2021 7:04 PM
> >> > To: devel@rtems.org
> >> > Cc: Sommer, Jan 
> >> > Subject: [PATCH v2] user/bsps: Mention fixed console baud rate for
> >> > zynq
> >> >
> >> > ---
> >> >  user/bsps/arm/xilinx-zynq.rst | 12 
> >> >  1 file changed, 12 insertions(+)
> >> >
> >> > diff --git a/user/bsps/arm/xilinx-zynq.rst
> >> > b/user/bsps/arm/xilinx-zynq.rst index 365c336..29f9cb0 100644
> >> > --- a/user/bsps/arm/xilinx-zynq.rst
> >> > +++ b/user/bsps/arm/xilinx-zynq.rst
> >> > @@ -37,6 +37,18 @@ to return the peripheral clock. Normally this is
> >> > half the CPU  clock. This function is declared ``weak`` so you can
> >> > override the  default behaviour by providing it in your application.
> >> >
> >> > +Console
> >> > +---
> >> > +
> >> > +The console driver for the UARTs will always be initialized to a
> >> > +baud rate of 115200 with 8 bit characters, 1 stop bit and no
> >> > +parity bits during start up.
> >> > +Previous configurations programmed into the hardware by the Xilinx
> >> > +tools or a bootloader will be overwritten.
> >> > +
> >> > +The settings for the console driver can be changed by the user
> >> > +application through the termios API afterwards.
> >> > +
> >> >  Debugging with xilinx_zynq_a9_qemu
> >> >  --
> >> >
> >> > --
> >> > 2.17.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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH 0/3] Add spidev driver for Xilinx AXI Quad SPI device

2021-03-16 Thread Jan.Sommer 
Could someone also please have a look at this patchset.
When this goes through, I would like to backport this, the cadence-spi driver 
and the spi shell command of Christian to rtems5.

Best regards,

Jan

> -Original Message-
> From: Sommer, Jan
> Sent: Wednesday, March 10, 2021 9:15 PM
> To: devel@rtems.org
> Cc: Sommer, Jan 
> Subject: [PATCH 0/3] Add spidev driver for Xilinx AXI Quad SPI device
> 
> This patchset adds a spidev driver for the Xilinx AXI Quad SPI device.
> It currently supports Standard SPI mode.
> 
> Thanks goes to Rick van der Wal for testing the driver with his SPI IMU.
> 
> Jan Sommer (3):
>   bsps/xilinx_zynq: Add SPI driver for xilinx-axi-spi
>   bsps/shared: Add Xilinx-AXI SPI driver to waf
>   bsps/xilinx_zynq: Add Xilinx AXI SPI driver to autotools build
> 
>  bsps/headers.am   |   2 +
>  bsps/include/dev/spi/xilinx-axi-spi-regs.h|  88 
>  bsps/include/dev/spi/xilinx-axi-spi.h |  67 +++
>  bsps/shared/dev/spi/xilinx-axi-spi.c  | 402 ++
>  c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am  |   1 +
>  .../lib/libbsp/arm/xilinx-zynqmp/Makefile.am  |   1 +
>  spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml |   2 +
>  spec/build/bsps/arm/xilinx-zynq/grp.yml   |   2 +
>  .../arm/xilinx-zynqmp/bspxilinxzynqmp.yml |   2 +
>  spec/build/bsps/objdevspixil.yml  |  18 +
>  10 files changed, 585 insertions(+)
>  create mode 100644 bsps/include/dev/spi/xilinx-axi-spi-regs.h
>  create mode 100644 bsps/include/dev/spi/xilinx-axi-spi.h
>  create mode 100644 bsps/shared/dev/spi/xilinx-axi-spi.c
>  create mode 100644 spec/build/bsps/objdevspixil.yml
> 
> --
> 2.17.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: code reformatting was Re: Regarding gsoc project 3860

2021-03-16 Thread Christian MAUDERER 

Am 15.03.21 um 23:05 schrieb Gedare Bloom:

On Mon, Mar 15, 2021 at 6:44 AM Joel Sherrill  wrote:




On Mon, Mar 15, 2021 at 4:20 AM Hesham Almatary  
wrote:


Hello Ayushman and Ida,

Usually, if multiple students really want to work on a particular
project (and can't/don't want to choose another), there can be
multiple proposals for the same project and we choose the best one.
Sometimes a project can be split up between two students to work on to
minimise conflicts.



There are multiple things that need to be addressed here.

First, there have been discussions on devel@ about code formatting tools.
Sebastian has posted a configuration for the indent program but offhand
I don't know where that is. It may be in the documentation.


I posted about this to Ida. I think it was uncrustify? I think several
tools have been looked into. No specific tool is required, but we
should pick the one that best allows us to meet the needs of the
project.


For indent to move forward from here, its impact on the code in a directory
that is thought to follow the RTEMS style well would need to be evaluated.
Do the rules need to be tweaked to avoid changes? Is the source code actually
just not in conformance with published rules? The process here is to evaluate
the difference between tool output and existing code and work to close the
delta by tweaking rules and fixing code. The end is expected to be that there
are a few places where the tool can't produce RTEMS style and we have to
discuss adopting something the tool can produce.

I don't recall if Sebastian evaluated the llvm formatter and created a 
configuration
for it. In this case, creating a configuration for this tool before evaluating 
the
difference in output would be the path forward. If this formatter is better, 
then
I would like to see an RTEMS style added to their options.

With either tool, a factor is integrating it into the development process. I'm
not sure what a GSoC project would do about this.



I think the tool integration is the main piece of GSoC-relevant work,
as this would involve some level of scripting and automation.


So there are two potential projects here. My question is not conflict on
project choice, it is whether either is an appropriate GSoC project. With
the shorter time frame, I think the scope of the project is in the right 
ballpark.
Is there enough coding? I don't know.



I'm not currently convinced there is enough coding work for two
projects in this area. I don't think there would have been enough
coding work for one project under the old GSoC scope.

Running the code formatter and submitting patches won't really count
as "code contributions"


I think the contributions from this project that would add value would be:

1. Finding a tool and a configuration that can do an RTEMS style or an 
acceptable close one.


2. Adding a "check-style" target to our build system.

3. Maybe add some kind of script similar to Linux "checkpatch.pl" that 
could check whether patches would need changes _before_ they are applied.


Finding stuff that currently doesn't fit our coding style is only a 
small part of it.


Best regards

Christian




--joel




On Mon, 15 Mar 2021 at 09:45, Ida Delphine  wrote:


Umm...did you bring up a discussion regarding this project earlier?


I do not have a record of Ayushman "claiming" this project, and anyway
we don't allow students to "claim" a project.


On Mon, 15 Mar 2021, 8:10 am Ayushman Mishra,  wrote:


AYUSHMAN MISHRA

Hello Ida delphini AYUSHMAN here , Can you please select any other project for 
gsoc as I am also currently working on proposal for the same project
https://devel.rtems.org/ticket/3860 for gsoc 2021



Ayushman, this is not a polite request for you to make, in addition it
would best have been made by direct reply to her email in the same
thread, not by starting a new e-mail thread. In an open-source
community, you should not impose yourself on another person. It goes
against the fundamental ideas of "freedom" that open-source is based
on. Part of GSoC is exactly about learning this kind of lesson, so
don't feel too bad about it, but do pay attention to how you interact
with others and make sure you are respecting their autonomy and
perspectives.


___
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


___
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 Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741

RE: [PATCH 2/3] covoar: Improve findCoverageMap error message

2021-03-16 Thread Alex White 
This patch no longer applies assuming that the latest revision of my earlier 
patch, "covoar: Handle periods in symbols from objdump",  is accepted.

-Original Message-
From: Alex White  
Sent: Friday, March 12, 2021 11:14 AM
To: devel@rtems.org
Cc: Alex White 
Subject: [PATCH 2/3] covoar: Improve findCoverageMap error message

---
 tester/covoar/ExecutableInfo.cc | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tester/covoar/ExecutableInfo.cc b/tester/covoar/ExecutableInfo.cc 
index 5a730fd..30828a6 100644
--- a/tester/covoar/ExecutableInfo.cc
+++ b/tester/covoar/ExecutableInfo.cc
@@ -177,7 +177,9 @@ namespace Coverage {
 
 if (periodIndex == std::string::npos) {
   // Symbol name has no '.', can't do another lookup.
-  throw rld::error (symbolName, "ExecutableInfo::findCoverageMap");
+  std::ostringstream what;
+  what << "Could not find " << symbolName;
+  throw rld::error (what, "ExecutableInfo::findCoverageMap");
 }
 
 cmi = coverageMaps.find(
@@ -185,7 +187,9 @@ namespace Coverage {
 );
 
 if ( cmi == coverageMaps.end() ) {
-  throw rld::error (symbolName, "ExecutableInfo::findCoverageMap");
+  std::ostringstream what;
+  what << "Could not find " << symbolName;
+  throw rld::error (what, "ExecutableInfo::findCoverageMap");
 }
 
 return *(cmi->second);
--
2.27.0

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 2/3] rtems: Allow initially locked MrsP semaphores

2021-03-16 Thread Sebastian Huber 
Rejecting initially locked MrsP semaphores was due to a limitiation of
the early limitiation of the MrsP protocol.  This limitation no longer
exists.
---
 cpukit/include/rtems/rtems/sem.h  |  3 ---
 cpukit/include/rtems/score/mrspimpl.h | 28 +--
 testsuites/smptests/smpmrsp01/init.c  | 14 ++
 3 files changed, 32 insertions(+), 13 deletions(-)

diff --git a/cpukit/include/rtems/rtems/sem.h b/cpukit/include/rtems/rtems/sem.h
index 1f0c952294..e117f1c211 100644
--- a/cpukit/include/rtems/rtems/sem.h
+++ b/cpukit/include/rtems/rtems/sem.h
@@ -240,9 +240,6 @@ extern "C" {
  * * When the directive operates on a global object, the directive sends a
  *   message to remote nodes.  This may preempt the calling task.
  *
- * * When a semaphore using the MrsP locking protocol is created, the initial
- *   count shall be exactly one.
- *
  * * The number of semaphores available to the application is configured
  *   through the #CONFIGURE_MAXIMUM_SEMAPHORES application configuration
  *   option.
diff --git a/cpukit/include/rtems/score/mrspimpl.h 
b/cpukit/include/rtems/score/mrspimpl.h
index 3cd5bcf33c..89711d6b1b 100644
--- a/cpukit/include/rtems/score/mrspimpl.h
+++ b/cpukit/include/rtems/score/mrspimpl.h
@@ -295,12 +295,13 @@ RTEMS_INLINE_ROUTINE Status_Control _MRSP_Initialize(
   bool initially_locked
 )
 {
-  uint32_t scheduler_count = _Scheduler_Count;
-  uint32_t i;
+  Thread_queue_Context queue_context;
+  ISR_Levellevel;
+  size_t   scheduler_count;
+  size_t   i;
+  Status_Control   status;
 
-  if ( initially_locked ) {
-return STATUS_INVALID_NUMBER;
-  }
+  scheduler_count = _Scheduler_Count;
 
   for ( i = 0 ; i < scheduler_count ; ++i ) {
 const Scheduler_Control *scheduler_of_index;
@@ -316,7 +317,22 @@ RTEMS_INLINE_ROUTINE Status_Control _MRSP_Initialize(
   }
 
   _Thread_queue_Object_initialize( &mrsp->Wait_queue );
-  return STATUS_SUCCESSFUL;
+
+  if ( !initially_locked ) {
+return STATUS_SUCCESSFUL;
+  }
+
+  _Thread_queue_Context_initialize( &queue_context );
+  _Thread_queue_Context_ISR_disable( &queue_context, level );
+  _Thread_queue_Context_set_ISR_level( &queue_context, level );
+  _MRSP_Acquire_critical( mrsp, &queue_context );
+  status = _MRSP_Claim_ownership( mrsp, executing, &queue_context );
+
+  if ( status != STATUS_SUCCESSFUL ) {
+_Thread_queue_Destroy( &mrsp->Wait_queue );
+  }
+
+  return status;
 }
 
 /**
diff --git a/testsuites/smptests/smpmrsp01/init.c 
b/testsuites/smptests/smpmrsp01/init.c
index 76bb928982..147838957d 100644
--- a/testsuites/smptests/smpmrsp01/init.c
+++ b/testsuites/smptests/smpmrsp01/init.c
@@ -734,12 +734,12 @@ static void test_mrsp_flush_error(test_context *ctx)
   rtems_test_assert(sc == RTEMS_SUCCESSFUL);
 }
 
-static void test_mrsp_initially_locked_error(void)
+static void test_mrsp_initially_locked(void)
 {
   rtems_status_code sc;
   rtems_id id;
 
-  puts("test MrsP initially locked error");
+  puts("test MrsP initially locked");
 
   sc = rtems_semaphore_create(
 rtems_build_name('M', 'R', 'S', 'P'),
@@ -749,7 +749,13 @@ static void test_mrsp_initially_locked_error(void)
 1,
 &id
   );
-  rtems_test_assert(sc == RTEMS_INVALID_NUMBER);
+  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+
+  sc = rtems_semaphore_release(id);
+  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
+
+  sc = rtems_semaphore_delete(id);
+  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
 }
 
 static void test_mrsp_nested_obtain_error(test_context *ctx)
@@ -1750,7 +1756,7 @@ static void Init(rtems_task_argument arg)
   }
 
   test_mrsp_flush_error(ctx);
-  test_mrsp_initially_locked_error();
+  test_mrsp_initially_locked();
   test_mrsp_nested_obtain_error(ctx);
   test_mrsp_deadlock_error(ctx);
   test_mrsp_multiple_obtain(ctx);
-- 
2.26.2

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 3/3] rtems: Improve semaphore create error checks

2021-03-16 Thread Sebastian Huber 
Do not mix checks for different error indicators (RTEMS_NOT_DEFINED and
RTEMS_INVALID_NUMBER).  This simplifies the specification of
rtems_semaphore_create().
---
 cpukit/rtems/src/semcreate.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/cpukit/rtems/src/semcreate.c b/cpukit/rtems/src/semcreate.c
index 0246c91bc9..b58ea0199f 100644
--- a/cpukit/rtems/src/semcreate.c
+++ b/cpukit/rtems/src/semcreate.c
@@ -72,12 +72,6 @@ rtems_status_code rtems_semaphore_create(
 
   if ( maybe_global == RTEMS_COUNTING_SEMAPHORE ) {
 variant = SEMAPHORE_VARIANT_COUNTING;
-  } else if ( count > 1 ) {
-/*
- * The remaining variants are all binary semphores, thus reject an invalid
- * count value.
- */
-return RTEMS_INVALID_NUMBER;
   } else if ( maybe_global == RTEMS_SIMPLE_BINARY_SEMAPHORE ) {
 variant = SEMAPHORE_VARIANT_SIMPLE_BINARY;
   } else if ( maybe_global == RTEMS_BINARY_SEMAPHORE ) {
@@ -109,6 +103,10 @@ rtems_status_code rtems_semaphore_create(
 return RTEMS_NOT_DEFINED;
   }
 
+  if ( count > 1 && variant != SEMAPHORE_VARIANT_COUNTING ) {
+return RTEMS_INVALID_NUMBER;
+  }
+
   the_semaphore = _Semaphore_Allocate();
 
   if ( !the_semaphore ) {
-- 
2.26.2

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 1/3] rtems: Require RTEMS_PRIORITY for MrsP semaphores

2021-03-16 Thread Sebastian Huber 
MrsP semaphores are a generalization of the priority ceiling semaphores
for SMP configurations.  Priority ceiling semaphores are required to use
the priority task wait queue discipline.  Require this discipline also
for MrsP semaphores.

Close #4347.
---
 cpukit/include/rtems/rtems/sem.h  |  3 ++-
 cpukit/rtems/src/semcreate.c  |  4 ++--
 testsuites/smptests/smpfatal03/init.c |  4 ++--
 testsuites/smptests/smpmrsp01/init.c  |  8 
 testsuites/smptests/smpscheduler02/init.c |  3 ++-
 testsuites/sptests/spmrsp01/init.c| 23 ++-
 testsuites/tmtests/tmfine01/init.c|  3 ++-
 7 files changed, 28 insertions(+), 20 deletions(-)

diff --git a/cpukit/include/rtems/rtems/sem.h b/cpukit/include/rtems/rtems/sem.h
index 74d0ab45a3..1f0c952294 100644
--- a/cpukit/include/rtems/rtems/sem.h
+++ b/cpukit/include/rtems/rtems/sem.h
@@ -803,7 +803,8 @@ rtems_status_code rtems_semaphore_flush( rtems_id id );
  *   sc = rtems_semaphore_create(
  * rtems_build_name( 'M', 'R', 'S', 'P' ),
  * 1,
- * RTEMS_BINARY_SEMAPHORE | RTEMS_MULTIPROCESSOR_RESOURCE_SHARING,
+ * RTEMS_BINARY_SEMAPHORE | RTEMS_PRIORITY |
+ *   RTEMS_MULTIPROCESSOR_RESOURCE_SHARING,
  * 1,
  * &semaphore_id
  *   );
diff --git a/cpukit/rtems/src/semcreate.c b/cpukit/rtems/src/semcreate.c
index 3647bb7b13..0246c91bc9 100644
--- a/cpukit/rtems/src/semcreate.c
+++ b/cpukit/rtems/src/semcreate.c
@@ -93,8 +93,8 @@ rtems_status_code rtems_semaphore_create(
   ) {
 variant = SEMAPHORE_VARIANT_MUTEX_PRIORITY_CEILING;
   } else if (
-mutex_with_protocol
-  == ( RTEMS_BINARY_SEMAPHORE | RTEMS_MULTIPROCESSOR_RESOURCE_SHARING )
+mutex_with_protocol == ( RTEMS_BINARY_SEMAPHORE | RTEMS_PRIORITY |
+  RTEMS_MULTIPROCESSOR_RESOURCE_SHARING )
   ) {
 #if defined(RTEMS_SMP)
 variant = SEMAPHORE_VARIANT_MRSP;
diff --git a/testsuites/smptests/smpfatal03/init.c 
b/testsuites/smptests/smpfatal03/init.c
index c40194aacb..7eb681b9f9 100644
--- a/testsuites/smptests/smpfatal03/init.c
+++ b/testsuites/smptests/smpfatal03/init.c
@@ -41,8 +41,8 @@ static void Init( rtems_task_argument arg )
   sc = rtems_semaphore_create(
 rtems_build_name('M', 'R', 'S', 'P'),
 1,
-RTEMS_MULTIPROCESSOR_RESOURCE_SHARING
-  | RTEMS_BINARY_SEMAPHORE,
+RTEMS_BINARY_SEMAPHORE | RTEMS_PRIORITY |
+  RTEMS_MULTIPROCESSOR_RESOURCE_SHARING,
 1,
 &sem_id
   );
diff --git a/testsuites/smptests/smpmrsp01/init.c 
b/testsuites/smptests/smpmrsp01/init.c
index 11535763ca..76bb928982 100644
--- a/testsuites/smptests/smpmrsp01/init.c
+++ b/testsuites/smptests/smpmrsp01/init.c
@@ -257,8 +257,8 @@ static void create_mrsp_sema(
   sc = rtems_semaphore_create(
 rtems_build_name('M', 'R', 'S', 'P'),
 1,
-RTEMS_MULTIPROCESSOR_RESOURCE_SHARING
-  | RTEMS_BINARY_SEMAPHORE,
+RTEMS_BINARY_SEMAPHORE | RTEMS_PRIORITY |
+  RTEMS_MULTIPROCESSOR_RESOURCE_SHARING,
 prio,
 id
   );
@@ -744,8 +744,8 @@ static void test_mrsp_initially_locked_error(void)
   sc = rtems_semaphore_create(
 rtems_build_name('M', 'R', 'S', 'P'),
 0,
-RTEMS_MULTIPROCESSOR_RESOURCE_SHARING
-  | RTEMS_BINARY_SEMAPHORE,
+RTEMS_BINARY_SEMAPHORE | RTEMS_PRIORITY |
+  RTEMS_MULTIPROCESSOR_RESOURCE_SHARING,
 1,
 &id
   );
diff --git a/testsuites/smptests/smpscheduler02/init.c 
b/testsuites/smptests/smpscheduler02/init.c
index 9297efec23..b337fc667e 100644
--- a/testsuites/smptests/smpscheduler02/init.c
+++ b/testsuites/smptests/smpscheduler02/init.c
@@ -82,7 +82,8 @@ static void sticky_task(rtems_task_argument arg)
   sc = rtems_semaphore_create(
 rtems_build_name(' ', 'M', 'T', 'X'),
 1,
-RTEMS_BINARY_SEMAPHORE | RTEMS_MULTIPROCESSOR_RESOURCE_SHARING,
+RTEMS_BINARY_SEMAPHORE | RTEMS_PRIORITY |
+  RTEMS_MULTIPROCESSOR_RESOURCE_SHARING,
 2,
 &mtx_id
   );
diff --git a/testsuites/sptests/spmrsp01/init.c 
b/testsuites/sptests/spmrsp01/init.c
index a5f645d534..ca35d90595 100644
--- a/testsuites/sptests/spmrsp01/init.c
+++ b/testsuites/sptests/spmrsp01/init.c
@@ -53,8 +53,8 @@ static void test_mrsp_create_errors(void)
   sc = rtems_semaphore_create(
 rtems_build_name('M', 'R', 'S', 'P'),
 1,
-RTEMS_MULTIPROCESSOR_RESOURCE_SHARING
-  | RTEMS_BINARY_SEMAPHORE,
+RTEMS_BINARY_SEMAPHORE | RTEMS_PRIORITY
+  | RTEMS_MULTIPROCESSOR_RESOURCE_SHARING,
 UINT32_MAX,
 &id
   );
@@ -63,29 +63,33 @@ static void test_mrsp_create_errors(void)
   create_not_defined(
 RTEMS_MULTIPROCESSOR_RESOURCE_SHARING
   | RTEMS_COUNTING_SEMAPHORE
+  | RTEMS_PRIORITY
   );
 
   create_not_defined(
 RTEMS_MULTIPROCESSOR_RESOURCE_SHARING
   | RTEMS_SIMPLE_BINARY_SEMAPHORE
+  | RTEMS_PRIORITY
   );
 
   create_not_defined(
 RTEMS_MULTIPROCESSOR_RESOURCE_SHARING
   | RTEMS_BINARY_SEMAPHORE
-  | RTEMS_PRIORITY
+  | RTEMS_FIFO
   );
 
   create_not_defined(
 RTEMS_MULTIPROCESSOR_RESOURCE_SHARING

[PATCH] RTEMS 5.2: rtems: Allow RTEMS_PRIORITY for MrsP semaphores

2021-03-16 Thread Sebastian Huber 
In order to improve the compatibility of RTEMS 5.2 with future version
of RTEMS which fixed #4346 allow MrsP semaphores to be created with
RTEMS_PRIORITY.

Close #4347.
---
 cpukit/rtems/src/semcreate.c   | 7 ++-
 testsuites/sptests/spmrsp01/init.c | 6 --
 2 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/cpukit/rtems/src/semcreate.c b/cpukit/rtems/src/semcreate.c
index b57b635d85..ea89800685 100644
--- a/cpukit/rtems/src/semcreate.c
+++ b/cpukit/rtems/src/semcreate.c
@@ -92,9 +92,14 @@ rtems_status_code rtems_semaphore_create(
   ) {
 variant = SEMAPHORE_VARIANT_MUTEX_PRIORITY_CEILING;
   } else if (
-mutex_with_protocol
+( mutex_with_protocol & ~RTEMS_PRIORITY )
   == ( RTEMS_BINARY_SEMAPHORE | RTEMS_MULTIPROCESSOR_RESOURCE_SHARING )
   ) {
+/*
+ * In RTEMS 5.2 using RTEMS_FIFO and RTEMS_PRIORITY for MrsP semaphores is
+ * allowed.  In RTEMS 6, RTEMS_PRIORITY is required for MrsP semaphores
+ * analogous to priority ceiling semaphores.
+ */
 #if defined(RTEMS_SMP)
 variant = SEMAPHORE_VARIANT_MRSP;
 #else
diff --git a/testsuites/sptests/spmrsp01/init.c 
b/testsuites/sptests/spmrsp01/init.c
index a5f645d534..801b679ec9 100644
--- a/testsuites/sptests/spmrsp01/init.c
+++ b/testsuites/sptests/spmrsp01/init.c
@@ -70,12 +70,6 @@ static void test_mrsp_create_errors(void)
   | RTEMS_SIMPLE_BINARY_SEMAPHORE
   );
 
-  create_not_defined(
-RTEMS_MULTIPROCESSOR_RESOURCE_SHARING
-  | RTEMS_BINARY_SEMAPHORE
-  | RTEMS_PRIORITY
-  );
-
   create_not_defined(
 RTEMS_MULTIPROCESSOR_RESOURCE_SHARING
   | RTEMS_INHERIT_PRIORITY
-- 
2.26.2

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [rtems commit] pwdgrp.c: Fix Unchecked return value from library ( CID #1255518)

2021-03-16 Thread Ryan Long 
I found this error yesterday, when doing more testing based on Chris's 
feedback. I've taken out the _Assert_Unused_variable_equals() in pwdgrp.c and 
replaced it with just a (void). The test passed afterwards, but Joel wants me 
to test it a little further. I'll get the patch in to fix that by the end of 
the day. 

-Original Message-
From: Sebastian Huber  
Sent: Tuesday, March 16, 2021 6:33 AM
To: RTEMS ; Ryan Long 
Subject: Re: [rtems commit] pwdgrp.c: Fix Unchecked return value from library ( 
CID #1255518)

On 16/03/2021 12:30, Sebastian Huber wrote:

> On 08/03/2021 21:56, Joel Sherrill wrote:
>
>> Module:    rtems
>> Branch:    master
>> Commit:    55ba229d228d1b7372256978828c573dd0af56d4
>> Changeset:http://git.rtems.org/rtems/commit/?id=55ba229d228d1b7372256
>> 978828c573dd0af56d4
>>
>>
>> Author:    Ryan Long
>> Date:  Tue Mar  2 11:46:02 2021 -0500
>>
>> pwdgrp.c: Fix Unchecked return value from library (CID #1255518)
>>
>> CID 1255518: Unchecked return value from library in pwdgrp_init().
>>
>> Closes #4282
>
> I get an assertion in the tests with RTEMS_DEBUG enabled:
>
>     test start: PWDGRP 1
>
>     *** BEGIN OF TEST PWDGRP 1 ***
>
>     *** TEST VERSION: 6.0.0.ca801609a7100804520809d1407174f465befee5
>
>     *** TEST STATE: EXPECTED_PASS
>
>     *** TEST BUILD: RTEMS_DEBUG RTEMS_NETWORKING RTEMS_POSIX_API
>
>     *** TEST TOOLS: 10.2.1 20210315 (RTEMS 6, RSB 
> 62363ba982213588ef5d8bc8c4ff3acc28075f3f,
>     Newlib d10d0d9)
>
>     assertion "(sc) == (0)" failed: file 
> "/home/EB/sebastian_h/src/rtems/cpukit/libcsupport/src/pwdgrp.c",
>     line 72, function: pwdgrp_init

Also these tests:

     test start: PSXPASSWD 2

     *** BEGIN OF TEST PSXPASSWD 2 ***

     *** TEST VERSION: 6.0.0.ca801609a7100804520809d1407174f465befee5

     *** TEST STATE: EXPECTED_PASS

     *** TEST BUILD: RTEMS_DEBUG RTEMS_NETWORKING RTEMS_POSIX_API

     *** TEST TOOLS: 10.2.1 20210315 (RTEMS 6, RSB 
62363ba982213588ef5d8bc8c4ff3acc28075f3f,
     Newlib d10d0d9)

     Init - Creating /etc

     Init - Creating /etc/passwd

     Init - Creating /etc/group

     Init - setpwent() -- OK

     assertion "(sc) == (0)" failed: file 
"/home/EB/sebastian_h/src/rtems/cpukit/libcsupport/src/pwdgrp.c",

     line 72, function: pwdgrp_init


     test start: SHELL 1

     *** BEGIN OF TEST SHELL 1 ***

     *** TEST VERSION: 6.0.0.ca801609a7100804520809d1407174f465befee5

     *** TEST STATE: EXPECTED_PASS

     *** TEST BUILD: RTEMS_DEBUG RTEMS_NETWORKING RTEMS_POSIX_API

     *** TEST TOOLS: 10.2.1 20210315 (RTEMS 6, RSB 
62363ba982213588ef5d8bc8c4ff3acc28075f3f,
     Newlib d10d0d9)

     assertion "(sc) == (0)" failed: file 
"/home/EB/sebastian_h/src/rtems/cpukit/libcsupport/src/pwdgrp.c",
     line 72, function: pwdgrp_init

--
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: All (18) RSB tool failures on rtems6 (details on m68k)

2021-03-16 Thread Joel Sherrill 
Thanks. I will spin them again.

What ended up working was removing the installed tools from
a previous hash, all downloaded source, all logs, and the RSB build
directory. I suspect it was a hiccup on binutils of some kind.

What is puzzling is that it didn't happen on the FreeBSD or Ubuntu
machines. But they are slower and I tend to build more frequently
on the CentOS machine. Maybe it caught a bad step where the
others didn't.

Anyway, everything is bad on track except for the known issues of
rtems-bsp-tester and mips on FreeBSD. And the quite odd one that
I have qemu hanging with the rtems-tester on CentOS for a handful
of tests. That last one I need to look into.

--joel


On Tue, Mar 16, 2021 at 6:46 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Joel,
>
> I updated the tools today. Maybe the error disappeared. It builds fine
> using openSUSE Leap 15.2.
>
> --
> 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] pwdgrp.c: Fix Unchecked return value from library ( CID #1255518)

2021-03-16 Thread Joel Sherrill 
On Tue, Mar 16, 2021 at 9:15 AM Ryan Long  wrote:

> I found this error yesterday, when doing more testing based on Chris's
> feedback. I've taken out the _Assert_Unused_variable_equals() in pwdgrp.c
> and replaced it with just a (void). The test passed afterwards, but Joel
> wants me to test it a little further. I'll get the patch in to fix that by
> the end of the day.


I wanted to see fileio run OK but it looks like the Zynq BSP on Qemu
doesn't have working input at the moment. I had Ryan switch over to leon3
just to test this.

Does console input work for you on Zynq qemu right now? I emailed Jan last
night to see if he had tested that.

--joel

>
>
> -Original Message-
> From: Sebastian Huber 
> Sent: Tuesday, March 16, 2021 6:33 AM
> To: RTEMS ; Ryan Long 
> Subject: Re: [rtems commit] pwdgrp.c: Fix Unchecked return value from
> library ( CID #1255518)
>
> On 16/03/2021 12:30, Sebastian Huber wrote:
>
> > On 08/03/2021 21:56, Joel Sherrill wrote:
> >
> >> Module:rtems
> >> Branch:master
> >> Commit:55ba229d228d1b7372256978828c573dd0af56d4
> >> Changeset:http://git.rtems.org/rtems/commit/?id=55ba229d228d1b7372256
> >> 978828c573dd0af56d4
> >>
> >>
> >> Author:Ryan Long
> >> Date:  Tue Mar  2 11:46:02 2021 -0500
> >>
> >> pwdgrp.c: Fix Unchecked return value from library (CID #1255518)
> >>
> >> CID 1255518: Unchecked return value from library in pwdgrp_init().
> >>
> >> Closes #4282
> >
> > I get an assertion in the tests with RTEMS_DEBUG enabled:
> >
> > test start: PWDGRP 1
> >
> > *** BEGIN OF TEST PWDGRP 1 ***
> >
> > *** TEST VERSION: 6.0.0.ca801609a7100804520809d1407174f465befee5
> >
> > *** TEST STATE: EXPECTED_PASS
> >
> > *** TEST BUILD: RTEMS_DEBUG RTEMS_NETWORKING RTEMS_POSIX_API
> >
> > *** TEST TOOLS: 10.2.1 20210315 (RTEMS 6, RSB
> > 62363ba982213588ef5d8bc8c4ff3acc28075f3f,
> > Newlib d10d0d9)
> >
> > assertion "(sc) == (0)" failed: file
> > "/home/EB/sebastian_h/src/rtems/cpukit/libcsupport/src/pwdgrp.c",
> > line 72, function: pwdgrp_init
>
> Also these tests:
>
>  test start: PSXPASSWD 2
>
>  *** BEGIN OF TEST PSXPASSWD 2 ***
>
>  *** TEST VERSION: 6.0.0.ca801609a7100804520809d1407174f465befee5
>
>  *** TEST STATE: EXPECTED_PASS
>
>  *** TEST BUILD: RTEMS_DEBUG RTEMS_NETWORKING RTEMS_POSIX_API
>
>  *** TEST TOOLS: 10.2.1 20210315 (RTEMS 6, RSB
> 62363ba982213588ef5d8bc8c4ff3acc28075f3f,
>  Newlib d10d0d9)
>
>  Init - Creating /etc
>
>  Init - Creating /etc/passwd
>
>  Init - Creating /etc/group
>
>  Init - setpwent() -- OK
>
>  assertion "(sc) == (0)" failed: file
> "/home/EB/sebastian_h/src/rtems/cpukit/libcsupport/src/pwdgrp.c",
>
>  line 72, function: pwdgrp_init
>
>
>  test start: SHELL 1
>
>  *** BEGIN OF TEST SHELL 1 ***
>
>  *** TEST VERSION: 6.0.0.ca801609a7100804520809d1407174f465befee5
>
>  *** TEST STATE: EXPECTED_PASS
>
>  *** TEST BUILD: RTEMS_DEBUG RTEMS_NETWORKING RTEMS_POSIX_API
>
>  *** TEST TOOLS: 10.2.1 20210315 (RTEMS 6, RSB
> 62363ba982213588ef5d8bc8c4ff3acc28075f3f,
>  Newlib d10d0d9)
>
>  assertion "(sc) == (0)" failed: file
> "/home/EB/sebastian_h/src/rtems/cpukit/libcsupport/src/pwdgrp.c",
>  line 72, function: pwdgrp_init
>
> --
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: All (18) RSB tool failures on rtems6 (details on m68k)

2021-03-16 Thread Sebastian Huber 

On 16/03/2021 15:19, Joel Sherrill wrote:



Anyway, everything is bad on track except for the known issues of
rtems-bsp-tester and mips on FreeBSD.
To build mips on FreeBSD you have to use the GNU sed. According to the 
GCC build instructions this is mandatory in general to build 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

[PATCH v3] covoar: Handle periods in symbols from objdump

2021-03-16 Thread Alex White 
Occasionally the compiler will generate symbols that look similar to
symbols defined in RTEMS code except that they contain some suffix.
These symbol suffixes are only found in the ELF symbol table; the
symbols appear to be normal in the DWARF info. This appears to be
happening on all architectures.

For example, the function _Message_queue_Create from rtems appears as
"_Message_queue_Create.part.0". Other suffixes include ".isra.0",
".constprop.0", and ".0".

This looks to be related to compiler optimizations. Symbols with
suffixes were being treated as unique. For our purposes, they should be
mapped to the equivalent symbols in the DWARF info. This has been
fixed.
---
 tester/covoar/ExecutableInfo.cc   | 22 +++---
 tester/covoar/ObjdumpProcessor.cc |  6 ++
 tester/covoar/SymbolTable.cc  | 12 +---
 3 files changed, 34 insertions(+), 6 deletions(-)

diff --git a/tester/covoar/ExecutableInfo.cc b/tester/covoar/ExecutableInfo.cc
index c996d75..9384973 100644
--- a/tester/covoar/ExecutableInfo.cc
+++ b/tester/covoar/ExecutableInfo.cc
@@ -118,8 +118,7 @@ namespace Coverage {
 // Obtain the coverage map containing the specified address.
 itsSymbol = theSymbolTable.getSymbol( address );
 if (itsSymbol != "") {
-  it = coverageMaps.find( itsSymbol );
-  aCoverageMap = (*it).second;
+  aCoverageMap = &findCoverageMap(itsSymbol);
 }
 
 return aCoverageMap;
@@ -150,8 +149,25 @@ namespace Coverage {
   )
   {
 CoverageMaps::iterator cmi = coverageMaps.find( symbolName );
-if ( cmi == coverageMaps.end() )
+if ( cmi != coverageMaps.end() ) {
+  return *(cmi->second);
+}
+
+size_t periodIndex = symbolName.find(".");
+
+if (periodIndex == std::string::npos) {
+  // Symbol name has no '.', can't do another lookup.
   throw CoverageMapNotFoundError(symbolName);
+}
+
+cmi = coverageMaps.find(
+  symbolName.substr(0, periodIndex)
+);
+
+if ( cmi == coverageMaps.end() ) {
+  throw CoverageMapNotFoundError(symbolName);
+}
+
 return *(cmi->second);
   }
 
diff --git a/tester/covoar/ObjdumpProcessor.cc 
b/tester/covoar/ObjdumpProcessor.cc
index fa9894d..544bfa1 100644
--- a/tester/covoar/ObjdumpProcessor.cc
+++ b/tester/covoar/ObjdumpProcessor.cc
@@ -417,6 +417,12 @@ namespace Coverage {
 processSymbol = false;
 theInstructions.clear();
 
+// Look for a '.' character and strip everything after it.
+char *periodIndex = strstr(symbol, ".");
+if (periodIndex != NULL) {
+  *periodIndex = 0;
+}
+
 // See if the new symbol is one that we care about.
 if (SymbolsToAnalyze->isDesired( symbol )) {
   currentSymbol = symbol;
diff --git a/tester/covoar/SymbolTable.cc b/tester/covoar/SymbolTable.cc
index 53bc8af..00062cc 100644
--- a/tester/covoar/SymbolTable.cc
+++ b/tester/covoar/SymbolTable.cc
@@ -46,12 +46,18 @@ namespace Coverage {
 symbolData.startingAddress = start;
 symbolData.length = length;
 
-if ( info[ symbol ].empty() == false ) {
-  if ( info[ symbol ].front().length != length ) {
+for (auto& symData : info[ symbol ]) {
+  // The starting address could differ since we strip any suffixes 
beginning
+  // with a '.'
+  if (symData.startingAddress != start) {
+continue;
+  }
+
+  if (symData.length != length) {
 std::ostringstream what;
 what << "Different lengths for the symbol "
  << symbol
- << " (" << info[ symbol ].front().length
+ << " (" << symData.length
  << " and " << length
  << ")";
 throw rld::error( what, "SymbolTable::addSymbol" );
-- 
2.27.0

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: All (18) RSB tool failures on rtems6 (details on m68k)

2021-03-16 Thread Sebastian Huber 

On 16/03/2021 15:23, Sebastian Huber wrote:


On 16/03/2021 15:19, Joel Sherrill wrote:



Anyway, everything is bad on track except for the known issues of
rtems-bsp-tester and mips on FreeBSD.
To build mips on FreeBSD you have to use the GNU sed. According to the 
GCC build instructions this is mandatory in general to build GCC.


Just for reference:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235293

--
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 v3] covoar: Handle periods in symbols from objdump

2021-03-16 Thread Joel Sherrill 
On Tue, Mar 16, 2021 at 9:25 AM Alex White  wrote:

> Occasionally the compiler will generate symbols that look similar to
> symbols defined in RTEMS code except that they contain some suffix.
> These symbol suffixes are only found in the ELF symbol table; the
> symbols appear to be normal in the DWARF info. This appears to be
> happening on all architectures.
>
> For example, the function _Message_queue_Create from rtems appears as
> "_Message_queue_Create.part.0". Other suffixes include ".isra.0",
> ".constprop.0", and ".0".
>
> This looks to be related to compiler optimizations. Symbols with
> suffixes were being treated as unique. For our purposes, they should be
> mapped to the equivalent symbols in the DWARF info. This has been
> fixed.
>

Everything Alex said is correct. It appears to be related to the compiler
optimizing and moving a section of a method "out of line". I suspect it
could
be that it is moving an alternate path ahead of the code generated for the
entry point to improve some straight execution path through the method.

Perhaps Alex can point to a BSP and test exe for an example.
But they definitely were there and looked like GCC had split the method
into different pieces and at least one had an address before the method
entry point. He never showed me a method split into more than one piece
but given they ended with a number, that seems likely.

--joel


> ---
>  tester/covoar/ExecutableInfo.cc   | 22 +++---
>  tester/covoar/ObjdumpProcessor.cc |  6 ++
>  tester/covoar/SymbolTable.cc  | 12 +---
>  3 files changed, 34 insertions(+), 6 deletions(-)
>
> diff --git a/tester/covoar/ExecutableInfo.cc
> b/tester/covoar/ExecutableInfo.cc
> index c996d75..9384973 100644
> --- a/tester/covoar/ExecutableInfo.cc
> +++ b/tester/covoar/ExecutableInfo.cc
> @@ -118,8 +118,7 @@ namespace Coverage {
>  // Obtain the coverage map containing the specified address.
>  itsSymbol = theSymbolTable.getSymbol( address );
>  if (itsSymbol != "") {
> -  it = coverageMaps.find( itsSymbol );
> -  aCoverageMap = (*it).second;
> +  aCoverageMap = &findCoverageMap(itsSymbol);
>  }
>
>  return aCoverageMap;
> @@ -150,8 +149,25 @@ namespace Coverage {
>)
>{
>  CoverageMaps::iterator cmi = coverageMaps.find( symbolName );
> -if ( cmi == coverageMaps.end() )
> +if ( cmi != coverageMaps.end() ) {
> +  return *(cmi->second);
> +}
> +
> +size_t periodIndex = symbolName.find(".");
> +
> +if (periodIndex == std::string::npos) {
> +  // Symbol name has no '.', can't do another lookup.
>throw CoverageMapNotFoundError(symbolName);
> +}
> +
> +cmi = coverageMaps.find(
> +  symbolName.substr(0, periodIndex)
> +);
> +
> +if ( cmi == coverageMaps.end() ) {
> +  throw CoverageMapNotFoundError(symbolName);
> +}
> +
>  return *(cmi->second);
>}
>
> diff --git a/tester/covoar/ObjdumpProcessor.cc
> b/tester/covoar/ObjdumpProcessor.cc
> index fa9894d..544bfa1 100644
> --- a/tester/covoar/ObjdumpProcessor.cc
> +++ b/tester/covoar/ObjdumpProcessor.cc
> @@ -417,6 +417,12 @@ namespace Coverage {
>  processSymbol = false;
>  theInstructions.clear();
>
> +// Look for a '.' character and strip everything after it.
> +char *periodIndex = strstr(symbol, ".");
> +if (periodIndex != NULL) {
> +  *periodIndex = 0;
> +}
> +
>  // See if the new symbol is one that we care about.
>  if (SymbolsToAnalyze->isDesired( symbol )) {
>currentSymbol = symbol;
> diff --git a/tester/covoar/SymbolTable.cc b/tester/covoar/SymbolTable.cc
> index 53bc8af..00062cc 100644
> --- a/tester/covoar/SymbolTable.cc
> +++ b/tester/covoar/SymbolTable.cc
> @@ -46,12 +46,18 @@ namespace Coverage {
>  symbolData.startingAddress = start;
>  symbolData.length = length;
>
> -if ( info[ symbol ].empty() == false ) {
> -  if ( info[ symbol ].front().length != length ) {
> +for (auto& symData : info[ symbol ]) {
> +  // The starting address could differ since we strip any suffixes
> beginning
> +  // with a '.'
> +  if (symData.startingAddress != start) {
> +continue;
> +  }
> +
> +  if (symData.length != length) {
>  std::ostringstream what;
>  what << "Different lengths for the symbol "
>   << symbol
> - << " (" << info[ symbol ].front().length
> + << " (" << symData.length
>   << " and " << length
>   << ")";
>  throw rld::error( what, "SymbolTable::addSymbol" );
> --
> 2.27.0
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: All (18) RSB tool failures on rtems6 (details on m68k)

2021-03-16 Thread Joel Sherrill 
On Tue, Mar 16, 2021 at 9:39 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 16/03/2021 15:23, Sebastian Huber wrote:
>
> > On 16/03/2021 15:19, Joel Sherrill wrote:
> >
> >>
> >> Anyway, everything is bad on track except for the known issues of
> >> rtems-bsp-tester and mips on FreeBSD.
> > To build mips on FreeBSD you have to use the GNU sed. According to the
> > GCC build instructions this is mandatory in general to build GCC.
>
> Just for reference:
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235293


Do you just have it in /usr/local and put that at the head of your PATH or
is
there some other step?

--joel

>
>
> --
> 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: All (18) RSB tool failures on rtems6 (details on m68k)

2021-03-16 Thread Sebastian Huber 

On 16/03/2021 15:59, Joel Sherrill wrote:




On Tue, Mar 16, 2021 at 9:39 AM Sebastian Huber 
> wrote:


On 16/03/2021 15:23, Sebastian Huber wrote:

> On 16/03/2021 15:19, Joel Sherrill wrote:
>
>>
>> Anyway, everything is bad on track except for the known issues of
>> rtems-bsp-tester and mips on FreeBSD.
> To build mips on FreeBSD you have to use the GNU sed. According
to the
> GCC build instructions this is mandatory in general to build GCC.

Just for reference:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235293



Do you just have it in /usr/local and put that at the head of your 
PATH or is

there some other step?

I installed it to $HOME/bin and added it to $PATH.

--
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 v3] covoar: Handle periods in symbols from objdump

2021-03-16 Thread Alex White 
I’m not sure if I have seen an example of method split into more than one 
piece. It has been a while since I made this fix.

A specific test executable that shows the suffixes is 
testsuites/libtests/block08.exe, but most (if not all) of them should have 
symbols like this from what I can tell.

I found a good explanation of this directly in the GCC source here:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/ipa-split.c;h=5e918ee3fbf6a86bd7fbfab6293f90c146b74977;hb=HEAD

Alex

From: Joel Sherrill 
Sent: Tuesday, March 16, 2021 9:53 AM
To: Alex White 
Cc: rtems-de...@rtems.org 
Subject: Re: [PATCH v3] covoar: Handle periods in symbols from objdump



On Tue, Mar 16, 2021 at 9:25 AM Alex White 
mailto:alex.wh...@oarcorp.com>> wrote:
Occasionally the compiler will generate symbols that look similar to
symbols defined in RTEMS code except that they contain some suffix.
These symbol suffixes are only found in the ELF symbol table; the
symbols appear to be normal in the DWARF info. This appears to be
happening on all architectures.

For example, the function _Message_queue_Create from rtems appears as
"_Message_queue_Create.part.0". Other suffixes include ".isra.0",
".constprop.0", and ".0".

This looks to be related to compiler optimizations. Symbols with
suffixes were being treated as unique. For our purposes, they should be
mapped to the equivalent symbols in the DWARF info. This has been
fixed.

Everything Alex said is correct. It appears to be related to the compiler
optimizing and moving a section of a method "out of line". I suspect it could
be that it is moving an alternate path ahead of the code generated for the
entry point to improve some straight execution path through the method.

Perhaps Alex can point to a BSP and test exe for an example.
But they definitely were there and looked like GCC had split the method
into different pieces and at least one had an address before the method
entry point. He never showed me a method split into more than one piece
but given they ended with a number, that seems likely.

--joel

---
 tester/covoar/ExecutableInfo.cc   | 22 +++---
 tester/covoar/ObjdumpProcessor.cc |  6 ++
 tester/covoar/SymbolTable.cc  | 12 +---
 3 files changed, 34 insertions(+), 6 deletions(-)

diff --git a/tester/covoar/ExecutableInfo.cc b/tester/covoar/ExecutableInfo.cc
index c996d75..9384973 100644
--- a/tester/covoar/ExecutableInfo.cc
+++ b/tester/covoar/ExecutableInfo.cc
@@ -118,8 +118,7 @@ namespace Coverage {
 // Obtain the coverage map containing the specified address.
 itsSymbol = theSymbolTable.getSymbol( address );
 if (itsSymbol != "") {
-  it = coverageMaps.find( itsSymbol );
-  aCoverageMap = (*it).second;
+  aCoverageMap = &findCoverageMap(itsSymbol);
 }

 return aCoverageMap;
@@ -150,8 +149,25 @@ namespace Coverage {
   )
   {
 CoverageMaps::iterator cmi = coverageMaps.find( symbolName );
-if ( cmi == coverageMaps.end() )
+if ( cmi != coverageMaps.end() ) {
+  return *(cmi->second);
+}
+
+size_t periodIndex = symbolName.find(".");
+
+if (periodIndex == std::string::npos) {
+  // Symbol name has no '.', can't do another lookup.
   throw CoverageMapNotFoundError(symbolName);
+}
+
+cmi = coverageMaps.find(
+  symbolName.substr(0, periodIndex)
+);
+
+if ( cmi == coverageMaps.end() ) {
+  throw CoverageMapNotFoundError(symbolName);
+}
+
 return *(cmi->second);
   }

diff --git a/tester/covoar/ObjdumpProcessor.cc 
b/tester/covoar/ObjdumpProcessor.cc
index fa9894d..544bfa1 100644
--- a/tester/covoar/ObjdumpProcessor.cc
+++ b/tester/covoar/ObjdumpProcessor.cc
@@ -417,6 +417,12 @@ namespace Coverage {
 processSymbol = false;
 theInstructions.clear();

+// Look for a '.' character and strip everything after it.
+char *periodIndex = strstr(symbol, ".");
+if (periodIndex != NULL) {
+  *periodIndex = 0;
+}
+
 // See if the new symbol is one that we care about.
 if (SymbolsToAnalyze->isDesired( symbol )) {
   currentSymbol = symbol;
diff --git a/tester/covoar/SymbolTable.cc b/tester/covoar/SymbolTable.cc
index 53bc8af..00062cc 100644
--- a/tester/covoar/SymbolTable.cc
+++ b/tester/covoar/SymbolTable.cc
@@ -46,12 +46,18 @@ namespace Coverage {
 symbolData.startingAddress = start;
 symbolData.length = length;

-if ( info[ symbol ].empty() == false ) {
-  if ( info[ symbol ].front().length != length ) {
+for (auto& symData : info[ symbol ]) {
+  // The starting address could differ since we strip any suffixes 
beginning
+  // with a '.'
+  if (symData.startingAddress != start) {
+continue;
+  }
+
+  if (symData.length != length) {
 std::ostringstream what;
 what << "Different lengths for the symbol "
  << symbol
- << " (" << info[ symbol ].front().length
+ << " (" << symData.length

Re: [PATCH 2/5] rtems-fdt.c: Fix Resource leak (CID #1437645)

2021-03-16 Thread Gedare Bloom 
On Tue, Mar 16, 2021 at 1:15 AM Niteesh G. S.  wrote:
>
>
>
> On Tue, 16 Mar 2021, 1:37 am Gedare Bloom,  wrote:
>>
>> This one looks ok to me, Niteesh?
>
> +1
>
> The below question is not related to this patch.
>
> Out of interest, I started going through the code  and I am a bit confused in 
> the following statement
>
> https://git.rtems.org/rtems/tree/cpukit/libmisc/rtems-fdt/rtems-fdt.c#n574
>
> This else block is reached when the FDT blob is not compressed, in this case 
> the size variable is set to the file size since this is raw data.
>
> In the while loop, we are looping on size, but we never modify the size. I 
> think, line 583 should be
> size -= r;
> Instead of
> r -= size;
> Is this a bug??
> Or am I missing something?
>

it looks weird to me too. Chris?

> PS: I am really sorry, If the formatting looks off I wrote this mail using my 
> mobile.
>
> Thanks
> Niteesh
>
>>
>> On Fri, Mar 12, 2021 at 8:19 AM Ryan Long  wrote:
>> >
>> > CID 1437645: Resource leak in rtems_fdt_load().
>> >
>> > Closes #4297
>> > ---
>> >  cpukit/libmisc/rtems-fdt/rtems-fdt.c | 1 +
>> >  1 file changed, 1 insertion(+)
>> >
>> > diff --git a/cpukit/libmisc/rtems-fdt/rtems-fdt.c 
>> > b/cpukit/libmisc/rtems-fdt/rtems-fdt.c
>> > index 0ea3653..5bb7ce0 100644
>> > --- a/cpukit/libmisc/rtems-fdt/rtems-fdt.c
>> > +++ b/cpukit/libmisc/rtems-fdt/rtems-fdt.c
>> > @@ -611,6 +611,7 @@ rtems_fdt_load (const char* filename, 
>> > rtems_fdt_handle* handle)
>> >  return fe;
>> >}
>> >
>> > +  close (bf);
>> >return 0;
>> >  }
>> >
>> > --
>> > 1.8.3.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

Re: [PATCH 6/6] rtems-docs: Edit commands to build first app

2021-03-16 Thread Gedare Bloom 
$ cd rtems-docs
$ grep -r "Creating a Patch" --exclude-dir=build
eng/vc-users.rts:Creating a Patch

On Tue, Mar 16, 2021 at 2:28 AM Ida Delphine  wrote:
>
> Regarding the patch to add instructions on how to set up a  patch message in 
> which file should I create this patch or make changes?
>
> On Mon, Mar 15, 2021 at 8:57 PM Gedare Bloom  wrote:
>>
>> Hi Ida,
>>
>> On Mon, Mar 15, 2021 at 1:50 PM Gedare Bloom  wrote:
>> >
>> > Hi Ida,
>> >
>> > did you send the same set of patches twice, or are there changes
>> > between the two sets?
>> >
>>
>> Since I'm not quite sure what to look at here, please do me a favor
>> and send a new patchset with a -v2 indicator [1], and also set the
>> patch message to specify rtems-docs. git format patch supports to set
>> the prefix with:
>>  git format-patch HEAD^ --subject-prefix="PATCH rtems-docs"
>> You can also create an alias to make this simpler [2]. In fact, if you
>> can send a patch to add instructions how to set up patch message with
>> the repo name to the text at [1] that would be another nice
>> contribution :)
>>
>> [1] https://docs.rtems.org/branches/master/eng/vc-users.html#creating-a-patch
>> [2] https://lists.rtems.org/pipermail/devel/2020-April/059308.html
>>
>> Thank you,
>> Gedare
>>
>> > On Sun, Mar 14, 2021 at 8:26 PM Ida Delphine  wrote:
>> > >
>> > > ---
>> > >  user/start/app.rst | 104 ++---
>> > >  1 file changed, 52 insertions(+), 52 deletions(-)
>> > >
>> > > diff --git a/user/start/app.rst b/user/start/app.rst
>> > > index 8900f78..c343551 100644
>> > > --- a/user/start/app.rst
>> > > +++ b/user/start/app.rst
>> > > @@ -8,7 +8,7 @@ Build Your Application
>> > >  ==
>> > >
>> > >  You tested a BSP in the previous section.  We built the ``erc32`` BSP
>> > > -and it is installed under :file:`$HOME/quick-start/rtems/5`.
>> > > +and it is installed under :file:`$HOME/quick-start/rtems/6`.
>> > >
>> > >  We will now create a simple Hello World application with a Git
>> > >  repository and using the `Waf `_ build system.
>> > > @@ -107,7 +107,7 @@ and copy the Waf script:
>> > >  #
>> > >  from __future__ import print_function
>> > >
>> > > -rtems_version = "5"
>> > > +rtems_version = "6"
>> > >
>> > >  try:
>> > >  import rtems_waf.rtems as rtems
>> > > @@ -142,52 +142,52 @@ Configure the application using Waf's 
>> > > ``configure`` command:
>> > >
>> > >  .. code-block:: none
>> > >
>> > > -./waf configure --rtems=$HOME/quick-start/rtems/5 
>> > > --rtems-bsp=sparc/erc32
>> > > +./waf configure --rtems=$HOME/quick-start/rtems/6 
>> > > --rtems-bsp=sparc/erc32 --rtems-version=6
>> > >
>> > >  The output will be something close to:
>> > >
>> > >  .. code-block:: none
>> > >
>> > > - Setting top to   : $BASE/app/hello
>> > > - Setting out to   : $BASE/app/hello/build
>> > > - RTEMS Version: 5
>> > > - Architectures: sparc-rtems5
>> > > - Board Support Package (BSP)  : sparc-rtems5-erc32
>> > > - Show commands: no
>> > > - Long commands: no
>> > > - Checking for program 'sparc-rtems5-gcc'  : 
>> > > $BASE/rtems/5/bin/sparc-rtems5-gcc
>> > > - Checking for program 'sparc-rtems5-g++'  : 
>> > > $BASE/rtems/5/bin/sparc-rtems5-g++
>> > > - Checking for program 'sparc-rtems5-gcc'  : 
>> > > $BASE/rtems/5/bin/sparc-rtems5-gcc
>> > > - Checking for program 'sparc-rtems5-ld'   : 
>> > > $BASE/rtems/5/bin/sparc-rtems5-ld
>> > > - Checking for program 'sparc-rtems5-ar'   : 
>> > > $BASE/rtems/5/bin/sparc-rtems5-ar
>> > > - Checking for program 'sparc-rtems5-nm'   : 
>> > > $BASE/rtems/5/bin/sparc-rtems5-nm
>> > > - Checking for program 'sparc-rtems5-objdump' : 
>> > > $BASE/rtems/5/bin/sparc-rtems5-objdump
>> > > - Checking for program 'sparc-rtems5-objcopy' : 
>> > > $BASE/rtems/5/bin/sparc-rtems5-objcopy
>> > > - Checking for program 'sparc-rtems5-readelf' : 
>> > > $BASE/rtems/5/bin/sparc-rtems5-readelf
>> > > - Checking for program 'sparc-rtems5-strip'   : 
>> > > $BASE/rtems/5/bin/sparc-rtems5-strip
>> > > - Checking for program 'sparc-rtems5-ranlib'  : 
>> > > $BASE/rtems/5/bin/sparc-rtems5-ranlib
>> > > - Checking for program 'rtems-ld' : 
>> > > $BASE/rtems/5/bin/rtems-ld
>> > > - Checking for program 'rtems-tld': 
>> > > $BASE/rtems/5/bin/rtems-tld
>> > > - Checking for program 'rtems-syms'   : 
>> > > $BASE/rtems/5/bin/rtems-syms
>> > > - Checking for program 'rtems-bin2c'  : 
>> > > $BASE/rtems/5/bin/rtems-bin2c
>> > > - Checking for program 'tar'  : /usr/bin/tar
>> > > - Checking for program 'gcc, cc'  : 
>> > > $BASE/rtems/5/bin/sparc-rtems5-gcc
>> > > - Checking for program 'ar'   :

Re: [PATCH v3] covoar: Handle periods in symbols from objdump

2021-03-16 Thread Gedare Bloom 
On Tue, Mar 16, 2021 at 8:25 AM Alex White  wrote:
>
> Occasionally the compiler will generate symbols that look similar to
> symbols defined in RTEMS code except that they contain some suffix.
> These symbol suffixes are only found in the ELF symbol table; the
> symbols appear to be normal in the DWARF info. This appears to be
> happening on all architectures.
>
> For example, the function _Message_queue_Create from rtems appears as
> "_Message_queue_Create.part.0". Other suffixes include ".isra.0",
> ".constprop.0", and ".0".
>

Do any non-compiler-generated symbols include "."?

Are there symbols that start with a "." that might be caught? I know
we do this in assembly programming often, e.g., ".vectors", although
probably it is unlikely to appear in C/asm I just want to be thorough.

> This looks to be related to compiler optimizations. Symbols with
> suffixes were being treated as unique. For our purposes, they should be
> mapped to the equivalent symbols in the DWARF info. This has been
> fixed.
> ---
>  tester/covoar/ExecutableInfo.cc   | 22 +++---
>  tester/covoar/ObjdumpProcessor.cc |  6 ++
>  tester/covoar/SymbolTable.cc  | 12 +---
>  3 files changed, 34 insertions(+), 6 deletions(-)
>
> diff --git a/tester/covoar/ExecutableInfo.cc b/tester/covoar/ExecutableInfo.cc
> index c996d75..9384973 100644
> --- a/tester/covoar/ExecutableInfo.cc
> +++ b/tester/covoar/ExecutableInfo.cc
> @@ -118,8 +118,7 @@ namespace Coverage {
>  // Obtain the coverage map containing the specified address.
>  itsSymbol = theSymbolTable.getSymbol( address );
>  if (itsSymbol != "") {
> -  it = coverageMaps.find( itsSymbol );
> -  aCoverageMap = (*it).second;
> +  aCoverageMap = &findCoverageMap(itsSymbol);
>  }
>
>  return aCoverageMap;
> @@ -150,8 +149,25 @@ namespace Coverage {
>)
>{
>  CoverageMaps::iterator cmi = coverageMaps.find( symbolName );
> -if ( cmi == coverageMaps.end() )
> +if ( cmi != coverageMaps.end() ) {
> +  return *(cmi->second);
> +}
> +
> +size_t periodIndex = symbolName.find(".");
> +
> +if (periodIndex == std::string::npos) {
> +  // Symbol name has no '.', can't do another lookup.
>throw CoverageMapNotFoundError(symbolName);
> +}
> +
> +cmi = coverageMaps.find(
> +  symbolName.substr(0, periodIndex)
> +);
> +
> +if ( cmi == coverageMaps.end() ) {
> +  throw CoverageMapNotFoundError(symbolName);
> +}
> +
>  return *(cmi->second);
>}
>
> diff --git a/tester/covoar/ObjdumpProcessor.cc 
> b/tester/covoar/ObjdumpProcessor.cc
> index fa9894d..544bfa1 100644
> --- a/tester/covoar/ObjdumpProcessor.cc
> +++ b/tester/covoar/ObjdumpProcessor.cc
> @@ -417,6 +417,12 @@ namespace Coverage {
>  processSymbol = false;
>  theInstructions.clear();
>
> +// Look for a '.' character and strip everything after it.
> +char *periodIndex = strstr(symbol, ".");
> +if (periodIndex != NULL) {
> +  *periodIndex = 0;
> +}
> +
>  // See if the new symbol is one that we care about.
>  if (SymbolsToAnalyze->isDesired( symbol )) {
>currentSymbol = symbol;
> diff --git a/tester/covoar/SymbolTable.cc b/tester/covoar/SymbolTable.cc
> index 53bc8af..00062cc 100644
> --- a/tester/covoar/SymbolTable.cc
> +++ b/tester/covoar/SymbolTable.cc
> @@ -46,12 +46,18 @@ namespace Coverage {
>  symbolData.startingAddress = start;
>  symbolData.length = length;
>
> -if ( info[ symbol ].empty() == false ) {
> -  if ( info[ symbol ].front().length != length ) {
> +for (auto& symData : info[ symbol ]) {
> +  // The starting address could differ since we strip any suffixes 
> beginning
> +  // with a '.'
> +  if (symData.startingAddress != start) {
> +continue;
> +  }
> +
> +  if (symData.length != length) {
>  std::ostringstream what;
>  what << "Different lengths for the symbol "
>   << symbol
> - << " (" << info[ symbol ].front().length
> + << " (" << symData.length
>   << " and " << length
>   << ")";
>  throw rld::error( what, "SymbolTable::addSymbol" );
> --
> 2.27.0
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] RTEMS 5.2: rtems: Allow RTEMS_PRIORITY for MrsP semaphores

2021-03-16 Thread Gedare Bloom 
On Tue, Mar 16, 2021 at 8:01 AM Sebastian Huber
 wrote:
>
> In order to improve the compatibility of RTEMS 5.2 with future version
> of RTEMS which fixed #4346 allow MrsP semaphores to be created with

minor note, this "fixed #4346" might get picked up by the Trac hook,
I'm not sure.

Otherwise I think this is ok.

> RTEMS_PRIORITY.
>
> Close #4347.
> ---
>  cpukit/rtems/src/semcreate.c   | 7 ++-
>  testsuites/sptests/spmrsp01/init.c | 6 --
>  2 files changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/cpukit/rtems/src/semcreate.c b/cpukit/rtems/src/semcreate.c
> index b57b635d85..ea89800685 100644
> --- a/cpukit/rtems/src/semcreate.c
> +++ b/cpukit/rtems/src/semcreate.c
> @@ -92,9 +92,14 @@ rtems_status_code rtems_semaphore_create(
>) {
>  variant = SEMAPHORE_VARIANT_MUTEX_PRIORITY_CEILING;
>} else if (
> -mutex_with_protocol
> +( mutex_with_protocol & ~RTEMS_PRIORITY )
>== ( RTEMS_BINARY_SEMAPHORE | RTEMS_MULTIPROCESSOR_RESOURCE_SHARING )
>) {
> +/*
> + * In RTEMS 5.2 using RTEMS_FIFO and RTEMS_PRIORITY for MrsP semaphores 
> is
> + * allowed.  In RTEMS 6, RTEMS_PRIORITY is required for MrsP semaphores
> + * analogous to priority ceiling semaphores.
> + */
>  #if defined(RTEMS_SMP)
>  variant = SEMAPHORE_VARIANT_MRSP;
>  #else
> diff --git a/testsuites/sptests/spmrsp01/init.c 
> b/testsuites/sptests/spmrsp01/init.c
> index a5f645d534..801b679ec9 100644
> --- a/testsuites/sptests/spmrsp01/init.c
> +++ b/testsuites/sptests/spmrsp01/init.c
> @@ -70,12 +70,6 @@ static void test_mrsp_create_errors(void)
>| RTEMS_SIMPLE_BINARY_SEMAPHORE
>);
>
> -  create_not_defined(
> -RTEMS_MULTIPROCESSOR_RESOURCE_SHARING
> -  | RTEMS_BINARY_SEMAPHORE
> -  | RTEMS_PRIORITY
> -  );
> -
>create_not_defined(
>  RTEMS_MULTIPROCESSOR_RESOURCE_SHARING
>| RTEMS_INHERIT_PRIORITY
> --
> 2.26.2
>
> ___
> 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] Add configuration option for single processor applications

2021-03-16 Thread Richi Dubey 
This change sets the value of number of processor as 1 for a single processor 
application.
Useful when trying to run a single processor application on a multi processor 
scheduler.
---
 cpukit/include/rtems/confdefs/scheduler.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/cpukit/include/rtems/confdefs/scheduler.h 
b/cpukit/include/rtems/confdefs/scheduler.h
index 84ca810fd7..116b2aec87 100644
--- a/cpukit/include/rtems/confdefs/scheduler.h
+++ b/cpukit/include/rtems/confdefs/scheduler.h
@@ -45,6 +45,10 @@
 
 #include 
 
+#ifndef CONFIGURE_MAXIMUM_PROCESSORS
+  #define CONFIGURE_MAXIMUM_PROCESSORS 1
+#endif
+
 #if !defined(CONFIGURE_SCHEDULER_CBS) \
   && !defined(CONFIGURE_SCHEDULER_EDF) \
   && !defined(CONFIGURE_SCHEDULER_EDF_SMP) \
-- 
2.17.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 3/3] rtems: Improve semaphore create error checks

2021-03-16 Thread Gedare Bloom 
These 3 look good to me

On Tue, Mar 16, 2021 at 7:58 AM Sebastian Huber
 wrote:
>
> Do not mix checks for different error indicators (RTEMS_NOT_DEFINED and
> RTEMS_INVALID_NUMBER).  This simplifies the specification of
> rtems_semaphore_create().
> ---
>  cpukit/rtems/src/semcreate.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/cpukit/rtems/src/semcreate.c b/cpukit/rtems/src/semcreate.c
> index 0246c91bc9..b58ea0199f 100644
> --- a/cpukit/rtems/src/semcreate.c
> +++ b/cpukit/rtems/src/semcreate.c
> @@ -72,12 +72,6 @@ rtems_status_code rtems_semaphore_create(
>
>if ( maybe_global == RTEMS_COUNTING_SEMAPHORE ) {
>  variant = SEMAPHORE_VARIANT_COUNTING;
> -  } else if ( count > 1 ) {
> -/*
> - * The remaining variants are all binary semphores, thus reject an 
> invalid
> - * count value.
> - */
> -return RTEMS_INVALID_NUMBER;
>} else if ( maybe_global == RTEMS_SIMPLE_BINARY_SEMAPHORE ) {
>  variant = SEMAPHORE_VARIANT_SIMPLE_BINARY;
>} else if ( maybe_global == RTEMS_BINARY_SEMAPHORE ) {
> @@ -109,6 +103,10 @@ rtems_status_code rtems_semaphore_create(
>  return RTEMS_NOT_DEFINED;
>}
>
> +  if ( count > 1 && variant != SEMAPHORE_VARIANT_COUNTING ) {
> +return RTEMS_INVALID_NUMBER;
> +  }
> +
>the_semaphore = _Semaphore_Allocate();
>
>if ( !the_semaphore ) {
> --
> 2.26.2
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Add configuration option for single processor applications

2021-03-16 Thread Sebastian Huber 

On 16/03/2021 16:45, Richi Dubey wrote:


This change sets the value of number of processor as 1 for a single processor 
application.
Useful when trying to run a single processor application on a multi processor 
scheduler.
I think this patch is superfluous. In which scenario do you think it is 
necessary?


By default, exactly one processor is configured in all RTEMS build 
configurations.


See:

/* Ensure that _CONFIGURE_MAXIMUM_PROCESSORS > 1 only in SMP 
configurations */

#if defined(CONFIGURE_MAXIMUM_PROCESSORS) && defined(RTEMS_SMP)
  #define _CONFIGURE_MAXIMUM_PROCESSORS CONFIGURE_MAXIMUM_PROCESSORS
#else
  #define _CONFIGURE_MAXIMUM_PROCESSORS 1
#endif

--
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

Potential GSoC Project - Covoar Change C-isms to C++

2021-03-16 Thread Joel Sherrill 
Hi

I know GSoC students are looking for projects so I thought I would post
about a couple that have come up recently and don't have tickets and better
write ups.

The covoar tool in rtems-tools was originally written to use C style IO
(e.g. fprintf) instead of C++ streams and C style strings instead of
std::string.  This project is to convert all instances of those to C++.
Testing incrementally, careful review of output reports, and manual review
of changed error messages will be important to this being successful. Also
submitting focused patches will be a critical part of this. I suspect one
patch per file for each issue will be appropriate.

The person doing this will have to be able to run the test coverage
procedure.

As part of doing this, there may be other C-isms noticed which need to be
addressed.

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Potential GSoC Project(s) - Improve Test Coverage

2021-03-16 Thread Joel Sherrill 
  Hi

I know GSoC students are looking for projects so I thought I would post
about a couple that have come up recently and don't have tickets and better
write ups.

This likely can be done by multiple students and all code should be in C.
One must be able to run the RTEMS Test Suite and produce code coverage
reports by subsystem/directory. Example reports are at
https://ftp.rtems.org/pub/rtems/people/joel/coverage/coverage-2021-02-28/.
It is likely that the person doing this could focus on analysis of results
on a single architecture and a secondary for sanity checks and rely on core
developers to generate the reports on all architectures. Results should
improve across all similarly.

This project consists of analysing uncovered code ranges in the report,
determining why they are unexecuted by the test suite, and addressing that.
Most of the time this is done by adding new test cases but there are other
cases where the code can be refactored/reworked to improve testability or
the code is simply unneeded based on the RTEMS configuration (e.g.
profiling or SMP code when not built for that). I think there is a Wiki
page which could be brought over into the Software Engineering Guide with
more detailed guidance.

When identifying uncovered areas to work on, it is generally recommended to
focus on a particular subsystem picking methods which are unexecuted at all
first. Then work on larges uncovered range or the method/area with the most
uncovered code.

There are multiple code subsystems which have uncovered ranges. Work on
this is easy to partition so there are no conflicts or dependencies between
projects if that's how we organize it.

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-docs v2 3/6] rtems-docs: Edit command to install toolsuite

2021-03-16 Thread Gedare Bloom 
Hi Ida,

Since the patches now indicate rtems-docs, you don't need to include
that in the commit message. Instead, it is recommended to put the
manual directory name that is modified as the first part of the
commit, e.g., "user: bump version 5 to 6 in start/tools.rst"

More below:

On Tue, Mar 16, 2021 at 2:16 AM Ida Delphine  wrote:
>
> Edit edit sample output of tool suite installation.
> Edit command to check if C cross compiler works and sample output of this 
> command.
> ---
>  user/start/tools.rst | 26 +-
>  1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/user/start/tools.rst b/user/start/tools.rst
> index baa2387..9a915ab 100644
> --- a/user/start/tools.rst
> +++ b/user/start/tools.rst
> @@ -12,7 +12,7 @@ Install the Tool Suite
>
>  You have chosen an installation prefix, the BSP to build, the tool's
>  architecure and prepared the source for the RSB in the previous sections.  We
> -have chosen :file:`$HOME/quick-start/rtems/5` as the installation prefix, the
> +have chosen :file:`$HOME/quick-start/rtems/6` as the installation prefix, the
>  ``erc32`` BSP and the SPARC architecture name of ``sparc-rtems5``, and 
> unpacked
>  the RSB source in :file:`$HOME/quick-start/src`.
>
> @@ -25,7 +25,7 @@ Build and install the tool suite:
>  .. code-block:: none
>
>  cd $HOME/quick-start/src/rsb/rtems
> -../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/5 
> 5/rtems-sparc
> +../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6 
> 6/rtems-sparc
>
>  This command should output something like this (omitted lines are denoted by
>  ...). The build host appears as part of the name of the package being
> @@ -33,19 +33,19 @@ built. The name you see may vary depending on the host 
> you are using:
>
>  .. code-block:: none
>
> -RTEMS Source Builder - Set Builder, 5.1.0
> -Build Set: 5/rtems-sparc
> +RTEMS Source Builder - Set Builder, 6
> +Build Set: 6/rtems-sparc
>  ...
>  config: tools/rtems-binutils-2.34.cfg
> -package: sparc-rtems5-binutils-2.34-x86_64-freebsd12.1-1
> -building: sparc-rtems5-binutils-2.34-x86_64-freebsd12.1-1
> -sizes: sparc-rtems5-binutils-2.34-x86_64-freebsd12.1-1: 305.866MB 
> (installed: 29.966MB)
> -cleaning: sparc-rtems5-binutils-2.34-x86_64-freebsd12.1-1
> +package: sparc-rtems6=-binutils-2.34-x86_64-freebsd12.1-1
> +building: sparc-rtems6-binutils-2.34-x86_64-freebsd12.1-1
> +sizes: sparc-rtems6-binutils-2.34-x86_64-freebsd12.1-1: 305.866MB 
> (installed: 29.966MB)
> +cleaning: sparc-rtems6-binutils-2.34-x86_64-freebsd12.1-1
>  reporting: tools/rtems-binutils-2.34.cfg -> 
> sparc-rtems5-binutils-2.34-x86_64-freebsd12.1-1.txt
>  reporting: tools/rtems-binutils-2.34.cfg -> 
> sparc-rtems5-binutils-2.34-x86_64-freebsd12.1-1.xml
>  config: tools/rtems-gcc-7.5.0-newlib-fbaa096.cfg
> -package: sparc-rtems5-gcc-7.5.0-newlib-fbaa096-x86_64-freebsd12.1-1
> -building: sparc-rtems5-gcc-7.5.0-newlib-fbaa096-x86_64-freebsd12.1-1
> +package: sparc-rtems6-gcc-7.5.0-newlib-fbaa096-x86_64-freebsd12.1-1
> +building: sparc-rtems6-gcc-7.5.0-newlib-fbaa096-x86_64-freebsd12.1-1
>  
>  Build Sizes: usage: 5.684GB total: 1.112GB (sources: 143.803MB, patches: 
> 21.348KB, installed 995.188MB)
>  Build Set: Time 0:21:35.626294

Did you run the command and capture the sample output, or do you edit
the sample output manually?

It would be better to copy-paste the actual sample output. Making this
version change update automatic could be a nice small scripting
exercise.

> @@ -55,7 +55,7 @@ works with the following command:
>
>  .. code-block:: none
>
> -$HOME/quick-start/rtems/5/bin/sparc-rtems5-gcc --version
> +$HOME/quick-start/rtems/6/bin/sparc-rtems6-gcc --version
>
>  This command should output something like below.  The version informtion 
> helps
Unrelated, but can you fix this typo: information

>  you to identify the exact sources used to build the cross compiler of your
> @@ -69,8 +69,8 @@ source code used.
>
>  .. code-block:: none
>
> -sparc-rtems5-gcc (GCC) 7.5.0 20191114 (RTEMS 5, RSB 5.1.0, Newlib 
> fbaa096)
> -Copyright (C) 2017 Free Software Foundation, Inc.
> +sparc-rtems6-gcc (GCC) 10.2.1 20210309 (RTEMS 6, RSB 
> 5e449fb5c2cb6812a238f9f9764fd339cbbf05c2, Newlib d10d0d9)
> +Copyright (C) 2020 Free Software Foundation, Inc.
>  This is free software; see the source for copying conditions.  There is 
> NO
>  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
> PURPOSE.
>
> --
> 2.25.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

Re: [PATCH rtems-docs v2 3/6] rtems-docs: Edit command to install toolsuite

2021-03-16 Thread Ida Delphine 
I ran the commands and copied and pasted wherever there were mismatches
especially with respect to the version numbers.

Should I resend the patchset with a better commit message?

On Tue, 16 Mar 2021, 6:50 pm Gedare Bloom,  wrote:

> Hi Ida,
>
> Since the patches now indicate rtems-docs, you don't need to include
> that in the commit message. Instead, it is recommended to put the
> manual directory name that is modified as the first part of the
> commit, e.g., "user: bump version 5 to 6 in start/tools.rst"
>
> More below:
>
> On Tue, Mar 16, 2021 at 2:16 AM Ida Delphine  wrote:
> >
> > Edit edit sample output of tool suite installation.
> > Edit command to check if C cross compiler works and sample output of
> this command.
> > ---
> >  user/start/tools.rst | 26 +-
> >  1 file changed, 13 insertions(+), 13 deletions(-)
> >
> > diff --git a/user/start/tools.rst b/user/start/tools.rst
> > index baa2387..9a915ab 100644
> > --- a/user/start/tools.rst
> > +++ b/user/start/tools.rst
> > @@ -12,7 +12,7 @@ Install the Tool Suite
> >
> >  You have chosen an installation prefix, the BSP to build, the tool's
> >  architecure and prepared the source for the RSB in the previous
> sections.  We
> > -have chosen :file:`$HOME/quick-start/rtems/5` as the installation
> prefix, the
> > +have chosen :file:`$HOME/quick-start/rtems/6` as the installation
> prefix, the
> >  ``erc32`` BSP and the SPARC architecture name of ``sparc-rtems5``, and
> unpacked
> >  the RSB source in :file:`$HOME/quick-start/src`.
> >
> > @@ -25,7 +25,7 @@ Build and install the tool suite:
> >  .. code-block:: none
> >
> >  cd $HOME/quick-start/src/rsb/rtems
> > -../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/5
> 5/rtems-sparc
> > +../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6
> 6/rtems-sparc
> >
> >  This command should output something like this (omitted lines are
> denoted by
> >  ...). The build host appears as part of the name of the package being
> > @@ -33,19 +33,19 @@ built. The name you see may vary depending on the
> host you are using:
> >
> >  .. code-block:: none
> >
> > -RTEMS Source Builder - Set Builder, 5.1.0
> > -Build Set: 5/rtems-sparc
> > +RTEMS Source Builder - Set Builder, 6
> > +Build Set: 6/rtems-sparc
> >  ...
> >  config: tools/rtems-binutils-2.34.cfg
> > -package: sparc-rtems5-binutils-2.34-x86_64-freebsd12.1-1
> > -building: sparc-rtems5-binutils-2.34-x86_64-freebsd12.1-1
> > -sizes: sparc-rtems5-binutils-2.34-x86_64-freebsd12.1-1: 305.866MB
> (installed: 29.966MB)
> > -cleaning: sparc-rtems5-binutils-2.34-x86_64-freebsd12.1-1
> > +package: sparc-rtems6=-binutils-2.34-x86_64-freebsd12.1-1
> > +building: sparc-rtems6-binutils-2.34-x86_64-freebsd12.1-1
> > +sizes: sparc-rtems6-binutils-2.34-x86_64-freebsd12.1-1: 305.866MB
> (installed: 29.966MB)
> > +cleaning: sparc-rtems6-binutils-2.34-x86_64-freebsd12.1-1
> >  reporting: tools/rtems-binutils-2.34.cfg ->
> sparc-rtems5-binutils-2.34-x86_64-freebsd12.1-1.txt
> >  reporting: tools/rtems-binutils-2.34.cfg ->
> sparc-rtems5-binutils-2.34-x86_64-freebsd12.1-1.xml
> >  config: tools/rtems-gcc-7.5.0-newlib-fbaa096.cfg
> > -package: sparc-rtems5-gcc-7.5.0-newlib-fbaa096-x86_64-freebsd12.1-1
> > -building: sparc-rtems5-gcc-7.5.0-newlib-fbaa096-x86_64-freebsd12.1-1
> > +package: sparc-rtems6-gcc-7.5.0-newlib-fbaa096-x86_64-freebsd12.1-1
> > +building: sparc-rtems6-gcc-7.5.0-newlib-fbaa096-x86_64-freebsd12.1-1
> >  
> >  Build Sizes: usage: 5.684GB total: 1.112GB (sources: 143.803MB,
> patches: 21.348KB, installed 995.188MB)
> >  Build Set: Time 0:21:35.626294
>
> Did you run the command and capture the sample output, or do you edit
> the sample output manually?
>
> It would be better to copy-paste the actual sample output. Making this
> version change update automatic could be a nice small scripting
> exercise.
>
> > @@ -55,7 +55,7 @@ works with the following command:
> >
> >  .. code-block:: none
> >
> > -$HOME/quick-start/rtems/5/bin/sparc-rtems5-gcc --version
> > +$HOME/quick-start/rtems/6/bin/sparc-rtems6-gcc --version
> >
> >  This command should output something like below.  The version
> informtion helps
> Unrelated, but can you fix this typo: information
>
> >  you to identify the exact sources used to build the cross compiler of
> your
> > @@ -69,8 +69,8 @@ source code used.
> >
> >  .. code-block:: none
> >
> > -sparc-rtems5-gcc (GCC) 7.5.0 20191114 (RTEMS 5, RSB 5.1.0, Newlib
> fbaa096)
> > -Copyright (C) 2017 Free Software Foundation, Inc.
> > +sparc-rtems6-gcc (GCC) 10.2.1 20210309 (RTEMS 6, RSB
> 5e449fb5c2cb6812a238f9f9764fd339cbbf05c2, Newlib d10d0d9)
> > +Copyright (C) 2020 Free Software Foundation, Inc.
> >  This is free software; see the source for copying conditions.
> There is NO
> >  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURP

Re: [PATCH v3] covoar: Handle periods in symbols from objdump

2021-03-16 Thread Chris Johns 
On 17/3/21 2:05 am, Alex White wrote:
> I’m not sure if I have seen an example of method split into more than one 
> piece.
> It has been a while since I made this fix.
> 
> A specific test executable that shows the suffixes is
> testsuites/libtests/block08.exe, but most (if not all) of them should have
> symbols like this from what I can tell.
> 
> I found a good explanation of this directly in the GCC source here:
> 
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/ipa-split.c;h=5e918ee3fbf6a86bd7fbfab6293f90c146b74977;hb=HEAD
> 
> 

Thanks Alex, this is a good explanation of what is going on.

I have lost of the context of why covoar would like to strip the suffixes and
use only the base symbol name. Could you please explain why this is being done?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH rtems-docs] eng/vc-users: Set up patch message with repo name

2021-03-16 Thread Ida Delphine 
From: Meh Mbeh Ida Delphine 

Added instructions on how to set up a patch messahe with a repo name.

Author:Meh Mbeh Ida Delphine 
Date:  Tue Mar 16 19:11:23 2021 +0100
---
 eng/vc-users.rst | 8 
 1 file changed, 8 insertions(+)

diff --git a/eng/vc-users.rst b/eng/vc-users.rst
index 31de516..772019e 100644
--- a/eng/vc-users.rst
+++ b/eng/vc-users.rst
@@ -458,6 +458,14 @@ specify a version number for your patch, for example, use
 
 to indicate the second version of a patch, ``-v3`` for a third, and so forth.
 
+Also, in order to create a patch specifying the repo name in the patch 
message, 
+you should use the``--subject-prefix`` flag. For example, if contributing to 
+the rtems-docs repo, use
+
+.. code-block:: shell
+
+  git format-patch HEAD^ --subject-prefix="PATCH rtems-docs"
+
 Patches created using ``git format-patch`` are formatted so they can be emailed
 and rely on having Git configured with your name and email address, for example
 
-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/5] rtems-fdt.c: Fix Resource leak (CID #1437645)

2021-03-16 Thread Chris Johns 
On 17/3/21 2:14 am, Gedare Bloom wrote:
> On Tue, Mar 16, 2021 at 1:15 AM Niteesh G. S.  wrote:
>> On Tue, 16 Mar 2021, 1:37 am Gedare Bloom,  wrote:
>>>
>>> This one looks ok to me, Niteesh?
>>
>> +1
>>
>> The below question is not related to this patch.
>>
>> Out of interest, I started going through the code  and I am a bit confused 
>> in the following statement
>>
>> https://git.rtems.org/rtems/tree/cpukit/libmisc/rtems-fdt/rtems-fdt.c#n574
>>
>> This else block is reached when the FDT blob is not compressed, in this case 
>> the size variable is set to the file size since this is raw data.
>>
>> In the while loop, we are looping on size, but we never modify the size. I 
>> think, line 583 should be
>> size -= r;
>> Instead of
>> r -= size;
>> Is this a bug??
>> Or am I missing something?
>>
> 
> it looks weird to me too. Chris?
> 

That is a bug. Nice find.

The use case for this call has an FPGA bitfile and the compressed FDT file in a
single package.

Thanks
Chris

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-docs v2 3/6] rtems-docs: Edit command to install toolsuite

2021-03-16 Thread Gedare Bloom 
On Tue, Mar 16, 2021 at 12:16 PM Ida Delphine  wrote:
>
> I ran the commands and copied and pasted wherever there were mismatches 
> especially with respect to the version numbers.
>
OK, I noticed some inconsistencies and was wondering. It would be
better to provide the actual output for the entire snippets, see
further below what I noticed.

> Should I resend the patchset with a better commit message?
>
Yes. I think it would be better to also update the entire output
examples, and to separate them from the manual changes you make to the
version numbers. In other words, update the version numbers by hand
for some things, and update the console output examples separately.
You can put multiple changes together in one patch that are related,
for example you might just send one patch with all the console output
example updates.

> On Tue, 16 Mar 2021, 6:50 pm Gedare Bloom,  wrote:
>>
>> Hi Ida,
>>
>> Since the patches now indicate rtems-docs, you don't need to include
>> that in the commit message. Instead, it is recommended to put the
>> manual directory name that is modified as the first part of the
>> commit, e.g., "user: bump version 5 to 6 in start/tools.rst"
>>
>> More below:
>>
>> On Tue, Mar 16, 2021 at 2:16 AM Ida Delphine  wrote:
>> >
>> > Edit edit sample output of tool suite installation.
>> > Edit command to check if C cross compiler works and sample output of this 
>> > command.
>> > ---
>> >  user/start/tools.rst | 26 +-
>> >  1 file changed, 13 insertions(+), 13 deletions(-)
>> >
>> > diff --git a/user/start/tools.rst b/user/start/tools.rst
>> > index baa2387..9a915ab 100644
>> > --- a/user/start/tools.rst
>> > +++ b/user/start/tools.rst
>> > @@ -12,7 +12,7 @@ Install the Tool Suite
>> >
>> >  You have chosen an installation prefix, the BSP to build, the tool's
>> >  architecure and prepared the source for the RSB in the previous sections. 
>> >  We
unrelated, fix typo: architecture

>> > -have chosen :file:`$HOME/quick-start/rtems/5` as the installation prefix, 
>> > the
>> > +have chosen :file:`$HOME/quick-start/rtems/6` as the installation prefix, 
>> > the
>> >  ``erc32`` BSP and the SPARC architecture name of ``sparc-rtems5``, and 
>> > unpacked
>> >  the RSB source in :file:`$HOME/quick-start/src`.
>> >
>> > @@ -25,7 +25,7 @@ Build and install the tool suite:
>> >  .. code-block:: none
>> >
>> >  cd $HOME/quick-start/src/rsb/rtems
>> > -../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/5 
>> > 5/rtems-sparc
>> > +../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6 
>> > 6/rtems-sparc
>> >
>> >  This command should output something like this (omitted lines are denoted 
>> > by
>> >  ...). The build host appears as part of the name of the package being
>> > @@ -33,19 +33,19 @@ built. The name you see may vary depending on the host 
>> > you are using:
>> >
>> >  .. code-block:: none
>> >
>> > -RTEMS Source Builder - Set Builder, 5.1.0
>> > -Build Set: 5/rtems-sparc
>> > +RTEMS Source Builder - Set Builder, 6
>> > +Build Set: 6/rtems-sparc
>> >  ...
>> >  config: tools/rtems-binutils-2.34.cfg
>> > -package: sparc-rtems5-binutils-2.34-x86_64-freebsd12.1-1
>> > -building: sparc-rtems5-binutils-2.34-x86_64-freebsd12.1-1
>> > -sizes: sparc-rtems5-binutils-2.34-x86_64-freebsd12.1-1: 305.866MB 
>> > (installed: 29.966MB)
>> > -cleaning: sparc-rtems5-binutils-2.34-x86_64-freebsd12.1-1
>> > +package: sparc-rtems6=-binutils-2.34-x86_64-freebsd12.1-1

The = sign here is what got me thinking something odd is going on.
Please copy-paste the entire output/snippet you get, and update the
examples completely so that each snippet is self-consistent at least.

>> > +building: sparc-rtems6-binutils-2.34-x86_64-freebsd12.1-1
>> > +sizes: sparc-rtems6-binutils-2.34-x86_64-freebsd12.1-1: 305.866MB 
>> > (installed: 29.966MB)
>> > +cleaning: sparc-rtems6-binutils-2.34-x86_64-freebsd12.1-1
>> >  reporting: tools/rtems-binutils-2.34.cfg -> 
>> > sparc-rtems5-binutils-2.34-x86_64-freebsd12.1-1.txt
>> >  reporting: tools/rtems-binutils-2.34.cfg -> 
>> > sparc-rtems5-binutils-2.34-x86_64-freebsd12.1-1.xml
>> >  config: tools/rtems-gcc-7.5.0-newlib-fbaa096.cfg
>> > -package: sparc-rtems5-gcc-7.5.0-newlib-fbaa096-x86_64-freebsd12.1-1
>> > -building: sparc-rtems5-gcc-7.5.0-newlib-fbaa096-x86_64-freebsd12.1-1
>> > +package: sparc-rtems6-gcc-7.5.0-newlib-fbaa096-x86_64-freebsd12.1-1
>> > +building: sparc-rtems6-gcc-7.5.0-newlib-fbaa096-x86_64-freebsd12.1-1
>> >  
>> >  Build Sizes: usage: 5.684GB total: 1.112GB (sources: 143.803MB, 
>> > patches: 21.348KB, installed 995.188MB)
>> >  Build Set: Time 0:21:35.626294
>>
>> Did you run the command and capture the sample output, or do you edit
>> the sample output manually?
>>
>> It would be better to copy-paste the actual sample output. Making this
>> version change update automatic could be a nice small scriptin

Re: [PATCH rtems-docs] eng/vc-users: Set up patch message with repo name

2021-03-16 Thread Gedare Bloom 
Hi Ida,

I have built and checked the output, it looks good but I did make a
tiny change to remove HEAD^ with ... to be a bit non-specific, and
fixed a typo in your commit message. I would however like you to
confirm that you can build the docs :) as your next step, it is best
to confirm that patches you send build properly. Pull the updated repo
and build it to confirm you see your change properly made.

When I applied this patch, I got
warning: 2 lines add whitespace errors.
I have fixed those two lines where there was a whitespace character at
the end of the line. Although that is not such a big deal in the docs,
we prefer to avoid those trailing spaces in code. Keep that in mind.
Maybe someday we'll have a proper style checker to help ;)

Congratulations on your first contribution :)

Gedare

On Tue, Mar 16, 2021 at 12:31 PM Ida Delphine  wrote:
>
> From: Meh Mbeh Ida Delphine 
>
> Added instructions on how to set up a patch messahe with a repo name.
>
> Author:Meh Mbeh Ida Delphine 
> Date:  Tue Mar 16 19:11:23 2021 +0100
> ---
>  eng/vc-users.rst | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/eng/vc-users.rst b/eng/vc-users.rst
> index 31de516..772019e 100644
> --- a/eng/vc-users.rst
> +++ b/eng/vc-users.rst
> @@ -458,6 +458,14 @@ specify a version number for your patch, for example, use
>
>  to indicate the second version of a patch, ``-v3`` for a third, and so forth.
>
> +Also, in order to create a patch specifying the repo name in the patch 
> message,
> +you should use the``--subject-prefix`` flag. For example, if contributing to
> +the rtems-docs repo, use
> +
> +.. code-block:: shell
> +
> +  git format-patch HEAD^ --subject-prefix="PATCH rtems-docs"
> +
>  Patches created using ``git format-patch`` are formatted so they can be 
> emailed
>  and rely on having Git configured with your name and email address, for 
> example
>
> --
> 2.25.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

Re: [PATCH rtems-docs] eng/vc-users: Set up patch message with repo name

2021-03-16 Thread Ida Delphine 
Yay!!!
Thanks for the feedback. Will try building the docs.

On Tue, 16 Mar 2021, 8:08 pm Gedare Bloom,  wrote:

> Hi Ida,
>
> I have built and checked the output, it looks good but I did make a
> tiny change to remove HEAD^ with ... to be a bit non-specific, and
> fixed a typo in your commit message. I would however like you to
> confirm that you can build the docs :) as your next step, it is best
> to confirm that patches you send build properly. Pull the updated repo
> and build it to confirm you see your change properly made.
>
> When I applied this patch, I got
> warning: 2 lines add whitespace errors.
> I have fixed those two lines where there was a whitespace character at
> the end of the line. Although that is not such a big deal in the docs,
> we prefer to avoid those trailing spaces in code. Keep that in mind.
> Maybe someday we'll have a proper style checker to help ;)
>
> Congratulations on your first contribution :)
>
> Gedare
>
> On Tue, Mar 16, 2021 at 12:31 PM Ida Delphine  wrote:
> >
> > From: Meh Mbeh Ida Delphine 
> >
> > Added instructions on how to set up a patch messahe with a repo name.
> >
> > Author:Meh Mbeh Ida Delphine 
> > Date:  Tue Mar 16 19:11:23 2021 +0100
> > ---
> >  eng/vc-users.rst | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/eng/vc-users.rst b/eng/vc-users.rst
> > index 31de516..772019e 100644
> > --- a/eng/vc-users.rst
> > +++ b/eng/vc-users.rst
> > @@ -458,6 +458,14 @@ specify a version number for your patch, for
> example, use
> >
> >  to indicate the second version of a patch, ``-v3`` for a third, and so
> forth.
> >
> > +Also, in order to create a patch specifying the repo name in the patch
> message,
> > +you should use the``--subject-prefix`` flag. For example, if
> contributing to
> > +the rtems-docs repo, use
> > +
> > +.. code-block:: shell
> > +
> > +  git format-patch HEAD^ --subject-prefix="PATCH rtems-docs"
> > +
> >  Patches created using ``git format-patch`` are formatted so they can be
> emailed
> >  and rely on having Git configured with your name and email address, for
> example
> >
> > --
> > 2.25.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

RE: [PATCH v3] covoar: Handle periods in symbols from objdump

2021-03-16 Thread Alex White 
> I have lost of the context of why covoar would like to strip the suffixes and
> use only the base symbol name. Could you please explain why this is being
> done?

Sure. The symbol names in the DWARF info never contain these suffixes.

Covoar strips the suffixes while reading the objdump output so that the symbol 
names match those found in the DWARF info. This ensures that the proper 
coverage map is found when it looks up the symbol.

Your question prompted me to look back at my code and realize that my 
modification of ExecutableInfo::findCoverageMap() was unnecessary because I 
already modified ObjdumpProcessor::load() to always strip the symbol. The 
additional suffix handling code that I added to findCoverageMap() will never be 
run. If only I had done coverage analysis on the covoar tool itself...

Looks like I'll be sending a v4 of this patch. :)

Alex
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH v3] covoar: Handle periods in symbols from objdump

2021-03-16 Thread Alex White 
Assuming I'm sending a v4 of this patch out, should I add the explanation of 
the compiler-generated suffixes to the commit message or perhaps as a comment 
in the code?

Alex

> -Original Message-
> From: devel  On Behalf Of Alex White
> Sent: Tuesday, March 16, 2021 3:32 PM
> To: Chris Johns ; j...@rtems.org
> Cc: rtems-de...@rtems.org 
> Subject: RE: [PATCH v3] covoar: Handle periods in symbols from objdump
> 
> > I have lost of the context of why covoar would like to strip the
> > suffixes and use only the base symbol name. Could you please explain
> > why this is being done?
> 
> Sure. The symbol names in the DWARF info never contain these suffixes.
> 
> Covoar strips the suffixes while reading the objdump output so that the
> symbol names match those found in the DWARF info. This ensures that the
> proper coverage map is found when it looks up the symbol.
> 
> Your question prompted me to look back at my code and realize that my
> modification of ExecutableInfo::findCoverageMap() was unnecessary
> because I already modified ObjdumpProcessor::load() to always strip the
> symbol. The additional suffix handling code that I added to
> findCoverageMap() will never be run. If only I had done coverage analysis on
> the covoar tool itself...
> 
> Looks like I'll be sending a v4 of this patch. :)
> 
> Alex
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH v3] covoar: Handle periods in symbols from objdump

2021-03-16 Thread Alex White 
> Do any non-compiler-generated symbols include "."?

Yes, according to the output of nm:

$ i386-rtems6-nm build/i386/pc686/testsuites/libtests/block08.exe | grep " \."
0011bdd2 t .check_stack_switch

I don't think there are any function symbols that include ".", though.

> 
> Are there symbols that start with a "." that might be caught? I know we do
> this in assembly programming often, e.g., ".vectors", although probably it is
> unlikely to appear in C/asm I just want to be thorough.
> 

I didn't spot any when I looked:

$ grep -r "PUBLIC\s*(\." --exclude-dir=build

I guess it is possible, though. I'm not sure how I would properly handle it. 
Currently, covoar would just chop off everything after the ".", fail to find a 
coverage map, log an error, and move on.

Do we think that is good enough?

Alex
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v3] covoar: Handle periods in symbols from objdump

2021-03-16 Thread Joel Sherrill 
On Tue, Mar 16, 2021, 4:47 PM Alex White  wrote:

> > Do any non-compiler-generated symbols include "."?
>
> Yes, according to the output of nm:
>
> $ i386-rtems6-nm build/i386/pc686/testsuites/libtests/block08.exe | grep "
> \."
> 0011bdd2 t .check_stack_switch
>
> I don't think there are any function symbols that include ".", though.
>

I don't think including a dot is legal in any programming language we are
interested in. Holy qualified names in Ada use dot in fully qualified names
between the parts but that is mangled in the compiler.

>
> >
> > Are there symbols that start with a "." that might be caught? I know we
> do
> > this in assembly programming often, e.g., ".vectors", although probably
> it is
> > unlikely to appear in C/asm I just want to be thorough.
> >
>
> I didn't spot any when I looked:
>
> $ grep -r "PUBLIC\s*(\." --exclude-dir=build
>
> I guess it is possible, though. I'm not sure how I would properly handle
> it. Currently, covoar would just chop off everything after the ".", fail to
> find a coverage map, log an error, and move on.
>
> Do we think that is good enough?
>

Until we find a language where a user written method can have a dot in the
generated name. :)

>
> Alex
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v3] covoar: Handle periods in symbols from objdump

2021-03-16 Thread Chris Johns 
On 17/3/21 8:16 am, Alex White wrote:
> Assuming I'm sending a v4 of this patch out, should I add the explanation of 
> the compiler-generated suffixes to the commit message or perhaps as a comment 
> in the code?

Yes if you think it helps. In the end what you are doing makes the tool work and
this doco help maintain the code because we now know why it is being done.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v3] covoar: Handle periods in symbols from objdump

2021-03-16 Thread Chris Johns 
On 17/3/21 9:56 am, Joel Sherrill wrote:
> On Tue, Mar 16, 2021, 4:47 PM Alex White  > wrote:
> 
> > Do any non-compiler-generated symbols include "."?
> 
> Yes, according to the output of nm:
> 
> $ i386-rtems6-nm build/i386/pc686/testsuites/libtests/block08.exe | grep 
> " \."
> 0011bdd2 t .check_stack_switch
> 
> I don't think there are any function symbols that include ".", though.
> 
> I don't think including a dot is legal in any programming language we are
> interested in. Holy qualified names in Ada use dot in fully qualified names
> between the parts but that is mangled in the compiler.
> 
> > Are there symbols that start with a "." that might be caught? I know we 
> do
> > this in assembly programming often, e.g., ".vectors", although probably 
> it is
> > unlikely to appear in C/asm I just want to be thorough.
> >
> 
> I didn't spot any when I looked:
> 
> $ grep -r "PUBLIC\s*(\." --exclude-dir=build
> 
> I guess it is possible, though. I'm not sure how I would properly handle 
> it.
> Currently, covoar would just chop off everything after the ".", fail to 
> find
> a coverage map, log an error, and move on.
> 
> Do we think that is good enough?
> 
> Until we find a language where a user written method can have a dot in the
> generated name. :)

Do the asm symbols appear in the DWARF info? Could you search the DWARF and if
it fails check for a . in the symbol and if it does remove the suffix and try 
again?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v3] covoar: Handle periods in symbols from objdump

2021-03-16 Thread Joel Sherrill 
On Tue, Mar 16, 2021, 7:15 PM Chris Johns  wrote:

> On 17/3/21 8:16 am, Alex White wrote:
> > Assuming I'm sending a v4 of this patch out, should I add the
> explanation of the compiler-generated suffixes to the commit message or
> perhaps as a comment in the code?
>
> Yes if you think it helps. In the end what you are doing makes the tool
> work and
> this doco help maintain the code because we now know why it is being done.
>

Comment in the code is better. Git commit will not be seen if someone is
questioning it.

>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

About is_non_preempt_mode_supported

2021-03-16 Thread Richi Dubey 
Hi,

I am debugging tm19 running on Strong APA scheduler. It gives the following
error:
rtems_signal_catch FAILED -- expected (RTEMS_SUCCESSFUL) got
(RTEMS_NOT_IMPLEMENTED)

which is due to line 167
.
This arises because the variable is_non_preempt_mode_supported in
_Scheduler_Control of SMP Strong APA scheduler is set to false.

On further checking, I can see that almost all the SMP schedulers have this
variable set as false in cpukit/include/rtems/scheduler.h. Please let me
know why this is the case. What would I need to do to support non preempt
tasks in the Strong APA scheduler?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel