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: Joseph Myers <joseph at codesourcery dot com>
- To: Daniel Colascione <dancol at dancol dot org>
- Cc: Zack Weinberg <zackw at panix dot com>, <emacs-devel at gnu dot org>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 18 Jan 2016 22:27:25 +0000
- 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>
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.
--
Joseph S. Myers
joseph@codesourcery.com