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
next 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).