From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) by sourceware.org (Postfix) with ESMTPS id 347813AA7C89 for ; Thu, 4 Mar 2021 14:00:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 347813AA7C89 Received: by mail-ed1-x535.google.com with SMTP id bd6so21721435edb.10 for ; Thu, 04 Mar 2021 06:00:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=4ArJl1qiepzTXEOl4+dwY09ThEvevSv0STH8jls6n38=; b=Tzg58k7LoxIuR1U55wsSnW5UbTza79mq3jmsoZsBk1kEJ5LoH0RKXfnVRX7wc12E9u Qb7tncq1aq0GEGfMV7Iz/kZZrTO7qF+nlf/pWb2WpfkpVdSyDfrcBEDM6PYDlWVgcl2I KgGi7WhHG8kO1LjfnvivVMaz9onde5r9+zNzPNHFKZr0EkeGTOatkgSV80weCgDwoQAS GiHVC9gh5b63TiAzHsSdMfGQaGMvhUEpnt6JrD/z7v7aQTY52tGeGEKyPdpym2KFR1Sw 6goxJu+PNAN6NDcq7hxdNraFWIILZaCsuZJbJBJ3nEvqB92i5wDo6LM+sjLNjLYp7PTQ 5T5A== X-Gm-Message-State: AOAM530dNvBPeYIO58n4lf4jnPDlrznUKosu84/Ed4p9iLVkbpMZRSDc W7nS3/n9ieW2HFtMwCh6jHwTS9Lx0a4w9+vFzJciUV94EgoQxw== X-Google-Smtp-Source: ABdhPJxc7fDEq9yL40LeD8WWeOLuC1uQI0q9715b+Qw57ytPF+KqWq3HE7JGv9RzPmDoTIiHiy6M5vbxGudS6LgtUlE= X-Received: by 2002:aa7:cf90:: with SMTP id z16mr4459236edx.273.1614866432311; Thu, 04 Mar 2021 06:00:32 -0800 (PST) MIME-Version: 1.0 References: <1d931491-9672-62c0-363b-73facdc8ed09@redhat.com> In-Reply-To: <1d931491-9672-62c0-363b-73facdc8ed09@redhat.com> From: Navin P Date: Thu, 4 Mar 2021 19:30:20 +0530 Message-ID: Subject: Re: [PATCH] define SHT_LLVM_ADDRSIG section rather than error out To: =?UTF-8?Q?Timm_B=C3=A4der?= Cc: Mark Wielaard , elfutils-devel@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2021 14:00:35 -0000 On Thu, Mar 4, 2021 at 7:14 PM Timm B=C3=A4der wrote: > > On 18/11/2020 06:34, Navin P via Elfutils-devel wrote: > >>> diff --git a/src/elflint.c b/src/elflint.c > >>> index ef3e3732..62663800 100644 > >>> --- a/src/elflint.c > >>> +++ b/src/elflint.c > >>> @@ -3905,6 +3905,7 @@ section [%2zu] '%s': size not multiple of entry > >>> size\n"), > >>> && shdr->sh_type !=3D SHT_GNU_ATTRIBUTES > >>> && shdr->sh_type !=3D SHT_GNU_LIBLIST > >>> && shdr->sh_type !=3D SHT_CHECKSUM > >>> + && shdr->sh_type !=3D SHT_LLVM_ADDRSIG > >>> && shdr->sh_type !=3D SHT_GNU_verdef > >>> && shdr->sh_type !=3D SHT_GNU_verneed > >>> && shdr->sh_type !=3D SHT_GNU_versym > >> > >> Note that for various of these SHT_GNU extensions we actually do have > >> some extra checks. Do we need to check anything for a section marked > >> SHT_LLVM_ADDRSIG? > >> > > We can do two things here > > a) Recognize the section exists but ignore its contents which is what i > > do. This needn't be the correct approach. > > You may need to check the contents to sht_llvm_addrsig but that is > > lot of work after the format has been frozen. > > https://www.mail-archive.com/netdev@vger.kernel.org/msg348254.html > > readelf output > > [22] .llvm_addrsig LOOS+0xfff4c03 0000000000000000 ... > > > > b) If we don't want to recognize SHT_LLVM_ADDRSIG > > you can strip section from object file by objcopy -R .llvm_addrsig size= .o > > conditionally based on clang compiler. > > > > Hey Navin and Mark, > > any update on this? I see that SHT_LLVM_ADDRSIG is still not in upstream > glibc. Are you working on that, Navin? > > As for the checks, I'm not sure we can do anything here since elfutils > can't know whether a symbol is rightfully marked as address-significant. > clang has a flag -fno-addrsig that doesn't generate the addrsig section. https://releases.llvm.org/7.0.0/tools/clang/docs/ClangCommandLineReference.= html#cmdoption-clang-faddrsig So adding that for option for only clang should work. I remember I ran the tests and it worked. But you should check again. As far as i remember this should complete the changes Here is a small example navin@mint-Aspire:~/c$ cat tmp.c int main() { return 0 ; } navin@mint-Aspire:~/c$ clang tmp.c -c navin@mint-Aspire:~/c$ readelf -a tmp.o | grep -i addrsig [ 7] .llvm_addrsig LOOS+0xfff4c03 0000000000000000 00000120 navin@mint-Aspire:~/c$ clang tmp.c -c -fno-addrsig navin@mint-Aspire:~/c$ readelf -a tmp.o | grep -i addrsig navin@mint-Aspire:~/c$