From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 74152 invoked by alias); 28 Apr 2016 08:48:05 -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 74052 invoked by uid 89); 28 Apr 2016 08:48:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=HX-Received:sk:71mr150 X-HELO: mail-wm0-f46.google.com Received: from mail-wm0-f46.google.com (HELO mail-wm0-f46.google.com) (74.125.82.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 28 Apr 2016 08:47:52 +0000 Received: by mail-wm0-f46.google.com with SMTP id e201so67857332wme.0 for ; Thu, 28 Apr 2016 01:47:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vyzYDYFNVHgUNJuLxaYMlqLl2OHVhHsjT0Aw4kFydZw=; b=i+Ox9E5Rt3uxW0Kqu8vqprrAUvhLRBqW8M5Je1TFkZvPmOufQj3HriFoSEIpBjZJjh cFPestL8CAarR7+KOaHHRgzEuPK7S2rzdVVh6CaUUemE/WmJdL+HfeXYTSPC1b5Qvf6Z HH6b13TaoiYVkztvkIe85vhX7E9t6O+hWFfO9snxwPFhLmzFccVMdMAqpLCPTW/BDyVY AkpIS1+zVxnaOugNlWaDOU32Nj39AK9O75Eaky/yu0SjHtCSmDUB25H8nCjceN1CXhJn wffRaEv4FpUqb7pIzN237NXDPQcjywtgH45BGg/Us1HqOb7wxbA2O3bQusBLHE4iNBhv c0uQ== X-Gm-Message-State: AOPr4FVW8lQfpPVE+Ron5xw5/LJAv7aLH1LqI3bnN2xtR5dDbXyafLkAQ0kktGtLZn4nwwuQ X-Received: by 10.28.15.74 with SMTP id 71mr15008313wmp.34.1461833270000; Thu, 28 Apr 2016 01:47:50 -0700 (PDT) Received: from [192.168.1.66] (ppp37-190-24-201.pppoe.spdop.ru. [37.190.24.201]) by smtp.gmail.com with ESMTPSA id pm4sm8427775wjb.35.2016.04.28.01.47.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 28 Apr 2016 01:47:48 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [PATCH] add -fprolog-pad=N option to c-family From: Maxim Kuvyrkov In-Reply-To: <5720E81D.9060409@arm.com> Date: Thu, 28 Apr 2016 08:48:00 -0000 Cc: Torsten Duwe , nd@arm.com, Li Bin , Jiri Kosina , GCC Patches , Marcus Shawcroft , Takahiro Akashi Content-Transfer-Encoding: quoted-printable Message-Id: <7134BE21-ACFB-4C45-871A-FADFA2973040@linaro.org> References: <20160427152217.GA2637@suse.de> <5720E81D.9060409@arm.com> To: Szabolcs Nagy X-SW-Source: 2016-04/txt/msg01759.txt.bz2 > On Apr 27, 2016, at 7:26 PM, Szabolcs Nagy wrote: >=20 > On 27/04/16 16:22, Torsten Duwe wrote: >> Hi Maxim, >>=20 >> thanks for starting the work on this; I have added the missing >> command line option. It builds now and the resulting compiler generates >> a linux kernel with the desired properties, so work can continue there. >>=20 >> Torsten >=20 > i guess the flag should be documented in invoke.texi >=20 > it's not clear what N means in -fprolog-pad=3DN, how > location recording is enabled and how it interacts > with -fipa-ra. (-pg disables -fipa-ra, but -fprolog-pad > works without -pg.) I think, it should be responsibility of the user to disable -fipa-ra if cod= e intended to be patched-in will be incompatible with IPA-RA. I agree, tho= ugh, that documentation of -fprolog-pad=3D should make a special note of th= is fact and recommend inclusion of -fno-ipa-ra to the cflags whenever -fpro= log-pad=3D is used.. >=20 > with -mfentry, by default the user only has to > implement the fentry call (linux wants nops there, but > e.g. glibc could use -pg -mfentry for profiling on > aarch64 and the target specific details are easier to > document for an -m option than for something general). I don't understand your point here, could you elaborate, please? >=20 > the nop-padding is more general, but the size and > layout of nops and the call abi will be target > specific and the user will most likely need to modify > the binary (to get the right sequence) which needs > additional tooling. i don't know who might use it > other than linux (which already has tools to deal with > -mfentry). Right, but this tooling will require minimal (if any) changes to be adapted= to nop-pad approach. If I remember correctly, recent versions of GCC and = kernel for x86_64 generate NOPs, not the call sequence in the prologs when = -mfentry is used. >=20 > i'm not against nop-padding, but i think more evidence > is needed that the generalization is a good idea and > users can deal with the resulting issues. -- Maxim Kuvyrkov www.linaro.org