is dl_iterate_phdr() supposed to be async-signal safe?

is dl_iterate_phdr() supposed to be async-signal safe?

[David Mosberger]

Subject pretty much says it all: I thought it was meant to be
async-signal safe but looking at the __pthread_mutex_lock() code, it
pretty clearly can't be, since it's updating the count and ownership
members non-atomically with respect to signal-delivery.  Or am I
missing something?

So much for dl_iterate_phdr() being an "obvious" interface... ;-/

	--david

Re: is dl_iterate_phdr() supposed to be async-signal safe?

[Roland McGrath]

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

Re: is dl_iterate_phdr() supposed to be async-signal safe?

[David Mosberger]

>>>>> 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

what to do about dl_iterate_phdr()

[David Mosberger]

dl_iterate_phdr() isn't signal-safe and therefore there is currently
no way to safely unwind out of a signal-handler.  My proposal to make
dl_iterate_phdr() async-signal-safe seems to have fallen on deaf ears.

So what's your position?  Is the official position that glibc simply
cannot safely unwind out of a signal handler or do you have an
alternate proposal in mind?

Thanks,

	--david