public inbox for libabigail@sourceware.org
 help / color / mirror / Atom feed
From: "Guillermo E. Martinez" <guillermo.e.martinez@oracle.com>
To: "Guillermo E. Martinez via Libabigail"
	<libabigail@sourceware.org>, Dodji Seketeli <dodji@seketeli.org>
Subject: Re: [PATCH v2] ctf-reader: Add support to read CTF information from Linux kernel
Date: Wed, 04 May 2022 07:48:52 -0500	[thread overview]
Message-ID: <2543885.7s5MMGUR32@sali> (raw)
In-Reply-To: <877d72fx7e.fsf@seketeli.org>

On Tuesday, May 3, 2022 10:32:53 AM CDT Dodji Seketeli wrote:
> Hello Guillermo,
> 
> Thanks a lot for this patch!  I like it.
oohh, thanks!!
> I do have some comments however.
> Please find them below.
great,
> [...]
> 
> 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 added this enum to handle the options::use_ctf (--ctf) from command line,
this option is passed thought abigail::ir::environment instance to know which
reader needs to be instantiated:

if (opts.use_ctf)
    env->set_debug_format_type(environment::CTF_FORMAT_TYPE);

if (env->get_debug_format_type() == environment::DWARF_FORMAT_TYPE)
  {
     // dwarf reader
  }
else if (env->get_debug_format_type() == environment::CTF_FORMAT_TYPE)
  { 
     // ctf reader
  }

By default is environment::DWARF_FORMAT_TYPE in include/abg-ir.h

Otherwise I think that we need to change the arguments in 
`build_corpus_group_from_kernel_dist_under'. For sure I can do this :-).

> 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);
> 
> [...]
ok, totally agree.
> +  debug_format_type debug_format_;
It is used to know which reader should be instantiated depending of command line.

> 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.
ok.
> [...]
> 
> +std::string
> +dic_type_key(ctf_dict_t *dic, ctf_id_t ctf_type)
> +{
> 
> Likewise.
ok.
> 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.
great!. So, consider it done.
> 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()
ok.
> 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
nice!.
> I hope this all makes sense.  If not, please do not hesitate to discuss
> it.
All make sense,
> Thanks again.
Thanks for these useful comments!!. I will send soon the patch v2 :-)

I was thinking to merge here the patch: 
https://sourceware.org/pipermail/libabigail/2022q2/004310.html[1]

Dodji, What do you think?

> Cheers,
Kind regards, 
Guillermo 



--------
[1] https://sourceware.org/pipermail/libabigail/2022q2/004310.html

  reply	other threads:[~2022-05-04 12:51 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
2022-05-04 12:48     ` Guillermo E. Martinez [this message]
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=2543885.7s5MMGUR32@sali \
    --to=guillermo.e.martinez@oracle.com \
    --cc=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).