This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] HPPA/IA64 : Don't use broken DL_AUTO_FUNCTION_ADDRESS()
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Mike Frysinger <vapier at gentoo dot org>, libc-alpha at sourceware dot org
- Cc: Guy Martin <gmsoft at tuxicoman dot be>, Andreas Schwab <schwab at linux-m68k dot org>
- Date: Sat, 19 Oct 2013 20:11:12 -0400
- Subject: Re: [PATCH] HPPA/IA64 : Don't use broken DL_AUTO_FUNCTION_ADDRESS()
- Authentication-results: sourceware.org; auth=none
- References: <20131017214754 dot 00555bf3 at dellete> <871u3ina5t dot fsf at igel dot home> <b42704e5527fa00f6e69cacd0d62c19d at tuxicoman dot be> <201310190206 dot 07506 dot vapier at gentoo dot org>
On 10/19/2013 02:06 AM, Mike Frysinger wrote:
> On Friday 18 October 2013 08:04:18 Guy Martin wrote:
>> On 2013-10-18 12:30, Andreas Schwab wrote:
>>> Guy Martin <firstname.lastname@example.org> writes:
>>>> To prevent this, we use instead the existing macro
>>>> DL_STATIC_FUNCTION_ADDRESS() which is identical to
>>>> DL_AUTO_FUNCTION_ADDRESS() but declares fptr as static.
>>> Can the callers ever be reentered?
>> AFAICS, it can't. The macro using DL_STATIC_FUNCTION_ADDRESS() are
>> DL_DT_INIT_ADDRESS() which is only used in dl-init.c and
>> DL_DT_FINI_ADDRESS() used in dl-fini.c and dl-close.c.
>> The only case where this might possibly be reentered would be parallel
>> calls of dlopen()/dlclose(). I'm not even sure those calls are supposed
>> to be thread safe.
> they aren't supposed to be, but we try to make them so
Are you certain?
I thought POSIX says (indirectly) that dlopen and dlclose
must be thread safe.
e.g. They are not on the list of functions allowed to be
thread unsafe, therefore they must be thread safe.
So it's entirely possible we have concurrent calls to dlopen
in progress, but the dl_load_lock should serialize the loading
of the object.
As long as the uses of DL_STATIC_FUNCTION_ADDRESS() fall within
the critical regions protected by dl_load_lock then they should
Andreas makes a good comment that they should really be rewritten
to avoid needing to create the function pointer, instead the code
should create and call it as required (that way the created fptr
need never leave scope). However doing so might be more work than
you have time for.
Therefore if you can show DL_STATIC_FUNCTION_ADDRESS uses are
serialized by dl_load_lock, then I think the patch is OK.