Re: PATCH: Malloc fails if MALLOC_ALIGNMENT > 2 * SIZE_SZ

[Roland McGrath <roland at hack dot frob dot com>]

> Well, as usual, H.J. hasn't said why he wants the change - so I'm not
> sure what he thinks he's doing with the revised patch.  Is it for an
> out-of-tree ABI?  Maybe x32?

He certainly should have said more in this re-posting.  But to be fair,
he did post it as an x32 change earlier (a month ago, in
http://sourceware.org/ml/libc-alpha/2011-07/msg00129.html).
I specifically asked him to separate his follow-on change from your old
change and re-post them for individual consideration.  (Of course,
he never did describe why his additional change was necessary.)

> As is, it will break Emacs on PPC -mlong-double-128.  

What about the version that doesn't change the MALLOC_ALIGNMENT default
and just adds the other code?  IMHO it could use a bit more commentary
about what the changes are accomplishing and why they are necessary,
which you could supply.

> My preference would be to emit some sensible error message before
> aborting, or to have malloc_set_state return an error; that latter is the
> most independently correct choice, but Emacs does not check for an error
> return, so it's not of as much practical value.  IMO it is too much to
> ask to preserve compatibility on this ABI, at significant complexity
> cost, solely for the benefit of emacs.  I would be outright amazed if
> anyone else called malloc_set_state.

Unfortunately, I don't think that's acceptable.  Wise or not, it's in
the ABI and we just don't go around breaking the ABI for existing
binaries like this.  

I would not be quite so amazed to find other users--any system doing a
"load up and dump" sort of operation could have the same need, and there
have been others of those before.  Besides, Emacs is the most important
existing binary on any system. ;-)

I would certainly be open to finding different ways to support such
things in the future, which might be less burdensome to maintaining ABI
compatibility than malloc_set_state is.  For example, I think it would
be fine to do it in a way wherein, for allocations that were made before
dumping, calling free after re-loading with a newer libc is a no-op
(and/or realloc cannot reuse).

Since the immediate interest in this is not for the benefit of
powerpc32, clearly what we should do right now as regards powerpc32 is
just leave well enough alone and not change MALLOC_ALIGNMENT for any
existing configuration.  For example, we could make the definition
conditional on SHLIB_COMPAT.

While we don't really have to worry about the situation of changing
MALLOC_ALIGNMENT right now, it seems worthwhile for someone to put some
consideration into what it would actually take to add some backward
compatibility support for malloc_set_state.  For example, I think it
would be entirely acceptable to have an old-version-set malloc_set_state
that does something rather costly.


Thanks,
Roland