From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (wildebeest.demon.nl [212.238.236.112]) by sourceware.org (Postfix) with ESMTPS id 0B7AD3858D35 for ; Wed, 10 Jun 2020 11:33:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0B7AD3858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mark@klomp.org Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id E026D300074F; Wed, 10 Jun 2020 13:33:08 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 92712470867A; Wed, 10 Jun 2020 13:33:08 +0200 (CEST) Message-ID: <4c9a5ec61c1157efbb71269d5aa67c07e46436a9.camel@klomp.org> Subject: Re: location list From: Mark Wielaard To: Sasha Da Rocha Pinheiro , "elfutils-devel@sourceware.org" Date: Wed, 10 Jun 2020 13:33:08 +0200 In-Reply-To: References: , Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-8.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-7.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.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: Wed, 10 Jun 2020 11:33:11 -0000 Hi Sasha, On Tue, 2020-06-09 at 16:38 +0000, Sasha Da Rocha Pinheiro via Elfutils-devel wrote: > I am now trying to design the changes needed to be done in Dyninst. > So far we have only used the functions dwarf_* under libdw. > What I understood is that libdw is kinda divided in subsets of functions, > dwarf_*, dwfl_* and dwelf_*. > I didn't find any documentation about it, or the purpose of these subset = of functions. > (Whats fl in dwfl for?) > But my understanding is that I can't use data structures from one on the = other one. > That alone will need some design to modify the way we parse dwarf info in= to Dyninst. > Currently the lifetime of a dwarf handle lasts through one execution, > because we parse dwarf data when the user needs it. So elfutils contains 4 libraries. libelf, which is a semi-standardize "unix" library to read and manipulate ELF files. libdw, which adds reading of DWARF data, linux process and kernel mappings, and various elf/dwarf utility functions. libasm, which provides a assembler and disassembler interface, but which isn't really finished/recommended at the moment (it only provides a partial x86 assembler/disassembler and a bpf disassembler). And libdebuginfod, which provides a way to fetch remotely stored executables, debuginfo and sources based on build-ids (from a debuginfod server). There used to be non-public, internal, "libebl" backend libraries, for each elfutils supported architecture (libebl_aarch64.so, libebl_riscv.so, etc.) which were loaded dynamically to safe a bit of memory in case the backend/arch wasn't used. But with 0.178 the libraries are build into libdw.so directly and no longer dynamically loaded. libebl was never intended to be used directly. [lib]ebl stands for ELF Backend Library. [lib]dw is short for DWARF. [lib]dwfl then can be read as DWARF Frontend library functions. And [lib]dwelf are the DWARF and ELF utility functions. The main data structure of libelf is the Elf handle which can be used to go through an ELF through sections (Shdrs) or program (Phdrs) headers. The main data structure that the libdw dwarf_* functions work on is the Dwarf handle, which is associated with one Elf handle. The main data structure of the libdwfl dwfl_* functions is the Dwfl handle. A Dwfl represents a program (or kernel) with library (or kernel modules) memory lay out. Each Dwfl_Module represents a piece of executable code mapped at a certain memory range. The Dwfl uses buildids to associate/create Elf images and Dwarf handles associated with each Dwfl_Module (it can optionally use libdebuginfod to download/cache any it doesn't have yet). Since kernel modules are ET_REL file (non-relocated object files), libdwfl also resolves any relocations between .debug_sections (this is the property we abused in the example code I gave you, where we construct a Dwfl from a single ET_REL object file). Given a Dwfl_Module you can get the associated Elf or Dwarf with dwfl_module_getelf or dwfl_module_getdwarf. You will note that those functions also provide a Dwarf_Addr bias which might be non- zero if the address range where the Dwfl_Module is mapped is different (at an offset) from the addresses found in the Elf image or Dwarf data. You would use the libdwfl functions if you want to represent a whole program as it would be mapped into memory (or the kernel and its modules). It is convenient if you got a process map (dwfl_linux_proc_report) or core file (dwfl_core_file_report). The libdwfl functions would automatically associate an Elf image and find the Dwarf data for you. It is even nice to use for "single file" programs like we did in the example with the single file because it does the automatic lookup of the Dwarf handle, and because, if the file is an ET_REL object, you get the relocation between .debug sections for free. It might make sense to provide utility functions (in libdwelf) to do both functions separately from setting up a Dwfl. You can already do most of the lookups by hand using dwelf_elf_gnu_debuglink, dwelf_dwarf_gnu_debugaltlink, dwelf_elf_gnu_build_id, plus the libdebuginfod calls. But one generic helper function might be convenient. The only other way to do the relocation resolving at the moment is through eu-strip --reloc-debug-sections-only (but this is a permanent, non-reversible operation on the file, which will make it unsuitable for linking with other object files). Hope that give a bit of an overview. Cheers, Mark