[PATCH v2 1/2] bsps/aarch64: Ensure FPU trap state is consistent

2022-10-27 Thread Kinsey Moore 
RTEMS may be booted from a dirty environment. Ensure that FPU trap
settings are consistent.
---
 bsps/aarch64/shared/start/start.S | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/bsps/aarch64/shared/start/start.S 
b/bsps/aarch64/shared/start/start.S
index 8bd4f86f4e..0237583463 100644
--- a/bsps/aarch64/shared/start/start.S
+++ b/bsps/aarch64/shared/start/start.S
@@ -307,6 +307,12 @@ _el1_start:
 
   /* FPU does not need to be enabled on AArch64 */
 
+  /* Ensure FPU traps are disabled by default */
+  mrs x0, FPCR
+  bic x0, x0, #((1 << 8) | (1 << 9) | (1 << 10) | (1 << 11) | (1 << 12))
+  bic x0, x0, #(1 << 15)
+  msr FPCR, x0
+
 #endif /* AARCH64_MULTILIB_VFP */
 
   /* Branch to start hook 1 */
-- 
2.30.2

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

[PATCH v2 2/2] cpukit/aarch64: Emulate FPSR for FENV traps

2022-10-27 Thread Kinsey Moore 
The AArch64 TRM specifies that when FPCR is set to trap floating point
exceptions, the FPSR exception bits are not set. This ensures that FPSR
is updated as FENV expects even if floating point exception traps are
enabled.
---
 .../cpu/aarch64/aarch64-exception-default.c   | 20 +++
 1 file changed, 20 insertions(+)

diff --git a/cpukit/score/cpu/aarch64/aarch64-exception-default.c 
b/cpukit/score/cpu/aarch64/aarch64-exception-default.c
index 3494c88ea6..f1591cbd5d 100644
--- a/cpukit/score/cpu/aarch64/aarch64-exception-default.c
+++ b/cpukit/score/cpu/aarch64/aarch64-exception-default.c
@@ -48,6 +48,26 @@
 
 void _AArch64_Exception_default( CPU_Exception_frame *frame )
 {
+  uint64_t EC = AARCH64_ESR_EL1_EC_GET( frame->register_syndrome );
+
+  /* Emulate FPSR flags for FENV if a FPU exception occurred */
+  if ( EC == 0x2c ) {
+/*
+ * This must be done because FENV depends on FPSR values, but trapped FPU
+ * exceptions don't set FPSR bits. In the case where a signal is mapped, 
the
+ * signal code executes after the exception frame is restored and FENV
+ * functions executed in that context will need this information to be
+ * accurate.
+ */
+uint64_t ISS = AARCH64_ESR_EL1_EC_GET( frame->register_syndrome );
+
+/* If the exception bits are valid, use them */
+if ( ( ISS & ( 1 << 23 ) ) != 0 ) {
+  /* The bits of the lower byte match the FPSR exception bits */
+  frame->register_fpsr |= ( ISS & 0xff );
+}
+  }
+
   rtems_fatal( RTEMS_FATAL_SOURCE_EXCEPTION, (rtems_fatal_code) frame );
 }
 
-- 
2.30.2

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

Re: [PATCH 1/2] bsps/aarch64: Ensure FPU trap state is consistent

2022-10-27 Thread Chris Johns 
On 28/10/2022 9:57 am, Kinsey Moore wrote:
> 
> On Thu, Oct 27, 2022 at 5:46 PM Chris Johns  > wrote:
> 
> On 28/10/2022 9:25 am, Kinsey Moore wrote:
> > On Thu, Oct 27, 2022 at 5:10 PM Chris Johns  
> > >> wrote:
> >
> >     On 28/10/2022 9:05 am, Kinsey Moore wrote:
> >     > RTEMS may be booted from a dirty environment. Ensure that FPU trap
> >     > settings are consistent.
> >     > ---
> >     >  bsps/aarch64/shared/start/start.S | 10 ++
> >     >  1 file changed, 10 insertions(+)
> >     >
> >     > diff --git a/bsps/aarch64/shared/start/start.S
> >     b/bsps/aarch64/shared/start/start.S
> >     > index 8bd4f86f4e..de0fdf4c80 100644
> >     > --- a/bsps/aarch64/shared/start/start.S
> >     > +++ b/bsps/aarch64/shared/start/start.S
> >     > @@ -307,6 +307,16 @@ _el1_start:
> >     > 
> >     >    /* FPU does not need to be enabled on AArch64 */
> >     > 
> >     > +  /* Ensure FPU traps are disabled by default */
> >     > +  mrs x0, FPCR
> >     > +  bic x0, x0, #(1 << 8)
> >     > +  bic x0, x0, #(1 << 9)
> >     > +  bic x0, x0, #(1 << 10)
> >     > +  bic x0, x0, #(1 << 11)
> >     > +  bic x0, x0, #(1 << 12)
> >     > +  bic x0, x0, #(1 << 15)
> >
> >     Does `bic x0, x0, #((1 << 8) | (1 << 9) | (1 << 10) | ...)` work?
> >
> > The assembler complains about the operand being out of range. I can 
> split it
> > into 8-12 in one and 15 by itself and everything seems to work.
> 
> Huh? If you use a hex value does it work?
> 
> I think the equivalent value would be 0x9f00. That generates the same error as
> putting all the components on the same line. I think there's a 6-bit immediate
> involved that's the limitation.

