[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#325600: closed by Aurelien Jarno <aurelien@aurel32.net> (Closing bugs fixed in unreleased version 2.4-1 of the glibc)

The patch that you didn't know existed was included with the bug report.

I am trying the patch that Aurelien suggested - it does look like a better solution - I was going to try to decode the inline assembler in that area this weekend to see if there was a mistake.

There have been offers on the debian-alpha list for Alpha machine donations - some of them decent enough machines.

What needs to happen for a machine to be useful for developers?


Pierre Habouzit wrote:
On Fri, Apr 13, 2007 at 10:26:09AM +0200, Uwe Schindler wrote:
Tom Evans a écrit :
When will this version be moved into stable/Etch?
This version (or a later one) will move to stable for Lenny, but will
never move to Etch, as it is now a released version.
Somewhere in the past there was a very simple patch (look for "not_cancel")
that worked for the 2.3 release of the glibc (Tom wrote that):

"If I simply change (in linuxthreads/sysdep/unix/sysv/linux/not-cancel.h) from:

# define waitpid_not_cancel(pid, stat_loc, options) \
  INLINE_SYSCALL (osf_wait4, 4, pid, stat_loc, options, NULL)


# define waitpid_not_cancel(pid, stat_loc, options) \
  wait4( pid, stat_loc, options, NULL )

all is well - I understand the performance benefits of the inlining,
but since x86 is NPTL anyway, perhaps this is an okay solution?

I'm guessing that there is an Alpha-related optimizer bug perhaps?
Or that the inline_syscall4 in sysdep/unix/alpha/sysdep.h is somehow

Why was this patch never included for stable?
  Because we weren't aware it existed ? Because no alpha machine is
available to developers for a year now ?

  You know we're not semi gods with an echelon trigger on any glibc
patch that floats in the intarweb.

  But if the patch is _indeed_ that simple, I truly believe we could
make it into etch-r1.

Reply to: