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: fix ia64 longjmp() to work from alternate signal-stack


>>>>> On Thu, 26 Aug 2004 02:24:01 -0700, Ulrich Drepper <drepper@redhat.com> said:

  Uli> David Mosberger wrote:
  >> If there are no objections, please apply this patch.

  Uli> I don't like this.  The behavior of longjmp if the starting point is
  Uli> using the alternate stack while the destination uses the normal stack,
  Uli> is currently unspecified in POSIX.  I've asked for clarification in the
  Uli> POSIX working group.  The result I expect is "don't do it", aka,
  Uli> unspecified.

I wouldn't mind at all if that were the conclusion.  I even thought
SuS left this unspecified, but upon rereading the spec, it seems SuS
explicitly allows this case.  Can you let me know when you hear back?

  Uli> For the unwind/cancellation handling this might not apply.  But
  Uli> it is an implementation decision to use setjmp/longjmp.  So,
  Uli> the solution should be to use special versions of those
  Uli> interfaces in the nptl implementation.  For all platforms but
  Uli> ia64 the new names are just aliases of the normal code.  For
  Uli> ia64 this heavier code is used.  This will also take care of
  Uli> most of the performance penalties since they don't apply in
  Uli> general, only in the thread code.

Couldn't we avoid the setjmp/longjmp altogether?  On ia64, code
without unwind info is considered broken and since we unwind anyhow we
could have a C cleanup handler for start_thread() at almost zero cost.
That would obviate the need for setjmp() in start_thread() and might
even speed up thread-creation a little.

	--david


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