public inbox for libabigail@sourceware.org
 help / color / mirror / Atom feed
From: Dodji Seketeli <dodji@seketeli.org>
To: "Guillermo E. 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: Thu, 06 Oct 2022 16:12:49 +0200	[thread overview]
Message-ID: <86h70havmm.fsf@seketeli.org> (raw)
In-Reply-To: <86mta9bdpm.fsf@seketeli.org> (Dodji Seketeli's message of "Thu, 06 Oct 2022 09:42:13 +0200")

Hey again Guillermo,

So, even before you sent the patch, I was "playing" with the idea of
re-organizing the code of the readers to make front-ends/readers be
first class citizens in libabigail.

The idea is to have all the front-ends share/implement an abstract
interface: the Front End Interface, named abigail::fe_iface.  So there
would be abigail::elf_reader::reader, abigail::dwarf_reader::reader and
abigail::ctf_reader::reader and abigtail::abixml_reader::reader
front-ends, all implementing the abigail::fe_iface.  They would all have
to grok their intended input, build the IR as a result and pass it to
the middle-end.

Most of the craft of analyzing the ELF part would be of course in
located in the abigail::elf_reader::reader type.

The abigail::{dwarf,ctf}_reader::reader types would just have to use the
elf_reader::reader type to handle ELF stuff.

An example of what that would look like is in the
"users/dodji/front-end" branch at
https://sourceware.org/git/?p=libabigail.git;a=shortlog;h=refs/heads/users/dodji/front-end.

The interface of the new elf-reader type is at
https://sourceware.org/git/?p=libabigail.git;a=blob;f=include/abg-elf-reader.h;hb=refs/heads/users/dodji/front-end.

The abigail::fe_iface interface it implements is at
https://sourceware.org/git/?p=libabigail.git;a=blob;f=include/abg-fe-iface.h;hb=refs/heads/users/dodji/front-end.

It's not yet documented, but after the discussion we had on your patch,
I tried to implement a helper function
abigail::tools_utils::file_has_dwarf_debug_info() using the new
abigail::elf_reader::reader type.

You can see it at
https://sourceware.org/git/?p=libabigail.git;a=blob;f=src/abg-tools-utils.cc;hb=refs/heads/users/dodji/front-end#l423

So, that function file_has_dwarf_debug_info() can be used to determine
if an ELF file has debug info (even taking into account split debug
information).  Based on that information, the tool could chose the right
front-end to use.

This is still work-in-progress, but the branch passes "make distcheck",
for what it's worth.

If you are interested, maybe you could base the subsequent versions of
your patch on this branch?  What do you think?

In any case, I'll keep exploring this topic on that branch and I'll send
a message to the list a bit later to present it a little bit further.

Cheers,

-- 
		Dodji

  reply	other threads:[~2022-10-06 14:12 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 [this message]
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
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=86h70havmm.fsf@seketeli.org \
    --to=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).