From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 0B5143858D33 for ; Thu, 28 Jul 2022 16:41:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0B5143858D33 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from tarox.wildebeest.org (83-87-18-245.cable.dynamic.v4.ziggo.nl [83.87.18.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 91A84303C3D5; Thu, 28 Jul 2022 18:41:27 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 471CD413CBBB; Thu, 28 Jul 2022 18:41:27 +0200 (CEST) Message-ID: <198e9e0414a04b741baa865c856534a6171504c9.camel@klomp.org> Subject: Re: runtime validation of DT_SYMTAB lookups - why is there no DT_SYMSZ? From: Mark Wielaard To: Milian Wolff , elfutils-devel@sourceware.org Date: Thu, 28 Jul 2022 18:41:27 +0200 In-Reply-To: <2563495.X3S6A8DOgW@milian-workstation> References: <2825590.45ddzSUfD6@milian-workstation> <2563495.X3S6A8DOgW@milian-workstation> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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, 28 Jul 2022 16:41:31 -0000 Hi Milian, On Wed, 2022-07-27 at 13:38 +0200, Milian Wolff wrote: > Thanks for confirming that this isn't available currently. Would it > be=20 > possible to add this? What's the process for standardization here? I gues= s it=20 > would take a very long time, yet this seems to me as if it would be benef= icial=20 > in the long term. Standardization of the ELF gabi takes place on (sorry google groups, I know, sigh): https://groups.google.com/g/generic-abi you should be able to subscribe with generic-abi+subscribe@googlegroups.com so you don't have to go through the webgui mess. There is also https://sourceware.org/gnu-gabi/ but that is more for GNU extensions and I think you want something generic. > > Di Chen recently > > (or actually not that recently, I just still haven't reviewed, > > sorry!) > > posted a patch for > > https://sourceware.org/bugzilla/show_bug.cgi?id=3D28873 to print out > > the > > symbols from the dynamic segment > > https://sourceware.org/pipermail/elfutils-devel/2022q2/005086.html >=20 > Interesting. But from what I can tell, this patch has access to the > full Elf=20 > object and thus can access segments which are not normally loaded at > runtime? Yes it could, but it doesn't use anything that isn't referenced from the phdrs or dynamic segment, so it only uses those parts that are normally loaded at runtime. If you go through the dynamic segment then everything it references (.dynsym in this case) is from a loaded segment. So going through phdrs to check where it is loaded and the length is fine. > Try with eu-elflint --gnu which suppresses some known issues. >=20 > Indeed, with `--gnu` the tool reports `No errors`. >=20 > > Also could you show those symbol values (1272, 3684, 25720, 27227) > > they > > might have a special type, so their st_value isn't really an > > address? >=20 > ``` > $ eu-readelf -s libQt5Qml.so.5.12.0 | grep -E > "^\s*(1272|3684|25720|27227):" > 1272: 003f9974 0 NOTYPE GLOBAL DEFAULT 25 > __bss_start__@@Qt_5 > 3684: 003f9974 0 NOTYPE GLOBAL DEFAULT 25 > __bss_start@@Qt_5 > 1272: 003ccc4c 0 NOTYPE LOCAL DEFAULT 17 $d > 3684: 003cbfec 0 NOTYPE LOCAL DEFAULT 17 $d > 25720: 003f9974 0 NOTYPE GLOBAL DEFAULT 25 __bss_start > 27227: 003f9974 0 NOTYPE GLOBAL DEFAULT 25 __bss_start__ > ``` >=20 > The first two matches come from the `.dynsym`, the last four come > from=20 > `.symtab`. >=20 > Can anyone tell me how `eu-readelf` resolves these symbol names? Currently through the section tables, which point to the string table section used. But Di Chen's patch would change that by going through the dynamic segment and phdrs to find the strtab for the dynsym segment (but will of course still need to go through the sections for the .symtab symbols since those aren't accessible through the phdrs). Cheers, Mark