Problem with libpthread of uClibc

Problem with libpthread of uClibc

[Nitin Garg]

Hi,

We are using ARM Cortex-A9 processor. The toolchain is gcc-4.0.0 with
uClibc-0.9.30 and the kernel is 2.6.28.

Using this toolchain when we build any application like "Hello World"
and link it against pthread lib, the application does a segmentation
fault when executed on target and gives "Illegal instruction" error
message.

I debugged the problem and it came out to be that "swp" instructions
were disabled on the cortex-a9. The SWP instruction has been
deprecated starting with the ARMv6 architecture. On newer ARMv7
processors, this instruction is disabled by default but it can be
enabled by bit 10 in the System Control register. We can also build
the kernel with CONFIG_OABI_COMPAT enabled.

The real problem seems to be in the linuxthreads of uClibc where "swp"
is being used for locks.
Shall this not be replaced with ldrex/strex for ARMv7 onwards?

Regards,
Nitin

Re: Problem with libpthread of uClibc

[Ian Lance Taylor]

Nitin Garg <nitingarg98@gmail.com> writes:

> We are using ARM Cortex-A9 processor. The toolchain is gcc-4.0.0 with
> uClibc-0.9.30 and the kernel is 2.6.28.
>
> Using this toolchain when we build any application like "Hello World"
> and link it against pthread lib, the application does a segmentation
> fault when executed on target and gives "Illegal instruction" error
> message.
>
> I debugged the problem and it came out to be that "swp" instructions
> were disabled on the cortex-a9. The SWP instruction has been
> deprecated starting with the ARMv6 architecture. On newer ARMv7
> processors, this instruction is disabled by default but it can be
> enabled by bit 10 in the System Control register. We can also build
> the kernel with CONFIG_OABI_COMPAT enabled.
>
> The real problem seems to be in the linuxthreads of uClibc where "swp"
> is being used for locks.
> Shall this not be replaced with ldrex/strex for ARMv7 onwards?

This message is not appropriate for the mailing list gcc@gcc.gnu.org.
gcc@gcc.gnu.org is for the discussion of gcc development.  Please take
any followups to this message to gcc-help@gcc.gnu.org.  Thanks.

Actually I'm not sure there is any gcc issue here at all.  gcc 4.0.0 is
fairly old.

Ian