Updated Warnings Report
Hi I fixed about 20 warnings that impacted all BSPs. The PowerPC BSPs are still the worst culprits. I suspect this is due to Sebastian's recent changes. ftp://ftp.rtems.org/pub/rtems/people/joel/warnings/warnings-4.12-master-20170827b/ There are still 197 unique warnings which is way up. I am hoping that this number drops significantly after Sebastian cleans up the PowerPC BSPs. There are still some non-PowerPC warnings that need attention. I filed a ticket on a couple. Please dig into the warnings and help. Top Ten BSPs with Warnings 34 powerpc-phycore_mpc5554 (inBSP=0 inLibCPU=32) 34 powerpc-qoriq_core_0 (inBSP=0 inLibCPU=32) 34 powerpc-qoriq_core_1 (inBSP=0 inLibCPU=32) 34 powerpc-qoriq_e500 (inBSP=0 inLibCPU=32) 38 powerpc-ss555 (inBSP=0 inLibCPU=36) 71 powerpc-qoriq_e6500_64 (inBSP=0 inLibCPU=4) 4 arm-raspberrypi2 (inBSP=2 inLibCPU=0) 4 arm-raspberrypi (inBSP=2 inLibCPU=0) 6 powerpc-haleakala (inBSP=4 inLibCPU=0) 38 powerpc-mvme5500 (inBSP=36 inLibCPU=0) Thanks. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 2/2] main_dd.c: Eliminate no prototype warning for swab()
On Sun, Aug 27, 2017 at 5:02 PM, Joel Sherrill wrote:
> ---
> cpukit/libmisc/shell/main_dd.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/cpukit/libmisc/shell/main_dd.c b/cpukit/libmisc/shell/main_dd.c
> index e9c8bf3..6ae4abb 100644
> --- a/cpukit/libmisc/shell/main_dd.c
> +++ b/cpukit/libmisc/shell/main_dd.c
> @@ -73,6 +73,17 @@ __FBSDID("$FreeBSD: src/bin/dd/dd.c,v 1.43 2004/08/15
> 19:10:05 rwatson Exp $");
> #include
> #include
>
> +#ifdef __rtems__
> +/*
> + * We should be able to define _XOPEN_SOURCE=900 to get a prototype for
> + * swab() but if that is defined before including , then the RTEMS
> + * headers don't compile. If defined after including , then
> + * it still doesn't trip the include. Thus this prototype.
> + */
Why don't the rtems headers compile?
I don't see a patch 1/2.
> +
> +void swab(const void *from, void *to, ssize_t n);
> +#endif
> +
> #include "dd.h"
> #include "extern-dd.h"
>
> --
> 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 2/2] main_dd.c: Eliminate no prototype warning for swab()
On Mon, Aug 28, 2017 at 9:39 AM, Gedare Bloom wrote:
> On Sun, Aug 27, 2017 at 5:02 PM, Joel Sherrill wrote:
> > ---
> > cpukit/libmisc/shell/main_dd.c | 11 +++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/cpukit/libmisc/shell/main_dd.c b/cpukit/libmisc/shell/main_
> dd.c
> > index e9c8bf3..6ae4abb 100644
> > --- a/cpukit/libmisc/shell/main_dd.c
> > +++ b/cpukit/libmisc/shell/main_dd.c
> > @@ -73,6 +73,17 @@ __FBSDID("$FreeBSD: src/bin/dd/dd.c,v 1.43 2004/08/15
> 19:10:05 rwatson Exp $");
> > #include
> > #include
> >
> > +#ifdef __rtems__
> > +/*
> > + * We should be able to define _XOPEN_SOURCE=900 to get a prototype for
> > + * swab() but if that is defined before including , then the
> RTEMS
> > + * headers don't compile. If defined after including , then
> > + * it still doesn't trip the include. Thus this prototype.
> > + */
> Why don't the rtems headers compile?
>
>
Looks like rtems.h needs BSD stuff enabled to know the core time types.
When
you add _XOPEN_SOURCE 900, it doesn't compile. If you add it immediately
below rtems.h, then it doesn't have any impact.
Try removing the warning for a few minutes yourself and see if you have
any insight. My hunch is that this hints at something ugly.
> I don't see a patch 1/2.
>
I was working on a branch and the other patch was an obvious warning fix
so I committed it directly.
I posted this one because it is definitely more of a hack and hints at
some weird underlying header file issue.
>
> > +
> > +void swab(const void *from, void *to, ssize_t n);
> > +#endif
> > +
> > #include "dd.h"
> > #include "extern-dd.h"
> >
> > --
> > 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
x86 get TLS method
Hi I am working on a paravirtualized target that requires the code to be compiled with -fPIC. This changes the TLS method from %gs to calling a subroutine. My question is what's the generic way to get the TLS area for a thread? Is the ARM method in C specific to the ARM or generic? Thanks. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
