Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Simon Marchi <simark@simark.ca>
To: Christian Biesinger <cbiesinger@google.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH v3] Replace solib_global_lookup with gdbarch_iterate_over_objfiles_in_search_order
Date: Fri, 20 Sep 2019 01:01:00 -0000	[thread overview]
Message-ID: <5a2bc785-4ecd-0c21-10b0-ab8f3d17aa02@simark.ca> (raw)
In-Reply-To: <20190827230330.89757-1-cbiesinger@google.com>

On 2019-08-27 7:03 p.m., Christian Biesinger via gdb-patches wrote:
> [Test solib-corrupted.exp is now fixed]
> 
> All implementations of either function use it for the same purpose (except
> Darwin, which is a no-op): to prefer a symbol in the current objfile over
> symbols with the same name in other objfiles. There does not seem to be a
> reason to have both mechanisms for that purpose.

Hi Christian,

The patch LGTM, I'm also confident that it doesn't change the current
behavior.  I just have two very minor comments below.

Note that SPU support is about to be removed [1].  If you wait until it is
removed, it would simplify a bit this patch, as you wish.

[1] https://sourceware.org/ml/gdb-patches/2019-09/msg00067.html

> @@ -3202,32 +3204,41 @@ svr4_lp64_fetch_link_map_offsets (void)
>  
>  struct target_so_ops svr4_so_ops;
>  
> -/* Lookup global symbol for ELF DSOs linked with -Bsymbolic.  Those DSOs have a
> +/* Search order for ELF DSOs linked with -Bsymbolic.  Those DSOs have a
>     different rule for symbol lookup.  The lookup begins here in the DSO, not in
>     the main executable.  */
>  
> -static struct block_symbol
> -elf_lookup_lib_symbol (struct objfile *objfile,
> -		       const char *name,
> -		       const domain_enum domain)
> +void
> +svr4_iterate_over_objfiles_in_search_order
> +  (struct gdbarch *gdbarch,
> +   iterate_over_objfiles_in_search_order_cb_ftype *cb,
> +   void *cb_data, struct objfile *current_objfile)
>  {
> -  bfd *abfd;
> -
> -  if (objfile == symfile_objfile)
> -    abfd = exec_bfd;
> -  else
> +  if (current_objfile != nullptr)
>      {
> -      /* OBJFILE should have been passed as the non-debug one.  */
> -      gdb_assert (objfile->separate_debug_objfile_backlink == NULL);
> +      bfd *abfd;
>  
> -      abfd = objfile->obfd;
> -    }
> +      if (current_objfile->separate_debug_objfile_backlink != nullptr)
> +        current_objfile = current_objfile->separate_debug_objfile_backlink;
>  
> -  if (abfd == NULL || scan_dyntag (DT_SYMBOLIC, abfd, NULL, NULL) != 1)
> -    return {};
> +      if (current_objfile == symfile_objfile)
> +	abfd = exec_bfd;
> +      else
> +	abfd = current_objfile->obfd;
> +
> +      if (abfd != nullptr &&
> +	  scan_dyntag (DT_SYMBOLIC, abfd, nullptr, nullptr) == 1)
> +	{
> +	  if (cb (current_objfile, cb_data) != 0)
> +	    return;
> +	}
> +    }
>  
> -  return lookup_global_symbol_from_objfile (objfile, GLOBAL_BLOCK, name,
> -					    domain);
> +  for (objfile *objfile : current_program_space->objfiles ())
> +    {
> +      if (cb (objfile, cb_data) != 0)
> +	return;
> +    }
>  }

If we do search the current objfile in the first part of that
function, we could skip it in the second part.

> diff --git a/gdb/solib-svr4.h b/gdb/solib-svr4.h
> index a051e70b79..b99b8e2e3a 100644
> --- a/gdb/solib-svr4.h
> +++ b/gdb/solib-svr4.h
> @@ -21,6 +21,7 @@
>  #define SOLIB_SVR4_H
>  
>  #include "solist.h"
> +#include "gdbarch.h"

Could this be a forward declaration of `struct gdbarch` instead?

Though if you wait until SPU is removed, the function
svr4_iterate_over_objfiles_in_search_order won't need to be exported, it should
be made static.

Simon


  parent reply	other threads:[~2019-09-20  1:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-27 20:30 [PATCH v2] " Christian Biesinger via gdb-patches
2019-08-27 21:38 ` [PATCH v3] " Christian Biesinger via gdb-patches
2019-08-27 23:03   ` Christian Biesinger via gdb-patches
2019-09-10 14:35     ` [ping] " Christian Biesinger via gdb-patches
2019-09-17 12:03       ` Christian Biesinger via gdb-patches
2019-09-20  1:01     ` Simon Marchi [this message]
2019-09-20  2:57       ` Christian Biesinger via gdb-patches
2019-09-20  2:57         ` [PUSHED/OBVIOUS] Don't duplicate comment in symfile.c and .h Christian Biesinger via gdb-patches
2019-09-20  2:59           ` Christian Biesinger via gdb-patches
2019-09-20  2:58         ` [PATCH v4] Replace solib_global_lookup with gdbarch_iterate_over_objfiles_in_search_order Christian Biesinger via gdb-patches
2019-09-20 10:56           ` Simon Marchi
2019-09-21  2:20             ` Christian Biesinger via gdb-patches

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=5a2bc785-4ecd-0c21-10b0-ab8f3d17aa02@simark.ca \
    --to=simark@simark.ca \
    --cc=cbiesinger@google.com \
    --cc=gdb-patches@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