Re: [PATCH] cpukit/smp: Prevent premature thread dispatch

2021-09-16 Thread Sebastian Huber 

On 16/09/2021 22:50, Kinsey Moore wrote:

There is currently a narrow window between the CPU state being set to UP
and the dispatch disable flag being set. It is possible to perform a
cross-processor thread dispatch in this window which catches the CPU in
a state which is not actually fully ready for that type of thread
dispatch.

This moves the CPU state change to just before the CPU's first thread
dispatch and later than the dispatch disable flag change which closes
the window for the race condition.
---
  cpukit/score/src/threadstartmultitasking.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/cpukit/score/src/threadstartmultitasking.c 
b/cpukit/score/src/threadstartmultitasking.c
index 094a535394..0c0951a243 100644
--- a/cpukit/score/src/threadstartmultitasking.c
+++ b/cpukit/score/src/threadstartmultitasking.c
@@ -29,8 +29,6 @@ void _Thread_Start_multitasking( void )
Thread_Control  *heir;
  
  #if defined(RTEMS_SMP)

-  _Per_CPU_State_change( cpu_self, PER_CPU_STATE_UP );
-
/*
 * Threads begin execution in the _Thread_Handler() function.   This
 * function will set the thread dispatch disable level to zero.
@@ -44,6 +42,8 @@ void _Thread_Start_multitasking( void )
  
  #if defined(RTEMS_SMP)

_CPU_SMP_Prepare_start_multitasking();
+
+  _Per_CPU_State_change( cpu_self, PER_CPU_STATE_UP );
  #endif
  
  #if defined(_CPU_Start_multitasking)




For which branch is this patch? The code on the master is different.

Which scenario caused a problem here? I guess there is a second bug 
involved, since maskable interrupt should be disabled for this code 
path. How could there be a race condition?


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RSB

2021-09-16 Thread Chris Johns 
On 17/9/21 9:54 am, Joel Sherrill wrote:
> On Thu, Sep 16, 2021, 6:36 PM Chris Johns  > wrote:
> 
> On 16/9/21 10:59 pm, Joel Sherrill wrote:
> > On Wed, Sep 15, 2021 at 7:08 PM Chris Johns  > wrote:
> >> On 16/9/21 1:46 am, Joel Sherrill wrote:
> >>> On Tue, Sep 14, 2021 at 5:52 PM Chris Johns  > wrote:
>  On 15/9/21 4:49 am, Joel Sherrill wrote:
> >>> The issue I mentioned is that the same rtems-tools-@t...@-1.tar.bz2
> >>> is used for every architecture. Perhaps 
> rtems-tools-@ARCH@-@t...@-1.tar.bz2.
> >>> Then you can script building all architectures without renaming files.
> >>
> >> That implies the tools are arch specific and they are not. The tools
> should be
> >> tagged with the host arch details if we add anything.
> >
> > The issue is that the tarball name is wrong and the rtems-tools one
> rtems-tools,
> > binutils, gcc/newlib, and gdb. It includes EVERYTHING that is built
> > when you use 6/rtems-arm.
> 
> I am not surprised, maybe the staging changes may have effected the tar 
> naming?
> 
> If you wanted to select a parent which parent would be selected?
> 
> I don't mind everything being lumped together. Except for rtems-tools, it is 
> all
> an arm RTEMS tool chain which is why it never struck me that it was using the
> repo rtems-tools as the name.

I think separate is still the way to go. It should be an easy script to unpack
the pieces and make a single tarball.

> Maybe rtems-toolchain-CPU. Ideally rtems-tools would be separate.

The CPU has to be x86 etc. I am not comfortable with a target arch being mixed
in here.

> Maybe a variable to define the package name to override some default.

I think the naming needs to be consistent for the RSB. How it is deployed is
left to you and others to sort out.

> The current design packages at the config file level it gives you the 
> various
> pieces as a single block so you can packages them. A single tarball for 
> the top
> level would make it hard for someone to use to make packages that can be
> deployed.
> 
> For tools the name of the tarball needs to match the contents and it is 
> native.
> The fact each arch bset builds the same thing is a side effect of the 
> packaging
> being used. Adding the arch might create the impression each arch tools 
> package
> has to be kept separate.
> 
> > The automake tarball has automake and autoconf
> 
> I am not sure why this is happening. Maybe 2 tarballs should be created. 
> This
> stuff is a little more complicated because of the internal build stage. 
> Autoconf
> and automake cannot be cleanly relocated so in installers I have created 
> in the
> past I had the installer build the packages using the install prefix.
> 
> 
> This one isn't critical as we aren't using it going forward. This is an issue 
> on
> 5 and older.

> > The rtems-tools tarball has everything I listed above. Beyond
> > rtems-tools, binutils,
> > gcc/newlib, and gdb, I suppose it also includes sis or dtc on some
> > architectures.
> 
> Do you want the RSB to generate user accessible tar files that need no 
> further
> touching?
> 
> Ideally they shouldn't be named the same. I don't particularly care if they
> duplicate files. Packages would be nice not to duplicate since we should be 
> able
> to control that. 

If the contents is the same then they are the same and if an arch is added to
the name we end up with a new set of confusions. For example, can the separately
arch named rtems tool packages be installed and removed under the same prefix?
They can be installed but they cannot be removed. File systems do not reference
count.

> I'm already post processing to extract a common tarball. But the names and
> contents of the RSB generated tarballs don't accurately reflect the contents 
> and
> don't reflect the target CPU (or host). 

The issue appear is when you package for a distro. The install phase is easy and
things work but the removal is when things break. You install an arm package
then you install a powerpc package with bunches of common gcc, binutils files
plus rtems-tools and all still works. You then remove the powerpc package and
all the shared pieces are removed and the arm tools are now broken.

Here is the last set of packages we made as an example:

https://ftp.rtems.org/pub/rtems/archive/rpms/linux/4.11/centos/7/x86_64/

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

[PATCH v4] improve the format of error reporting on i386

2021-09-16 Thread zack leung 
Thread id is now a Hex value. formatting improved for hex values
Updates #4203
---
 cpukit/score/cpu/i386/cpu.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
index 77b7a7161c..0f17cf0148 100644
--- a/cpukit/score/cpu/i386/cpu.c
+++ b/cpukit/score/cpu/i386/cpu.c
@@ -215,16 +215,16 @@ void _CPU_Exception_frame_print (const
CPU_Exception_frame *ctx)
 {
   unsigned int faultAddr = 0;
   printk("--\n");
-  printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
PRId32 "\n",
+  printk("Exception %" PRIu32 " caught at PC 0x%" PRIx32 " by thread 0x%"
PRIx32 "\n",
  ctx->idtIndex,
  ctx->eip,
  _Thread_Executing->Object.id);
   printk("--\n");
   printk("Processor execution context at time of the fault was  :\n");
   printk("--\n");
-  printk(" EAX = %" PRIx32 "EBX = %" PRIx32 "ECX = %" PRIx32 "
EDX = %" PRIx32 "\n",
+  printk(" EAX = 0x%" PRIx32 "EBX = 0x%" PRIx32 "ECX = 0x%" PRIx32
"EDX = 0x%" PRIx32 "\n",
  ctx->eax, ctx->ebx, ctx->ecx, ctx->edx);
-  printk(" ESI = %" PRIx32 "EDI = %" PRIx32 "EBP = %" PRIx32 "
ESP = %" PRIx32 "\n",
+  printk(" ESI = 0x%" PRIx32 "EDI = 0x%" PRIx32 "EBP = 0x%" PRIx32
"ESP = 0x%" PRIx32 "\n",
  ctx->esi, ctx->edi, ctx->ebp, ctx->esp0);
   printk("--\n");
   printk("Error code pushed by processor itself (if not 0) = %" PRIx32
"\n",
-- 
2.33.0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RSB

2021-09-16 Thread Joel Sherrill 
On Thu, Sep 16, 2021, 6:36 PM Chris Johns  wrote:

> On 16/9/21 10:59 pm, Joel Sherrill wrote:
> > On Wed, Sep 15, 2021 at 7:08 PM Chris Johns  wrote:
> >> On 16/9/21 1:46 am, Joel Sherrill wrote:
> >>> On Tue, Sep 14, 2021 at 5:52 PM Chris Johns  wrote:
>  On 15/9/21 4:49 am, Joel Sherrill wrote:
> >>> The issue I mentioned is that the same rtems-tools-@t...@-1.tar.bz2
> >>> is used for every architecture. Perhaps rtems-tools-@ARCH@-@TAG@
> -1.tar.bz2.
> >>> Then you can script building all architectures without renaming files.
> >>
> >> That implies the tools are arch specific and they are not. The tools
> should be
> >> tagged with the host arch details if we add anything.
> >
> > The issue is that the tarball name is wrong and the rtems-tools one
> rtems-tools,
> > binutils, gcc/newlib, and gdb. It includes EVERYTHING that is built
> > when you use 6/rtems-arm.
>
> I am not surprised, maybe the staging changes may have effected the tar
> naming?
>
> If you wanted to select a parent which parent would be selected?
>

I don't mind everything being lumped together. Except for rtems-tools, it
is all an arm RTEMS tool chain which is why it never struck me that it was
using the repo rtems-tools as the name.

Maybe rtems-toolchain-CPU. Ideally rtems-tools would be separate.

Maybe a variable to define the package name to override some default.

>
> The current design packages at the config file level it gives you the
> various
> pieces as a single block so you can packages them. A single tarball for
> the top
> level would make it hard for someone to use to make packages that can be
> deployed.
>
> For tools the name of the tarball needs to match the contents and it is
> native.
> The fact each arch bset builds the same thing is a side effect of the
> packaging
> being used. Adding the arch might create the impression each arch tools
> package
> has to be kept separate.
>
> > The automake tarball has automake and autoconf
>
> I am not sure why this is happening. Maybe 2 tarballs should be created.
> This
> stuff is a little more complicated because of the internal build stage.
> Autoconf
> and automake cannot be cleanly relocated so in installers I have created
> in the
> past I had the installer build the packages using the install prefix.
>

This one isn't critical as we aren't using it going forward. This is an
issue on 5 and older.



> > The rtems-tools tarball has everything I listed above. Beyond
> > rtems-tools, binutils,
> > gcc/newlib, and gdb, I suppose it also includes sis or dtc on some
> > architectures.
>
> Do you want the RSB to generate user accessible tar files that need no
> further
> touching?
>

Ideally they shouldn't be named the same. I don't particularly care if they
duplicate files. Packages would be nice not to duplicate since we should be
able to control that.

I'm already post processing to extract a common tarball. But the names and
contents of the RSB generated tarballs don't accurately reflect the
contents and don't reflect the target CPU (or host).

>
> > If it used the name from the top level bset it might be ok. Then you
> would have
> > autotools and something derived from 6/rtems-arm
>
> Yeap.
>
> > I can send you lists of what is in each tarball if you like.
>
> No need, I have an OK idea of what is contained in the packages


> Ok


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

Re: [PATCH v4] improve the format of error reporting on i386

2021-09-16 Thread Chris Johns 
On 17/9/21 12:56 am, Gedare Bloom wrote:
> Although we are not currently filtering HTML on this mailing list

I turned it on for this list. Is it not working?

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

Re: RSB

2021-09-16 Thread Chris Johns 
On 16/9/21 10:59 pm, Joel Sherrill wrote:
> On Wed, Sep 15, 2021 at 7:08 PM Chris Johns  wrote:
>> On 16/9/21 1:46 am, Joel Sherrill wrote:
>>> On Tue, Sep 14, 2021 at 5:52 PM Chris Johns  wrote:
 On 15/9/21 4:49 am, Joel Sherrill wrote:
>>> The issue I mentioned is that the same rtems-tools-@t...@-1.tar.bz2
>>> is used for every architecture. Perhaps rtems-tools-@ARCH@-@t...@-1.tar.bz2.
>>> Then you can script building all architectures without renaming files.
>>
>> That implies the tools are arch specific and they are not. The tools should 
>> be
>> tagged with the host arch details if we add anything.
> 
> The issue is that the tarball name is wrong and the rtems-tools one 
> rtems-tools,
> binutils, gcc/newlib, and gdb. It includes EVERYTHING that is built
> when you use 6/rtems-arm.

I am not surprised, maybe the staging changes may have effected the tar naming?

If you wanted to select a parent which parent would be selected?

The current design packages at the config file level it gives you the various
pieces as a single block so you can packages them. A single tarball for the top
level would make it hard for someone to use to make packages that can be 
deployed.

For tools the name of the tarball needs to match the contents and it is native.
The fact each arch bset builds the same thing is a side effect of the packaging
being used. Adding the arch might create the impression each arch tools package
has to be kept separate.

> The automake tarball has automake and autoconf

I am not sure why this is happening. Maybe 2 tarballs should be created. This
stuff is a little more complicated because of the internal build stage. Autoconf
and automake cannot be cleanly relocated so in installers I have created in the
past I had the installer build the packages using the install prefix.

> The rtems-tools tarball has everything I listed above. Beyond
> rtems-tools, binutils,
> gcc/newlib, and gdb, I suppose it also includes sis or dtc on some
> architectures.

Do you want the RSB to generate user accessible tar files that need no further
touching?

> If it used the name from the top level bset it might be ok. Then you would 
> have
> autotools and something derived from 6/rtems-arm

Yeap.

> I can send you lists of what is in each tarball if you like.

No need, I have an OK idea of what is contained in the packages

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

Building rtems-kernel with RSB

2021-09-16 Thread Ryan Long 
Hi,

I'm trying to build rtems-kernel with the RSB. I haven't gotten it to work. I'm 
getting "Undefined reference to" errors for variables defined in tls.h 
(_TLS_Data_size, _TLS_Data_begin, etc.). I noticed that they are being defined 
in linkcmds.base in my bsp-install directory. The current command I'm using is

../source-builder/sb-set-builder \
--prefix=/home/rlong/rtems-work/bsp-install/arm-rtems6 \
-rtems-bsp=arm/xilinx_zynq_a9_qemu \
6/rtems-kernel

I'm not sure what argument needs the location of bsp-install (if it's needed). 
Can anyone help me out?

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

[PATCH] cpukit/smp: Prevent premature thread dispatch

2021-09-16 Thread Kinsey Moore 
There is currently a narrow window between the CPU state being set to UP
and the dispatch disable flag being set. It is possible to perform a
cross-processor thread dispatch in this window which catches the CPU in
a state which is not actually fully ready for that type of thread
dispatch.

This moves the CPU state change to just before the CPU's first thread
dispatch and later than the dispatch disable flag change which closes
the window for the race condition.
---
 cpukit/score/src/threadstartmultitasking.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/cpukit/score/src/threadstartmultitasking.c 
b/cpukit/score/src/threadstartmultitasking.c
index 094a535394..0c0951a243 100644
--- a/cpukit/score/src/threadstartmultitasking.c
+++ b/cpukit/score/src/threadstartmultitasking.c
@@ -29,8 +29,6 @@ void _Thread_Start_multitasking( void )
   Thread_Control  *heir;
 
 #if defined(RTEMS_SMP)
-  _Per_CPU_State_change( cpu_self, PER_CPU_STATE_UP );
-
   /*
* Threads begin execution in the _Thread_Handler() function.   This
* function will set the thread dispatch disable level to zero.
@@ -44,6 +42,8 @@ void _Thread_Start_multitasking( void )
 
 #if defined(RTEMS_SMP)
   _CPU_SMP_Prepare_start_multitasking();
+
+  _Per_CPU_State_change( cpu_self, PER_CPU_STATE_UP );
 #endif
 
 #if defined(_CPU_Start_multitasking)
-- 
2.30.2

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

[PATCH RSB v3] Remove automake/autoconf from rtems 6 tools

2021-09-16 Thread Joel Sherrill 
These are unneeded with the waf build system.

Closes #4081.
---
 rtems/config/6/rtems-autotools-base.bset |  9 -
 rtems/config/6/rtems-autotools-internal.bset | 11 ---
 rtems/config/6/rtems-autotools.bset  | 25 -
 rtems/config/6/rtems-default.bset|  2 --
 rtems/config/6/rtems-microblaze.bset |  2 --
 5 files changed, 49 deletions(-)
 delete mode 100644 rtems/config/6/rtems-autotools-base.bset
 delete mode 100644 rtems/config/6/rtems-autotools-internal.bset
 delete mode 100644 rtems/config/6/rtems-autotools.bset

diff --git a/rtems/config/6/rtems-autotools-base.bset 
b/rtems/config/6/rtems-autotools-base.bset
deleted file mode 100644
index c6819c1..000
--- a/rtems/config/6/rtems-autotools-base.bset
+++ /dev/null
@@ -1,9 +0,0 @@
-%define release 1
-%define rtems_arch none
-
-%include 6/rtems-base.bset
-
-package: rtems-%{rtems_version}-autotools-%{_host}-%{release}
-
-tools/rtems-autoconf-2.69-1
-tools/rtems-automake-1.12.6-1
diff --git a/rtems/config/6/rtems-autotools-internal.bset 
b/rtems/config/6/rtems-autotools-internal.bset
deleted file mode 100644
index 19d2f19..000
--- a/rtems/config/6/rtems-autotools-internal.bset
+++ /dev/null
@@ -1,11 +0,0 @@
-#
-# Do not use via the command line.
-#
-
-%define _internal_autotools yes
-%define _disable_collecting yes
-%define _disable_packaging  yes
-%define _disable_reporting  yes
-%define _disable_installing yes
-
-%include 6/rtems-autotools-base.bset
diff --git a/rtems/config/6/rtems-autotools.bset 
b/rtems/config/6/rtems-autotools.bset
deleted file mode 100644
index e57d25d..000
--- a/rtems/config/6/rtems-autotools.bset
+++ /dev/null
@@ -1,25 +0,0 @@
-#
-# Autoconf and automake are not relocatable and cannot be cross-compiled.
-# RTEMS uses autoconf and automake and building RTEMS in the RSB requires
-# bootstrapping and this requires a current autoconf and automake. The RSB
-# provides to support by:
-#
-#  1. Building and installing autoconf and automake with a prefix to a
-# temporary internal path.
-#  2. Using the temporary internal build, build and install another copy
-# using the final prefix location.
-#
-
-#
-# A magic internal path that would break if changes in the defaults.mc
-# macro file are made.
-#
-%define _internal_autotools_path %{_tmppath}/sb-%{_uid}/${SB_PREFIX_CLEAN}
-
-#
-# Disable emailing reports of this building for RTEMS.
-#
-%define mail_disable
-
-6/rtems-autotools-internal
-6/rtems-autotools-base
diff --git a/rtems/config/6/rtems-default.bset 
b/rtems/config/6/rtems-default.bset
index 1b60066..0c07b08 100644
--- a/rtems/config/6/rtems-default.bset
+++ b/rtems/config/6/rtems-default.bset
@@ -3,8 +3,6 @@
 #
 %include 6/rtems-base.bset
 
-6/rtems-autotools
-
 #
 # Build gdb first to raise the Python install error as early as possible.
 # GDB needs expat so it needs to be built before.
diff --git a/rtems/config/6/rtems-microblaze.bset 
b/rtems/config/6/rtems-microblaze.bset
index 4b12899..3eb7a89 100644
--- a/rtems/config/6/rtems-microblaze.bset
+++ b/rtems/config/6/rtems-microblaze.bset
@@ -6,8 +6,6 @@
 #
 %include 6/rtems-base.bset
 
-6/rtems-autotools
-
 devel/dtc-1.6.0-1
 
 #
-- 
1.8.3.1

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

Re: [PATCH RSB v2] Remove automake/autoconf from rtems 6 tools

2021-09-16 Thread Joel Sherrill 
On Thu, Sep 16, 2021 at 10:01 AM Gedare Bloom  wrote:
>
> On Thu, Sep 16, 2021 at 8:56 AM Joel Sherrill  wrote:
> >
> > These are unneeded with the waf build system.
> >
> > Closes #4081.
> > ---
> >  bare/config/devel/autotools-base.bset  |  9 -
> >  bare/config/devel/autotools-internal.bset  | 13 -
> >  bare/config/devel/autotools.bset   | 14 --
> Not these.

Sorry. Misunderstood.

> >  rtems/config/6/rtems-autotools-base.bset   |  9 -
> >  rtems/config/6/rtems-autotools-internal.bset   | 11 ---
> >  rtems/config/6/rtems-autotools.bset| 25 
> > -
> >  rtems/config/6/rtems-default.bset  |  2 --
> >  rtems/config/6/rtems-microblaze.bset   |  2 --
> Just these. The rtems-autotools* ones :)
>
> >  rtems/config/tools/rtems-autoconf-2.69-1.cfg   | 23 ---
> >  rtems/config/tools/rtems-automake-1.12.6-1.cfg | 23 ---
> I don't think these can be removed either, I think they're used for
> the gcc-cross build.

I'll leave them but they sound incorrectly named going forward. They will
no longer be "rtems-auto*" -- just auto* required to build something else.

> >  10 files changed, 131 deletions(-)
> >  delete mode 100644 bare/config/devel/autotools-base.bset
> >  delete mode 100644 bare/config/devel/autotools-internal.bset
> >  delete mode 100644 bare/config/devel/autotools.bset
> >  delete mode 100644 rtems/config/6/rtems-autotools-base.bset
> >  delete mode 100644 rtems/config/6/rtems-autotools-internal.bset
> >  delete mode 100644 rtems/config/6/rtems-autotools.bset
> >  delete mode 100644 rtems/config/tools/rtems-autoconf-2.69-1.cfg
> >  delete mode 100644 rtems/config/tools/rtems-automake-1.12.6-1.cfg
> >
> > diff --git a/bare/config/devel/autotools-base.bset 
> > b/bare/config/devel/autotools-base.bset
> > deleted file mode 100644
> > index 22456ed..000
> > --- a/bare/config/devel/autotools-base.bset
> > +++ /dev/null
> > @@ -1,9 +0,0 @@
> > -#
> > -# Build set for autoconf, automake, and libtools.
> > -#
> > -
> > -%define release 1
> > -
> > -devel/autoconf-2.69-1
> > -devel/automake-1.12.6-1
> > -devel/libtool-2.4.2-1
> > diff --git a/bare/config/devel/autotools-internal.bset 
> > b/bare/config/devel/autotools-internal.bset
> > deleted file mode 100644
> > index bad3890..000
> > --- a/bare/config/devel/autotools-internal.bset
> > +++ /dev/null
> > @@ -1,13 +0,0 @@
> > -#
> > -# Tools Set for Internal Autotools Stable
> > -#
> > -# Do not use via the command line.
> > -#
> > -
> > -%define _internal_autotools yes
> > -%define _disable_collecting yes
> > -%define _disable_packaging  yes
> > -%define _disable_reporting  yes
> > -%define _disable_installing yes
> > -
> > -%include devel/autotools-base.bset
> > diff --git a/bare/config/devel/autotools.bset 
> > b/bare/config/devel/autotools.bset
> > deleted file mode 100644
> > index 5fcafa4..000
> > --- a/bare/config/devel/autotools.bset
> > +++ /dev/null
> > @@ -1,14 +0,0 @@
> > -#
> > -# Build set for autoconf, automake, and libtools.
> > -#
> > -
> > -%define release 1
> > -
> > -#
> > -# A magic internal path that would break if changes in the defaults.mc
> > -# macro file are made.
> > -#
> > -%define _internal_autotools_path %{_tmppath}/sb-%{_uid}/${SB_PREFIX_CLEAN}
> > -
> > -devel/autotools-internal.bset
> > -devel/autotools-base.bset
> > diff --git a/rtems/config/6/rtems-autotools-base.bset 
> > b/rtems/config/6/rtems-autotools-base.bset
> > deleted file mode 100644
> > index c6819c1..000
> > --- a/rtems/config/6/rtems-autotools-base.bset
> > +++ /dev/null
> > @@ -1,9 +0,0 @@
> > -%define release 1
> > -%define rtems_arch none
> > -
> > -%include 6/rtems-base.bset
> > -
> > -package: rtems-%{rtems_version}-autotools-%{_host}-%{release}
> > -
> > -tools/rtems-autoconf-2.69-1
> > -tools/rtems-automake-1.12.6-1
> > diff --git a/rtems/config/6/rtems-autotools-internal.bset 
> > b/rtems/config/6/rtems-autotools-internal.bset
> > deleted file mode 100644
> > index 19d2f19..000
> > --- a/rtems/config/6/rtems-autotools-internal.bset
> > +++ /dev/null
> > @@ -1,11 +0,0 @@
> > -#
> > -# Do not use via the command line.
> > -#
> > -
> > -%define _internal_autotools yes
> > -%define _disable_collecting yes
> > -%define _disable_packaging  yes
> > -%define _disable_reporting  yes
> > -%define _disable_installing yes
> > -
> > -%include 6/rtems-autotools-base.bset
> > diff --git a/rtems/config/6/rtems-autotools.bset 
> > b/rtems/config/6/rtems-autotools.bset
> > deleted file mode 100644
> > index e57d25d..000
> > --- a/rtems/config/6/rtems-autotools.bset
> > +++ /dev/null
> > @@ -1,25 +0,0 @@
> > -#
> > -# Autoconf and automake are not relocatable and cannot be cross-compiled.
> > -# RTEMS uses autoconf and automake and building RTEMS in the RSB requires
> > -# bootstrapping and this requires a current autoconf and automake. The RSB
> > -# provides to support by:
> > -#
>

Re: [PATCH RSB v2] Remove automake/autoconf from rtems 6 tools

2021-09-16 Thread Gedare Bloom 
On Thu, Sep 16, 2021 at 8:56 AM Joel Sherrill  wrote:
>
> These are unneeded with the waf build system.
>
> Closes #4081.
> ---
>  bare/config/devel/autotools-base.bset  |  9 -
>  bare/config/devel/autotools-internal.bset  | 13 -
>  bare/config/devel/autotools.bset   | 14 --
Not these.

>  rtems/config/6/rtems-autotools-base.bset   |  9 -
>  rtems/config/6/rtems-autotools-internal.bset   | 11 ---
>  rtems/config/6/rtems-autotools.bset| 25 -
>  rtems/config/6/rtems-default.bset  |  2 --
>  rtems/config/6/rtems-microblaze.bset   |  2 --
Just these. The rtems-autotools* ones :)

>  rtems/config/tools/rtems-autoconf-2.69-1.cfg   | 23 ---
>  rtems/config/tools/rtems-automake-1.12.6-1.cfg | 23 ---
I don't think these can be removed either, I think they're used for
the gcc-cross build.

>  10 files changed, 131 deletions(-)
>  delete mode 100644 bare/config/devel/autotools-base.bset
>  delete mode 100644 bare/config/devel/autotools-internal.bset
>  delete mode 100644 bare/config/devel/autotools.bset
>  delete mode 100644 rtems/config/6/rtems-autotools-base.bset
>  delete mode 100644 rtems/config/6/rtems-autotools-internal.bset
>  delete mode 100644 rtems/config/6/rtems-autotools.bset
>  delete mode 100644 rtems/config/tools/rtems-autoconf-2.69-1.cfg
>  delete mode 100644 rtems/config/tools/rtems-automake-1.12.6-1.cfg
>
> diff --git a/bare/config/devel/autotools-base.bset 
> b/bare/config/devel/autotools-base.bset
> deleted file mode 100644
> index 22456ed..000
> --- a/bare/config/devel/autotools-base.bset
> +++ /dev/null
> @@ -1,9 +0,0 @@
> -#
> -# Build set for autoconf, automake, and libtools.
> -#
> -
> -%define release 1
> -
> -devel/autoconf-2.69-1
> -devel/automake-1.12.6-1
> -devel/libtool-2.4.2-1
> diff --git a/bare/config/devel/autotools-internal.bset 
> b/bare/config/devel/autotools-internal.bset
> deleted file mode 100644
> index bad3890..000
> --- a/bare/config/devel/autotools-internal.bset
> +++ /dev/null
> @@ -1,13 +0,0 @@
> -#
> -# Tools Set for Internal Autotools Stable
> -#
> -# Do not use via the command line.
> -#
> -
> -%define _internal_autotools yes
> -%define _disable_collecting yes
> -%define _disable_packaging  yes
> -%define _disable_reporting  yes
> -%define _disable_installing yes
> -
> -%include devel/autotools-base.bset
> diff --git a/bare/config/devel/autotools.bset 
> b/bare/config/devel/autotools.bset
> deleted file mode 100644
> index 5fcafa4..000
> --- a/bare/config/devel/autotools.bset
> +++ /dev/null
> @@ -1,14 +0,0 @@
> -#
> -# Build set for autoconf, automake, and libtools.
> -#
> -
> -%define release 1
> -
> -#
> -# A magic internal path that would break if changes in the defaults.mc
> -# macro file are made.
> -#
> -%define _internal_autotools_path %{_tmppath}/sb-%{_uid}/${SB_PREFIX_CLEAN}
> -
> -devel/autotools-internal.bset
> -devel/autotools-base.bset
> diff --git a/rtems/config/6/rtems-autotools-base.bset 
> b/rtems/config/6/rtems-autotools-base.bset
> deleted file mode 100644
> index c6819c1..000
> --- a/rtems/config/6/rtems-autotools-base.bset
> +++ /dev/null
> @@ -1,9 +0,0 @@
> -%define release 1
> -%define rtems_arch none
> -
> -%include 6/rtems-base.bset
> -
> -package: rtems-%{rtems_version}-autotools-%{_host}-%{release}
> -
> -tools/rtems-autoconf-2.69-1
> -tools/rtems-automake-1.12.6-1
> diff --git a/rtems/config/6/rtems-autotools-internal.bset 
> b/rtems/config/6/rtems-autotools-internal.bset
> deleted file mode 100644
> index 19d2f19..000
> --- a/rtems/config/6/rtems-autotools-internal.bset
> +++ /dev/null
> @@ -1,11 +0,0 @@
> -#
> -# Do not use via the command line.
> -#
> -
> -%define _internal_autotools yes
> -%define _disable_collecting yes
> -%define _disable_packaging  yes
> -%define _disable_reporting  yes
> -%define _disable_installing yes
> -
> -%include 6/rtems-autotools-base.bset
> diff --git a/rtems/config/6/rtems-autotools.bset 
> b/rtems/config/6/rtems-autotools.bset
> deleted file mode 100644
> index e57d25d..000
> --- a/rtems/config/6/rtems-autotools.bset
> +++ /dev/null
> @@ -1,25 +0,0 @@
> -#
> -# Autoconf and automake are not relocatable and cannot be cross-compiled.
> -# RTEMS uses autoconf and automake and building RTEMS in the RSB requires
> -# bootstrapping and this requires a current autoconf and automake. The RSB
> -# provides to support by:
> -#
> -#  1. Building and installing autoconf and automake with a prefix to a
> -# temporary internal path.
> -#  2. Using the temporary internal build, build and install another copy
> -# using the final prefix location.
> -#
> -
> -#
> -# A magic internal path that would break if changes in the defaults.mc
> -# macro file are made.
> -#
> -%define _internal_autotools_path %{_tmppath}/sb-%{_uid}/${SB_PREFIX_CLEAN}
> -
> -#
> -# Disable emailing reports of this building for RTEMS.
> -#
>

Re: [PATCH RSB] Remove automake/autoconf from rtems 6 tools

2021-09-16 Thread Joel Sherrill 
On Thu, Sep 16, 2021 at 9:50 AM Gedare Bloom  wrote:
>
> Hi Joel,
>
> On Thu, Sep 16, 2021 at 8:42 AM Joel Sherrill  wrote:
> >
> > These are unneeded with the waf build system.
> >
> > Closes #4081.
>
> You should also git rm the rtems-autotools* files?

I thought the ones in bare were for use when building other packages but
happy to delete those also.

V2 may already be on the list.

--joel
>
>
> > ---
> >  rtems/config/6/rtems-default.bset| 2 --
> >  rtems/config/6/rtems-microblaze.bset | 2 --
> >  2 files changed, 4 deletions(-)
> >
> > diff --git a/rtems/config/6/rtems-default.bset 
> > b/rtems/config/6/rtems-default.bset
> > index 1b60066..0c07b08 100644
> > --- a/rtems/config/6/rtems-default.bset
> > +++ b/rtems/config/6/rtems-default.bset
> > @@ -3,8 +3,6 @@
> >  #
> >  %include 6/rtems-base.bset
> >
> > -6/rtems-autotools
> > -
> >  #
> >  # Build gdb first to raise the Python install error as early as possible.
> >  # GDB needs expat so it needs to be built before.
> > diff --git a/rtems/config/6/rtems-microblaze.bset 
> > b/rtems/config/6/rtems-microblaze.bset
> > index 4b12899..3eb7a89 100644
> > --- a/rtems/config/6/rtems-microblaze.bset
> > +++ b/rtems/config/6/rtems-microblaze.bset
> > @@ -6,8 +6,6 @@
> >  #
> >  %include 6/rtems-base.bset
> >
> > -6/rtems-autotools
> > -
> >  devel/dtc-1.6.0-1
> >
> >  #
> > --
> > 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

[PATCH RSB v2] Remove automake/autoconf from rtems 6 tools

2021-09-16 Thread Joel Sherrill 
These are unneeded with the waf build system.

Closes #4081.
---
 bare/config/devel/autotools-base.bset  |  9 -
 bare/config/devel/autotools-internal.bset  | 13 -
 bare/config/devel/autotools.bset   | 14 --
 rtems/config/6/rtems-autotools-base.bset   |  9 -
 rtems/config/6/rtems-autotools-internal.bset   | 11 ---
 rtems/config/6/rtems-autotools.bset| 25 -
 rtems/config/6/rtems-default.bset  |  2 --
 rtems/config/6/rtems-microblaze.bset   |  2 --
 rtems/config/tools/rtems-autoconf-2.69-1.cfg   | 23 ---
 rtems/config/tools/rtems-automake-1.12.6-1.cfg | 23 ---
 10 files changed, 131 deletions(-)
 delete mode 100644 bare/config/devel/autotools-base.bset
 delete mode 100644 bare/config/devel/autotools-internal.bset
 delete mode 100644 bare/config/devel/autotools.bset
 delete mode 100644 rtems/config/6/rtems-autotools-base.bset
 delete mode 100644 rtems/config/6/rtems-autotools-internal.bset
 delete mode 100644 rtems/config/6/rtems-autotools.bset
 delete mode 100644 rtems/config/tools/rtems-autoconf-2.69-1.cfg
 delete mode 100644 rtems/config/tools/rtems-automake-1.12.6-1.cfg

diff --git a/bare/config/devel/autotools-base.bset 
b/bare/config/devel/autotools-base.bset
deleted file mode 100644
index 22456ed..000
--- a/bare/config/devel/autotools-base.bset
+++ /dev/null
@@ -1,9 +0,0 @@
-#
-# Build set for autoconf, automake, and libtools.
-#
-
-%define release 1
-
-devel/autoconf-2.69-1
-devel/automake-1.12.6-1
-devel/libtool-2.4.2-1
diff --git a/bare/config/devel/autotools-internal.bset 
b/bare/config/devel/autotools-internal.bset
deleted file mode 100644
index bad3890..000
--- a/bare/config/devel/autotools-internal.bset
+++ /dev/null
@@ -1,13 +0,0 @@
-#
-# Tools Set for Internal Autotools Stable
-#
-# Do not use via the command line.
-#
-
-%define _internal_autotools yes
-%define _disable_collecting yes
-%define _disable_packaging  yes
-%define _disable_reporting  yes
-%define _disable_installing yes
-
-%include devel/autotools-base.bset
diff --git a/bare/config/devel/autotools.bset b/bare/config/devel/autotools.bset
deleted file mode 100644
index 5fcafa4..000
--- a/bare/config/devel/autotools.bset
+++ /dev/null
@@ -1,14 +0,0 @@
-#
-# Build set for autoconf, automake, and libtools.
-#
-
-%define release 1
-
-#
-# A magic internal path that would break if changes in the defaults.mc
-# macro file are made.
-#
-%define _internal_autotools_path %{_tmppath}/sb-%{_uid}/${SB_PREFIX_CLEAN}
-
-devel/autotools-internal.bset
-devel/autotools-base.bset
diff --git a/rtems/config/6/rtems-autotools-base.bset 
b/rtems/config/6/rtems-autotools-base.bset
deleted file mode 100644
index c6819c1..000
--- a/rtems/config/6/rtems-autotools-base.bset
+++ /dev/null
@@ -1,9 +0,0 @@
-%define release 1
-%define rtems_arch none
-
-%include 6/rtems-base.bset
-
-package: rtems-%{rtems_version}-autotools-%{_host}-%{release}
-
-tools/rtems-autoconf-2.69-1
-tools/rtems-automake-1.12.6-1
diff --git a/rtems/config/6/rtems-autotools-internal.bset 
b/rtems/config/6/rtems-autotools-internal.bset
deleted file mode 100644
index 19d2f19..000
--- a/rtems/config/6/rtems-autotools-internal.bset
+++ /dev/null
@@ -1,11 +0,0 @@
-#
-# Do not use via the command line.
-#
-
-%define _internal_autotools yes
-%define _disable_collecting yes
-%define _disable_packaging  yes
-%define _disable_reporting  yes
-%define _disable_installing yes
-
-%include 6/rtems-autotools-base.bset
diff --git a/rtems/config/6/rtems-autotools.bset 
b/rtems/config/6/rtems-autotools.bset
deleted file mode 100644
index e57d25d..000
--- a/rtems/config/6/rtems-autotools.bset
+++ /dev/null
@@ -1,25 +0,0 @@
-#
-# Autoconf and automake are not relocatable and cannot be cross-compiled.
-# RTEMS uses autoconf and automake and building RTEMS in the RSB requires
-# bootstrapping and this requires a current autoconf and automake. The RSB
-# provides to support by:
-#
-#  1. Building and installing autoconf and automake with a prefix to a
-# temporary internal path.
-#  2. Using the temporary internal build, build and install another copy
-# using the final prefix location.
-#
-
-#
-# A magic internal path that would break if changes in the defaults.mc
-# macro file are made.
-#
-%define _internal_autotools_path %{_tmppath}/sb-%{_uid}/${SB_PREFIX_CLEAN}
-
-#
-# Disable emailing reports of this building for RTEMS.
-#
-%define mail_disable
-
-6/rtems-autotools-internal
-6/rtems-autotools-base
diff --git a/rtems/config/6/rtems-default.bset 
b/rtems/config/6/rtems-default.bset
index 1b60066..0c07b08 100644
--- a/rtems/config/6/rtems-default.bset
+++ b/rtems/config/6/rtems-default.bset
@@ -3,8 +3,6 @@
 #
 %include 6/rtems-base.bset
 
-6/rtems-autotools
-
 #
 # Build gdb first to raise the Python install error as early as possible.
 # GDB needs expat so it needs to be built before.
diff --git

Re: [PATCH v4] improve the format of error reporting on i386

2021-09-16 Thread Gedare Bloom 
Hi Zack,

Although we are not currently filtering HTML on this mailing list, it
is strongly preferred that you would send plaintext email when there's
no need for the HTML features. We may disable/filter HTML in the
future, as is now done for us...@rtems.org

This email could have been as easily sent in plaintext. Make sure
anything that is PRIx32 has a 0x prepended to it.

Thanks,
Gedare

On Wed, Sep 15, 2021 at 6:26 PM zack leung  wrote:
>
>
> printk("--\n");
> printk("Exception %" PRIu32 " caught at PC 0x%" PRIx32 " by thread 0x%" 
> PRIx32 "\n",
> ctx->idtIndex,
> ctx->eip,
> _Thread_Executing->Object.id);
> printk("--\n");
> printk("Processor execution context at time of the fault was :\n");
> printk("--\n");
> printk(" EAX = %" PRIx32 " EBX = 0x%" PRIx32 " ECX = %" PRIx32 " EDX = %" 
> PRIx32 "\n",
> ctx->eax, ctx->ebx, ctx->ecx, ctx->edx);
> printk(" ESI = 0x%" PRIx32 " EDI = 0x%" PRIx32 " EBP = 0x%" PRIx32 " ESP = 
> 0x%" PRIx32 "\n",
> ctx->esi, ctx->edi, ctx->ebp, ctx->esp0);
>
>
> Before I send my patch here is what i'll change . So i can do this for 
> example format the hex values with 0x and
> have the thread id as a hex value.
>
> On Wed, 15 Sept 2021 at 15:18, Gedare Bloom  wrote:
>>
>> On Mon, Sep 13, 2021 at 6:10 PM zack leung  wrote:
>> >
>> > Gedare told me just to change the ID when I submitted the other I sent you
>> > in discord. Sorry for things bouncing back and forth.
>> >
>>
>> I said not to change the `type` of the register context variables from
>> 32 to ptr. You can change their representation to hex that's fine by
>> me, with the fixed width and 0x prepended.
>>
>> > On Mon, 13 Sept 2021 at 23:44, Joel Sherrill  wrote:
>> >
>> > > On Sun, Sep 12, 2021 at 7:02 PM zack leung 
>> > > wrote:
>> > > >
>> > > > Thread id is now a Hex value.
>> > > > Updates #4203
>> > > > ---
>> > > > cpukit/score/cpu/i386/cpu.c | 2 +-
>> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
>> > > >
>> > > > diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
>> > > > index 77b7a7161c..06af57418d 100644
>> > > > --- a/cpukit/score/cpu/i386/cpu.c
>> > > > +++ b/cpukit/score/cpu/i386/cpu.c
>> > > > @@ -215,7 +215,7 @@ void _CPU_Exception_frame_print (const
>> > > > CPU_Exception_frame *ctx)
>> > > > {
>> > > > unsigned int faultAddr = 0;
>> > > > printk("--\n");
>> > > > - printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
>> > > > PRId32 "\n",
>> > > > + printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
>> > > > PRIx32 "\n",
>> > >
>> > > PC and ID should use  PC 0x%08" PRIx32.
>> > >
>> > > Prefixing with 0x to indicate that the number is hexadecimal. Printing
>> > > it with leading zero's and 8 digits wide helps since the address and
>> > > thread id are 32-bit (8 nibbles).  A thread id is usually printed like
>> > > 0x0a010004
>> > >
>> > > Does this patch have all your other changes? I've slept since seeing
>> > > this time and thought there were changes..
>> > >
>> > > --joel
>> > >
>> > > > ctx->idtIndex,
>> > > > ctx->eip,
>> > > > _Thread_Executing->Object.id);
>> > > > --
>> > > > 2.33.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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH RSB] Remove automake/autoconf from rtems 6 tools

2021-09-16 Thread Gedare Bloom 
Hi Joel,

On Thu, Sep 16, 2021 at 8:42 AM Joel Sherrill  wrote:
>
> These are unneeded with the waf build system.
>
> Closes #4081.

You should also git rm the rtems-autotools* files?


> ---
>  rtems/config/6/rtems-default.bset| 2 --
>  rtems/config/6/rtems-microblaze.bset | 2 --
>  2 files changed, 4 deletions(-)
>
> diff --git a/rtems/config/6/rtems-default.bset 
> b/rtems/config/6/rtems-default.bset
> index 1b60066..0c07b08 100644
> --- a/rtems/config/6/rtems-default.bset
> +++ b/rtems/config/6/rtems-default.bset
> @@ -3,8 +3,6 @@
>  #
>  %include 6/rtems-base.bset
>
> -6/rtems-autotools
> -
>  #
>  # Build gdb first to raise the Python install error as early as possible.
>  # GDB needs expat so it needs to be built before.
> diff --git a/rtems/config/6/rtems-microblaze.bset 
> b/rtems/config/6/rtems-microblaze.bset
> index 4b12899..3eb7a89 100644
> --- a/rtems/config/6/rtems-microblaze.bset
> +++ b/rtems/config/6/rtems-microblaze.bset
> @@ -6,8 +6,6 @@
>  #
>  %include 6/rtems-base.bset
>
> -6/rtems-autotools
> -
>  devel/dtc-1.6.0-1
>
>  #
> --
> 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

[PATCH RSB] Remove automake/autoconf from rtems 6 tools

2021-09-16 Thread Joel Sherrill 
These are unneeded with the waf build system.

Closes #4081.
---
 rtems/config/6/rtems-default.bset| 2 --
 rtems/config/6/rtems-microblaze.bset | 2 --
 2 files changed, 4 deletions(-)

diff --git a/rtems/config/6/rtems-default.bset 
b/rtems/config/6/rtems-default.bset
index 1b60066..0c07b08 100644
--- a/rtems/config/6/rtems-default.bset
+++ b/rtems/config/6/rtems-default.bset
@@ -3,8 +3,6 @@
 #
 %include 6/rtems-base.bset
 
-6/rtems-autotools
-
 #
 # Build gdb first to raise the Python install error as early as possible.
 # GDB needs expat so it needs to be built before.
diff --git a/rtems/config/6/rtems-microblaze.bset 
b/rtems/config/6/rtems-microblaze.bset
index 4b12899..3eb7a89 100644
--- a/rtems/config/6/rtems-microblaze.bset
+++ b/rtems/config/6/rtems-microblaze.bset
@@ -6,8 +6,6 @@
 #
 %include 6/rtems-base.bset
 
-6/rtems-autotools
-
 devel/dtc-1.6.0-1
 
 #
-- 
1.8.3.1

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

Re: Remove old build system

2021-09-16 Thread Joel Sherrill 
On Thu, Sep 16, 2021 at 8:31 AM Sebastian Huber
 wrote:
>
> Hello,
>
> I updated the commit which removes the old build system:
>
> https://git.rtems.org/sebh/rtems.git/commit/?h=remove-old-build-system=a6dbaeeeb34bbb10922f6a75590d05333599075c

I'm ok with it being merged assuming it technically is correct. No
transition objections.

I have one queued up to remove automake/autoconf from the various
RTEMS 6 tool builds which I should be able to post today.

--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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Remove old build system

2021-09-16 Thread Sebastian Huber 

Hello,

I updated the commit which removes the old build system:

https://git.rtems.org/sebh/rtems.git/commit/?h=remove-old-build-system=a6dbaeeeb34bbb10922f6a75590d05333599075c

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RSB

2021-09-16 Thread Joel Sherrill 
On Wed, Sep 15, 2021 at 7:08 PM Chris Johns  wrote:
>
> On 16/9/21 1:46 am, Joel Sherrill wrote:
> > On Tue, Sep 14, 2021 at 5:52 PM Chris Johns  wrote:
> >>
> >> On 15/9/21 4:49 am, Joel Sherrill wrote:
> >>> On Mon, Sep 13, 2021, 7:02 PM Joel Sherrill  >>> > wrote:
> >>> On Mon, Sep 13, 2021 at 6:54 PM Chris Johns  >>> > wrote:
> >>> > On 13/9/21 11:20 pm, Joel Sherrill wrote:
> >>> > > Hi
> >>> > >
> >>> > > If building a bset tar file, does it matter if the installation 
> >>> prefix
> >>> > > is writable?
> >>> > >
> >>> > > ../source-builder/sb-set-builder --bset-tar-file --log=l-i386.txt
> >>> > > --prefix=/rtems/tools 5/rtems-i386
> >>> > > RTEMS Source Builder - Set Builder, 5 (c7870f6e6199)
> >>> > > error: prefix is not writable: /rtems/tools
> >>> > >
> >>> > > It does if you are planning to immediately install but if 
> >>> building for
> >>> > > later installation, I don't think it matters.
> >>> > >
> >>> > > Thoughts?
> >>> >
> >>> > What happens if you add --no-install?
> >>>
> >>> It skips the test.
> >>>
> >>> And doesn't install anything.
> >>
> >> Excellent.
> >>
> >>> > If this does help the question moves to if making a bset is 
> >>> packaging
> >>> around an
> >>> > install or is it the only output option?
> >>>
> >>> With a bset-tar, I don't think it did an install anyway. But it's been
> >>> a long day. I can
> >>> check again tomorrow if you want me to.
> >>>
> >>> Builds and installs tools unless you specify no install.
> >>>
> >>> Tar files is an additive behavior.
> >>
> >> OK and thanks
> >>
> >>> I am off today but will try to review the help and user docs to make sure 
> >>> this
> >>> is clear.
> >>>
> >>> Any thoughts on the tools tarballs not having the architecture name in 
> >>> it? If
> >>> you build multiple architectures or just want to maintain tool tarballs 
> >>> for
> >>> multiple architectures, you have to manually rename them.
> >>
> >> Could you please remind me about the naming and then what you would like?
> >
> > After building tools for ARM for RTEMS 5, this is what is in the tar/
> > directory.
> >
> > + ls -1 tar
> > automake-1.12.6-x86_64-linux-gnu-1.tar.bz2
> > rtems-tools-0a5d2057749066e7d184836e92c7ce5334fccc90-1.tar.bz2
> >
> > I wondered where autoconf was and it is in the automake tarball. Either
> > autoconf should be in a separate tarball of the tarfile should be autotools
> > like is used in the bsets. Not sure which but just saying automake-1.12.6
> > and including autoconf is not right.
>
> It would seem the tar name is not the parent bset.

Yes.

>
> > The issue I mentioned is that the same rtems-tools-@t...@-1.tar.bz2
> > is used for every architecture. Perhaps rtems-tools-@ARCH@-@t...@-1.tar.bz2.
> > Then you can script building all architectures without renaming files.
>
> That implies the tools are arch specific and they are not. The tools should be
> tagged with the host arch details if we add anything.

The issue is that the tarball name is wrong and the rtems-tools one rtems-tools,
binutils, gcc/newlib, and gdb. It includes EVERYTHING that is built
when you use
6/rtems-arm.

The automake tarball has automake and autoconf

The rtems-tools tarball has everything I listed above. Beyond
rtems-tools, binutils,
gcc/newlib, and gdb, I suppose it also includes sis or dtc on some
architectures.

If it used the name from the top level bset it might be ok. Then you would have
autotools and something derived from 6/rtems-arm

I can send you lists of what is in each tarball if you like.

>
> > One thing I also noticed which might cause problems with people feeding
> > the tools tarball into another packaging system is that there are duplicate
> > files across architectures.
>
> Yeap.

This is just an observation but isn't a problem for us. The tarfile
names and contents
not aligning is the problem.

>
> > I don't see the RSB addressing this but someone
> > creating RPM, deb, etc packages might have to.
>
> Correct.
>
> > If post processing
> > is needed to break out a rtems-tools-common tarball, that is on someone
> > feeding these into something that doesn't like duplicate files in packages.
> >
> > So.. (1) automake has autoconf also and (2) same name is used for 
> > rtems-tools
> > independent of architecture.
>
> Packaging is beyond the RSB. You have highlighted a couple of issues and more
> exist. For example in each build of gcc there are common host files and there
> are common host independent files. To map multiple builds of tools into a
> packaging system you need to identify all common pieces and then group them
> based on the packaging system requirements. You then create a package 
> dependency
> tree for the generated packages.
>
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] eng: Add register block specification types

2021-09-16 Thread Chris Johns 
On 16/9/21 3:54 pm, Sebastian Huber wrote:
> Ok, so your real problem is that I wrote "bytes" in the description of the
> register-block-size and offset attributes?

I have listed a number of concerns, this is just an example of one.

I suggest we get together and work through each statement. It will be quicker
and we can adjust the wording in a single pass.

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