[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-gnu-arch] [bug #15915] MACHINE_ALIGNMENT miscalculated on PPC32

From: Tom Lord
Subject: [Bug-gnu-arch] [bug #15915] MACHINE_ALIGNMENT miscalculated on PPC32
Date: Mon, 27 Feb 2006 10:27:08 -0800
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc3 Firefox/1.0.7

Follow-up Comment #1, bug #15915 (project gnu-arch):

Wow.  I always knew that `gen-alignment' would eventually
come back and bite me somehow -- I just never knew exactly
how.  Now I do.

If I'm following the reports correctly, the real bug 
is in the invariant check.   The invariant check makes
a false assumption that the machine's strictest alignment
requirements are determined by the size of the largest
scalar type.

The macro MACHINE_ALIGNMENT is poorly named.  It should 
really be something like:

The primary use of MACHINE_ALIGNMENT is to safely wrap
`malloc' in an allocator that adds a header to allocated
memory.   `ar.c' is an example of such an allocator.
The user asks for N bytes.  We want a K byte header.
So we allocate:


bytes, put the header at byte 0, and start the user data
at byte:


The invariant that we are truly trying to maintain is that,
so long as `malloc' returns memory suitably aligned for anything,
so does our wrapper (such as the `ar' functions).

The actual invariant test in the code tests for a stricter 
condition that happens not to be true in this case.   It's
the invariant, not `gen-alignment', that is bogus.

A fix that showed up on the Red Hat bugzilla involved computing
MACHINE_ALIGNMENT differently.   That "fix" introduces a bug
(that may or may not actually effect existing architectures)
and should not be made.   It's the call to `invariant' that
contains the bug.



Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]