This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Any particular reason why mmap family functions aren't hidden in ld.so?
- From: Roland McGrath <roland at hack dot frob dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 15 Oct 2015 12:49:30 -0700 (PDT)
- Subject: Re: Any particular reason why mmap family functions aren't hidden in ld.so?
- Authentication-results: sourceware.org; auth=none
- References: <CAMe9rOp3tnr8iuJiH0wGgv69tdixyquqP_J8K4Q-xobpd8cQXw at mail dot gmail dot com> <20151015192840 dot 890D62C3C0E at topped-with-meat dot com> <CAMe9rOqi0pM_=2vLky0APCHPrdiU_eAdq__DNpLj0onw1MZfiQ at mail dot gmail dot com>
> Why does Hurd need PLT?
The functions in ld.so are special versions that can only be used at
bootstrap time. Once libc.so is loaded, open, mmap, etc. all come from
there. It's neither feasible nor desireable in the Hurd to have full
duplicates of the libc functions in ld.so.
> > mean just that the compiler doesn't know they will be resolved without a
> > PLT, right? The linker doesn't actually produce PLT entries for them
> > (except for Hurd).
>
> To call mmap via PLT on i386, compiler has to set up EBX. There is
> no need for it if mmap is hidden.
I understand what it means for the compiler to know whether a PLT might be
used. What I asked you was to confirm that you are just talking about such
compiler issues and not any link-time semantics issue.