This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: glibc 2.21 - Master is frozen solid at -26 degC.


On 01/27/2015 06:56 PM, David Miller wrote:
> From: "Carlos O'Donell" <carlos@redhat.com>
> Date: Mon, 26 Jan 2015 23:59:56 -0500
> 
>> It's -26 degC in Deep River Ontario and the Ottawa river
>> is frozen solid ... and so is master.
>>
>> Please TO: me on all patches and I'll ACK them throughout
>> the day EST time.
>>
>> Manual fixes, obvious comment cleanups, and build fixes
>> within machine-specific files are OK.
>>
>> Thank you to everyone who has already posted test results
>> for your machine. Please keep testing.
>>
>> If you need help, please ask for it.
> 
> So I've got 32-bit sparcv9 and 64-bit sparc working by just blowing away
> all of the existing sparc sem_*.c files.

That makes sense. These architectures have useful working atomic.h
implementations that can do atomic-compare-and-exchange on 32-bit or
64-bit values. With those conditions that new semaphore implementation
should just work.

> I tried a pure 32-bit sparc build to start working on that part and I
> get very non-helpful warnings (which are treated as errors) during the
> NPTL build:
> 
> nptl-init.c: In function âsighandler_setxidâ:
> nptl-init.c:242:1: error: optimization may eliminate reads and/or writes to register variables [-Werror=volatile-register-var]
> nptl-init.c:242:1: error: optimization may eliminate reads and/or writes to register variables [-Werror=volatile-register-var]
> 
> I get these all over the NPTL code, and every instance points to the
> function's declaration rather than at any code within the function, which
> makes tracking down what it's unhappy about not so easy.
> 
> I'll keep digging into this.

The pure 32-bit sparc port does not use any volatile register variables
that I can see. It does use a register variable for __pthread_self,
and it does use volatile variables, but not both together.

The function sighandler_setxid uses tls.h, sysdep.h, and atomic.h,
so it's impossible to determine which might be at fault :-(

It's really weird the compiler doesn't reference a source line number.

I'd start with atomic.h.

Cheers,
Carlos.





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]