Re: Memory alignment of pointers for sparc64
On Wed, Sep 04, 2002 at 11:06:04PM -0700, Bill Moseley wrote: Hi, I was trying to build the C application swish-e on the Sourceforge Sun Ultra60 - Debian 3.0. Swish-e allocates memory from a memory pool. The application byte-aligns the allocated pointers based on the sizeof(void *). (Actually the original programmer used sizeof(long) ). So on 4 byte machines you would get pointers that end in 0, 4, 8, and C hex. On DEC alpha sizeof(void *) == 8 so the pointers low byte is 0 and 8. Now the problem is that on sparc64 sizeof(void *) == 4 but we need to align our pointers on 8-byte boundaries otherwise we get SIGBUS errors. I'm pretty sure you mean sparc and not sparc64 (even if you are running an ultra, it is still 32bit userspace). On sparc64, sizeof(void *) does in fact equal 8bytes (64bit bins). Why not force minimum 8byte allocations? Will it really cause that much of a usage problem? Would probably cause less fragmentation, I bet. Guess you could do: #ifdef __sparc__ # define PointerAlign 8 #else # define PointerAlign sizeof(void *) #endif What was wrong with the original usage of sizeof(long)? -- Debian - http://www.debian.org/ Linux 1394 - http://linux1394.sourceforge.net/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/
Re: Memory alignment of pointers for sparc64
At 09:17 AM 09/05/02 -0400, Michael J. Saletnik wrote: On September 4, 2002 at 23:06, Bill Moseley wrote: the allocated pointers based on the sizeof(void *). On September 5, 2002 at 08:13, Ben Collins wrote: What was wrong with the original usage of sizeof(long)? Wouldn't it be most correct to use sizeof(caddr_t) ? I'm not familiar with caddr_t. (And I don't really have a grasp of what the underlying issue is regarding memory alignment.) Still, caddr_t == 4 on this machine (where I need 8), so it can't be used in all cases. Thanks, -- Bill Moseley mailto:[EMAIL PROTECTED]
Re: Memory alignment of pointers for sparc64
On Thu, 5 Sep 2002, Bill Moseley wrote: About all I understand of this problem is that our code allocates memory on 4-byte boundaries, and that cased SIGBUS on this one machine. I printed out the results of malloc() calls and noticed it was always on 8-byte boundaries. Hard-coding to 8-byte fixed our code. AFAIK on 32 bit SPARC, like you are using (and on other platforms, like MIPS, etc) you often need to align structures on 8 bytes for floating point members. doubles have to be aligned on their size generally. If your structures contains only things = 32 bits then you can get away with a 4 byte alignment in general, but if you add a double or a long long then some arches will demand 8 bytes. The basic rule is that the member of a structure has to be aligned on it's size - so a 2 byte short needs to have an addresss congruent to 2, a 4 byte long needs to be congruent to 4, a double to 8. Generally an allocator of this nature should align to the largest intrinsic type used in the structures it is allocating for. If that's a double or a uint64_t then it has to be 8 bytes. Jason
Re: Memory alignment of pointers for sparc64
On Thu, 5 Sep 2002, Bill Moseley wrote: Here's where it's blowing up: struct dev_ino *p; struct stat buf; ... // allocate a bit of memory from the pool. p = (struct dev_ino *) Mem_ZoneAlloc( sw-Index-entryZone,sizeof(struct dev_ino)); p-dev = buf.st_dev; // *poof!* SIGBUS SIGBUS when the address ends in 4 or C but OK when it ends in 0 or 8. Hum, that seems a bit surprising, what does your 'struct dev_ino' look like? Jason
Re: Memory alignment of pointers for sparc64
At 02:16 PM 09/05/02 -0600, Jason Gunthorpe wrote:
On Thu, 5 Sep 2002, Bill Moseley wrote:
Here's where it's blowing up:
struct dev_ino *p;
struct stat buf;
...
// allocate a bit of memory from the pool.
p = (struct dev_ino *) Mem_ZoneAlloc(
sw-Index-entryZone,sizeof(struct dev_ino));
p-dev = buf.st_dev; // *poof!* SIGBUS
SIGBUS when the address ends in 4 or C but OK when it ends in 0 or 8.
Hum, that seems a bit surprising, what does your 'struct dev_ino' look
like?
struct dev_ino
{
dev_t dev;
ino_t ino;
struct dev_ino *next;
};
And now I see another SIGBUS with this code:
Program received signal SIGBUS, Bus error.
0x0001ae60 in coalesce_word_locations (sw=0xdbdf0, indexf=0xf46e8,
e=0x7037dd50) at index.c:2691
2691*(unsigned int *)size_p = tmp;
And if I print out the address:
tmp is an unsigned int.
size_p at: 9BB5D
Bus error.
My guess is that's another alignment error.
That bit of code is used to compress our data in RAM.
Thanks,
--
Bill Moseley
mailto:[EMAIL PROTECTED]
Re: Memory alignment of pointers for sparc64
If I understand correctly, how about `__alignof__', utilizing GCC's
knowledge of the architecture?
$ cat a.c
#include stdio.h
#ifdef __GNUC__
size_t alignment = __alignof__ (double);
#else
size_t alignment = 8;
#endif
main () { printf (%d\n, alignment); exit (0); }
$ arch cc a.c ./a.out
i586
4
---
$ arch cc a.c ./a.out
sparc64
8
