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 24B463854830 for ; Fri, 9 Jul 2021 11:00:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 24B463854830 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 DAB6930016BF; Fri, 9 Jul 2021 13:00:46 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 9E3BE40165C2; Fri, 9 Jul 2021 13:00:46 +0200 (CEST) Message-ID: <196abc454208d90d8819e887500cbd34e29ce772.camel@klomp.org> Subject: Re: Working with ELF already loaded in memory From: Mark Wielaard To: Sonal Santan , "elfutils-devel@sourceware.org" Date: Fri, 09 Jul 2021 13:00:46 +0200 In-Reply-To: References: <19d95e93c233c8cf9abb1f065aba571d45657280.camel@klomp.org> 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.4 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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: Fri, 09 Jul 2021 11:00:49 -0000 Hi Sonal, On Fri, 2021-07-09 at 05:34 +0000, Sonal Santan wrote: >=20 > Thanks for the pointer. I was looking for APIs inside > /usr/include/elfutils directory and > did not realize elfutils also places header files under /usr/include > directory. I am working=20 > with this API now. Ah, yes, the libelf library is kind of "standard" (it is also available on BSDs, AIX, Solaris, etc.) so it goes under /usr/include. The libdw library places its headers under /usr/include/elfutils/{libdw.h,libdwelf.h,libdwfl.h}. > > You can also use libdwfl (part of libdw) to do some of the above automa= gically. > > See for example: > >=20 > > /* Call dwfl_report_module for each file mapped into the address space = of PID. > > 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); >=20 > Does this also work for ELF files which are loaded into heap as blob -- n= ot really > _mapped_ into the address space? I guess I will have to provide some hint= s to dwfl > so it can locate the loaded blob when walking through the process map? It probably wouldn't work if the the library is not normally mapped into memory since it relies on the content of /proc//map to locate what is mapped where. You can also create your own and use: /* Similar, but reads an input stream in the format of Linux /proc/PID/maps files giving module layout, not the file for a live process. */ extern int dwfl_linux_proc_maps_report (Dwfl *dwfl, FILE *); But there are also more specific interfaces to map segments to modules in libdwfl.h. They don't have to be file mapped, but can also come for memory or parts of a file (see for example the core file mapper). But these interfaces are a little obscure with minimal documentation. Please feel free to ask for more background if you get stuck. Cheers, Mark