# New Ticket Created by Andy Dougherty
# Please include the string: [perl #17000]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt2/Ticket/Display.html?id=17000 >
On Sat, 31 Aug 2002, Steven W McDougall wrote:
> parrot t/pmc/perlhash_1.pbc
>
> produced a bus error.
>
> I chased the error down to parrot/hash.c: new_bucket(),
> ====>>>> bucket->value = *value; <<<<==== BUS ERROR HERE
[long interesting discussion about how bucket->value got to be 4-byte
aligned, but gcc needs 8-byte alignment for floats.]
Superp detective work!
> The align_1 parameter to mem_allocate() does not--as you might
> think--control the alignment of the allocated block. Rather, it
> controls the *size* of the allocated block, rounding it up to the next
> multiple of the power of 2 indicated by align_1. This means that the
> alignment of a block returned by mem_allocate() is dependent on the
> *previous* calls to mem_allocate().
In retrospect, that's an, err, odd design.
> I don't know how this thing is supposed to work, so I don't know how
> to fix it. Logically, there are a few possibilities.
>
> 1. Fix gcc on IRIX64 to permit assignment of unions with arbitrary
> alignment.
I suspect that's unlikely to happen soon.
This is a long-standing problem. Also, it affects SPARC as well as IRIX64.
> 2. Add a parameter to mem_alloc() (or use align_1) to control the
> alignment of the allocated block.
Yes, this sounds very sensible to me. (Specifically, using align_1.)
> 3. Require all callers of mem_alloc() to pass an align_1 parameter
> big enough to meet the alignment requirements of the platform.
> (Seems like the Wrong Thing.)
Agreed, but it would work in the short term.
The following patch effectively implmements #3. I think it's a temporary
hack, and mem_allocate() ought to implement #2 above instead, but that
will take more thought and time than I have today. (Such checks should be
made conditional on various Configure-determined cpp #defines so that that
checks would be performed only on platform configurations where they were
required. It should also be possible to make Configure-time space/speed
tradeoffs (e.g. always requiring 8-byte alignment at the cost of some
wasted space)).
This patch should help IRIX64. It also fixes gcc/SPARC, which currently
crashes in the same way as detailed above. It may also help Tru64, which
is plagued by unaligned access errors. Or it may not. I don't think it
will hurt :-).
diff -r -u parrot-orig/include/parrot/headers.h parrot-andy/include/parrot/headers.h
--- parrot-orig/include/parrot/headers.h Fri Aug 23 03:55:22 2002
+++ parrot-andy/include/parrot/headers.h Wed Sep 4 12:20:10 2002
@@ -17,7 +17,8 @@
#include "parrot/parrot.h"
#define BUFFER_ALIGNMENT 16
-#define STRING_ALIGNMENT 4
+/* XXX Temporary alignment hack. See mem_allocate in resources.c */
+#define STRING_ALIGNMENT 16 /* was 4 */
static void *
diff -r -u parrot-orig/resources.c parrot-andy/resources.c
--- parrot-orig/resources.c Sat Aug 24 01:31:20 2002
+++ parrot-andy/resources.c Wed Sep 4 12:26:08 2002
@@ -69,6 +69,15 @@
return new_block;
}
+/* Alignment problems: align_1 sets the size, but not the alignment
+ of the memory block we are about to allocate. The alignment of *this*
+ block is currently determined by the align_1 sent in by the
+ *previous* allocation. See
+ http://archive.develooper.com/perl6-internals%40perl.org/msg12310.html
+ for details.
+ Currently, we work around it by forcing all the *ALIGNMENT
+ #defines in include/parrot/*.h to be the same :-).
+*/
/* Allocates memory for headers */
static void *
mem_allocate(struct Parrot_Interp *interpreter, size_t *req_size,
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