Ah, must be an aarch64 thing. I have been using ARM and thumb mode asm this 
week :)

I will leave this with you to sort out which is best.

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

Re: [PATCH 1/2] bsps/aarch64: Ensure FPU trap state is consistent

2022-10-27 Thread Kinsey Moore 
On Thu, Oct 27, 2022 at 5:46 PM Chris Johns  wrote:

> On 28/10/2022 9:25 am, Kinsey Moore wrote:
> > On Thu, Oct 27, 2022 at 5:10 PM Chris Johns  > > wrote:
> >
> > On 28/10/2022 9:05 am, Kinsey Moore wrote:
> > > RTEMS may be booted from a dirty environment. Ensure that FPU trap
> > > settings are consistent.
> > > ---
> > >  bsps/aarch64/shared/start/start.S | 10 ++
> > >  1 file changed, 10 insertions(+)
> > >
> > > diff --git a/bsps/aarch64/shared/start/start.S
> > b/bsps/aarch64/shared/start/start.S
> > > index 8bd4f86f4e..de0fdf4c80 100644
> > > --- a/bsps/aarch64/shared/start/start.S
> > > +++ b/bsps/aarch64/shared/start/start.S
> > > @@ -307,6 +307,16 @@ _el1_start:
> > >
> > >/* FPU does not need to be enabled on AArch64 */
> > >
> > > +  /* Ensure FPU traps are disabled by default */
> > > +  mrs x0, FPCR
> > > +  bic x0, x0, #(1 << 8)
> > > +  bic x0, x0, #(1 << 9)
> > > +  bic x0, x0, #(1 << 10)
> > > +  bic x0, x0, #(1 << 11)
> > > +  bic x0, x0, #(1 << 12)
> > > +  bic x0, x0, #(1 << 15)
> >
> > Does `bic x0, x0, #((1 << 8) | (1 << 9) | (1 << 10) | ...)` work?
> >
> > The assembler complains about the operand being out of range. I can
> split it
> > into 8-12 in one and 15 by itself and everything seems to work.
>
> Huh? If you use a hex value does it work?
>
> I think the equivalent value would be 0x9f00. That generates the same
error as putting all the components on the same line. I think there's a
6-bit immediate involved that's the limitation.

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

Re: [PATCH 1/2] bsps/aarch64: Ensure FPU trap state is consistent

2022-10-27 Thread Chris Johns 
On 28/10/2022 9:25 am, Kinsey Moore wrote:
> On Thu, Oct 27, 2022 at 5:10 PM Chris Johns  > wrote:
> 
> On 28/10/2022 9:05 am, Kinsey Moore wrote:
> > RTEMS may be booted from a dirty environment. Ensure that FPU trap
> > settings are consistent.
> > ---
> >  bsps/aarch64/shared/start/start.S | 10 ++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/bsps/aarch64/shared/start/start.S
> b/bsps/aarch64/shared/start/start.S
> > index 8bd4f86f4e..de0fdf4c80 100644
> > --- a/bsps/aarch64/shared/start/start.S
> > +++ b/bsps/aarch64/shared/start/start.S
> > @@ -307,6 +307,16 @@ _el1_start:
> > 
> >    /* FPU does not need to be enabled on AArch64 */
> > 
> > +  /* Ensure FPU traps are disabled by default */
> > +  mrs x0, FPCR
> > +  bic x0, x0, #(1 << 8)
> > +  bic x0, x0, #(1 << 9)
> > +  bic x0, x0, #(1 << 10)
> > +  bic x0, x0, #(1 << 11)
> > +  bic x0, x0, #(1 << 12)
> > +  bic x0, x0, #(1 << 15)
> 
> Does `bic x0, x0, #((1 << 8) | (1 << 9) | (1 << 10) | ...)` work?
> 
> The assembler complains about the operand being out of range. I can split it
> into 8-12 in one and 15 by itself and everything seems to work.

