public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "Evgenii Stepanov via binutils" <binutils@sourceware.org>
To: Binutils <binutils@sourceware.org>
Subject: Re: [PATCH] Generalize GC support for SHF_LINK_ORDER.
Date: Mon, 01 May 2017 22:37:00 -0000	[thread overview]
Message-ID: <CAFKCwrjV9qXGYNOrAV4w=pfxNNyLm7DkkdWQEK4K6+VaEt32jA@mail.gmail.com> (raw)
In-Reply-To: <20170401001620.107395-1-eugenis@google.com>

Friendly ping. Any opinions?


On Fri, Mar 31, 2017 at 5:16 PM, Evgenii Stepanov <eugenis@google.com> wrote:
> This change implements new GC semantics of SHF_LINK_ORDER discussed
> in the following thread on generic-abi ML:
> https://groups.google.com/d/msg/generic-abi/_CbBM6T6WeM/LZnqx1KZAQAJ
>
> It is a generalization of the logic that prevents garbage collection
> of .ARM.exidx sections by adding a GC reference from the
> corresponding text section (found by the sh_link field of the
> .ARM.exidx section).
>
> The new logic is exactly the same, and the code is basically a copy
> of the .ARM.exidx code, but now it is keyed off the SHF_LINK_ORDER
> flag instead of SHT_ARM_EXIDX section type. The existing ARM behavior
> is not changed because Gold already demands that SHT_ARM_EXIDX
> sections have SHF_LINK_ORDER flag set.
>
> Another change is not to consider __start_$section and
> __stop_$section symbols as GC references when $section has
> SHF_LINK_ORDER flag. The idea behind this is that SHF_LINK_ORDER
> section can contain metadata for the linked section, and section
> start/stop symbols can be used to enumarate that metadata at runtime.
> In this case the liveness of the metadata section should be
> determined only by the liveness of the linked section, and not be
> affected by the presence of start/stop symbols.
> ---
>  ChangeLog      |  6 ++++++
>  gold/arm.cc    | 47 -----------------------------------------------
>  gold/object.cc |  4 +++-
>  gold/reloc.cc  | 26 ++++++++++++++++++++++++++
>  4 files changed, 35 insertions(+), 48 deletions(-)
>
> diff --git a/ChangeLog b/ChangeLog
> index 3904dc134d..082cb0670f 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,9 @@
> +2016-03-31 Evgenii Stepanov <eugenis@google.com>
> +
> +       * gold/arm.cc: Remove do_gc_process_relocs
> +       * gold/reloc.cc: Handle SHF_LINK_ORDER in do_gc_process_relocs
> +       * gold/object.cc: Do not add SHF_LINK_ORDER sections to cident_sections.
> +
>  2016-03-17  Cary Coutant  <ccoutant@gmail.com>
>
>         * configure.ac: Add mips and s390 to the gold target check.
> diff --git a/gold/arm.cc b/gold/arm.cc
> index c47b00224c..f83c3bd737 100644
> --- a/gold/arm.cc
> +++ b/gold/arm.cc
> @@ -1686,10 +1686,6 @@ class Arm_relobj : public Sized_relobj_file<32, big_endian>
>    void
>    do_read_symbols(Read_symbols_data* sd);
>
> -  // Process relocs for garbage collection.
> -  void
> -  do_gc_process_relocs(Symbol_table*, Layout*, Read_relocs_data*);
> -
>   private:
>
>    // Whether a section needs to be scanned for relocation stubs.
> @@ -6939,49 +6935,6 @@ Arm_relobj<big_endian>::do_read_symbols(Read_symbols_data* sd)
>      }
>  }
>
> -// Process relocations for garbage collection.  The ARM target uses .ARM.exidx
> -// sections for unwinding.  These sections are referenced implicitly by
> -// text sections linked in the section headers.  If we ignore these implicit
> -// references, the .ARM.exidx sections and any .ARM.extab sections they use
> -// will be garbage-collected incorrectly.  Hence we override the same function
> -// in the base class to handle these implicit references.
> -
> -template<bool big_endian>
> -void
> -Arm_relobj<big_endian>::do_gc_process_relocs(Symbol_table* symtab,
> -                                            Layout* layout,
> -                                            Read_relocs_data* rd)
> -{
> -  // First, call base class method to process relocations in this object.
> -  Sized_relobj_file<32, big_endian>::do_gc_process_relocs(symtab, layout, rd);
> -
> -  // If --gc-sections is not specified, there is nothing more to do.
> -  // This happens when --icf is used but --gc-sections is not.
> -  if (!parameters->options().gc_sections())
> -    return;
> -
> -  unsigned int shnum = this->shnum();
> -  const unsigned int shdr_size = elfcpp::Elf_sizes<32>::shdr_size;
> -  const unsigned char* pshdrs = this->get_view(this->elf_file()->shoff(),
> -                                              shnum * shdr_size,
> -                                              true, true);
> -
> -  // Scan section headers for sections of type SHT_ARM_EXIDX.  Add references
> -  // to these from the linked text sections.
> -  const unsigned char* ps = pshdrs + shdr_size;
> -  for (unsigned int i = 1; i < shnum; ++i, ps += shdr_size)
> -    {
> -      elfcpp::Shdr<32, big_endian> shdr(ps);
> -      if (shdr.get_sh_type() == elfcpp::SHT_ARM_EXIDX)
> -       {
> -         // Found an .ARM.exidx section, add it to the set of reachable
> -         // sections from its linked text section.
> -         unsigned int text_shndx = this->adjust_shndx(shdr.get_sh_link());
> -         symtab->gc()->add_reference(this, text_shndx, this, i);
> -       }
> -    }
> -}
> -
>  // Update output local symbol count.  Owing to EXIDX entry merging, some local
>  // symbols  will be removed in output.  Adjust output local symbol count
>  // accordingly.  We can only changed the static output local symbol count.  It
> diff --git a/gold/object.cc b/gold/object.cc
> index a631c9937c..160156397d 100644
> --- a/gold/object.cc
> +++ b/gold/object.cc
> @@ -1623,10 +1623,12 @@ Sized_relobj_file<size, big_endian>::do_layout(Symbol_table* symtab,
>               symtab->gc()->worklist().push_back(Section_id(this, i));
>             }
>           // If the section name XXX can be represented as a C identifier
> +          // and the section does not have SHF_LINK_ORDER flag
>           // it cannot be discarded if there are references to
>           // __start_XXX and __stop_XXX symbols.  These need to be
>           // specially handled.
> -         if (is_cident(name))
> +         if (!(shdr.get_sh_flags() & elfcpp::SHF_LINK_ORDER)
> +             && is_cident(name))
>             {
>               symtab->gc()->add_cident_section(name, Section_id(this, i));
>             }
> diff --git a/gold/reloc.cc b/gold/reloc.cc
> index ca54f153a3..f782627f26 100644
> --- a/gold/reloc.cc
> +++ b/gold/reloc.cc
> @@ -35,6 +35,7 @@
>  #include "icf.h"
>  #include "compressed_output.h"
>  #include "incremental.h"
> +#include "gc.h"
>
>  namespace gold
>  {
> @@ -415,6 +416,31 @@ Sized_relobj_file<size, big_endian>::do_gc_process_relocs(Symbol_table* symtab,
>                                          local_symbols);
>          }
>      }
> +
> +  // If --gc-sections is not specified, there is nothing more to do.
> +  // This happens when --icf is used but --gc-sections is not.
> +  if (!parameters->options().gc_sections())
> +    return;
> +
> +  unsigned int shnum = this->shnum();
> +  const unsigned char* pshdrs = this->get_view(this->elf_file_.shoff(),
> +                                              shnum * This::shdr_size,
> +                                              true, true);
> +
> +  // Scan section headers for sections with SHF_LINK_ORDER.  Add references
> +  // to these from the linked text sections.
> +  const unsigned char* ps = pshdrs + This::shdr_size;
> +  for (unsigned int i = 1; i < shnum; ++i, ps += This::shdr_size)
> +    {
> +      This::Shdr shdr(ps);
> +      if (shdr.get_sh_flags() & elfcpp::SHF_LINK_ORDER)
> +       {
> +         // Found an SHF_LINK_ORDER section, add it to the set of reachable
> +         // sections from its linked text section.
> +         unsigned int text_shndx = this->adjust_shndx(shdr.get_sh_link());
> +         symtab->gc()->add_reference(this, text_shndx, this, i);
> +       }
> +    }
>  }
>
>
> --
> 2.12.2.564.g063fe858b8-goog
>

      reply	other threads:[~2017-05-01 22:37 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-01  0:16 Evgenii Stepanov via binutils
2017-05-01 22:37 ` Evgenii Stepanov via binutils [this message]

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='CAFKCwrjV9qXGYNOrAV4w=pfxNNyLm7DkkdWQEK4K6+VaEt32jA@mail.gmail.com' \
    --to=binutils@sourceware.org \
    --cc=eugenis@google.com \
    /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).