[Bug malloc/6527] [powerpc] Malloc alignment insufficient for PowerPC

["jouko.orava at iki dot fi" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=6527

Jouko Orava <jouko.orava at iki dot fi> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jouko.orava at iki dot fi

--- Comment #5 from Jouko Orava <jouko.orava at iki dot fi> ---
Insufficient alignment in malloc()/calloc() pointers is now plaguing SSE4 and
AVX support on x86-64, too; see GCC bugzilla bugs #55916 and related #60088 for
examples. GCC does provide the __BIGGEST_ALIGNMENT__ preprocessor macro, and
future glibc might prefer to use that (rounded up to a power of two) for
alignment, to avoid these issues.

Due to existing malloc_get_state/malloc_set_state users (emacs),
we cannot just change the alignment.

Currently, existing malloc_get_state dumps contain versions 1 to 4, major
version number being zero. Ignoring the difficulties in implementation, we
could use a specific major state version number for new states, with minor
version number indicating the native/minimum alignment shift (log2 of
MALLOC_ALIGNMENT). Then, the case of zero major, 1 to 4 minor state,
becomes just a special case; alignment being the current one used for that
architecture in glibc.

As to the implementation, the only sane way I can think of is to add tests with
unlikely jumps to a slow path to the beginning of every public API call,
in case the "current alignment" is not the one optimized for at glibc compile
time.

(Note that this would allow an user to use a recompiled glibc with different
 optimal alignment, without breaking existing state dumps.)

Is there anything in this approach that makes it obviously/immediately
unacceptable?

-- 
You are receiving this mail because:
You are on the CC list for the bug.