Huh? If you use a hex value does it work?

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

Re: [PATCH 1/2] bsps/aarch64: Ensure FPU trap state is consistent

2022-10-27 Thread Kinsey Moore 
On Thu, Oct 27, 2022 at 5:10 PM Chris Johns  wrote:

> On 28/10/2022 9:05 am, Kinsey Moore wrote:
> > RTEMS may be booted from a dirty environment. Ensure that FPU trap
> > settings are consistent.
> > ---
> >  bsps/aarch64/shared/start/start.S | 10 ++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/bsps/aarch64/shared/start/start.S
> b/bsps/aarch64/shared/start/start.S
> > index 8bd4f86f4e..de0fdf4c80 100644
> > --- a/bsps/aarch64/shared/start/start.S
> > +++ b/bsps/aarch64/shared/start/start.S
> > @@ -307,6 +307,16 @@ _el1_start:
> >
> >/* FPU does not need to be enabled on AArch64 */
> >
> > +  /* Ensure FPU traps are disabled by default */
> > +  mrs x0, FPCR
> > +  bic x0, x0, #(1 << 8)
> > +  bic x0, x0, #(1 << 9)
> > +  bic x0, x0, #(1 << 10)
> > +  bic x0, x0, #(1 << 11)
> > +  bic x0, x0, #(1 << 12)
> > +  bic x0, x0, #(1 << 15)
>
> Does `bic x0, x0, #((1 << 8) | (1 << 9) | (1 << 10) | ...)` work?
>
The assembler complains about the operand being out of range. I can split
it into 8-12 in one and 15 by itself and everything seems to work.

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

Re: [PATCH 1/2] bsps/aarch64: Ensure FPU trap state is consistent

2022-10-27 Thread Chris Johns 
On 28/10/2022 9:05 am, Kinsey Moore wrote:
> RTEMS may be booted from a dirty environment. Ensure that FPU trap
> settings are consistent.
> ---
>  bsps/aarch64/shared/start/start.S | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/bsps/aarch64/shared/start/start.S 
> b/bsps/aarch64/shared/start/start.S
> index 8bd4f86f4e..de0fdf4c80 100644
> --- a/bsps/aarch64/shared/start/start.S
> +++ b/bsps/aarch64/shared/start/start.S
> @@ -307,6 +307,16 @@ _el1_start:
>  
>/* FPU does not need to be enabled on AArch64 */
>  
> +  /* Ensure FPU traps are disabled by default */
> +  mrs x0, FPCR
> +  bic x0, x0, #(1 << 8)
> +  bic x0, x0, #(1 << 9)
> +  bic x0, x0, #(1 << 10)
> +  bic x0, x0, #(1 << 11)
> +  bic x0, x0, #(1 << 12)
> +  bic x0, x0, #(1 << 15)

Does `bic x0, x0, #((1 << 8) | (1 << 9) | (1 << 10) | ...)` work?

The operand2 is a mask of bits to clear.

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

[PATCH 1/2] bsps/aarch64: Ensure FPU trap state is consistent

2022-10-27 Thread Kinsey Moore 
RTEMS may be booted from a dirty environment. Ensure that FPU trap
settings are consistent.
---
 bsps/aarch64/shared/start/start.S | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/bsps/aarch64/shared/start/start.S 
b/bsps/aarch64/shared/start/start.S
index 8bd4f86f4e..de0fdf4c80 100644
--- a/bsps/aarch64/shared/start/start.S
+++ b/bsps/aarch64/shared/start/start.S
@@ -307,6 +307,16 @@ _el1_start:
 
   /* FPU does not need to be enabled on AArch64 */
 
+  /* Ensure FPU traps are disabled by default */
+  mrs x0, FPCR
+  bic x0, x0, #(1 << 8)
+  bic x0, x0, #(1 << 9)
+  bic x0, x0, #(1 << 10)
+  bic x0, x0, #(1 << 11)
+  bic x0, x0, #(1 << 12)
+  bic x0, x0, #(1 << 15)
+  msr FPCR, x0
+
 #endif /* AARCH64_MULTILIB_VFP */
 
   /* Branch to start hook 1 */
