This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 00/13] nptl: Fix Race conditions in pthread cancellation (BZ#12683)
- From: Rich Felker <dalias at libc dot org>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Joseph Myers <joseph at codesourcery dot com>, libc-alpha at sourceware dot org
- Date: Sun, 11 Oct 2015 12:28:35 -0400
- Subject: Re: [PATCH 00/13] nptl: Fix Race conditions in pthread cancellation (BZ#12683)
- Authentication-results: sourceware.org; auth=none
- References: <1444234995-9542-1-git-send-email-adhemerval dot zanella at linaro dot com> <alpine dot DEB dot 2 dot 10 dot 1510071645260 dot 29388 at digraph dot polyomino dot org dot uk> <5615635F dot 5030306 at linaro dot org> <20151007210127 dot A30C02C39DF at topped-with-meat dot com> <56166ACB dot 40603 at redhat dot com>
On Thu, Oct 08, 2015 at 03:08:27PM +0200, Florian Weimer wrote:
> On 10/07/2015 11:01 PM, Roland McGrath wrote:
> >> My mistake, I have it changed in the initial cover letter, but I forgot
> >> to re-add when I had to rewrite it. And my understanding is for ILP32
> >> sizeof(long int) is the same as the sizeof(void*).
> >
> > No reason to assume that. Use uintptr_t.
>
> This type still wouldn't be correct if we ever end up with a 32-on-64
> platform which is mostly implemented in userspace. It would have 32-bit
> function pointers, but the vdso page would still be outside the first 4
> GiB of the address space.
The "P" in ILP32 means "pointer". I don't think you can call such a
platorm ILP32. Certainly lots of things many people would want to work
can't work -- backtraces, introspective profiling, etc. would all
break if there are valid userspace pointers that don't actually fit in
the pointer type.
IMO the right solution when implementing such a thing (32-on-64
implemented in userspace) is for the userspace runtime not to use the
vdso or to manually make a copy/remapping of the vdso in addressible
memory. Or if it's just "mostly in userspace" then the kernel can map
the vdso at the right place.
Rich