From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) by sourceware.org (Postfix) with ESMTPS id 1B0343858C74 for ; Wed, 9 Mar 2022 18:12:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1B0343858C74 Received: by mail-pg1-x533.google.com with SMTP id q19so2637967pgm.6 for ; Wed, 09 Mar 2022 10:12:10 -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=IjGRcM3DRvwLt98uiUsNnGoH9KupV4MntaMPo4UgTns=; b=ZJw8RKZBplf+kw7F7t9nAu+8r380aNlq2lLpImmGcCGqcc2KWFgC+5jKWd1KM2XiQJ PXrH1xJShUivHrZhVgSzU3t3qnapu35YBhrs7Fyb+Sd/C3l5lHgN9RrSSQX3k+vCAMgY 4igglGCURKIw1cJwhEcqxWbWEHH3xLLNWWkgO7IGyJrY+86xc74e4GPfKOjN1/x0TgyU M6hak4SSnr7ADJI6NKHOGvlApKmiD6FWRIwdLNEpv+TJ9KwMiiweAWvJgUfAyA9lGB2M mVVjZ3GozvrhwAaF5R3gYW9WPuKHjb315H5w9uVoIZUtkiJeCOn14XpmCzv0MFwjUjw5 R72g== X-Gm-Message-State: AOAM533k6kPoY8nuOSunoD8XBjBxUp4pMPAcEcR/ohpMmsCyAo5svY2M FRdAeKY/nb9Tq1g0c4g5g2whCumQO8RhsL5E1PSpF0/5h5c= X-Google-Smtp-Source: ABdhPJyq+JMCChE+lBrkSp7vkRQAZxorgH/xYJsHFV/lF48oC2JkQw6ENmcRPnUnAtn/n7/nHl73KhnTNb584N5TMpQ= X-Received: by 2002:a63:4a44:0:b0:372:db13:5583 with SMTP id j4-20020a634a44000000b00372db135583mr818983pgl.210.1646849529110; Wed, 09 Mar 2022 10:12:09 -0800 (PST) MIME-Version: 1.0 References: <319f39e5-1f17-23ef-e3fa-2169876aa31c@suse.com> <5ac79eef-290c-5f77-2387-99be18e10ee8@suse.com> <4c2ceba6-a7f9-89ce-ac19-5a6865edb28d@suse.com> <6bbe3394-c599-28ea-fa65-80b46d7b447a@suse.com> In-Reply-To: <6bbe3394-c599-28ea-fa65-80b46d7b447a@suse.com> From: "H.J. Lu" Date: Wed, 9 Mar 2022 10:11:33 -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.7 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 18:12:11 -0000 On Wed, Mar 9, 2022 at 8:49 AM Jan Beulich wrote: > > On 09.03.2022 16:54, H.J. Lu wrote: > > On Wed, Mar 9, 2022 at 7:41 AM Jan Beulich wrote: > >> > >> On 09.03.2022 16:32, H.J. Lu wrote: > >>> On Wed, Mar 9, 2022 at 7:17 AM Jan Beulich wrote: > >>>> > >>>> On 09.03.2022 16:08, H.J. Lu wrote: > >>>>> 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. > >>>> > >>>> Because earlier on no-one cared to think about the issue? This really > >>>> should have been considered when the ABI was initially written. _That_ > >>>> would then also have been the time to introduce separate relocation > >>>> types. Now we need to apply workarounds ... > >>>> > >>> > >>> If there is a real issue, we should fix it without a command-line > >>> option. Can you use the input section name/flags to check it? > >> > >> I don't see how - it's overwhelmingly likely all in .text. > > > > These are very very special cases. You can place these special > > instruction sequences in a different text section. > > Not easily, and even less so in existing code. OS boot code typically is > a mix of 16-, 32-, and 64-bit code, just to give an example. Here are my preferences: 1. Add a new relocation type. 2. Add a bit to SHF_MASKPROC to indicate special relocation semantics. 3. Add a suffix to section name to indicate special relocation semantics. Existing sources aren't impacted. -- H.J.