-- 
2.30.2

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

[PATCH 2/2] cpukit/aarch64: Emulate FPSR for FENV traps

2022-10-27 Thread Kinsey Moore 
The AArch64 TRM specifies that when FPCR is set to trap floating point
exceptions, the FPSR exception bits are not set. This ensures that FPSR
is updated as FENV expects even if floating point exception traps are
enabled.
---
 .../cpu/aarch64/aarch64-exception-default.c   | 20 +++
 1 file changed, 20 insertions(+)

diff --git a/cpukit/score/cpu/aarch64/aarch64-exception-default.c 
b/cpukit/score/cpu/aarch64/aarch64-exception-default.c
index 3494c88ea6..f1591cbd5d 100644
--- a/cpukit/score/cpu/aarch64/aarch64-exception-default.c
+++ b/cpukit/score/cpu/aarch64/aarch64-exception-default.c
@@ -48,6 +48,26 @@
 
 void _AArch64_Exception_default( CPU_Exception_frame *frame )
 {
+  uint64_t EC = AARCH64_ESR_EL1_EC_GET( frame->register_syndrome );
+
+  /* Emulate FPSR flags for FENV if a FPU exception occurred */
+  if ( EC == 0x2c ) {
+/*
+ * This must be done because FENV depends on FPSR values, but trapped FPU
+ * exceptions don't set FPSR bits. In the case where a signal is mapped, 
the
+ * signal code executes after the exception frame is restored and FENV
+ * functions executed in that context will need this information to be
+ * accurate.
+ */
+uint64_t ISS = AARCH64_ESR_EL1_EC_GET( frame->register_syndrome );
+
+/* If the exception bits are valid, use them */
+if ( ( ISS & ( 1 << 23 ) ) != 0 ) {
+  /* The bits of the lower byte match the FPSR exception bits */
+  frame->register_fpsr |= ( ISS & 0xff );
+}
+  }
+
   rtems_fatal( RTEMS_FATAL_SOURCE_EXCEPTION, (rtems_fatal_code) frame );
 }
 
-- 
2.30.2

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

Re: Increase Frequency of Updates of RTEMS GitHub Tools Mirroring

2022-10-27 Thread Chris Johns 
Hi Christian,

Thank you for your considered comments.

On 27/10/2022 12:06 am, Christian MAUDERER wrote:
> Am 26.10.22 um 01:06 schrieb Chris Johns:
>> On 26/10/2022 4:46 am, Joel Sherrill wrote:
>>>  In general, our current approach is quite a hack. We should do things
>>>  more event driven. For example, if you want to update the RSB, then you
>>>  create a pull request. This pull request starts a CI script which
>>>  updates the mirrors and builds the RSB on a selected set of platforms.
>>>  If everything is all right, the pull request can be merged.
>>>
>>> Just getting to the point where a pull request triggered an update would
>>> be useful. Assuming a pull request with no content would be ok.
>>
>> I feel starting to have pull requests will only result in changes being 
>> posted
>> there by users who see pull requests as active. It is reasonable for a user 
>> to
>> think this. Who will then field those and merge them?
>>
>> Chris
> 
> Hello Chris,
> 
> I agree that as long as the RTEMS project doesn't officially use pull 
> requests,
> it's not a good idea to have something that looks official but isn't used. On
> the other hand, I think that it would be a really good idea for the RTEMS
> project to migrate to a patch management system where a pull-request with
> automated CI run is the official method for contributing.

I would love a patch management system to be in place. Getting consensus on what
to use, how we host it, who does the work and who maintains it is hard.

> That would take a lot
> of work from the shoulders of the maintainers because for a lot of patches, no
> more manual tests whether the patch builds would be necessary. Of course the
> patch would still need review.

No question that would be the case. A good tool will also manage CI to make sure
we have buildable commits entering the repo.

> Beneath that, a system with pull requests usually has a nice overview over
> pending patches. At the moment we have patches on the mailing list mixed with
> discussions.

Yes this is true and I would like to add pull requests are widely used and
people know how to use them and trust them and this is important for us long
term. We need to stay current in the tools and methods we employ.

