[gccsdk] UnixLib and ARMv8

Lee Noar leenoar at sky.com
Mon Mar 14 12:05:17 PDT 2016

On 12/03/16 11:53, Chris Gransden wrote:
> In article <56E2EDD9.7020802 at sky.com>,
>     Lee Noar <leenoar at sky.com> wrote:
>> On 05/03/16 17:23, Theo Markettos wrote:
>>> On Sat, Mar 05, 2016 at 04:06:12PM +0100, John Tytgat wrote:
>>>> On 03/01/2016 07:26 PM, Theo Markettos wrote:
>>>>> [...]
>>>>> I can do some implementation and testing, if this is deemed to be
>>>>> a good idea. ('testing' in a loose sense - provoking concurrency
>>>>> conditions being somewhat hard)
>>>> FYI, UnixLib has some testing code in its 'test' subdirectory (incl.
>>>> pthread).  It might be useful to verify nothing gets obviously
>>>> broken.
>>> Useful to know.
>>> I'll let Lee take the lead since he probably knows more than I about the
>>> internals, but let me know if you need help.
>> I've just committed some changes that determine whether to use SWP
>> or LDREX/STREX at runtime using the info that Ben posted as a guide.
>> Perhaps if you have a RPi3, you could see if Otter works?
>> I think the pthread testing code may need some work to bring it up
>> to date, plus all the tests need to be built with the -static flag, but
>> that's proving difficult to achieve.
> QupZilla and Otter browser seem to run ok at first but then crash with the
> same stack trace. Sometimes straight away or after a couple of minutes use.
> MPlayer also crashes in a silimar way but there is no stack trace. Command
> line programs run OK. Also ArcEm and !Nettle run OK too.
> Here's the stack trace from Otter browser,


Those programs that don't use pthreads should be okay, it's the
pthread code that's the problem.
I've order a RPi3, so hopefully some hands on experimenting will
help. In the meantime, if anyone can spot the issue, let me know.


More information about the gcc mailing list