"Kevin B. McCarty" <[EMAIL PROTECTED]> writes:
> Hi,
> I am wondering: will g77 et al. cause programs to automatically align all
> 32-bit integers in memory with pointers that are multiples of 4 bytes?
> (Given that the integers are array elements that aren't members of any
> other structure, and exist at compile time.) Because I'm seeing a bug in
> pawX11.static (in cernlib's paw-static package) on m68k that appears to
> result from a violation of that assumption.
16 and 32 bit values must be word aligned or you get an exception.
Even if the kernel emulates unaligned access its very bad practice on
any arch.
> Here's a sample gdb session on powerpc, where it works correctly (I have
> omitted gdb output until the important point)
>
> arcturus[33]:~/Debian/cernlib/paw-test% gdb pawX11.static
> (gdb) b hlimit_
> (gdb) r
> (gdb) b mzbook_
> (gdb) c
> (gdb) b mzlift.F:340
> (gdb) c
> Breakpoint 3, mzlift_ (ixdiv=0x10579768, lp=0x10d6e3f8, lsupp=0x10d6e3e8,
> jbias=0x10487bec, name=0x10e64eec, nzero=0x1046e92c)
> at
> /home/kmccarty/Debian/cernlib/cernlib-2003.09.03/src/packlib/zebra/mq/mzlift.F:340
> 340 LQ(KQS+KADR) = NQLS
> (gdb) p *LSUPP
> $1 = (0, 0, 0, 0, 0, 0, 0, 0, 0)
> (gdb) n
> 342 79 LP(1) = NQLS
> (gdb) p *LSUPP
> $2 = (1999569, 0, 0, 0, 0, 0, 0, 0, 0)
> (gdb) p LSUPP
> $3 = (PTR TO -> ( integer (9))) 0x10d6e3e8
> (gdb) p & LQ(KQS+KADR)
> $4 = (PTR TO -> ( integer )) 0x10d6e3e8
>
> Second, the same session repeated on m68k:
>
> kullervo[13]:~/chroot-build/cernlib-2003.09.03/bin$ gdb ./pawX11.static
> [identical operations as above snipped]
> 340 LQ(KQS+KADR) = NQLS
> (gdb) p *LSUPP
> $1 = (0, 0, 0, 0, 0, 0, 0, 0, 0)
> (gdb) n
> 342 79 LP(1) = NQLS
> (gdb) p *LSUPP
> $2 = (30, -2100232192, 0, 0, 0, 0, 0, 0, 0)
> (gdb) p LSUPP
> $3 = (PTR TO -> ( integer (9))) 0x80c30c78
> (gdb) p & LQ(KQS+KADR)
> $4 = (PTR TO -> ( integer )) 0x80c30c7a
>
> Note that LQ(KQS+KADR) is now offset from LSUPP by 2 bytes even though
> both are declared as arrays of (4-byte) integers! So is this a bug in
> g77 / as / ld on m68k, or is the cernlib code just doing something
> unreliable?
>From the CPUs point that prefectly fine. word (16bit) alignment will
suffice. Cache line alignment for arrays might be faster though.
> Another oddity, by the way, is that the above problem only exists on m68k
> when the cernlib libraries are statically linked into the pawX11
> executable; when they are separate dynamic libraries, it does not occur
> (although other problems appear later).
>
> thanks,
MfG
Goswin