> A user has to get the attention of a maintainer to get a patch
> merged. Users that don't want to be pushy maybe don't ping such patches or 
> some
> might just forget that they send a patch to the list.

Agreed. I am guilty of forgetting.

> I'm sure that we lost
> quite a few patches due to that because no one felt responsible, no one noted
> the patch or no one had the time to test the patches before merging them.

I also think this is true.

> I know that I have even lost some of my own patches on the list because no one
> acknoledged them and I started to work on something else and forget them. I
> found some a few months later and was surprised that I didn't push them. I
> wouldn't guarantee that I found all of them. A patch management system should
> help to see whether there are still open ones.

Good to know I am not the only one.

> PS: I already mentioned it in another mail: I started to build some github CI
> scripts that we at embedded brains want to use for testing our own public
> patches. Github doesn't seem to limit the CI time on public projects so 
> everyone
> who wants to play a bit with it: Feel free to create pull requests to see how
> something like that works. Just select the "ci" branch on
> 
>   https://github.com/embedded-brains/rtems
> 
> That repo is clearly a fork (marked with "forked from RTEMS/rtems" so I don't
> see the risk that someone mixes it up with the official repos. But if unknown
> users will use it to create pull requests, I'll add a comment to the pull
> requests, that patches should be sent to the mailing list instead. If there 
> are
> a lot of unknown users, I'll automate the comments.

Yes I remember, maybe on discord. I took a look and it is nice. It is great to
see support companies running CI flows. OAR has tools builds and simulator test
runs posting to build results to the builds list and this is great and 
important.

I would like to see more hardware test runs and posted results. Does EB have any
plans to run the testsuite on hardware and post the results to builds?

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

[PATCH] rtems-bsps: Generate empty config.ini for arc/bsp combinations

2022-10-27 Thread chrisj 
From: Chris Johns 

- Generate a config for all BSPs in an arch
---
 rtems-bsps | 92 +++---
 1 file changed, 80 insertions(+), 12 deletions(-)

diff --git a/rtems-bsps b/rtems-bsps
index 8f3a887b9d..79ea745753 100755
--- a/rtems-bsps
+++ b/rtems-bsps
@@ -1,7 +1,7 @@
 #! /usr/bin/env python
 #
 # RTEMS (http://www.rtems.org/)
-# Copyright 2020 Chris Johns (chr...@rtems.org)
+# Copyright 2020, 2022 Chris Johns (chr...@rtems.org)
 # All rights reserved.
 #
 # Redistribution and use in source and binary forms, with or without
@@ -63,7 +63,10 @@ class ArchBsps:
 
 def _out(self, line=''):
 """Output a line to the output buffer."""
-self._output += [line]
+if isinstance(line, list):
+self._output += line
+else:
+self._output += [line]
 
 def _collect(self, ext):
 """Collect the config files from the source tree."""
@@ -266,7 +269,7 @@ class ArchBsps:
   (max_bsp, bsp, max_fb, family, p))
 else:
 self._out('%-*s |%s' % (max_bsp, bsp, family))
-
+
 def pairs(self, arch_selector=None, family_selector=None, show_path=False):
 """Generate output as pairs"""
 self._clear()
@@ -290,11 +293,70 @@ class ArchBsps:
  self.archs[arch][family][bsp])
 pair = arch + '/' + bsp
 pair = '%-*s %s' % (max_arch + max_bsp + 1, 
pair, p)
-
+
 self._out(pair)
 else:
 self._out('%s/%s' % (arch, bsp))
 
