From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93845 invoked by alias); 5 Feb 2016 21:13:21 -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 93828 invoked by uid 89); 5 Feb 2016 21:13:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.1 required=5.0 tests=BAYES_00,RCVD_IN_SBL_CSS,RP_MATCHES_RCVD,SPF_PASS autolearn=no version=3.3.2 spammy=Hx-languages-length:2442, HContent-Transfer-Encoding:8bit X-HELO: xyzzy.0x04.net Received: from xyzzy.0x04.net (HELO xyzzy.0x04.net) (109.74.193.254) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 05 Feb 2016 21:13:19 +0000 Received: from hogfather.0x04.net (89-65-66-135.dynamic.chello.pl [89.65.66.135]) by xyzzy.0x04.net (Postfix) with ESMTPS id D6D843FE5F; Fri, 5 Feb 2016 22:14:05 +0100 (CET) Received: from [192.168.43.80] (public-gprs516540.centertel.pl [31.61.136.253]) by hogfather.0x04.net (Postfix) with ESMTPSA id 7C374580088; Fri, 5 Feb 2016 22:13:16 +0100 (CET) Subject: Re: [PATCH] s390: Add -fsplit-stack support To: Ulrich Weigand References: <20160204162737.719BB5CE0@oc7340732750.ibm.com> Cc: krebbel@linux.vnet.ibm.com, gcc-patches@gcc.gnu.org From: =?UTF-8?Q?Marcin_Ko=c5=9bcielnicki?= Message-ID: <56B5106A.5040109@0x04.net> Date: Fri, 05 Feb 2016 21:13:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160204162737.719BB5CE0@oc7340732750.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2016-02/txt/msg00454.txt.bz2 On 04/02/16 17:27, Ulrich Weigand wrote: > Marcin KoÅ›cielnicki wrote: > >> Fair enough. Here's what I'm going to implement in gold: >> >> - any PLT relocation: call >> - PC32DBL on a larl: non-call >> - PC32DBL otherwise: call >> - any other relocation: non-call >> >> Does that sound right? > > Hmm, I'm wondering about the PC32DBL choices. There are now > a large number of other non-call instructions that use PC32DBL, > including lrl, strl, crl, cgrl, cgfrl, ... > > However, these all access *data* at the pointed-to location, > so it is quite unlikely they would ever be used with a > function symbol. So, assuming that you also check that the > target of the relocation is a function symbol, treating only > larl as non-call might be OK. Yeah, I make sure the symbol is a STT_FUNC. > > Maybe a more conservative approach might be to make the decision > the other way round: for PC32DBL check for *branch* instructions, > and treat only those are calls. There's just a few branch > instruction using PC32DBL: > > brasl (call) > brcl (conditional or unconditional sibcall) > brcth (???) > > where the last one is extremely unlikely (but theorically > possible) to be used as conditional sibcall combined with > a register decrement; I don't think this can ever happen > with current compilers however. I'll stay with checking for larl - while I can imagine someone adding a new conditional branch instruction, I don't see a need for another larl-like instruction. Besides, this way the failure mode for an unknown instruction would be producing an error, instead of silently emitting code with unfixed prologue. > > For full completeness, there are also PC16DBL relocations that > *could* target called functions, but only when compiling with > the -msmall-exec flag to assume total executable size is less > than 64 KB. These are used by the following instructions: > > bras > brc > brct > brctg > brxh > brxhg > brxle > brxlg > crj > cgrj > clrj > clgrj > cij > cgij > clij > clgij > > Note that those are *all* branch instructions, so it might > make sense to add any PC16DBL targetting a function symbol > to the list of calls, just in case. (But since basically > nobody ever uses -msmall-exec, it doesn't really matter > much either.) Ah right, I've added PC16DBL to the "always call" list. > > Bye, > Ulrich > I've updated and resubmitted the gold patch. Marcin Kościelnicki