From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from systemhalted (CPE0080c82c70ca.cpe.net.cable.rogers.com [24.112.140.233]) by dsl2.external.hp.com (Postfix) with ESMTP id 5FB3A4829 for ; Mon, 26 Aug 2002 13:43:54 -0600 (MDT) Date: Mon, 26 Aug 2002 15:41:35 -0400 From: Carlos O'Donell To: debian-glibc@lists.debian.org Cc: parisc-linux@lists.parisc-linux.org Message-ID: <20020826194135.GC632@systemhalted> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [parisc-linux] Breaking PARISC ABI - Testing procedures? Sender: parisc-linux-admin@lists.parisc-linux.org Errors-To: parisc-linux-admin@lists.parisc-linux.org List-Help: List-Post: List-Subscribe: , List-Id: parisc-linux developers list List-Unsubscribe: , List-Archive: debian-gcc, I sense another PARISC ABI breakage coming in the very near future. The ABI breakage is caused by the following three items: 1- setjmp/longjmp implementation is flawed (Testing) 2- mcontext_t is incorrect in glibc (BTS #157374) 3- sizeof(long double) is incorrect in gcc and glibc (?) My main question is: How does one run a preliminary test to ferret out possibly problems that were not forseen? My current procedure is to build a new glibc, create a chroot, install glibc there and begin building things. Does anyone have a general procedure for this? Or is this what experimental or unstable is about? :/ --- I'm working on providing various test cases for "1-" and I already have a patch in my local glibc tree (the initial patch made the mistake of not allocating enough room for jmpbuf - kudos to Randolph for noticing that during RFC). I have a patch for "2-" and it works, but we have a kernel bug when copying registers into the sigcontext that gets passed back to a 32-bit userspace from a 64-bit kernel. Luckily the old definition of mcontect_t matches the new sigcontext typedef for accesses to general registers and floating point registers, so we maintain backwards compat in that scenario. I would like to note that it has never worked when running a 64-bit kernel under parisc :} The last issue will get fixed when I get around to poking changes at gcc. c.