This is the mail archive of the libc-alpha@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]

Re: PowerPC malloc alignment


> From: Roland McGrath <roland@redhat.com>
> 
> That can at least be made easy to detect gracefully via magic/version.  
> Is it pathologically difficult to cope with an old dumped state?
> (I'm sure we went into this at the time, but I'm hazy on the details now.)
> Ideally, it would be doable enough just to handle the existing misaligned
> allocations but always align the new ones.  That copes even if libc itself
> or some other new-but-compatible library (X, whatever) has newly-compiled
> code that manages to care about the alignment of its own allocations.  It
> is probably sufficient in practice just to have the alignment parameterized
> by the malloc_save_state so malloc_set_state from an old dumped emacs
> reverts the behavior to the smaller alignment.

The alignment is supposed to be a _constant_ in the malloc
implementation, so you couldn't easily parameterize it.  The only way
I would see w/o sacrificing massive amounts of performance would be to
have two different versions of malloc compiled into libc, one with the
old and one with the new alignment.  This could be selected via hooks,
and when malloc_set_state was called on an old heap the old version
would be used.  Yes, quite ugly.

But how did these long double types come about?  Wheren't they
available in old PowerPC versions (if yes, then the alignment should
have been 16 from the very start), or only with "-mlong-double-128"?

IOW, why does this problem suddenly appear?

Regards,
Wolfram.


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