From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10243 invoked by alias); 2 Jul 2019 13:56:11 -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 10235 invoked by uid 89); 2 Jul 2019 13:56:10 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 02 Jul 2019 13:56:09 +0000 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x62DqZjU133800 for ; Tue, 2 Jul 2019 09:56:05 -0400 Received: from e06smtp02.uk.ibm.com (e06smtp02.uk.ibm.com [195.75.94.98]) by mx0a-001b2d01.pphosted.com with ESMTP id 2tg6qw4x4p-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 02 Jul 2019 09:56:04 -0400 Received: from localhost by e06smtp02.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 2 Jul 2019 14:56:01 +0100 Received: from b06cxnps4076.portsmouth.uk.ibm.com (9.149.109.198) by e06smtp02.uk.ibm.com (192.168.101.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Tue, 2 Jul 2019 14:55:58 +0100 Received: from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com [9.149.105.62]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x62DtvZ751707928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 2 Jul 2019 13:55:57 GMT Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 599A4AE051; Tue, 2 Jul 2019 13:55:57 +0000 (GMT) Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 33734AE04D; Tue, 2 Jul 2019 13:55:57 +0000 (GMT) Received: from dyn-9-152-98-98.boeblingen.de.ibm.com (unknown [9.152.98.98]) by d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTP; Tue, 2 Jul 2019 13:55:57 +0000 (GMT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: [PATCH] S/390: Improve storing asan frame_pc From: Ilya Leoshkevich In-Reply-To: <20190702133935.GN815@tucnak> Date: Tue, 02 Jul 2019 13:56:00 -0000 Cc: Segher Boessenkool , GCC Patches , krebbel@linux.ibm.com Content-Transfer-Encoding: quoted-printable References: <20190702085154.26981-1-iii@linux.ibm.com> <20190702130216.GI18316@gate.crashing.org> <20190702131957.GJ18316@gate.crashing.org> <3CC32047-1B4E-46E5-B3DE-B53B870CD565@linux.ibm.com> <20190702133935.GN815@tucnak> To: Jakub Jelinek x-cbid: 19070213-0008-0000-0000-000002F923F8 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19070213-0009-0000-0000-000022666D71 Message-Id: <89059C46-E9E7-4689-8241-C251148EABC3@linux.ibm.com> X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg00156.txt.bz2 > Am 02.07.2019 um 15:39 schrieb Jakub Jelinek : >=20 > On Tue, Jul 02, 2019 at 03:33:28PM +0200, Ilya Leoshkevich wrote: >>> Am 02.07.2019 um 15:19 schrieb Segher Boessenkool : >>>=20 >>> On Tue, Jul 02, 2019 at 08:02:16AM -0500, Segher Boessenkool wrote: >>>> On Tue, Jul 02, 2019 at 10:51:54AM +0200, Ilya Leoshkevich wrote: >>>>> +#undef TARGET_INSN_ALIGNMENT >>>>> +#define TARGET_INSN_ALIGNMENT 16 >>>>=20 >>>> There already is FUNCTION_BOUNDARY for something similar, which fits in >>>> well with STACK_BOUNDARY, PARM_BOUNDARY, many more *_BOUNDARY. I real= ise >>>> you may prefer a hook, but as long as we aren't getting rid of all the >>>> other macros, what's the point? >>>=20 >>> And maybe LABEL_BOUNDARY is bettter for this than INSN_BOUNDARY as well? >>=20 >> Can=E2=80=99t we just use FUNCTION_BOUNDARY then? >> I think .LASANPC is always emitted at the beginning of a function. >=20 > Isn't e.g. the hotpatch sequence emitted before it? You are right, with -fpatchable-function-entry it=E2=80=99s moved. So, I guess I should stick with the current approach. I could change TARGET_INSN_ALIGNMENT hook to INSN_BOUNDARY macro if that would better match the current design. I would still call it INSN, and not LABEL, because LABEL can refer to data.