From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::228]) by sourceware.org (Postfix) with ESMTPS id D53933858D3C for ; Fri, 7 Oct 2022 13:38:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D53933858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=seketeli.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=seketeli.org Received: (Authenticated sender: dodj@seketeli.org) by mail.gandi.net (Postfix) with ESMTPSA id 353061BF20D; Fri, 7 Oct 2022 13:38:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seketeli.org; s=gm1; t=1665149916; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/BAfaJZsi3fEcFvRMz06PXI4NKv0WBhdToDSWTC1WK4=; b=GOHkV/Dh3VEon0VbyQUHyg7qB/GcjszRNLJb/A8N2faUcXV+79+cuYHBl/f0f5pPnzKEfK eaz9PYFz6ewIdpc7DGP4Jl23FatHy83vrE1D3MIe4ekLdFt1Xe/TxzfrnuJVIuGsyipNPd tJnIxo0L46DGPa+IukuXwhdJUrh6TqtpQIvuWPdUV3MJGUnscDTKLxbFa+pupbBPRaIHAl vLOI2yBb3hiFTvhMA5svMdkgAUw84NJ41cS7OhTRTZmoON45SgnjwoIENbd5Re+MfhYtAc UBeYeCfP+d02m9W8AcYOaVmLnKntYjGynyVKlnOxW1QLtqjhibcWcYgHTi0LiA== Received: by localhost (Postfix, from userid 1001) id 5702A1A061E; Fri, 7 Oct 2022 15:38:35 +0200 (CEST) From: Dodji Seketeli To: Guillermo Martinez Cc: "Guillermo E. Martinez via Libabigail" Subject: Re: [PATCH] CTF as a fallback when no DWARF debug info is present Organization: Me, myself and I References: <20221001001544.210234-1-guillermo.e.martinez@oracle.com> <877d1g2c52.fsf@seketeli.org> <568fe730-3bb9-0267-00bc-2873e94e502f@oracle.com> <86mta9bdpm.fsf@seketeli.org> <7dbdea77-dbc9-7bdd-94ee-8e4cf46ce886@oracle.com> X-Operating-System: Red Hat Enterprise Linux Server 7.9 X-URL: http://www.seketeli.net/~dodji Date: Fri, 07 Oct 2022 15:38:35 +0200 In-Reply-To: <7dbdea77-dbc9-7bdd-94ee-8e4cf46ce886@oracle.com> (Guillermo Martinez's message of "Thu, 6 Oct 2022 19:53:37 +0000") Message-ID: <86czb3bvok.fsf@seketeli.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hello Guillermo, Guillermo Martinez a =C3=A9crit: > Yes, it sounds good!!, just I would like to know your opinion about of wh= at > will happen when neither DWARF nor CTF debug information is found, the cu= rrent > behavior is to extract symbols information and compare them, so which sym= bol > information should I use DWARF::symtab or CTF::symtab? In the new branch users/dodji/front-end, both the CTF and DWARF readers are going to be (re)using the same ELF Reader type. That was one of the goals of that branch. And so the symtab object is going to come from there, so which ever you chose right now, it won't matter in the end when the "front-end" branch is merged into master. > And an additional use case is whether the tools `kmidiff', `abidiff' could > compare a DWARF IR with CTF IR? Why not? We compare ABIXML againt DWARF or CTF already. So why not trying to compare CTF against DWARF, see what breaks and then try to fix it? :-) > I exercised it with some libraries and binaries using `abidiff' > (finding a couple of problems in CTF reader (already fixed) and three > possible issues for DWARF, I will submit information and the test > cases about those) but in general seems to be work!, but before to > continue I would like to know your thoughts. There you go \o/ I think it's a good idea. [...] >> Right, abg-elf-helpers.h does have find_section_by_name. That can be >> used to look for the debug info, I guess. However, we also need to >> support finding the debug info when it's split out into a different >> place, like when it's packaged in a separate debug-info package. Today, >> abg-dwarf-reader.cc uses dwfl (dwarf front-end library, I believe) to do >> this, as dwfl knows how to find the DWARF debug info, wherever it is. >>=20 > > Ohh, your are right, I saw `find_alt_debug_info', and in case of CTF fron= t-end > we don't use dwfl, it is done by `find_alt_debuginfo', reading directly t= he content > of `.gnu_debuglink' section, I'm not sure if CTF reader can use `find_alt= _debug_info' > because it calls dwfl_* functions seems be DWARF specific. So I'll invest= igate. > >> You can see how this is done in read_context::load_debug_info(), in >> abg-dwarf-reader.cc, around line 2654. Look for the comment "Look for >> split debuginfo files". Basically, dwfl_module_getdwarf returns a >> pointer to the debug info it's found, if it has found one. I think we >> should split this logic out to make it re-usable somehow. >>=20 >> If you think this is worthwhile, I can think of splitting it out and >> stick it into elf-helpers, maybe? >>=20 > > It will be really useful!, but I'm not sure `dwfl_module_getdwarf' > can operate in ELF without `.debug_*' sections. In the "front-end" branch, I've put the new file_has_dwarf_debug_info for you to see at https://sourceware.org/git/?p=3Dlibabigail.git;a=3Dblob;f=3Dsrc/abg-tools-u= tils.cc;hb=3Drefs/heads/users/dodji/front-end#l423 Maybe the new elf_reader::reader type (in the new src/abg-elf-reader.cc file in the "front-end" branch) should grow a new elf_reader::reader::ctf_debug_info() member function that returns a pointer to the CTF object, just like what elf_reader::reader::dwarf_debug_info does? That function would look into the .ctf section, or use file_alt_debuginfo to locate the .gnu_debuglink section and use its content to locate the split debuginfo file. I think it's fairly doable. What do you think? [...] Cheers, --=20 Dodji