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 7873A39960FC for ; Thu, 8 Jul 2021 15:02:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7873A39960FC 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 53D50302FBA6; Thu, 8 Jul 2021 17:02:02 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 0812B4003072; Thu, 8 Jul 2021 17:02:02 +0200 (CEST) Message-ID: <19d95e93c233c8cf9abb1f065aba571d45657280.camel@klomp.org> Subject: Re: Working with ELF already loaded in memory From: Mark Wielaard To: Sonal Santan , "elfutils-devel@sourceware.org" Date: Thu, 08 Jul 2021 17:02:01 +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-10.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-4.2 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.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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, 08 Jul 2021 15:02:08 -0000 Hi Sinal, On Thu, 2021-07-08 at 05:02 +0000, Sonal Santan via Elfutils-devel wrote: > Going through the libdw it appears that all APIs require either a > file handle or a file name of the ELF object to create a session. > Since we do not have access to the ELF file -- but rather the ELF > file contents are already loaded in memory -- is there any other > mechanism to create a session for extracting DWARF information using > libdw?=20 Yes, if you just need the information already loaded into memory and you know where the library is mapped you can use: /* Create descriptor for memory region. */ extern Elf *elf_memory (char *__image, size_t __size); You can then use that Elf handle to extract the information that has been mapped in. Which often is not the actual debug information though. If you have a Elf handle you can use: /* Returns the build ID as found in a NT_GNU_BUILD_ID note from either a SHT_NOTE section or from a PT_NOTE segment if the ELF file doesn't contain any section headers. On success a pointer to the build ID is written to *BUILDID_P, and the positive length of the build ID is returned. Returns 0 if the ELF lacks a NT_GNU_BUILD_ID note. Returns -1 in case of malformed data or other errors. */ extern ssize_t dwelf_elf_gnu_build_id (Elf *elf, const void **build_idp); You can then use the build_id to lookup the debug information (file). You can also use libdwfl (part of libdw) to do some of the above automagically. See for example: /* Call dwfl_report_module for each file mapped into the address space of P= ID. Returns zero on success, -1 if dwfl_report_module failed, or an errno code if opening the proc files failed. */ extern int dwfl_linux_proc_report (Dwfl *dwfl, pid_t pid); The Dwfl will then be a representation of the modules (executable and shared libraries) of that particular process. You can then iterate through those modules using dwfl_getmodules and get a Dwarf handle using dwfl_module_getdwarf (or for all with dwfl_getdwarf). libdw will then try to extract that build-id from each module and try various lookups to get the (separate on disk) debuginfo. Hope that helps, Mark