public inbox for libabigail@sourceware.org
 help / color / mirror / Atom feed
From: Dodji Seketeli <dodji@seketeli.org>
To: "Guillermo E. Martinez via Libabigail" <libabigail@sourceware.org>
Subject: Re: [PATCH v2] ctf-reader: Add support to read CTF information from Linux kernel
Date: Tue, 03 May 2022 17:32:53 +0200	[thread overview]
Message-ID: <877d72fx7e.fsf@seketeli.org> (raw)
In-Reply-To: <20220429141658.260012-1-guillermo.e.martinez@oracle.com> (Guillermo E. Martinez via Libabigail's message of "Fri, 29 Apr 2022 09:16:58 -0500")

Hello Guillermo,

Thanks a lot for this patch!  I like it.

I do have some comments however.
Please find them below.

[...]

diff --git a/include/abg-ir.h b/include/abg-ir.h
index a2f4e1a7..033e3708 100644
--- a/include/abg-ir.h
+++ b/include/abg-ir.h
@@ -136,7 +136,16 @@ class environment
 public:
   struct priv;
   std::unique_ptr<priv> priv_;
+  /// The possible debug format types. Default is DWARF_FORMAT_TYPE
+  enum debug_format_type
+  {
+    DWARF_FORMAT_TYPE,
+#ifdef WITH_CTF
+    CTF_FORMAT_TYPE,
+#endif
+  };

I'd prefer abg-ir.h to stay agnostic from front-end considerations
such as the kind of input (DWARF, CTF etc) as much as possible.  Those
considerations are handled in abg-corpus.h with the
abigail::corpus::origin enum, which is currently defined as:

  /// This abstracts where the corpus comes from.  That is, either it
  /// has been read from the native xml format, from DWARF or built
  /// artificially using the library's API.
  enum origin
  {
    ARTIFICIAL_ORIGIN = 0,
    NATIVE_XML_ORIGIN,
    DWARF_ORIGIN,
    CTF_ORIGIN,
    LINUX_KERNEL_BINARY_ORIGIN
  };

You can modify it to make it be a bitmap defined as:

  enum origin
  {
    ARTIFICIAL_ORIGIN = 0,
    NATIVE_XML_ORIGIN = 1,
    DWARF_ORIGIN = 1 << 1,
    CTF_ORIGIN = 1 << 2,
    LINUX_KERNEL_BINARY_ORIGIN = 1 << 3
  };

That way, you can modify abg-{ctf-reader,dwarf-reader,ir}.cc so that
instead of saying:

    if (corp->get_origin() == corpus::LINUX_KERNEL_BINARY_ORIGIN)
      // blah

it would instead say:

    if (corp->get_origin() & corpus::LINUX_KERNEL_BINARY_ORIGIN)
      // blah

or even:

    if (corp->get_origin()
	& corpus::LINUX_KERNEL_BINARY_ORIGIN
	& corpus:: CTF_ORIGIN)
      // blah

The different parts of the code that test for return of
corpus::get_origin() should be updated to take into account that the
value returned is now a bitmap.

Of course, in abg-ctf-reader.cc, the origin of the corpus would be set by doing:

    corp->set_origin(corpus::LINUX_KERNEL_BINARY_ORIGIN
		     | corpus::CTF_ORIGIN);

and in abg-dwarf-reader.cc, the origin of the corpus would be set by
doing: 

    ctxt.current_corpus()->set_origin(corpus::LINUX_KERNEL_BINARY_ORIGIN
				      | corpus::DWARF_ORIGIN);

[...]

+  debug_format_type debug_format_;

So, the abigail::ir::environment type should not have a debug_format_
data member.  If anything, all the data members are hidden in the
abigail::ir::environment::priv_, which is a pointer to
abigail::ir::environment::priv, defined in abg-ir-priv.h.  But I think
it's not neccessary to add anything there.  More on that below.

[...]

diff --git a/src/abg-ctf-reader.cc b/src/abg-ctf-reader.cc
index 2c6839cb..dcc65d4e 100644
--- a/src/abg-ctf-reader.cc
+++ b/src/abg-ctf-reader.cc

[...]

+  void initialize(const string& elf_path, ir::environment *env)
   {

Please, add a doxygen comment to this function.

[...]

+std::string
+dic_type_key(ctf_dict_t *dic, ctf_id_t ctf_type)
+{

Likewise.

diff --git a/src/abg-ir.cc b/src/abg-ir.cc
index 0ef5e8b2..5eebcfa3 100644
--- a/src/abg-ir.cc
+++ b/src/abg-ir.cc
@@ -3165,7 +3165,8 @@ typedef unordered_map<interned_string,
 
 /// Default constructor of the @ref environment type.
 environment::environment()
-  :priv_(new priv)
+  :priv_(new priv),
+  debug_format_(DWARF_FORMAT_TYPE)
 {}

As said above, the debug_format_ data member should not be added to
the environment type.

[...]

diff --git a/src/abg-tools-utils.cc b/src/abg-tools-utils.cc
index 1f0f6fa8..faa7243f 100644
--- a/src/abg-tools-utils.cc
+++ b/src/abg-tools-utils.cc

[...]

@@ -2543,12 +2576,21 @@ build_corpus_group_from_kernel_dist_under(const string&	root,
   t.start();
   bool got_binary_paths =
     get_binary_paths_from_kernel_dist(root, debug_info_root, vmlinux, modules);
+#ifdef WITH_CTF
+  string vmlinux_ctfa;
+  if (got_binary_paths &&
+      env->get_debug_format_type() == environment::CTF_FORMAT_TYPE)
+    {
+      got_binary_paths = get_vmlinux_ctfa_path_from_kernel_dist(root, vmlinux_ctfa);
+      ABG_ASSERT(!vmlinux_ctfa.empty());
+    }
+#endif
+

I think, rather than calling env->get_debug_format_type()
build_corpus_group_from_kernel_dist_under can be passed an additional
'corpus_origin' parameter of type corpus::origin.  The parameter would
have corpus::DWARF_ORIGIN as default argument, for instance.

Also, I think the rest of this function that follows could be
encapsulated into two functions that would be called:

    maybe_load_vmlinux_dwarf_corpus()

This function would load the vmlinux corpus from the ELF information.
That function would contain the code that is inside the block:

+      if (env->get_debug_format_type() == environment::DWARF_FORMAT_TYPE)
+        {

The new condition inside the function would rather be something like:

    if (corpus_origin & corpus::DWARF_ORIGIN)
      {
         //blah
      }
The function wouldn't do anything if the origin of the corpus is not DWARF.


The second function would be this one:

maybe_load_vmlinux_ctf_corpus()

it's invocation would be protected by an #ifdef WITH_CTF and its body
would be inside an if-block that would read:

    if (corpus_origin & corpus::CTF_ORIGIN)
      {
        // blah

I hope this all makes sense.  If not, please do not hesitate to discuss
it.

Thanks again.

Cheers,

-- 
		Dodji

  reply	other threads:[~2022-05-03 15:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-30 15:35 [PATCH] " Guillermo E. Martinez
2022-04-04 22:49 ` Guillermo Martinez
2022-04-29 14:16 ` [PATCH v2] " Guillermo E. Martinez
2022-05-03 15:32   ` Dodji Seketeli [this message]
2022-05-04 12:48     ` Guillermo E. Martinez
2022-05-12  8:50       ` Dodji Seketeli
2022-05-04 22:29     ` [PATCH v3] " Guillermo E. Martinez
2022-05-12 16:51       ` Dodji Seketeli
2022-05-16 16:03         ` Guillermo E. Martinez
2022-05-13  7:18       ` Dodji Seketeli

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=877d72fx7e.fsf@seketeli.org \
    --to=dodji@seketeli.org \
    --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).