+def config(self, arch_selector=None, family_selector=None):
+"""Generate output as pairs"""
+self._clear()
+self._out(['# Generated by rtems-bsp',
+   '[DEFAULT]',
+   '# Build',
+   'RTEMS_BUILD_LABEL = DEFAULT',
+   'RTEMS_DEBUG = False',
+   'RTEMS_PROFILING = False',
+   'RTEMS_POSIX_API = True',
+   '# Tests',
+   'BUILD_TESTS = False',
+   'BUILD_BENCHMARKS = False',
+   'BUILD_FSTESTS = False',
+   'BUILD_LIBTESTS = False',
+   'BUILD_MPTESTS = False',
+   'BUILD_PSXTESTS = False',
+   'BUILD_PSXTMTESTS = False',
+   'BUILD_RHEALSTONE = False',
+   'BUILD_SAMPLES = True',
+   'BUILD_SMPTESTS = False',
+   'BUILD_SPTESTS = False',
+   'BUILD_TMTESTS = False',
+   'BUILD_UNITTESTS = False',
+   'BUILD_VALIDATIONTESTS = False',
+   'RTEMS_TEST_VERBOSITY = Normal',
+   '# Compliler',
+   '; WARNING_FLAGS = -Wall',
+   '; CC_WARNING_FLAGS = -Wmissing-prototypes 
-Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs',
+   '; CXX_WARNING_FLAGS = ',
+   '; OPTIMIZATION_FLAGS = -O2 -g -fdata-sections 
-ffunction-sections',
+   '; BSP_OPTIMIZATION_FLAGS = ${OPTIMIZATION_FLAGS}',
+   '; CPUKIT_OPTIMIZATION_FLAGS = ${OPTIMIZATION_FLAGS}',
+   '; TEST_OPTIMIZATION_FLAGS = ${OPTIMIZATION_FLAGS}',
+   '; LINKFLAGS = ',
+   '; LDFLAGS = -Wl,--gc-sections',
+   '# BSP',
+   'BSP_VERBOSE_FATAL_EXTENSION = 1',
+   'BSP_PRINT_EXCEPTION_CONTEXT = 1',
+   'BSP_RESET_BOARD_AT_EXIT = 1'])
+self._out()
+max_arch = self._max_arch_len()
+max_bsp = self._max_bsp_len()
+if arch_selector is None:
+arch_matcher = []
+else:
+arch_matcher = [a.strip() for a in arch_selector.split(',')]
+if family_selector is None:
+family_matcher = []
+else:
+family_matcher = [f.strip() for f in family_selector.split(',')]
+for arch in sorted(self.archs.keys()):
+if arch_selector is None or arch in arch_matcher:
+for family in sorted(self.archs[arch].keys()):
+if family_selector is None or family in family_matcher:
+for bsp in sorted(self.archs[arch][family].keys()):
+self._out('[%s/%s]' % (arch, bsp))
+self._out()
+
 
 def run(args):
 """Runs the command"""
@@ -331,6 +393,10 @@ def run(args):
'--pairs',
help='Output architectures and BSPs in CPU/BSP format',
action='store_true')
+argsp.add_argument('-C',
+   '--config',
+

[PATCH] cpukit/libdebugger: Fix stepping on ARM architectures

2022-10-27 Thread chrisj 
From: Chris Johns 

Closes #4744
---
 cpukit/libdebugger/rtems-debugger-arm.c | 808 +++-
 1 file changed, 495 insertions(+), 313 deletions(-)

diff --git a/cpukit/libdebugger/rtems-debugger-arm.c 
b/cpukit/libdebugger/rtems-debugger-arm.c
index ba01a860c8..cdc615ce64 100644
--- a/cpukit/libdebugger/rtems-debugger-arm.c
+++ b/cpukit/libdebugger/rtems-debugger-arm.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2016-2019 Chris Johns .
+ * Copyright (c) 2016-2022 Chris Johns .
  * All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
@@ -86,14 +86,26 @@
   #define ARM_SWITCH_REG   uint32_t arm_switch_reg
   #define ARM_SWITCH_REG_ASM   [arm_switch_reg] "=" (arm_switch_reg)
   #define ARM_SWITCH_REG_ASM_L ARM_SWITCH_REG_ASM,
+  #define ASM_ARM_ASM  ".align 2\n.arm\n"
   #define ASM_ARM_MODE ".align 2\nbx pc\n.arm\n"
   #define ASM_THUMB_MODE   "add %[arm_switch_reg], pc, #1\nbx 
%[arm_switch_reg]\n.thumb\n"
+  #define ARM_THUMB_MODE() __asm__ volatile(ASM_THUMB_MODE : 
ARM_SWITCH_REG_ASM : :);
+  #define ARM_ARM_MODE()   __asm__ volatile(ASM_ARM_MODE : : :);
 #else
   #define ARM_SWITCH_REG
   #define ARM_SWITCH_REG_ASM
   #define ARM_SWITCH_REG_ASM_L
+  #define ASM_ARM_ASM
   #define ASM_ARM_MODE
   #define ASM_THUMB_MODE
