2020-10-16 07:33 skrev Sebastian Huber:
On 23/09/2020 12:24, Daniel Hellstrom wrote:
>> Command line defines are discouraged and in cpukit only
multilib
>> defined defines should be used. Can't you the existing
>> __FIX_LEON3FT_B2BST define to enable the errata workarounds?
>
> For UT700, for example, it is true that B2BST also needs to be
> defined, but in general a user may have TN0018 but not the
B2BST
since
> it was fixed in HW several years ago.
You mean users building for a custom chip design and a BSP which
is not
integrated in the RTEMS Project?
Yes. Maybe that should not be our primary focus for RTEMS though.
> There is no fix needed to the compiler or newlib affecting the
> multilibs, the workaround can be implemented purely in the
run-time
> time time which simplifies the impact on the user. When
building
> multiple BSPs this is very convenient too since the configure
line can
> remain the same regardless of the work around. The compiler
does
not
> emit any information about TN0018 or UT700 for example.
So far the rule was to use only multilib defined defines and CPU
options
in the cpukit. I am not sure what we should do to address issues
like
this. Maybe add CPU-specific CPU options?
We could turn on __FIX_LEON3FT_TN0018 define for the multilibs defined
in GCC, but make it RTEMS specific? Please see attached GCC patch.
This would take care of the mainstream users, and the other LEON3
users could enable the fix by adding the -D manually by specifying the
target CFLAGS when doing RTEMS configure? I could live with that.
When building with the GCC patch it gives:
daniel@daniel:/opt/rcc-1.3.0-gcc/src/samples$ sparc-gaisler-rtems5-gcc
-dM -E empty.c -mcpu=leon3 -mfix-gr712rc |grep TN0018
#define __FIX_LEON3FT_TN0018 1
daniel@daniel:/opt/rcc-1.3.0-gcc/src/samples$ sparc-gaisler-rtems5-gcc
-dM -E empty.c -mcpu=leon3 -mfix-ut700 |grep TN0018
#define __FIX_LEON3FT_TN0018 1
daniel@daniel:/opt/rcc-1.3.0-gcc/src/samples$ sparc-gaisler-rtems5-gcc
-dM -E empty.c -mcpu=leon3 -mfix-ut699 |grep TN0018
#define __FIX_LEON3FT_TN0018 1
daniel@daniel:/opt/rcc-1.3.0-gcc/src/samples$ sparc-gaisler-rtems5-gcc
-dM -E empty.c -mcpu=leon3 |grep TN0018
daniel@daniel:/opt/rcc-1.3.0-gcc/src/samples$ sparc-gaisler-rtems5-gcc
-dM -E empty.c -mcpu=leon |grep TN0018
We already have multilibs for these variants:
sparc-rtems6-gcc -print-multi-lib
.;
soft;@msoft-float
v8;@mcpu=v8
leon3;@mcpu=leon3
leon3v7;@mcpu=leon3v7
leon;@mcpu=leon
leon3/gr712rc;@mcpu=leon3@mfix-gr712rc
leon3v7/gr712rc;@mcpu=leon3v7@mfix-gr712rc
leon/ut699;@mcpu=leon@mfix-ut699
leon/at697f;@mcpu=leon@mfix-at697f
soft/v8;@msoft-float@mcpu=v8
soft/leon3;@msoft-float@mcpu=leon3
soft/leon3v7;@msoft-float@mcpu=leon3v7
soft/leon;@msoft-float@mcpu=leon
soft/leon3/gr712rc;@msoft-float@mcpu=leon3@mfix-gr712rc
soft/leon3v7/gr712rc;@msoft-float@mcpu=leon3v7@mfix-gr712rc
soft/leon/ut699;@msoft-float@mcpu=leon@mfix-ut699
soft/leon/at697f;@msoft-float@mcpu=leon@mfix-at697f
So adding a built-in define __FIX_LEON3FT_TN0018 to GCC 10 (and clang)
would be my preferred way to add this define for RTEMS. External users
can still define __FIX_LEON3FT_TN0018 on the command line or a header
file if needed.
Agreed. I will update the patch to remove the patch to the BSPs config
which adds the TN0018 build flags. When I tested my suggested
sparc/rtems GCC-10 patch it worked for the above listed multilibs (only
the affected ones defined the TN0018).
Independent of this we need a ticket for the TN0018.
I see you have created one, thanks.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
