This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/3] Mark ld.so internel mmap functions hidden
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Richard Henderson <rth at twiddle dot net>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 19 Oct 2015 15:19:37 -0700 (PDT)
- Subject: Re: [PATCH 1/3] Mark ld.so internel mmap functions hidden
- Authentication-results: sourceware.org; auth=none
- References: <1445189141-18068-1-git-send-email-hjl dot tools at gmail dot com> <20151019183113 dot 29D732C3AA0 at topped-with-meat dot com> <CAMe9rOo0cs_bDbKo1+-+ObeyDd09SUrPaYpCR7ACq0x0-f-usw at mail dot gmail dot com> <56255653 dot 1070500 at twiddle dot net>
> On 10/19/2015 09:31 AM, H.J. Lu wrote:
> > +# if IS_IN (rtld)
> > +# include <dl-mman.h>
> > +extern __typeof (__mprotect) __mprotect attribute_hidden;
> > +extern __typeof (__munmap) __munmap attribute_hidden;
>
> Surely if mmap can't be hidden, then munmap can't either.
Actually, that's not true. On the Hurd, the mmap in ld.so is a special
hack different from the real libc implementation because it has to handle
the file descriptor argument. munmap and mprotect have trivial
implementations that just use microkernel calls, so using the copies in
ld.so is fine (and might as well avoid the PLT when you can).
> Surely you should just put all of these within dl-mman.h, even if in the
> end there are a few lines of overlap.
Agreed. The details I just explained are very Hurd-specific, and it seems
sensible that the Hurd file declare as hidden the ones that can be because
of that Hurd-specific rationale.