From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-383715-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 8027 invoked by alias); 11 Nov 2014 22:00:24 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 8013 invoked by uid 89); 11 Nov 2014 22:00:23 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2
X-HELO: mail-ob0-f181.google.com
Received: from mail-ob0-f181.google.com (HELO mail-ob0-f181.google.com) (209.85.214.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 11 Nov 2014 22:00:22 +0000
Received: by mail-ob0-f181.google.com with SMTP id uy5so8257304obc.12        for <gcc-patches@gcc.gnu.org>; Tue, 11 Nov 2014 14:00:20 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.182.163.33 with SMTP id yf1mr35238493obb.0.1415743220873; Tue, 11 Nov 2014 14:00:20 -0800 (PST)
Received: by 10.76.84.102 with HTTP; Tue, 11 Nov 2014 14:00:20 -0800 (PST)
In-Reply-To: <alpine.DEB.2.10.1411112131010.12642@digraph.polyomino.org.uk>
References: <20141111153449.GB52080@msticlxl57.ims.intel.com>	<alpine.DEB.2.10.1411111754330.26374@digraph.polyomino.org.uk>	<87r3x9a7yt.fsf@tassilo.jf.intel.com>	<CAMe9rOp52vqvhjkdcVmriiz6qVobkq-dLunq2nZdoLsmi9H3Hw@mail.gmail.com>	<20141111210127.GI12538@two.firstfloor.org>	<CAMe9rOqe5XFh0UKSVz3jVk74-GGkstnQL_ixRUixRVBvV08cVA@mail.gmail.com>	<20141111212426.GJ12538@two.firstfloor.org>	<alpine.DEB.2.10.1411112131010.12642@digraph.polyomino.org.uk>
Date: Tue, 11 Nov 2014 22:07:00 -0000
Message-ID: <CAMe9rOr1YiM53b3Ecun9VCt-OJCJ1BUbJLsHoVx6uc4eMSRE=Q@mail.gmail.com>
Subject: Re: [PATCH, MPX runtime 1/2] Integrate MPX runtime library
From: "H.J. Lu" <hjl.tools@gmail.com>
To: Joseph Myers <joseph@codesourcery.com>
Cc: Andi Kleen <andi@firstfloor.org>, Ilya Enkovich <enkovich.gnu@gmail.com>, 	GCC Patches <gcc-patches@gcc.gnu.org>
Content-Type: text/plain; charset=UTF-8
X-IsSubscribed: yes
X-SW-Source: 2014-11/txt/msg01094.txt.bz2

On Tue, Nov 11, 2014 at 1:33 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Tue, 11 Nov 2014, Andi Kleen wrote:
>
>> On Tue, Nov 11, 2014 at 01:04:42PM -0800, H.J. Lu wrote:
>> > On Tue, Nov 11, 2014 at 1:01 PM, Andi Kleen <andi@firstfloor.org> wrote:
>> > >> It is similar to libsanitizer.  Put it in glibc isn't going to work well
>> > >> for MPX.
>> > >
>> > > Can you explain it more please?
>> > >
>> >
>> > Are you suggesting putting MPX run-time in glibc?  Will we have
>> > 2 glibc, one with MPX run-time and one without MPX run-time?
>>
>> No, I just think signal chaining should be in glibc.

Currently mpx-runtime uses

dlsym(RTLD_NEXT, "sigaction");

to get the original sigaction in liibc.so.  Glibc does provides __sigaction
for the original sigaction.  But dlsym(RTLD_NEXT, is more portable.

> I do wonder whether the signal handler needs to be enabled by default or
> whether there should simply be a function __mpx_handle_sigsegv provided
> with instructions to the user on how it can be used to get extra
> MPX-related information when SIGSEGV occurs (in which case it's entirely
> the user's responsibility to write a handler calling their own handler and
> the MPX one, if desired).  Or an LD_PRELOAD library like libSegFault.
>

It is certainly an option.

-- 
H.J.