From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AEC6FC433F5 for ; Fri, 15 Apr 2022 21:17:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1354528AbiDOVUQ (ORCPT ); Fri, 15 Apr 2022 17:20:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35818 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1353572AbiDOVUP (ORCPT ); Fri, 15 Apr 2022 17:20:15 -0400 Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4C295DEBBD for ; Fri, 15 Apr 2022 14:17:46 -0700 (PDT) Received: by mail-pj1-x1035.google.com with SMTP id md20-20020a17090b23d400b001cb70ef790dso12613486pjb.5 for ; Fri, 15 Apr 2022 14:17:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ARlboKGZt2tL08cLIG3z5uxNDQZQ5fpCTr/7WAJiVq8=; b=cenJMwzjlBQzlcUl96bqg5z0tBQEjpVBo4g/8GZIGQon8ua/x5txe+86XY3/Clt4cg aw6CxVRphKxDDxjevdj1MhakyLqpnn7eEx7BOS/H/QbIExHXHAYqgr3XF4AYvvc/zk62 yPNHtaCOmDDBcQLS7/Qd/UUi0dpV9OBejDyjASiOdvNjaSocZ8e8ZCNIsGnyrwQ3LCNA PsqMGrw9oVFBV1wrg9TU2GPt6MpQ4/hpmqWcFOHLRvmHjXlahv7HgT2aDFUu13InfCfc /l7rrFiuD3lmsR8/Y76u4/7xQNma9LMuxiVPPmPR7I0ePLTObXtR7S5iq65IJzHHupet +Ndw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ARlboKGZt2tL08cLIG3z5uxNDQZQ5fpCTr/7WAJiVq8=; b=kGWj7bWRj7cPkFsMFpnRxQfOPYleflhybhHf1bK2JmwptmVHpuV3ITqEyu7qlc2RVM XohonnyLiQbahggnVFNKNZXZkuOVPXtB1MbKYi7G+ll1YqvSGEGc6kvwwcq77McaHxBK RdMc7AKzrT6rdnAlfDKmgDY5GSi7ZIzppTmndnkfvJx4GMTyDXniEeYiZ1o/p2AbLtzB i3g2b9FVLz5TgHGN+imItxrQhT0RP7DqvwtspTahRMRvtp7lneYnCkcpNxg2A+0eFI5I jTCS+w/jJtP11ljLCEsIr+nFCw+baHJCqPyqnrjOp37QYCtkior9JQcroMKvdakr9ua0 ST+g== X-Gm-Message-State: AOAM531iPiFcd4SbYWqXZrK8IIGr/18wrytg0vZglaCAgtEPhw2c1yU+ +aiLwtqDicQ97Gw688cPJZPCRg== X-Google-Smtp-Source: ABdhPJxw9RC+e6c37TDC//xpP/w41H701z/bkDJeCWAoUNcqObLqqDwvMT5so+TW9XBkcVHKrCprOg== X-Received: by 2002:a17:90b:3a91:b0:1d1:d1ba:2a91 with SMTP id om17-20020a17090b3a9100b001d1d1ba2a91mr762168pjb.117.1650057465615; Fri, 15 Apr 2022 14:17:45 -0700 (PDT) Received: from google.com ([2620:15c:2ce:200:4daf:4929:e46f:4db5]) by smtp.gmail.com with ESMTPSA id h189-20020a636cc6000000b0039841f669bcsm5256863pgc.78.2022.04.15.14.17.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Apr 2022 14:17:45 -0700 (PDT) Date: Fri, 15 Apr 2022 14:17:40 -0700 From: Fangrui Song To: Nick Desaulniers Cc: Segher Boessenkool , hjl.tools@gmail.com, Peter Zijlstra , x86@kernel.org, Josh Poimboeuf , mbenes@suse.cz, rostedt@goodmis.org, linux-toolchains@vger.kernel.org Subject: Re: The trouble with __weak and objtool got worse Message-ID: <20220415211740.qju2brynn7uyxdg7@google.com> References: <20220415182229.GB25951@gate.crashing.org> <20220415200714.GC25951@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On 2022-04-15, Nick Desaulniers wrote: >On Fri, Apr 15, 2022 at 1:11 PM Segher Boessenkool > wrote: >> >> On Fri, Apr 15, 2022 at 11:36:32AM -0700, Nick Desaulniers wrote: >> > On Fri, Apr 15, 2022 at 11:27 AM Segher Boessenkool >> > wrote: >> > > >> > > > Alternatively: >> > > > >> > > > https://sourceware.org/pipermail/binutils/2020-December/114671.html >> > > > >> > > > seems to suggest: -Wa,--generate-unused-section-symbols=yes, ought to >> > > > work, except I'm getting: >> > > >> > > That email is for a proposed patch. Did anything further ever happen >> > > with it? >> > >> > $ gcc hello.c -Wa,--generate-unused-section-symbols=yes >> > as: unrecognized option '--generate-unused-section-symbols=yes' >> > $ gcc hello.c -Wa,-generate-unused-section-symbols=yes >> > $ gcc --version >> > gcc (Debian 11.2.0-16) 11.2.0 >> > >> > Uh, the email says -- prefix, but reality shows a single prefix? What >> > happened there? Maybe that link is to an earlier version than what >> > landed? >> >> Neither has landed. You get the -g option, which can take options of >> itself, parsed by the target or file format code. "as -gobbledygook" >> works fine as well :-) > >https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=d1bcae833b32f1408485ce69f844dcd7ded093a8 >Looks like it's been in binutils since 2.36 (IIUC the ChangeLog correctly). (Came to this thread from https://reviews.llvm.org/D123874) H.J.'s patch discards unused STT_SECTION symbols. The ability to add back such symbols (--generate-unused-section-symbols={yes|no}) is not in binutils. Neither 2.36 nor master branch has --generate-unused-section-symbols={yes|no}. as -generate-unused-section-symbols=yes is just a GNU as quirk that it interprets nearly all -g* options as -g, which generates .debug_arange and .debug_info compile units. The feature is very different from restoring STT_SECTION symbols. I know little about the kernel requirement but I think it shouldn't be too difficult to teach a relocatable object file consumer to not assume existence of STT_SECTION. The converse (add the feature to GNU as and LLVM integrated assembler) would be much more unideal. See also https://sourceware.org/pipermail/binutils/2022-March/119940.html > This problem was fixed in the kernel (and backported by distros to their > kernels if binutils was updated); it's fairly simplistic changes. > > I don't see the need for returning (optionally) to the old behaviour > again. I mean, at the time, when 2.36 came out, sure, the patch might > have made sense, but now?