From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6830 invoked by alias); 3 Oct 2016 09:45:12 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 6594 invoked by uid 89); 3 Oct 2016 09:45:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*p:D*org, consensus, exploited, HTo:D*oracle.com X-HELO: mail-pa0-f51.google.com Received: from mail-pa0-f51.google.com (HELO mail-pa0-f51.google.com) (209.85.220.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 03 Oct 2016 09:44:50 +0000 Received: by mail-pa0-f51.google.com with SMTP id qn7so59532536pac.3 for ; Mon, 03 Oct 2016 02:44:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=FV6sIRhEzqBx/ilW/AgVg9S9qsxiTVS7gIUvfRDTTvI=; b=WpL0xUC9D0Foz6dr2+4xih+0MPda6vfn+WfjdPvRwXm3KdVyWG+au/zbABKNBNcytu 3TFeszXBCmZoDYb0KN2muZl8rEqwP0+66TS0gFNKKp2igdoZxNbaLb5VSVRlKtjJ4Aa9 x5Cs27DoIzN/pqaZIwBBybyp5eyLpMG5HBvndad5nNk0ObCvDArIVEtFg33f9A6q9ZAv gNTAdlfTZdajRvqrwkr/be0I9XjLool1Zqet5BxxdAPQnIKieuSIyHfkK3UsJXevmik1 K2UBo7R2WWrfhE5em3p4ynZ+16UwVXaiPkm4S7iNfwW8nCLeqssji5H5CQpAAgM2wVLr TYzg== X-Gm-Message-State: AA6/9RmNWce5KPpXO3dXIIQxvuRo6oVbrOVH8fpepjFF6K1VANhTyIV+zrq1ETZmuR19GqMj X-Received: by 10.66.160.72 with SMTP id xi8mr36458310pab.78.1475487889115; Mon, 03 Oct 2016 02:44:49 -0700 (PDT) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id s80sm23097501pfd.10.2016.10.03.02.44.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Oct 2016 02:44:48 -0700 (PDT) Date: Mon, 03 Oct 2016 09:45:00 -0000 From: AKASHI Takahiro To: "Jose E. Marchesi" Cc: Torsten Duwe , GCC Patches , Szabolcs Nagy , nd@arm.com, Maxim Kuvyrkov , Li Bin , Jiri Kosina , Marcus Shawcroft , Andrew Wafaa Subject: Re: [PATCH v2] add -fprolog-pad=N option to c-family Message-ID: <20161003095211.GC14025@linaro.org> References: <20160427152217.GA2637@suse.de> <5720E81D.9060409@arm.com> <7134BE21-ACFB-4C45-871A-FADFA2973040@linaro.org> <20160929151419.GE32544@suse.de> <87oa35yad0.fsf@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <87oa35yad0.fsf@oracle.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-SW-Source: 2016-10/txt/msg00054.txt.bz2 On Fri, Sep 30, 2016 at 12:01:47PM +0200, Jose E. Marchesi wrote: > > In case anybody missed it, the Linux kernel side to make use > of this has also been finished meanwhile. Of course it can not > be accepted without compiler support; and this feature patch > is much more versatile than just Linux kernel live patching > on a single architecture. > > How is this supposed to be exploited atomically in RISC arches such as > sparc? In such architectures you usually need to patch several > instructions to load an absolute address into a register. We had some disucssions in the context of arm64: https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01093.html But I don't think that we reached a final consensus at that time. Thanks, -Takahiro AKASHI > If a general mechanism is what is intended I would suggest to offer the > possibility of extending the nops _before_ the function entry point, > like in: > > (a) nop ! Load address > nop ! Load address > nop ! Load address > nop ! Load address > nop ! Jump to loaded address. > entry: > (b) nop ! PC-relative jump to (a) > save %sp, bleh, %sp > ... > > So after the live-patcher patches the loading of the destination address > and the jump, it can atomically patch (b) to effectively replace the > implementation of `entry'. > > Wdyt? >