From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by sourceware.org (Postfix) with ESMTPS id 008123858415 for ; Wed, 9 Mar 2022 15:08:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 008123858415 Received: by mail-pj1-x1032.google.com with SMTP id lj8-20020a17090b344800b001bfaa46bca3so2429780pjb.2 for ; Wed, 09 Mar 2022 07:08:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tTgnzdhBp35v3v/398Ea7CUxXLU/H4B2A1Ns13phTx4=; b=AfH3gUNgO2krnF8wsOVc5WIrGPyuaEIZ6HnPHR+ko1+pbqE10jrGIu0JmCZMjive+0 BAEsdihIsDrCx2cdBXonEtzE0h9dY/4PYTmyQzm57kgl6AY1E0Coyq5VGeND291Cp5bd krh/8xhjwAtIhkHmSV8XTRwFyShtW9mxeSo8v8/SVRB/FTHUPZLDCsW8aU5+3XsprJax de9TSLbc44VG4BOKdh4LzG7ZZ6YfE/NAe3BuWuLq3GMkEmGNbAS4QspNGijToObn22MQ x1XifGcU2Q/uOXbpe6zSRJVkQLK5HtogW7EfFI1Ue8WHpuk8GZNSCs1MOrNNxAUgpha7 j4zg== X-Gm-Message-State: AOAM530EttUjejRmKjxX9hfk+nDGl/pRJNS2gmZaRtp5O9NiwcpqOqYe pedifA4eAai9D9afOqEE9dwCTrG9Ipavz1gVujXuDnfA X-Google-Smtp-Source: ABdhPJyuv45igX05a4IlDDHdzkdLuxe1epd4yNecz1sFfhbsi9ZEFx90GW2rwy4LNBTyLTq0BTN9STnfd+lA9I9rnhI= X-Received: by 2002:a17:90a:74c7:b0:1bf:5532:3ae8 with SMTP id p7-20020a17090a74c700b001bf55323ae8mr10586659pjl.120.1646838519985; Wed, 09 Mar 2022 07:08:39 -0800 (PST) MIME-Version: 1.0 References: <319f39e5-1f17-23ef-e3fa-2169876aa31c@suse.com> <5ac79eef-290c-5f77-2387-99be18e10ee8@suse.com> In-Reply-To: From: "H.J. Lu" Date: Wed, 9 Mar 2022 07:08:03 -0800 Message-ID: Subject: Re: [PATCH v2 1/3] x86-64/ELF: permit relaxed overflow checking for 32-bit PC-relative relocs To: Jan Beulich Cc: Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3020.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2022 15:08:42 -0000 On Wed, Mar 9, 2022 at 6:39 AM Jan Beulich wrote: > > On 09.03.2022 15:27, H.J. Lu wrote: > > On Wed, Mar 9, 2022 at 12:21 AM Jan Beulich wrote: > >> On 04.03.2022 15:18, H.J. Lu wrote: > >>> On Fri, Mar 04, 2022 at 02:34:58PM +0100, Jan Beulich wrote: > >>>> --- a/ld/ld.texi > >>>> +++ b/ld/ld.texi > >>>> @@ -1372,6 +1372,12 @@ missing properties in input files. @opt > >>>> the linker issue an error for missing properties in input files. > >>>> Supported for Linux/x86_64. > >>>> > >>>> +@item lax-pcrel-relocs > >>>> +Relax relocation overflow checks for certain 32-bit PC-relative relocations > >>>> +which, when used by 32-bit code inside a 64-bit object, may require a > >>>> +larger range of values to be considered valid. > >>>> +Supported for x86-64 ELF targets. > >>>> + > >>> > >>> I think the check should be turned on automatically. Can you use a GNU > >>> property bit to tell linker that a larger range of values should be > >>> checked for R_X86_64_PC32 > >> > >> I'm not convinced that would be desirable - the relaxed checking, after > >> all, also affects relocations to 64-bit mode. Hence certain overflows > >> won't be detected anymore. Therefore I'd expect people to make use of > >> the new option only if they really have any affected relocations in > >> 32-bit code. Additionally there's no way I can see to set such a > >> property indicator when encountering the relocations in question only > >> in data definitions, unless you wanted to tie the setting of the > >> indicator to the mere use of .code{16,32} anywhere in the source (which > >> would feel way to aggressive to me). IMO this level of control can only > >> be achieved via command line option (without (a) becoming much more > >> intrusive or (b) introducing new relocation types). > > > > A new relocation type sounds better. > > We've been there before with PC16 - there are enough arguments against > introducing new types. I also never had the intention to propose ABI > extensions. > A command-line option isn't user friendly. On the other hand, why now? The issue has been there forever. -- H.J.