[PATCH] malloc: Remove malloc_get_state, malloc_set_state

[Florian Weimer]

On 06/10/2016 07:42 PM, Paul Eggert wrote:
> Thanks for doing all this. Some comments:
>
>> +* The __malloc_get_state and __malloc_set_state functions have been
>> removed
>> +  from the API.  __malloc_get_state has been replaced with a stub
>> +  implementation.  Existing undumped Emacs binaries will have to be
>> +  recompiled so that they do not use glibc malloc (or malloc heap
>> dumping).
>> +  Existing installed Emacs binaries (after dumping) are not affected
>> by this
>> +  change.
>
> The NEWS item should talk about the public API and so should refer to
> names without leading underscores, and it'd be helpful to have a clearer
> discussion about the backwards-compatibility constraints. Perhaps
> wording like the following instead?
>
> -----
> The malloc_get_state and malloc_set_state functions have been removed.
> Already-existing binaries that dynamically link to these functions will
> get a hidden implementation in which malloc_get_state is a stub.  As far
> as we know, these functions are used only by GNU Emacs and this change
> will not adversely affect already-built Emacs executables.  Any undumped
> Emacs executables, which normally exist only during an Emacs build,
> should be rebuilt by re-running 'configure; make' in the Emacs build tree.
> -----

Thanks, I've incorporated this into the attached patch.

>> +attribute_compat_text_section
>> +malloc_get_state (void)
>>   {
>> ...
>> +  return NULL;
>>   }
>
> Perhaps __malloc_get_state should set errno to ENOSYS?  Emacs won't care
> about errno, so this would merely be insurance in case someone else does
> care.

Fixed.

> Perhaps the test program should be retained and should check that the
> hidden __malloc_get_state function indeed returns NULL?  Dunno how you'd
> test __malloc_set_state....

I have implemented a proper (obviously very white box) test.  The test 
passes on x86_64 and ppc.  It should be fairly realistic as far as such 
things go.  We do not want to maintain a copy of the Emacs unexec 
mechanism inside glibc, so this is a good as it gets, I think.

The test depends on the machinery for referencing compatibility symbols 
I posted earlier.

Thanks,
Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: malloc_set_state.patch
Type: text/x-patch
Size: 22985 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20160623/85f03cd4/attachment.bin>