Message ID | 20240301200405.87966-1-yakoyoku@gmail.com |
---|---|
State | Superseded |
Headers |
Return-Path: <elfutils-devel-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 23C743858412 for <patchwork@sourceware.org>; Fri, 1 Mar 2024 20:04:30 +0000 (GMT) X-Original-To: elfutils-devel@sourceware.org Delivered-To: elfutils-devel@sourceware.org Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) by sourceware.org (Postfix) with ESMTPS id 419873858C5F for <elfutils-devel@sourceware.org>; Fri, 1 Mar 2024 20:04:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 419873858C5F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 419873858C5F Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::52e ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709323460; cv=none; b=kyZ6xjab4oNYnXeFS9bHXitBmnxiwsejckLC7eA4ZinnJj6nlE3udBADGGLTgFHiJGRm7w57hWErZ1cWO0j39cQkz/M5g4V7DZkYx4E/O4gMozcOCpSmME6ew+m5EMv+qxPTp+KHnEDhUjtjXbus8yPYO8WRfleANwhJ1HDgJVI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709323460; c=relaxed/simple; bh=jgof3R4M/8ra8JN5n4LHXkEju8tDRALduKnOku0q2gs=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=Bj8NfliY1sohLBjpfTBUO7l/d7QGqx+Kbm2TeqFSii69UdNXuWlX/GbNJuBVU0fZoFCsHEAf+8uxOf+K5LoIoE/pR62iCa4Nx9yNDH1UtlJOPKXPAubFnQlgPCFYoU/5LaC4q74f7P9tmo2mvB9wW0HIgvJtkuXp8bKPlBM2ha4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pg1-x52e.google.com with SMTP id 41be03b00d2f7-5ce942efda5so2032385a12.2 for <elfutils-devel@sourceware.org>; Fri, 01 Mar 2024 12:04:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709323455; x=1709928255; darn=sourceware.org; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:from:to:cc:subject:date:message-id:reply-to; bh=yVOrAuoKBqu8JJi9ShKcT1g+9EVtLkatMovA3Fd/rtc=; b=jz0YXJiPftpSg/nohv2En7FcyHl2hM+paQlnDbmXwGgn5eR0FHj2BW1Hsq0oNGT/V5 hEHo+MiUws5CRzxNz9+Pof83A0+/uWkktqzbNms8XKKSmOk0TF1jI1uGut4LD+wES9Ru JL4s24Ox0xu1xxqiQFjh7s7xlUXk+SJBz5ImDLsMHdajk1J20nXZp2eRks88q+1h6vQd 4YQDubbXdNKuq7ivk2lfFGFFS/xqPBrx/MhhaMTwuoICpujx2IZrdj7IpDdBPS8Nc92m 6gC3NdBIE0+nYVd7q1JzbDMy21VNIDKYGqFiAkfOg/UfPpq1oaWcFNf/k+ek2qAk5vht ML8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709323455; x=1709928255; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=yVOrAuoKBqu8JJi9ShKcT1g+9EVtLkatMovA3Fd/rtc=; b=Gd+bNUgRLZLLe2xXCfYd0pEgDhKBTs3TeYLXIeJLSc3YcQKu6orMbTOIZUPV42kXgR wkdTRDoiYq9x+RQ4B8kXTqrXy2VKhzddBKVgw5eikepy0lMzZ85Stm6GT+vxE6E5oMFD nHYBCGYc1V8qmLR3MXIh5poXjsOPK6DVRf6PRwFtBweCHcQeKrlRPOJOgQg38jqdgcp0 lsLMbKKWIsYAuqh8jLpKqPl8ilfowcJREg/4M91pDKvEvaxAK5+8K9vuDJMEgdIjt3Qt ucwAOurx+eZWK+lmtNgcBTLOHdnJ9Mmi/B7DxI23R36J5rkavSbIB2AlyjiikLDOyA03 FC0A== X-Gm-Message-State: AOJu0YxZrRi6zihH3gLg3u0jg6ENZBFFe16l2pFjq58Mnri3S4GjjoWg y36jNv2abNtjcOPBGNnie6sOqITmpXvqVJrbwrWp3b+vD9rZGgblW5e+ur3D X-Google-Smtp-Source: AGHT+IHLRSo8P7mpD4Ai1IXg7AR5tmckFbiiWAkfzGjVTfOKXG8YVmVbvWDQFKp3MVgUZ6j167xVrQ== X-Received: by 2002:a17:902:ea11:b0:1dc:d515:79c8 with SMTP id s17-20020a170902ea1100b001dcd51579c8mr3274073plg.23.1709323455175; Fri, 01 Mar 2024 12:04:15 -0800 (PST) Received: from tx3000mach.io (static.220.238.itcsa.net. [190.15.220.238]) by smtp.gmail.com with ESMTPSA id y6-20020a170902700600b001dcc2951c02sm3845345plk.286.2024.03.01.12.04.14 for <elfutils-devel@sourceware.org> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Mar 2024 12:04:14 -0800 (PST) From: Martin Rodriguez Reboredo <yakoyoku@gmail.com> To: elfutils-devel@sourceware.org Subject: [PATCH] Setter for Dwfl's offline_next_address Date: Fri, 1 Mar 2024 17:04:05 -0300 Message-ID: <20240301200405.87966-1-yakoyoku@gmail.com> X-Mailer: git-send-email 2.44.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-9.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham 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.30 Precedence: list List-Id: Elfutils-devel mailing list <elfutils-devel.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/elfutils-devel>, <mailto:elfutils-devel-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/elfutils-devel/> List-Post: <mailto:elfutils-devel@sourceware.org> List-Help: <mailto:elfutils-devel-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/elfutils-devel>, <mailto:elfutils-devel-request@sourceware.org?subject=subscribe> Errors-To: elfutils-devel-bounces+patchwork=sourceware.org@sourceware.org |
Series |
Setter for Dwfl's offline_next_address
|
|
Commit Message
Martin Rodriguez Reboredo
March 1, 2024, 8:04 p.m. UTC
Added a new function dwfl_set_offline_next_addres which will set said
field from the Dwfl struct. This is a requirement for listing functions
from their addresses when using libdwfl offline, otherwise wrong symbols
are going to be returned.
Signed-off-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
---
libdwfl/libdwfl.h | 3 +++
libdwfl/offline.c | 6 ++++++
2 files changed, 9 insertions(+)
Comments
Hi Martin, On Fri, Mar 01, 2024 at 05:04:05PM -0300, Martin Rodriguez Reboredo wrote: > Added a new function dwfl_set_offline_next_addres which will set said > field from the Dwfl struct. This is a requirement for listing functions > from their addresses when using libdwfl offline, otherwise wrong symbols > are going to be returned. Could you give an example or testcase for this? Thanks, Mark
Oh hi Mark! On 3/2/24 17:47, Mark Wielaard wrote: > Hi Martin, > > On Fri, Mar 01, 2024 at 05:04:05PM -0300, Martin Rodriguez Reboredo wrote: >> Added a new function dwfl_set_offline_next_addres which will set said >> field from the Dwfl struct. This is a requirement for listing functions >> from their addresses when using libdwfl offline, otherwise wrong symbols >> are going to be returned. > > Could you give an example or testcase for this? This is intended for the Linux kernel perf tool so you might see it in action when I publish the changes. In regards to testing I thought that it was not needed due to the patch being a simple setter, but as requested I can think something in the lines of. int main (int argc, char **argv) { Dwfl *dwfl = dwfl_begin (&offline_callbacks); assert (dwfl != NULL); if (dwfl->offline_next_address != OFFLINE_REDZONE) { dwfl_end (dwfl); return 1; } int result = 0; dwfl_set_offline_next_address (dwfl, 0); if (dwfl->offline_next_address != 0) result = 1; dwfl_end (dwfl); return result; } But this will require libdwflP.h to be included, maybe if I add a getter too it'd remedy it. Thoughts? > > Thanks, > > Mark
Hi Martin, On Sat, Mar 02, 2024 at 07:43:38PM -0300, Martin Rodriguez Reboredo wrote: > On 3/2/24 17:47, Mark Wielaard wrote: > >On Fri, Mar 01, 2024 at 05:04:05PM -0300, Martin Rodriguez Reboredo wrote: > >>Added a new function dwfl_set_offline_next_addres which will set said > >>field from the Dwfl struct. This is a requirement for listing functions > >>from their addresses when using libdwfl offline, otherwise wrong symbols > >>are going to be returned. > > > >Could you give an example or testcase for this? > > This is intended for the Linux kernel perf tool so you might see it in > action when I publish the changes. In regards to testing I thought that > it was not needed due to the patch being a simple setter, but as > requested I can think something in the lines of. It would be interesting to see the perf tool patch. I don't understand the use case. So I assume perf currently does something which is wrong and with your patch calling this new dwfl_set_offline_next_addres it will do the right thing. That is what I was thinking of when asking for an example or testcase. I agree that on itself such a simple setter doesn't need a dedicated testcase. But maybe we can come up with a testcase given the right context. Cheers, Mark
On 3/2/24 21:05, Mark Wielaard wrote: > Hi Martin, > > [...] > > It would be interesting to see the perf tool patch. I don't understand > the use case. So I assume perf currently does something which is wrong > and with your patch calling this new dwfl_set_offline_next_addres it > will do the right thing. That is what I was thinking of when asking > for an example or testcase. I agree that on itself such a simple > setter doesn't need a dedicated testcase. But maybe we can come up > with a testcase given the right context. Erm, I think I have a more clear example. When I use libdw to do something like addr2line with an ELF file I fail to get the address source line. Then I saw that eu-addr2line sets offline_next_address to zero. The following is the program I've used to see the source info of an address. int main(int argc, const char **argv) { if (argc != 3) return 1; Dwfl *dwfl = dwfl_begin(&offline_callbacks); if (!dwfl) return 1; dwfl_set_offline_next_address(dwfl, 0); if (!dwfl_report_offline(dwfl, "", argv[1], -1)) { dwfl_end(dwfl); return 1; } if (dwfl_report_end(dwfl, NULL, NULL)) { dwfl_end(dwfl); return 1; } char *endp = NULL; GElf_Addr addr = strtoumax(argv[2], &endp, 16); Dwfl_Module *mod = dwfl_addrmodule(dwfl, addr); int width = get_addr_width(mod); printf("0x%.*" PRIx64 "\n", width, addr); GElf_Sym s; GElf_Off off = 0; const char *name = dwfl_module_addrinfo(mod, addr, &off, &s, NULL, NULL, NULL); Dwfl_Line *line = dwfl_module_getsrc(mod, addr); if (!line) line = dwfl_getsrc(dwfl, addr); if (line) { int nline, column; const char *filename = dwfl_lineinfo(line, &addr, &nline, &column, NULL, NULL); printf("%s:%i,%i\n", filename, nline, column); } else { printf("??:0\n"); } dwfl_end(dwfl); return 0; } It could print the symbol name but that would've made the program much longer but I think that this should be clear now. > > Cheers, > > Mark
diff --git a/libdwfl/libdwfl.h b/libdwfl/libdwfl.h index 49ad6664..0ee12b58 100644 --- a/libdwfl/libdwfl.h +++ b/libdwfl/libdwfl.h @@ -109,6 +109,9 @@ extern int dwfl_errno (void); extern const char *dwfl_errmsg (int err); +/* Set the next offline address. */ +extern void dwfl_set_offline_next_address (Dwfl *dwfl, GElf_Addr addr); + /* Start reporting the current set of segments and modules to the library. All existing segments are wiped. Existing modules are marked to be deleted, and will not be found via dwfl_addrmodule et al if they are not diff --git a/libdwfl/offline.c b/libdwfl/offline.c index e9ab0cc1..f65486d3 100644 --- a/libdwfl/offline.c +++ b/libdwfl/offline.c @@ -35,6 +35,12 @@ #include "libdwflP.h" #include <fcntl.h> +void +dwfl_set_offline_next_address (Dwfl *dwfl, GElf_Addr addr) +{ + dwfl->offline_next_address = addr; +} + /* Since dwfl_report_elf lays out the sections already, this will only be called when the section headers of the debuginfo file are being consulted instead, or for the section placed at 0. With binutils