public inbox for libabigail@sourceware.org
 help / color / mirror / Atom feed
From: "Guillermo E. Martinez" <guillermo.e.martinez@oracle.com>
To: libabigail@sourceware.org
Subject: Use CTF as a fallback when no DWARFs debug info is present
Date: Wed, 13 Jul 2022 18:25:09 -0500	[thread overview]
Message-ID: <21824871.EfDdHjke4D@sali> (raw)

Hello libabigail team,

Talking with my colleges Jose E.  Marchesi and Nick Alcock  about  of  the  user
interface provided by abidw, abidiff and some  other  tools  in  libabigail,  we
think such tools should be looks for DWARF debug information, and if it  is  not
present fall back for CTF even without --ctf option, this behaviour is  used  by
GDB (looking for .ctf and .debug_* section, but in libabigail  is  done  by  the
symtab class), so I did some minor changes in  abidw  and  abidiff  setting  the
corpus origin depending of `opts.use_ctf', trying to build the copus with  DWARF
debug information, but if it  is  not  possible  (`STATUS_DEBUG_INFO_NOT_FOUND')
looks for CTF info.

corpus::origin origin = opts.use_ctf ? CTF_ORIGIN : DWARF_ORIGIN;
...
if (origin == DWARF_ORIGIN)
  {
     // Build corpus with DWARF
  }
if ((status & STATUS_DEBUG_INFO_NOT_FOUND) ||
    origin == CTF_ORIGIN)
  {
     // Build corpus with CTF
  }

if (status & STATUS_DEBUG_INFO_NOT_FOUND)
  {
     // lets to know the user that no debug info
     // was found in DWARF neither CTF
  }

Doing in this way, seem to work, however there are functions  to  notifying  the
user about of  missing  debug  information  (e.g  `handle_error')  that  use  an
specific DWARF `read_context' reference, so if we want  to  reuse  it,  then  we
could split common functionality/interface for both readers  in  a  base  class:

class base_read_context
{
  ...
  virtual const string&
  alt_debug_info_path() const;

  void
  exported_decls_builder(corpus::exported_decls_builder* b);
  ...
};

class dwarf_reader::read_context : public base_read_context
{
  ...
};

class ctf_reader::read_context : public base_read_context
{
  ...
};


// Now reusing refers_to_alt_debug_info for both readers
bool
refers_to_alt_debug_info(const read_context&	ctxt,
                         string& alt_di_path)
{
  ...
}

Please let met know your feedback, I'll really appreciate! 

Regards,
guillermo



             reply	other threads:[~2022-07-13 23:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-13 23:25 Guillermo E. Martinez [this message]
2022-07-14  1:37 ` Ben Woodard
2022-07-14 15:06   ` Guillermo E. Martinez
2022-07-14 16:01     ` Ben Woodard
2022-07-14 17:35       ` Guillermo E. Martinez
2022-07-14 18:09         ` Ben Woodard
2022-07-14 23:13           ` Guillermo 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=21824871.EfDdHjke4D@sali \
    --to=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).