This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: protected data in a DSO with copy relocation
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 17 Dec 2014 15:22:53 -0800
- Subject: Re: protected data in a DSO with copy relocation
- Authentication-results: sourceware.org; auth=none
- References: <54919EB5 dot 5030209 at redhat dot com> <CAMe9rOrGcuMQ3J9iNwKvZ-H9irdqjataJzt1+Auck5_q6sOCNA at mail dot gmail dot com> <20141217225330 dot 375CB2C3ACD at topped-with-meat dot com>
On Wed, Dec 17, 2014 at 2:53 PM, Roland McGrath <roland@hack.frob.com> wrote:
>> I'd like to have a decision on
>>
>> https://sourceware.org/bugzilla/show_bug.cgi?id=17711
>>
>> If we want to support protected data in a DSO with copy relocation,
>> which will incur run-time and memory overhead, I can prepare ld.so
>> as well as linker patches. Otherwise, I will make a linker patch
>> to disallow protected data in a DSO with copy relocation.
>
> I think we certainly shouldn't do any rtld changes for this in the current
> cycle. If we can just punt thinking about it at all until after this
If we punt, we need to update the elf/vismain test which fails with
the current ld.
> release, that would be best. If we need some kind of decision sooner, then
> my inclination is to say that STV_PROTECTED is not useful enough to spend
> effort on supporting its corner cases. I'm not aware of uses cases for it
> that both appear in the real world and are actually worthwhile. But if
> there is no urgent need, then let's discuss this in detail after the release.
I agree.
--
H.J.