Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
On Fri, Oct 14, 2005 at 12:02:04AM -0400, Daniel Jacobowitz wrote: ... Just to clarify: if you fix the inline asm in glibc, then you don't need to recompile any of the currently broken libraries or applications. We don't need to fix the inline asm - the kernel is required to handle the misaligned accesses and in fact *normally* does. The following *short* thread and should explain what's going on with paer.debian.org: http://lists.parisc-linux.org/pipermail/parisc-linux/2005-May/026543.html thanks, grant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
On Thu, Oct 13, 2005 at 11:58:10PM -0600, Grant Grundler wrote: On Fri, Oct 14, 2005 at 12:02:04AM -0400, Daniel Jacobowitz wrote: ... Just to clarify: if you fix the inline asm in glibc, then you don't need to recompile any of the currently broken libraries or applications. We don't need to fix the inline asm - the kernel is required to handle the misaligned accesses and in fact *normally* does. The following *short* thread and should explain what's going on with paer.debian.org: http://lists.parisc-linux.org/pipermail/parisc-linux/2005-May/026543.html Oh, it seems the Debian kernel does not have that enabled by default. I am using the one from unstable (2.6.12), paer.debian.org uses the same one, and sarti.debian.org still uses a 2.4 one. I have found a sysctl access named kernel.unaligned-trap, which is set by default. If I clear this bit, the testcase I sent which include the source code of feholdexcept works correctly with both gcc-3.4 and with gcc-4.0. However if I use the feholdexcept from the glibc I still have a sigbus. Bye, Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
On Fri, Oct 14, 2005 at 10:50:38AM +0200, Aurelien Jarno wrote: On Thu, Oct 13, 2005 at 11:58:10PM -0600, Grant Grundler wrote: On Fri, Oct 14, 2005 at 12:02:04AM -0400, Daniel Jacobowitz wrote: ... Just to clarify: if you fix the inline asm in glibc, then you don't need to recompile any of the currently broken libraries or applications. We don't need to fix the inline asm - the kernel is required to handle the misaligned accesses and in fact *normally* does. The following *short* thread and should explain what's going on with paer.debian.org: http://lists.parisc-linux.org/pipermail/parisc-linux/2005-May/026543.html FYI, the Debian kernel is already using this patch in the 2.6.12 kernel. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
Aurelien Jarno wrote: [...] Oh yes, BTW, I have seen that glibc does not built anymore on hppa. It seems the new binutils does not accept some assembly instructions. Currently I am doing my tests with binutils 2.16.1. It has to be fixed before uploading a new glibc, but unfortunately I don't speak hppa assembly. Is there some build log somewhere (I have a look at http://buildd.debian.org/build.php?arch=hppapkg=glibc) but nothing newer then 2.3.5-6 :? Thanks, Joel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
On Fri, Oct 14, 2005 at 10:28:27PM +, Joel Soete wrote: Aurelien Jarno wrote: [...] Oh yes, BTW, I have seen that glibc does not built anymore on hppa. It seems the new binutils does not accept some assembly instructions. Currently I am doing my tests with binutils 2.16.1. It has to be fixed before uploading a new glibc, but unfortunately I don't speak hppa assembly. Is there some build log somewhere (I have a look at http://buildd.debian.org/build.php?arch=hppapkg=glibc) but nothing newer then 2.3.5-6 :? Don't worry about this - I've already checked in a fix to SVN this morning. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
[Ccing [EMAIL PROTECTED], because there is people who know hppa assembly
there]
Hi!
Steve Langasek a écrit :
Package: libc6
Version: 2.3.5-6.0.1
Severity: serious
Justification: this is the bug that broke the toolkit that held up the \
C++ transition that ruined the port that HP built
Hey Goto-san,
There is a bug in libm that results in unaligned access on hppa when calling
feholdexcept() or fegetenv(). Trivially reproducible with the following
code:
#include fenv.h
int main() {
int foo;
fenv_t fenv;
feholdexcept(fenv);
}
I'm afraid I can't offer a patch for this since I don't speak hppa assembly,
but the issue (and the fix) should be pretty obvious: fenv_t is a struct
composed of unsigned ints, so only 32-bit alignment is guaranteed;
feholdexcept() and fegetenv() populate the 8-int struct using four calls,
which means each call acts on 64 bits... and SIGBUS.
When looking at the assembly code generated with gcc-3.3/gcc-3.4 and
with gcc-4.0, I see some differences:
source code:
__asm__ (
fstd,ma %%fr0,8(%1)\n
fstd,ma %%fr1,8(%1)\n
fstd,ma %%fr2,8(%1)\n
fstd,ma %%fr3,8(%1)\n
: =m (*_regs), +r (_regs));
gcc-3.3/gcc-3.4 (code working correctly):
10624: 2e 91 10 23 fldd,ma -8(,r20),fpe6
10628: 2e 91 10 22 fldd,ma -8(,r20),fpe4
1062c: 2e 91 10 21 fldd,ma -8(,r20),fpe2
10630: 2e 91 30 20 fldd,mb -8(,r20),fr0
gcc-4.0 (SIGBUS):
1062c: 2f 91 10 23 fldd,ma -8(,ret0),fpe6
10630: 2f 91 10 22 fldd,ma -8(,ret0),fpe4
10634: 2f 91 10 21 fldd,ma -8(,ret0),fpe2
10638: 2f 91 30 20 fldd,mb -8(,ret0),fr0
I also don't speak hppa assembly, but it is obvious that the code does
not use the same registers. Maybe the bug is in gcc which generates
wrong code? At least the same source code built with gcc-3.3 and gcc-3.4
is working correctly.
Previous versions of gcc-4.0 where known to generate wrong code in the
glibc, causing fakeroot to stop working. Another gcc bug?
Bye,
Aurelien
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
On Thu, Oct 13, 2005 at 07:26:43PM +0200, Aurelien Jarno wrote: When looking at the assembly code generated with gcc-3.3/gcc-3.4 and with gcc-4.0, I see some differences: source code: __asm__ ( fstd,ma %%fr0,8(%1)\n fstd,ma %%fr1,8(%1)\n fstd,ma %%fr2,8(%1)\n fstd,ma %%fr3,8(%1)\n : =m (*_regs), +r (_regs)); gcc-3.3/gcc-3.4 (code working correctly): 10624: 2e 91 10 23 fldd,ma -8(,r20),fpe6 10628: 2e 91 10 22 fldd,ma -8(,r20),fpe4 1062c: 2e 91 10 21 fldd,ma -8(,r20),fpe2 10630: 2e 91 30 20 fldd,mb -8(,r20),fr0 gcc-4.0 (SIGBUS): 1062c: 2f 91 10 23 fldd,ma -8(,ret0),fpe6 10630: 2f 91 10 22 fldd,ma -8(,ret0),fpe4 10634: 2f 91 10 21 fldd,ma -8(,ret0),fpe2 10638: 2f 91 30 20 fldd,mb -8(,ret0),fr0 I also don't speak hppa assembly, but it is obvious that the code does not use the same registers. Maybe the bug is in gcc which generates wrong code? At least the same source code built with gcc-3.3 and gcc-3.4 is working correctly. No, it isn't: glibc (2.3.5-6.0.1) unstable; urgency=low * On hppa, build using gcc-3.4. -- Matthias Klose [EMAIL PROTECTED] Sat, 17 Sep 2005 10:55:42 + This is the version of libc6 running on the buildd and in paer's unstable chroot where I reproduced the error. So glibc is known to have problems on hppa when built with gcc-4.0, but this doesn't appear to be one of them. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
This one time, at band camp, Steve Langasek said:
On Thu, Oct 13, 2005 at 07:26:43PM +0200, Aurelien Jarno wrote:
When looking at the assembly code generated with gcc-3.3/gcc-3.4 and
with gcc-4.0, I see some differences:
I also don't speak hppa assembly, but it is obvious that the code does
not use the same registers. Maybe the bug is in gcc which generates
wrong code? At least the same source code built with gcc-3.3 and gcc-3.4
is working correctly.
No, it isn't:
glibc (2.3.5-6.0.1) unstable; urgency=low
* On hppa, build using gcc-3.4.
-- Matthias Klose [EMAIL PROTECTED] Sat, 17 Sep 2005 10:55:42 +
This is the version of libc6 running on the buildd and in paer's unstable
chroot where I reproduced the error. So glibc is known to have problems on
hppa when built with gcc-4.0, but this doesn't appear to be one of them.
I think you are misunderstanding him, Steve, or I am misunderstanding
the whole thing (which is not unlikely). I think Aurelian is saying
that the same source code that you supplied builds and runs fine with
gcc-3.4, but not with gcc-4.0:
[EMAIL PROTECTED]:~$ dchroot sid
Executing shell in chroot: /org/paer.debian.org/chroot/sid
[EMAIL PROTECTED]:~$ cat test.c
#include fenv.h
int main() {
int foo;
fenv_t fenv;
feholdexcept(fenv);
}
[EMAIL PROTECTED]:~$ gcc-3.4 -lm test.c -o test.3.4
[EMAIL PROTECTED]:~$ gcc-4.0 -lm test.c -o test.4
[EMAIL PROTECTED]:~$ ./test.3.4
[EMAIL PROTECTED]:~$ ./test.4
Bus error
This certainly smells more like a compiler bug than anything. The same
library and the same header files, 2 different compiler versions, 2
results.
Take care,
--
-
| ,''`.Stephen Gran |
| : :' :[EMAIL PROTECTED] |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
signature.asc
Description: Digital signature
Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
Hi,
Stephen Gran a écrit :
This one time, at band camp, Steve Langasek said:
On Thu, Oct 13, 2005 at 07:26:43PM +0200, Aurelien Jarno wrote:
When looking at the assembly code generated with gcc-3.3/gcc-3.4 and
with gcc-4.0, I see some differences:
I also don't speak hppa assembly, but it is obvious that the code does
not use the same registers. Maybe the bug is in gcc which generates
wrong code? At least the same source code built with gcc-3.3 and gcc-3.4
is working correctly.
No, it isn't:
glibc (2.3.5-6.0.1) unstable; urgency=low
* On hppa, build using gcc-3.4.
-- Matthias Klose [EMAIL PROTECTED] Sat, 17 Sep 2005 10:55:42 +
This is the version of libc6 running on the buildd and in paer's unstable
chroot where I reproduced the error. So glibc is known to have problems on
hppa when built with gcc-4.0, but this doesn't appear to be one of them.
I think you are misunderstanding him, Steve, or I am misunderstanding
the whole thing (which is not unlikely). I think Aurelian is saying
that the same source code that you supplied builds and runs fine with
gcc-3.4, but not with gcc-4.0:
[EMAIL PROTECTED]:~$ dchroot sid
Executing shell in chroot: /org/paer.debian.org/chroot/sid
[EMAIL PROTECTED]:~$ cat test.c
#include fenv.h
int main() {
int foo;
fenv_t fenv;
feholdexcept(fenv);
}
[EMAIL PROTECTED]:~$ gcc-3.4 -lm test.c -o test.3.4
[EMAIL PROTECTED]:~$ gcc-4.0 -lm test.c -o test.4
[EMAIL PROTECTED]:~$ ./test.3.4
[EMAIL PROTECTED]:~$ ./test.4
Bus error
This certainly smells more like a compiler bug than anything. The same
library and the same header files, 2 different compiler versions, 2
results.
Well we've discussed a bit of that on IRC with Steve, I think we have
two problems (maybe linked):
- gcc-3.4 and gcc-4.0 changed the way they align the code.
Have a look at your test.c file. There is nothing in it, and moreover
gdb show the problem appears in libm, which has been compiled with
gcc-3.4.
- gcc-4.0 generates wrong code
For that see my attached file. It's the file from the glibc, with the
code from Steve pasted at the end. It works with gcc-3.4, but fails
with gcc-4.0.
Bye,
Aurelien
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
/* Store current floating-point environment and clear exceptions.
Copyright (C) 2000 Free Software Foundation, Inc.
This file is part of the GNU C Library.
Contributed by David Huggins-Daines [EMAIL PROTECTED], 2000
The GNU C Library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
The GNU C Library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with the GNU C Library; if not, write to the Free
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307 USA. */
#include fenv.h
#include string.h
int
feholdexcept (fenv_t *envp)
{
fenv_t clear;
fenv_t * _regs = envp;
/* Store the environment. */
__asm__ (
fstd,ma %%fr0,8(%1)\n
fstd,ma %%fr1,8(%1)\n
fstd,ma %%fr2,8(%1)\n
fstd,ma %%fr3,8(%1)\n
: =m (*_regs), +r (_regs));
memcpy (clear, envp, sizeof (clear));
/* Now clear all exceptions. */
clear.__status_word = ~(FE_ALL_EXCEPT 27);
memset (clear.__exception, 0, sizeof (clear.__exception));
/* And set all exceptions to non-stop. */
clear.__status_word = ~FE_ALL_EXCEPT;
/* Load the new environment. */
_regs = clear;
__asm__ (
fldd,ma 8(%0),%%fr0\n
fldd,ma 8(%0),%%fr1\n
fldd,ma 8(%0),%%fr2\n
fldd,ma 8(%0),%%fr3\n
: : r (_regs));
return 0;
}
int main() {
int foo;
fenv_t fenv;
feholdexcept(fenv);
}
Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
On Fri, Oct 14, 2005 at 12:20:50AM +0200, Aurelien Jarno wrote: - gcc-4.0 generates wrong code For that see my attached file. It's the file from the glibc, with the code from Steve pasted at the end. It works with gcc-3.4, but fails with gcc-4.0. I don't think that's what is happening at all: I think that in one of these cases, your test file's on-stack fenv_t is aligned, and on the other it isn't. The code you posted for gcc 4.0 looks fine. I think the assembly is broken or the definition of fenv_t. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
On Thu, Oct 13, 2005 at 11:05:01PM +0100, Stephen Gran wrote: I think you are misunderstanding him, Steve, or I am misunderstanding the whole thing (which is not unlikely). I think Aurelian is saying that the same source code that you supplied builds and runs fine with gcc-3.4, but not with gcc-4.0: Well, while that's true, I don't believe that's what he was saying at the time; the 3.4 vs. 4.0 generated code he cited corresponded to the assembly from libm, not to the test case I provided. [EMAIL PROTECTED]:~$ gcc-3.4 -lm test.c -o test.3.4 [EMAIL PROTECTED]:~$ gcc-4.0 -lm test.c -o test.4 [EMAIL PROTECTED]:~$ ./test.3.4 [EMAIL PROTECTED]:~$ ./test.4 Bus error This certainly smells more like a compiler bug than anything. The same library and the same header files, 2 different compiler versions, 2 results. To say that this is a compiler bug, you would have to show that gcc-4.0 is *wrong* to 32-bit align the fenv_t struct instead of 64-bit aligning it. You'd have to check with the compiler folks to be sure, but I don't think this is a correct assertion for a struct of 32-bit unsigned ints. At any rate, knowing that gcc-3.4 does this alignment differently gives us a viable workaround for qt; since qt is already building with g++-3.4 on hppa (et al.), it's no trouble to also make it build-depend on and use gcc-3.4. On Fri, Oct 14, 2005 at 12:20:50AM +0200, Aurelien Jarno wrote: Well we've discussed a bit of that on IRC with Steve, I think we have two problems (maybe linked): - gcc-3.4 and gcc-4.0 changed the way they align the code. Have a look at your test.c file. There is nothing in it, and moreover gdb show the problem appears in libm, which has been compiled with gcc-3.4. - gcc-4.0 generates wrong code For that see my attached file. It's the file from the glibc, with the code from Steve pasted at the end. It works with gcc-3.4, but fails with gcc-4.0. I suspect that compiling this portion of glibc with gcc-4.0 will give the same behavior: building test.c with gcc-4.0 will fail, building test.c with gcc-3.4 will succeed. Either that, or both will fail if this is one of the cases where gcc-4.0 breaks glibc horribly, but I didn't see any reason to think this was the case. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
On Thu, Oct 13, 2005 at 05:04:55PM -0700, Steve Langasek wrote: To say that this is a compiler bug, you would have to show that gcc-4.0 is *wrong* to 32-bit align the fenv_t struct instead of 64-bit aligning it. You'd have to check with the compiler folks to be sure, but I don't think this is a correct assertion for a struct of 32-bit unsigned ints. If it wants to use fldd (floating point load double) it must be 8-byte aligned, otherwise it will take an unaligned access trap. I believe I added code to the kernel recently that will let someone toggle on and off unaligned access traps/logging with prctl... Might be worth checking. At any rate, knowing that gcc-3.4 does this alignment differently gives us a viable workaround for qt; since qt is already building with g++-3.4 on hppa (et al.), it's no trouble to also make it build-depend on and use gcc-3.4. Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
I don't think that's what is happening at all: I think that in one of these cases, your test file's on-stack fenv_t is aligned, and on the other it isn't. The code you posted for gcc 4.0 looks fine. I think the assembly is broken or the definition of fenv_t. drow is right, as usual. our fenv_t needs to be defined with __attribute__((aligned(8))) or similar. randolph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
On Fri, Oct 14, 2005 at 08:40:20AM +0800, Randolph Chung wrote: I don't think that's what is happening at all: I think that in one of these cases, your test file's on-stack fenv_t is aligned, and on the other it isn't. The code you posted for gcc 4.0 looks fine. I think the assembly is broken or the definition of fenv_t. drow is right, as usual. our fenv_t needs to be defined with __attribute__((aligned(8))) or similar. I'd recommend fixing the asm instead: that's an ABI change and would require heinous rebuilds. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
On Thu, Oct 13, 2005 at 08:54:30PM -0400, Daniel Jacobowitz wrote: drow is right, as usual. our fenv_t needs to be defined with __attribute__((aligned(8))) or similar. I'd recommend fixing the asm instead: that's an ABI change and would require heinous rebuilds. Sorry - I'm not following. The Application *Binary* Interface was providing 8 byte alignment with gcc 3.4, right? Why is it breaking the ABI if we tell gcc 4.0 to do the same? thanks, grant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
On Thu, Oct 13, 2005 at 09:17:21PM -0600, Grant Grundler wrote: On Thu, Oct 13, 2005 at 08:54:30PM -0400, Daniel Jacobowitz wrote: drow is right, as usual. our fenv_t needs to be defined with __attribute__((aligned(8))) or similar. I'd recommend fixing the asm instead: that's an ABI change and would require heinous rebuilds. Sorry - I'm not following. The Application *Binary* Interface was providing 8 byte alignment with gcc 3.4, right? Why is it breaking the ABI if we tell gcc 4.0 to do the same? No, the _type_ fenv_t is documented to have 4 byte alignment. In both. In 3.4 you got lucky and it was usually placed at 8. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
Daniel Jacobowitz a écrit : On Thu, Oct 13, 2005 at 09:17:21PM -0600, Grant Grundler wrote: On Thu, Oct 13, 2005 at 08:54:30PM -0400, Daniel Jacobowitz wrote: drow is right, as usual. our fenv_t needs to be defined with __attribute__((aligned(8))) or similar. I'd recommend fixing the asm instead: that's an ABI change and would require heinous rebuilds. Sorry - I'm not following. The Application *Binary* Interface was providing 8 byte alignment with gcc 3.4, right? Why is it breaking the ABI if we tell gcc 4.0 to do the same? No, the _type_ fenv_t is documented to have 4 byte alignment. In both. In 3.4 you got lucky and it was usually placed at 8. Ok, that's mean that theoretically it would break the ABI, but practically, it does not break the ABI as the alignment is the same (otherwise we would also have noticed SIGBUS in other applications). Said in other words, applications with 4-byte aligned fenv_t variables are not working (SIGBUS), so it won't hurt to break the ABI in that case, as the applications have to be rebuilt anyway to fix the problem. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
On Fri, Oct 14, 2005 at 05:59:33AM +0200, Aurelien Jarno wrote: Ok, that's mean that theoretically it would break the ABI, but practically, it does not break the ABI as the alignment is the same (otherwise we would also have noticed SIGBUS in other applications). Said in other words, applications with 4-byte aligned fenv_t variables are not working (SIGBUS), so it won't hurt to break the ABI in that case, as the applications have to be rebuilt anyway to fix the problem. Whichever you like then. I would appreciate it if someone could come up with a patch for one or the other, or at least an authoritative statement and I'll sort the code out in the morning; I have the next glibc upload otherwise ready. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
On Fri, Oct 14, 2005 at 05:59:33AM +0200, Aurelien Jarno wrote: Ok, that's mean that theoretically it would break the ABI, but practically, it does not break the ABI as the alignment is the same (otherwise we would also have noticed SIGBUS in other applications). Just to clarify: if you fix the inline asm in glibc, then you don't need to recompile any of the currently broken libraries or applications. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
On Thu, Oct 13, 2005 at 08:54:30PM -0400, Daniel Jacobowitz wrote: On Fri, Oct 14, 2005 at 08:40:20AM +0800, Randolph Chung wrote: I don't think that's what is happening at all: I think that in one of these cases, your test file's on-stack fenv_t is aligned, and on the other it isn't. The code you posted for gcc 4.0 looks fine. I think the assembly is broken or the definition of fenv_t. drow is right, as usual. our fenv_t needs to be defined with __attribute__((aligned(8))) or similar. I'd recommend fixing the asm instead: that's an ABI change and would require heinous rebuilds. After talking to Carlos, I'm going to take care of this in the morning and aim for an upload tomorrow. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
Daniel Jacobowitz a écrit : On Fri, Oct 14, 2005 at 05:59:33AM +0200, Aurelien Jarno wrote: Ok, that's mean that theoretically it would break the ABI, but practically, it does not break the ABI as the alignment is the same (otherwise we would also have noticed SIGBUS in other applications). Just to clarify: if you fix the inline asm in glibc, then you don't need to recompile any of the currently broken libraries or applications. Good point. However, I am not sure such instructions exists, as it seems the registers to load are 64-bit register. But it's only my opinion, as I don't speak hppa assembly. Please also note that all the assembly code in sysdeps/hppa/fpu/* seems to need patching. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
Daniel Jacobowitz a écrit :
On Fri, Oct 14, 2005 at 05:59:33AM +0200, Aurelien Jarno wrote:
Ok, that's mean that theoretically it would break the ABI, but
practically, it does not break the ABI as the alignment is the same
(otherwise we would also have noticed SIGBUS in other applications).
Said in other words, applications with 4-byte aligned fenv_t variables
are not working (SIGBUS), so it won't hurt to break the ABI in that
case, as the applications have to be rebuilt anyway to fix the problem.
Whichever you like then. I would appreciate it if someone could come
up with a patch for one or the other, or at least an authoritative
statement and I'll sort the code out in the morning; I have the next
glibc upload otherwise ready.
I have attached a patch that changes the alignment of the f_env type. I
have tested it separately from the glibc, it works. However, I would
prefer that some people have a look to the asm code of the glibc to see
what can be done.
Oh yes, BTW, I have seen that glibc does not built anymore on hppa. It
seems the new binutils does not accept some assembly instructions.
Currently I am doing my tests with binutils 2.16.1. It has to be fixed
before uploading a new glibc, but unfortunately I don't speak hppa assembly.
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
#! /bin/sh -e
# All lines beginning with `# DP:' are a description of the patch.
# DP: Description: Change type fenv_t type to 8 byte alignment, so
# that it can be access with 64-bit instructions.
# DP: Related bugs:
# DP: Dpatch author: Aurelien Jarno [EMAIL PROTECTED]
# DP: Patch author: Aurelien Jarno [EMAIL PROTECTED]
# DP: Upstream status:
# DP: Status Details:
# DP: Date: 2005-08-03
PATCHLEVEL=0
if [ $# -ne 2 ]; then
echo 2 `basename $0`: script expects -patch|-unpatch as argument
exit 1
fi
case $1 in
-patch) patch -d $2 -f --no-backup-if-mismatch -p$PATCHLEVEL $0;;
-unpatch) patch -d $2 -f --no-backup-if-mismatch -R -p$PATCHLEVEL $0;;
*)
echo 2 `basename $0`: script expects -patch|-unpatch as argument
exit 1
esac
exit 0
# append the patch here and adjust the -p? flag in the patch calls.
--- sysdeps/hppa/fpu/bits/fenv.h.orig 2001-07-06 06:55:52.0 +0200
+++ sysdeps/hppa/fpu/bits/fenv.h2005-10-14 06:09:22.246387881 +0200
@@ -67,7 +67,7 @@
{
unsigned int __status_word;
unsigned int __exception[7];
-} fenv_t;
+} __attribute__((aligned(8))) fenv_t;
/* If the default argument is used we use this value. */
#define FE_DFL_ENV ((fenv_t *) -1)
Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
On Fri, Oct 14, 2005 at 06:17:46AM +0200, Aurelien Jarno wrote: I have attached a patch that changes the alignment of the f_env type. I have tested it separately from the glibc, it works. Yes, your patch looks right. Please also add the following comment in front of the fenv_t declaration. It will help explain what's going on: /* While fr0-fr3 appear as 64-bit registers, they aren't 64-bit quantities. * They are really one 32-bit status register and seven 32-bit exception * registers. We just sodomize the fpu 64-bit store semantics for efficiency. * * 8 byte alignment is only needed for performance. * Normally the kernel will squawk about (but handle) unaligned accesses. * * fr4 is the first usable FP register. */ The above is a summary of an IRC conversation with the hppa glibc guru (Carlos O'donell), Kyle Mcmartin, and myself. However, I would prefer that some people have a look to the asm code of the glibc to see what can be done. Sorry - I've no clue where the offending asm lives. The asm ( 4 fstd ops) posted by Stephen Gran looked fine to me. I don't think anything needs to be done. BTW, the test case posted by Stephan Gran (sgran) does NOT fail for me. grundler 523gcc-3.4 -lm fptest.c -o test.3.4 grundler 524gcc-4.0 -lm fptest.c -o test.4.0 grundler 525./test.3.4 grundler 526./test.4.0 grundler 527 Here's what I get in the dmesg log instead of SIGBUS: test.4.0(3857): unaligned access to 0xbff4244c at ip=0x4044e9ff test.4.0(3857): unaligned access to 0xbff4244c at ip=0x4044ea03 test.4.0(3857): unaligned access to 0xbff4243c at ip=0x4044ea07 N.b.: I don't have high confidence in this kernel outout: o I should see 4 lines of output - one for each fstd op. o unaligned addresses should be 8 bytes apart, incrementing. And for the record: grundler 566uname -a Linux gsyprf11.external.hp.com 2.6.14-rc2-pa2 #2 SMP Thu Sep 29 20:24:31 PDT 2005 parisc64 GNU/Linux gcc version 3.4.5 20050706 (prerelease) (Debian 3.4.4-5) gcc version 4.0.2 (Debian 4.0.2-2) hth, grant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
