[v2,04/12] sparc: add missing pthread_spin_lock/pthread_spin_trylock

tst-spin1.c compile breaks with:
test/nptl/tst-spin1.c:34: undefined reference to `pthread_spin_lock'

pthread_spin_lock and pthread_spin_trylock is missing while
building sparc. add the meta c files here.

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
---
 libpthread/nptl/sysdeps/sparc/pthread_spin_lock.c    | 5 +++++
 libpthread/nptl/sysdeps/sparc/pthread_spin_trylock.c | 5 +++++
 2 files changed, 10 insertions(+)
 create mode 100644 libpthread/nptl/sysdeps/sparc/pthread_spin_lock.c
 create mode 100644 libpthread/nptl/sysdeps/sparc/pthread_spin_trylock.c

On Thu, Aug 28, 2014 at 12:31:22PM +0200, Waldemar Brodkorb wrote:
> tst-spin1.c compile breaks with:
> test/nptl/tst-spin1.c:34: undefined reference to `pthread_spin_lock'
> 
> pthread_spin_lock and pthread_spin_trylock is missing while
> building sparc. add the meta c files here.

1) what about pthread_spin_unlock?
2) wouldn't it be nicer to teach
   libpthread/nptl/sysdeps/sparc/Makefile.arch which of sparc32/sparc64
   it should use?
3) As you have seen (and removed the typoed subdirs), there is a
   specialization for sparcv9 there which should probably be used.

Applied the below in the meantime, thanks!
> 
> Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
> ---
>  libpthread/nptl/sysdeps/sparc/pthread_spin_lock.c    | 5 +++++
>  libpthread/nptl/sysdeps/sparc/pthread_spin_trylock.c | 5 +++++
>  2 files changed, 10 insertions(+)
>  create mode 100644 libpthread/nptl/sysdeps/sparc/pthread_spin_lock.c
>  create mode 100644 libpthread/nptl/sysdeps/sparc/pthread_spin_trylock.c
> 
> diff --git a/libpthread/nptl/sysdeps/sparc/pthread_spin_lock.c b/libpthread/nptl/sysdeps/sparc/pthread_spin_lock.c
> new file mode 100644
> index 0000000..dcc5ae2
> --- /dev/null
> +++ b/libpthread/nptl/sysdeps/sparc/pthread_spin_lock.c
> @@ -0,0 +1,5 @@
> +#if defined(__arch64__)
> +#include "sparc64/pthread_spin_lock.c"
> +#else
> +#include "sparc32/pthread_spin_lock.c"
> +#endif
> diff --git a/libpthread/nptl/sysdeps/sparc/pthread_spin_trylock.c b/libpthread/nptl/sysdeps/sparc/pthread_spin_trylock.c
> new file mode 100644
> index 0000000..af63eec
> --- /dev/null
> +++ b/libpthread/nptl/sysdeps/sparc/pthread_spin_trylock.c
> @@ -0,0 +1,5 @@
> +#if defined(__arch64__)
> +#include "sparc64/pthread_spin_trylock.c"
> +#else
> +#include "sparc32/pthread_spin_trylock.c"
> +#endif
> -- 
> 1.8.5.2 (Apple Git-48)
> 
> _______________________________________________
> uClibc mailing list
> uClibc@uclibc.org
> http://lists.busybox.net/mailman/listinfo/uclibc

Hi Bernhard,
Bernhard Reutner-Fischer wrote,

