Bug#395135: Please requeue gclcvs_2.7.0-62 on alpha

[Steve Langasek <vorlon@debian.org>]

On Fri, Oct 27, 2006 at 09:48:43AM -0400, Camm Maguire wrote:
> > FWIW, after tracking down the last header problem on alpha I let the test
> > build continue on through to see if there were any other problems.  Aside
> > from taking a long time to build, it now seems to be getting stuck in an
> > infinite loop running raw_pcl_gcl -- according to strace, trying to call a
> > syscall #513 which AFAIK does not exist on alpha, which then fails
> > repeatedly with errno 103 (ECONNABORTED).  I have no idea what any of this
> > is -- I /could/ give it to the buildd to try, but I really don't have any
> > reason to believe it will build any better there.

> > Do you have any idea what this syscall is supposed to be?  Are we looking at
> > a glibc bug here?

> This is my guess.  If I could get access to a system, I could provide
> more information.  Any idea of when sid chroots on escher (or other)
> might become available again?

No, sorry; though I'm currently working on getting some kernel patches in
that would let Debian support another class of higher-end alphas, which
might help us get a faster (and accessible) porter system.

Does gcl make any syscalls itself?  That would be a significant pointer in
the direction of glibc if it doesn't.

> This code built quite recently on alpha.  I'm particularly interested
> in mips and alpha, as they test new bfd object relocation code put
> into gcl recently.  I'd like to make sure there is no regression here,
> though I suspect none.

> If there were a problem here, you would see it before raw_pcl_gcl.
> There is noting this binary does but run some very simple
> initialization code, and then dump its image with unexec.  saved_gcl
> and saved_mod_gcl, already produced, use the same dumping code, so I
> don't suspect anything here either.  

> It appears that some constant specifying the syscall has gotten messed
> up on alpha.  

> If I can get access, I'd be happy to test.  Otherwise, here is what
> needs doing:

> ./configure --enable-ansi -enable-debug && make

This just gives me a build failure.

gcc -c -g -fsigned-char -pipe -Wall  -g -mieee -I/home/devel/release/gclcvs-2.7.0/o -I../h -I../gcl-tk sfasl.c
In file included from sfaslbfd.c:175,
                 from sfasl.c:43:
sfaslbfd_alpha.c: In function ‘alphaelf_install_patches’:
sfaslbfd_alpha.c:162: error: assignment of read-only location
sfaslbfd_alpha.c:168: error: assignment of read-only location
sfaslbfd_alpha.c:173: error: assignment of read-only location
sfaslbfd_alpha.c:178: error: assignment of read-only location
sfaslbfd_alpha.c: In function ‘alphaelf_init_got_info’:
sfaslbfd_alpha.c:232: error: too few arguments to function ‘bfd_hash_table_init’
make[1]: *** [sfasl.o] Error 1
make[1]: Leaving directory `/home/devel/release/gclcvs-2.7.0/o'
make: *** [unixport/saved_pre_gcl] Error 2


> Come to think of it, this bug might have just appeared on alpha too:

> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387498

No, it's not the same bug; the test case for system() works fine on my alpha
when compiling with -pg.

Here's the full cycle from a current strace:

fork()                                  = ? ERESTARTNOINTR (To be restarted)
--- SIGPROF (Profiling timer expired) @ 0 (0) ---
sigreturn()                             = ? (mask now [CHLD])
syscall_513(0x200006816e8, 0x80000, 0x11f269038, 0x1, 0, 0x1223400f0, 0xfffffc0001aa4000, 0x200005b6a30, 0x8, 0x1fd, 0x20000557c58, 0, 0x7b0a75b, 0x20000689740, 0x11f268fa0, 0, 0x4082904a484b2a29, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0x3fe0000000000000, 0x154e, 0x40b54ee660000000, 0x40b54e6660000000, 0, 0x3fe6666660000000 <unfinished ...>
--- SIGPROF (Profiling timer expired) @ 0 (0) ---
<... syscall_513 resumed> )             = 0x67
[repeat ad infinitum]

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/