This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

--- Comment #7 from Jouko Orava <jouko.orava at iki dot fi> ---
(In reply to joseph@codesourcery.com from comment #6)
> I don't think malloc should try to provide alignment for vector types,

Pity. It causes surprising segfaults for existing code,
and few programmers seem to understand the cause or mechanism.

On affected architectures, modifying malloc() is the best option;
the amount of existing code that assumes malloc() returns a pointer
suitable for even vector types, is just too large to manage otherwise.

I guess it is best if I take the easy way out, and instead of
trying to fix the issue, I shall work around it. I can trivially
provide a small library to override the glibc allocator, providing
sufficiently aligned pointers even for vector types.

GNU Fortran already uses malloc()/calloc() wrappers, so it should
be easy to patch separately at the GCC end (although, to be honest,
I don't think that will be acceptable to GCC folks, either).

> The most recently discussed suggestion for dealing with malloc_get_state / 
> malloc_set_state is that malloc_set_state should mark all previous 
> allocations as unfreeable

I'm sure emacs users will love that feature.

I'd thought that a slow path that uses e.g. separate metadata pool, so that it
can trivially (but slowly) support any alignment, would have been a more
sensible approach. After all, most users I know would prefer slower operation
to out of memory errors. Most Linux distributions do not have user limits that
would stop a memory-hogging userspace application from triggering the OOM
killer. (Or didn't it come up what would happen if the malloc_get_state() -
malloc_set_state() cycle would be repeated a few times?)

Anyway, thank you for your time, and for reading my overly verbose messages;
I'm sorry I couldn't be of more use with respect to this bug.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]