Re: [PATCH] malloc: Correct malloc alignment on 32-bit architectures [BZ #6527]

[Florian Weimer <fweimer at redhat dot com>]

On 05/13/2016 10:29 PM, Joseph Myers wrote:
> On Fri, 13 May 2016, Florian Weimer wrote:
>
> > We need to increase the malloc state version number, so that binaries
> > containing dumped heaps of the new layout will not try to run on
> > previous versions of glibc, resulting in obscure crashes.
>
> This increase is global for all architectures.  Do I understand correctly
> that it's harmless for architectures where malloc alignment isn't being
> changed?

Yes, the version comparison in malloc_set_state accepts the current and 
any older version, and we just end up refusing to run with a downgraded 
glibc unnecessarily.  If all goes well, there will be further 
backwards-incompatible changes which require another version bump in the 
2.24 cycle.  Or we remove the dumping capability completely (and just 
keeping the undumping part for compatibility with existing Emacs 
binaries).  After all, if we remove all the already-deprecated hooks, 
newly compiled Emacs will no longer call malloc_get_state and 
malloc_set_state.

> If we wished to increase alignment on another architecture, and didn't do
> so before 2.24 is released, would we need to increase this version again?

No, because the current undumping code works with any alignment.  But if 
we change the chunk header encoding, we need a new version.

> Do people think we should increase alignment on 32-bit x86, so that malloc
> returns memory properly aligned for _Decimal128 (the way the decimal
> floating-point specification adds the type means that malloc is meant to
> return memory appropriately aligned for it, and its alignment happens to
> be 16-byte) and __float128?

I'm not sure if we can do that.  The definition of max_align_t is part 
of the ABI.  Interposed mallocs will only provide 8-byte alignment. 
Applications will have a hard time figuring out that malloc provides 
16-byte alignment.

Thanks,
Florian