This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.

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: is dl_iterate_phdr() supposed to be async-signal safe?

From: David Mosberger <davidm at napali dot hpl dot hp dot com>
To: Roland McGrath <roland at redhat dot com>
Cc: davidm at hpl dot hp dot com, libc-hacker at sources dot redhat dot com
Date: Thu, 1 Apr 2004 16:08:56 -0800
Subject: Re: is dl_iterate_phdr() supposed to be async-signal safe?
References: <16491.51649.225477.81600@napali.hpl.hp.com><200404012122.i31LM3sg027149@magilla.sf.frob.com>
Reply-to: davidm at hpl dot hp dot com

>>>>> On Thu, 1 Apr 2004 13:22:03 -0800, Roland McGrath <roland@redhat.com> said:

  Roland> Why would you have thought that it was?  It is
  Roland> well-specified that no interface is async-signal-safe unless
  Roland> explicitly listed as such.  No such claim was ever made
  Roland> about dl_iterate_phdr.

Because otherwise there is no way to unwind from a signal handler and
I was mislead by the fact that it was using a recursive lock (and it
was only indirectly calling pthread_mutex_lock(), which is defined not
to be async-signal safe).

Can this please be fixed?  Wouldn't it be sufficient to disable signal
delivery during lock acquisition/release and while modifying the ELF
object list?

	--david

Follow-Ups:
- what to do about dl_iterate_phdr()
  - From: David Mosberger

References:
- is dl_iterate_phdr() supposed to be async-signal safe?
  - From: David Mosberger
- Re: is dl_iterate_phdr() supposed to be async-signal safe?
  - From: Roland McGrath

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