+  #define ARM_THUMB_MODE()
+  #define ARM_ARM_MODE()
+#endif
+
+#ifdef ARM_MULTILIB_HAS_BARRIER_INSTRUCTIONS
+#define ARM_SYNC_INST  "isb\n"
+#else
+#define ARM_SYNC_INST
 #endif
 
 /*
@@ -287,29 +299,19 @@ static const size_t exc_offsets[2][5] =
 static bool debug_session_active;
 
 /*
- * ARM debug hardware.
+ * ARM debug hardware. These variables are directly access
+ * from assembler so do not change types.
  */
 static int   debug_version;
 static void* debug_registers;
 static int   debug_revision;
-static bool  debug_disable_ints;
+static int   debug_disable_ints;
 static int   hw_breakpoints;
 static int   hw_watchpoints;
 
 /**
  * Hardware break and watch points.
  */
-typedef struct
-{
-  bool enabled;
-  bool loaded;
-  void*address;
-  size_t   length;
-  CPU_Exception_frame* frame;
-  uint32_t control;
-  uint32_t value;
-} arm_debug_hwbreak;
-
 #define ARM_HW_BREAKPOINT_MAX (16)
 #define ARM_HW_WATCHPOINT_MAX (16)
 
@@ -327,8 +329,23 @@ typedef struct
 #define ARM_HW_BP_PRIV_PL0_ONLY(0x02)
 #define ARM_HW_BP_PRIV_ALL_MODES   (0x03)
 
-static arm_debug_hwbreak hw_breaks[ARM_HW_BREAKPOINT_MAX];
-//static arm_debug_hwbreak hw_watches[ARM_HW_WATCHPOINT_MAX];
+/*
+ * A hw breakpoint has DBGBCR and DBGBVR registers. Allocate memory
+ * for each.
+ *
+ * Maintian the values ready to load into the hardware. The loader is
+ * a load of the value and then control for enabled BPs.
+ */
+static uint32_t hw_breaks[ARM_HW_BREAKPOINT_MAX * 2];
+
+/*
+ * The order in the array is important
+ */
+#define ARM_HWB_BCR(_bp) (hw_breaks[((_bp) * 2) + 1])
+#define ARM_HWB_VCR(_bp) (hw_breaks[(_bp) * 2])
+#define ARM_HWB_ENALBED(_bp) ((ARM_HWB_BCR(_bp) & 1) != 0)
+#define ARM_HWB_CLEAR(_bp) ARM_HWB_BCR(_bp) = 0; ARM_HWB_VCR(_bp) = 0
+#define ARM_HWB_CLEAR_ALL() memset(_breaks[0], 0, sizeof(hw_breaks))
 
 /*
  * Method of entry (MOE) to debug mode. Bits [5:2] of DBGDSCR.
@@ -439,6 +456,7 @@ arm_moe_label(uint32_t moe)
 asm volatile(  \
   ASM_ARM_MODE \
   ARM_CP_INSTR(mcr, _cp, _op1, val, _CRn, _CRm, _op2)  \
+  ARM_SYNC_INST\
   ASM_THUMB_MODE   \
   : ARM_SWITCH_REG_ASM \
   : [val] "r" (_val)); \
@@ -449,6 +467,7 @@ arm_moe_label(uint32_t moe)
 ARM_SWITCH_REG;\
 asm volatile(  \
   ASM_ARM_MODE \
+  ARM_SYNC_INST\
   ARM_CP_INSTR(mrc, _cp, _op1, val, _CRn, _CRm, _op2)  \
   ASM_THUMB_MODE   \
   : ARM_SWITCH_REG_ASM_L   \
@@ -491,9 +510,21 @@ arm_moe_label(uint32_t moe)
  * Read and write a memory mapped debug register. The register number is a word
  * offset from the base address.
  */
-#define ARM_MMAP_ADDR(reg)   (((volatile uint32_t*) debug_registers) + 
(reg))
-#define ARM_MMAP_WRITE(reg, val) *ARM_MMAP_ADDR(reg) = (val); 
_ARM_Data_synchronization_barrier()
-#define ARM_MMAP_READ(reg)   *ARM_MMAP_ADDR(reg)
+#define ARM_MMAP_ADDR(reg) \
+  (((volatile uint32_t*) debug_registers) + (reg))
+#define ARM_MMAP_WRITE(reg, val) *ARM_MMAP_ADDR(reg) = (val)
+#define ARM_MMAP_READ(reg) *ARM_MMAP_ADDR(reg)
+#define ARM_MMAP_WRITE_SYNC(reg, val) \
+  ARM_MMAP_WRITE(reg, val); \
+  _ARM_Data_synchronization_barrier(); \
+