You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 3944 Reporter: anonymous Assigned to:@xavierleroy Status: closed (set by @xavierleroy on 2006-01-04T09:28:04Z) Resolution: fixed Priority: normal Severity: minor Version: 3.09.0 Category: ~DO NOT USE (was: OCaml general) Monitored by: smimram jcristau
Bug description
Hi,
Recently the compilation of missinglib (an ocaml library without bindings) failed on sparc (in Debian) because the test program was producing a bus error [1].
Gdb gives the following:
(gdb) run
Starting program: /tmp/missinglib-0.4.10.debian/test/runtests.opt
........................................................
Program received signal SIGBUS, Bus error.
0x0005f698 in caml_format_float ()
(gdb) where
#0 0x0005f698 in caml_format_float () #1 0x0006a3ec in caml_c_call ()
The function caml_format_float is apparently called to print the duration of the tests. Notice that 0xa3f74 is not a multiple of 8, which I guess is the cause of this issue. This corresponds to the source code line
sprintf(dest, String_val(fmt), Double_val(arg));
So, here %i1 contains the float argument (arg) of the function. Maybe the float allocation should always return a 8-byte aligned cell? Aligning floats (i.e. C doubles) on values (here long) is not always enough since in this case sizeof(double) > sizeof(value) (8 > 4). For example, caml_copy_float does not to take care of alignment.
Please review the file config/m.h generated by configure. It should #define
ARCH_ALIGN_DOUBLE. (There is a special case for the Sparc in configure
to force it!) If it does not, try to see what went wrong in configure
(sorry, no access to a Debian/Sparc machine).
The problem seems to be that the configure script, when it looks for alignment requirements (ARCH_ALIGN_DOUBLE), doesn't detect this sparc correctly.
config.guess returns 'sparc64-unknown-linux-gnu', which doesn't match sparc--.
The pattern probably needs to be changed to reflect this
Original bug ID: 3944
Reporter: anonymous
Assigned to: @xavierleroy
Status: closed (set by @xavierleroy on 2006-01-04T09:28:04Z)
Resolution: fixed
Priority: normal
Severity: minor
Version: 3.09.0
Category: ~DO NOT USE (was: OCaml general)
Monitored by: smimram jcristau
Bug description
Hi,
Recently the compilation of missinglib (an ocaml library without bindings) failed on sparc (in Debian) because the test program was producing a bus error [1].
Gdb gives the following:
(gdb) run
Starting program: /tmp/missinglib-0.4.10.debian/test/runtests.opt
........................................................
Program received signal SIGBUS, Bus error.
0x0005f698 in caml_format_float ()
(gdb) where
#0 0x0005f698 in caml_format_float ()
#1 0x0006a3ec in caml_c_call ()
0x0005f680 <caml_format_float+240>: call 0x5d110 <caml_stat_alloc>
0x0005f684 <caml_format_float+244>: nop
0x0005f688 <caml_format_float+248>: mov %o0, %l0
0x0005f68c <caml_format_float+252>: mov %l0, %o0
0x0005f690 <caml_format_float+256>: mov %i0, %o1
0x0005f694 <caml_format_float+260>: call 0x7d814
0x0005f698 <caml_format_float+264>: ldd [ %i1 ], %o2
0x0005f69c <caml_format_float+268>: call 0x5d3d4 <caml_copy_string>
(gdb) p (double*)$i1
$1 = (double *) 0xa3f74
The function caml_format_float is apparently called to print the duration of the tests. Notice that 0xa3f74 is not a multiple of 8, which I guess is the cause of this issue. This corresponds to the source code line
sprintf(dest, String_val(fmt), Double_val(arg));
So, here %i1 contains the float argument (arg) of the function. Maybe the float allocation should always return a 8-byte aligned cell? Aligning floats (i.e. C doubles) on values (here long) is not always enough since in this case sizeof(double) > sizeof(value) (8 > 4). For example, caml_copy_float does not to take care of alignment.
Thanks.
[1] http://buildd.debian.org/fetch.php?&pkg=missinglib&ver=0.4.10.debian-2&arch=sparc&stamp=1136143511&file=log&as=raw
The text was updated successfully, but these errors were encountered: