This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Removal of unexec support from glibc malloc
- From: Florian Weimer <fweimer at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Daniel Colascione <dancol at dancol dot org>, Zack Weinberg <zackw at panix dot com>, emacs-devel at gnu dot org, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 19 Jan 2016 00:16:36 +0100
- Subject: Re: Removal of unexec support from glibc malloc
- Authentication-results: sourceware.org; auth=none
- References: <569CDB81 dot 6040600 at redhat dot com> <569D3BE0 dot 6050103 at cs dot ucla dot edu> <m2a8o2vg5x dot fsf at newartisans dot com> <569D4157 dot 7050408 at dancol dot org> <CAKCAbMiRVTT=UQeEcRiQJMCnNwoNqu71nrgkRvqYn4VjVJ-9ig at mail dot gmail dot com> <569D432F dot 9070308 at dancol dot org> <alpine dot DEB dot 2 dot 10 dot 1601182226390 dot 18513 at digraph dot polyomino dot org dot uk>
On 01/18/2016 11:27 PM, Joseph Myers wrote:
> On Mon, 18 Jan 2016, Daniel Colascione wrote:
>
>> On 01/18/2016 11:54 AM, Zack Weinberg wrote:
>>> On Mon, Jan 18, 2016 at 2:47 PM, Daniel Colascione <dancol@dancol.org> wrote:
>>>>
>>>> As long as the ABI support is there, we can keep using the "separate
>>>> malloc implementation" even if glibc doesn't cooperate by providing
>>>> convenient headers to access it.
>>>
>>> Clarification: it will not be possible to link new executables against
>>> the symbols in question. (This is what a "compat symbol" in glibc is -
>>> available only to existing binaries, not to new invocations of ld.)
>>
>> Oh, with a linker script or other hackery, I'm sure I could make it
>> available to new invocations of ld. It's just bytes.
>
> Being a compat symbol also means that future architecture ports and ABIs
> don't include the functionality at all.
And even if the symbol is still there, the the version you need to
supply will be architecture-specific. Don't do this. :)
Florian