glibc 2.21 - Machine maintainers, please test your machines.

[Chris Metcalf]

On 1/24/2015 10:37 AM, H.J. Lu wrote:
> On Sat, Jan 24, 2015 at 7:14 AM, Chris Metcalf <cmetcalf@ezchip.com> wrote:
>> On 1/23/2015 4:32 PM, Carlos O'Donell wrote:
>>> Dear Machine Maintainers,
>>>
>>> Please start testing your machines against glibc
>>> master.
>>>
>>> Please update the glibc 2.21 release page with your
>>> testing results:
>>>
>>> https://sourceware.org/glibc/wiki/Release/2.21
>>>
>>> If nobody objects I want to cut the release as soon
>>> as we have results for all the machines.
>>>
>>> Cheers,
>>> Carlos.
>>
>> tilegx64 is fine (modulo the one bug compiler bug that has been outstanding
>> for multiple glibc releases now).
>>
>> tilegx32 has a bunch of new failures, all of which manifest as bus errors:
>>
>> FAIL: nptl/tst-sem14
>> FAIL: nptl/tst-sem3
>> FAIL: nptl/tst-sem6
>> FAIL: nptl/tst-signal3
>> FAIL: nptl/tst-tls2
>> FAIL: nptl/tst-tls3
>>
>> I assume these are all from the new semaphore code but have not had an
>> opportunity to look more closely.  One thing that could cause this is if
>> somehow we are trying to do atomic operations on 64-bit values that aren't
>> aligned to an 8-byte boundary.
>>
> Can you verify if it is the case?
>
>

I have to run now but here's a quick gdb output.  It seems to be the case.

Program received signal SIGBUS, Bus error.
0xf7fb3c98 in __new_sem_wait_fast (definitive_result=0, sem=0xf7d30004)
     at sem_waitcommon.c:236
236           if (atomic_compare_exchange_weak_acquire (&sem->data, &d, d - 1))
(gdb) bt
#0  0xf7fb3c98 in __new_sem_wait_fast (definitive_result=0, sem=0xf7d30004)
     at sem_waitcommon.c:236
#1  __new_sem_wait (sem=0xf7d30004) at sem_wait.c:25
#2  0x00011f00 in ?? ()
Backtrace stopped: frame did not save the PC
(gdb) print &sem->data
$1 = (uint64_t *) 0xf7d30004

-- 
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com