This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PR 18167, Relax PR 15228 protected visibility restriction


On 03/27/2015 05:25 PM, H.J. Lu wrote:
> On Fri, Mar 27, 2015 at 10:09 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Fri, Mar 27, 2015 at 10:06 AM, Pedro Alves <palves@redhat.com> wrote:
>>> On 03/27/2015 04:54 PM, H.J. Lu wrote:
>>>> On Fri, Mar 27, 2015 at 9:43 AM, Pedro Alves <palves@redhat.com> wrote:
>>>>> On 03/27/2015 04:40 PM, H.J. Lu wrote:
>>>>>> On Fri, Mar 27, 2015 at 9:38 AM, Pedro Alves <palves@redhat.com> wrote:
>>>>>
>>>>>>> Urgh.  The glibc issue sounds the most alarming.  If we can't keep
>>>>>>> back compatibility, isn't there a new bit/attribute we can put
>>>>>>> somewhere to tag new binaries with protected symbols in a
>>>>>>> way that existing systems just error out when loading them?
>>>>>>
>>>>>>
>>>>>> There is no backward compatibility to speak with since protected
>>>>>> data symbol never worked before.
>>>>>
>>>>> OK, but when it's all fixed, programs and libraries will start
>>>>> using the feature.  It'd be best if such programs/libraries just
>>>>> failed to load in older systems, than crash or corrupt data at random.
>>>>>
>>>>
>>>> If one of gcc, glibc or binutils isn't fixed, the program may misbehave.
>>>> I don't know how it be avoided at run-time with fixing all 3.
>>>
>>> I'm not really worried about gcc or binutils.  Those are easy to
>>> update.  The issue is picking a binary that was built against fixed
>>> gcc and binutils, and then running it on an system that happens to
>>> not have glibc fixed.  That just seems like ABI breakage.
>>>
>>> How about emitting a reference to a symbol that only fixed glibc
>>> provides?
>>
>> It is easy to verify.  Stay tuned.
>>
> 
> Please try the testcase in:
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=17711
> 
> If the run-time glibc isn't fixed, the program will crash.  It doesn't matter
> which glibc you link against.  If your old binary with protected symbol
> behaves, it will work with the fixed run-time glibc.

It aborts here, here:

(gdb) r
Starting program: /tmp/bug/x

Program received signal SIGABRT, Aborted.
0x0000003615e35877 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56        return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb) bt
#0  0x0000003615e35877 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x0000003615e36f68 in __GI_abort () at abort.c:89
#2  0x00000000004006e8 in main () at x.c:13
(gdb)

7       int main()
8       {
9         if (bar_p () != &bar)
10          __builtin_abort();
11
12        if (a_p () != &a)
13          __builtin_abort();   <<<<<<<<<<<
14
15        bar ();
16        if (a != 30)
17          __builtin_abort();
18        return 0;
19      }

That is, that isn't the loader crashing the program, but
just the program itself detecting that protected symbols
don't work.  Is that what you wanted me to verify?

Thanks,
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]