public inbox for libabigail@sourceware.org
 help / color / mirror / Atom feed
From: Ben Woodard <woodard@redhat.com>
To: Dodji Seketeli <dodji@seketeli.org>,
	Guillermo Martinez <guillermo.e.martinez@oracle.com>
Cc: "Guillermo E. Martinez via Libabigail" <libabigail@sourceware.org>
Subject: Re: [PATCH] CTF as a fallback when no DWARF debug info is present
Date: Fri, 7 Oct 2022 09:04:58 -0700	[thread overview]
Message-ID: <30e8eec6-8f76-0bf7-0e9d-41d1ba02baa8@redhat.com> (raw)
In-Reply-To: <86czb3bvok.fsf@seketeli.org>


On 10/7/22 06:38, Dodji Seketeli wrote:
> Hello Guillermo,
>
> Guillermo Martinez <guillermo.e.martinez@oracle.com> a écrit:
>
>> Yes, it sounds good!!, just I would like to know your opinion about of what
>> will happen when neither DWARF nor CTF debug information is found, the current
>> behavior is to extract symbols information and compare them, so which symbol
>> 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'm strongly in favor of this.
>
>> 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.
>>>
>> Ohh, your are right, I saw `find_alt_debug_info', and in case of CTF front-end
>> we don't use dwfl, it is done by `find_alt_debuginfo', reading directly the 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 investigate.
>>
>>> 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.
>>>
>>> If you think this is worthwhile, I can think of splitting it out and
>>> stick it into elf-helpers, maybe?
>>>
>> 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=libabigail.git;a=blob;f=src/abg-tools-utils.cc;hb=refs/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,
>


  reply	other threads:[~2022-10-07 16:05 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-01  0:15 Guillermo E. Martinez
2022-10-04  9:04 ` Dodji Seketeli
2022-10-04 23:13   ` Guillermo E. Martinez
2022-10-06  7:42     ` Dodji Seketeli
2022-10-06 14:12       ` Dodji Seketeli
2022-10-07 14:13         ` Guillermo E. Martinez
2022-10-06 19:53       ` Guillermo Martinez
2022-10-06 19:50         ` Guillermo E. Martinez
2022-10-07 13:38         ` Dodji Seketeli
2022-10-07 16:04           ` Ben Woodard [this message]
2022-11-15 20:13 ` [PATCHv2] ELF based front-end readers fallback feature Guillermo E. Martinez
2022-11-21 18:51   ` [PATCHv3] " Guillermo E. Martinez
2022-11-22 14:19     ` Dodji Seketeli
2022-11-22 16:02       ` Guillermo E. Martinez
2022-11-22 16:00     ` [PATCH v4] " Guillermo E. Martinez
2022-11-28 15:56       ` Dodji Seketeli
2022-11-28 21:59         ` Guillermo E. Martinez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=30e8eec6-8f76-0bf7-0e9d-41d1ba02baa8@redhat.com \
    --to=woodard@redhat.com \
    --cc=dodji@seketeli.org \
    --cc=guillermo.e.martinez@oracle.com \
    --cc=libabigail@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).