This is the mail archive of the
mailing list for the glibc project.
Re: Copy relocations against protected symbols
- From: Alan Modra <amodra at gmail dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Cary Coutant <ccoutant at google dot com>, Binutils <binutils at sourceware dot org>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 19 Dec 2014 08:43:54 +1030
- Subject: Re: Copy relocations against protected symbols
- Authentication-results: sourceware.org; auth=none
- References: <CAMe9rOoJ-0ER8VAckjZyLwdgGJFeQBfri+d+NY81WozizTnCQw at mail dot gmail dot com>
On Thu, Dec 18, 2014 at 11:02:59AM -0800, H.J. Lu wrote:
> Adding glibc.
> On Thu, Dec 18, 2014 at 10:52 AM, Cary Coutant <firstname.lastname@example.org> wrote:
> >> Should we simply disallow creating DSO with protected data on targets
> >> with copy relocation?
> > I don't think so. Protected symbols are useful, and their presence
> As soon as they are used in executable, the program will misbehave.
Not if the references in the executable are in code compiled with
-fPIC. I agree with Cary, disallowing protected visibility variables
in shared libraries, or disabling the compiler optimisation that
allows shared library code to access protected variables without a GOT
indirection, is too big a hammer.
> > doesn't mean that a copy relocation will be needed. It would be pretty
> > heavy-handed, since most targets do support copy relocations.
> When you create libfoo.so with normal data, bar, it will link and
> work fine with executable, x, which accesses bar. But after
> you change bar in libfoo.so to protected without relinking x, x will
> misbehave and users may not have a clue what is going on.
Right, but this is just one of many ways to shoot yourself in the
Australia Development Lab, IBM