> On Thu, Aug 28, 2014 at 12:31:22PM +0200, Waldemar Brodkorb wrote:
> > tst-spin1.c compile breaks with:
> > test/nptl/tst-spin1.c:34: undefined reference to `pthread_spin_lock'
> > 
> > pthread_spin_lock and pthread_spin_trylock is missing while
> > building sparc. add the meta c files here.
> 
> 1) what about pthread_spin_unlock?

Yeah, I need to check this. I put it on my TODO.

> 2) wouldn't it be nicer to teach
>    libpthread/nptl/sysdeps/sparc/Makefile.arch which of sparc32/sparc64
>    it should use?

Depends.

> 3) As you have seen (and removed the typoed subdirs), there is a
>    specialization for sparcv9 there which should probably be used.
> 
> Applied the below in the meantime, thanks!

Is uCLibc usable and tested in any way for Sparc64?
May be I got it wrong. Here how I understand the Sparc architecture
stuff:
- There are mainly three different instruction sets:
  SPARCv7
  SPARCv8
  SPARCv9

SPARCv7 is for older 32 Bit systems and should also work for every
other 32 Bit sparc system. SPARCv8 is the preferred 32 Bit
instruction set. This is what I test with qemu-system-sparc.
And there is SPARCv9 which is used for 64 Bit sparc systems.
I use "ultrasparc" gcc optimization for qemu-system-sparc64 and
glibc. Using either v9a or v9b doesn't work for Linux for me.

And then I have read about SPARCv8+, which can be used for
Sparc64 systems with a 32 Bit userland. (like x32 for x86_64?)

So what exactly you mean?

When just trying to use uClibc for sparc64 with CONFIG_SPARC_V9=y
I get following error:
libc/sysdeps/linux/sparc/__longjmp.S: Assembler messages:
libc/sysdeps/linux/sparc/__longjmp.S:33: Error: invalid operands
(*UND* and *ABS* sections) for `*'

In glibc __longjmp.S is not used for sparc64, so I am not confident
that uClibc is ever used for sparc64.

best regards
 Waldemar

On 29 August 2014 08:06:53 CEST, Waldemar Brodkorb <wbx@openadk.org> wrote:
>Hi Bernhard,
>Bernhard Reutner-Fischer wrote,
>
>> On Thu, Aug 28, 2014 at 12:31:22PM +0200, Waldemar Brodkorb wrote:


>Is uCLibc usable and tested in any way for Sparc64?

I don't think it is complete, no. I think Austin added just a stub but never continued it. We might as well remove it completely until someone interested in sparc64 comes along with patches.

thanks,

Hi Bernhard,
Bernhard Reutner-Fischer wrote,

> On 29 August 2014 08:06:53 CEST, Waldemar Brodkorb <wbx@openadk.org> wrote:
> >Hi Bernhard,
> >Bernhard Reutner-Fischer wrote,
> >
> >> On Thu, Aug 28, 2014 at 12:31:22PM +0200, Waldemar Brodkorb wrote:
> 
> 
> >Is uCLibc usable and tested in any way for Sparc64?
> 
> I don't think it is complete, no. I think Austin added just a stub but never continued it. We might as well remove it completely until someone interested in sparc64 comes along with patches.
> 
> thanks,

I agree here. uClibc focus is on embedded systems, I don't know any
sparc64/sparcv9 embedded hardware. Gaisler's leon3/leon4 is
sparc32/sparcv8. My old Javastation Krups is sparc32/sparcv8, too.

In which way you would accept removal of sparc64/sparcv9 stuff.
One big patch? Many small patches?

best regards
 Waldemar

On 30 August 2014 20:26:32 CEST, Waldemar Brodkorb <wbx@openadk.org> wrote:
>Hi Bernhard,
>Bernhard Reutner-Fischer wrote,
>
>> On 29 August 2014 08:06:53 CEST, Waldemar Brodkorb <wbx@openadk.org>
>wrote:
>> >Hi Bernhard,
>> >Bernhard Reutner-Fischer wrote,
>> >
>> >> On Thu, Aug 28, 2014 at 12:31:22PM +0200, Waldemar Brodkorb wrote:
>> 
>> 
>> >Is uCLibc usable and tested in any way for Sparc64?
>> 
>> I don't think it is complete, no. I think Austin added just a stub
>but never continued it. We might as well remove it completely until
>someone interested in sparc64 comes along with patches.
>> 
>> thanks,
>
>I agree here. uClibc focus is on embedded systems, I don't know any
>sparc64/sparcv9 embedded hardware. Gaisler's leon3/leon4 is
>sparc32/sparcv8. My old Javastation Krups is sparc32/sparcv8, too.
>
>In which way you would accept removal of sparc64/sparcv9 stuff.
>One big patch? Many small patches?

One big would be great.
TIA,
>
>best regards
> Waldemar
>