Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: will schmidt via Gdb-patches <gdb-patches@sourceware.org>
To: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Cc: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>,
	rogerio <rogealve@br.ibm.com>, Alan Modra <amodra@gmail.com>
Subject: [Patch v2] Handle .TOC. sections during gdb-compile for rs6000 target.
Date: Wed, 28 Jul 2021 14:08:21 -0500	[thread overview]
Message-ID: <21185e6d3118c97c9dde66df366bb9ff3b31dede.camel@vnet.ibm.com> (raw)

[gdb] Handle .TOC. sections during gdb-compile for rs6000 target.
    
Hi,

[V2]  Multiple changes and cleanups per feedback.  Added logic
to iterate through the sections to find one with SEC_ALLOC flags
set to serve as a substitite for an absent .toc section.
This was/is exercised with the test suite running in a power9 LE
environment.   Per that testing, I don't believe I've got a case
where we had to resort as far as using the bfd_abs_section_ptr
as a fallback, so additional scrutiny may be required for that
portion of this patch.

[V1, updated]

  When we encounter a .TOC. symbol in the object we are loading,
we need to associate this with the .toc section in order to
properly resolve other symbols in the object.  IF a .toc section
is not found, iterate the sections until we find one with the
SEC_ALLOC flag.   If that also fails, fall back to using
bfd_abs_section_ptr.

This is part of a short series of patches that allows gdb-compile
support to function for the ppc64le target.

OK for trunk?

Thanks
-Will
    
    
    gdb/Changelog:
    yyyy-mm-dd  Will Schmidt  <will_schmidt@vnet.ibm.com>
    
            * gdb/compile/compile-object-load.c (compile_object_load):
            Add handling for the .TOC. symbol.

diff --git a/gdb/compile/compile-object-load.c b/gdb/compile/compile-object-load.c
index 1c512801bcd..70742bf9b8e 100644
--- a/gdb/compile/compile-object-load.c
+++ b/gdb/compile/compile-object-load.c
@@ -720,10 +720,52 @@ compile_object_load (const compile_file_names &file_names,
 	     need for _GLOBAL_OFFSET_TABLE_.  Together with -fPIE the data
 	     remain PC-relative even with _GLOBAL_OFFSET_TABLE_ as zero.  */
 	  sym->value = 0;
 	  continue;
 	}
+      if (strcmp (sym->name, ".TOC.") == 0)
+	{
+	  /* Handle the .TOC. symbol as the linker would do.  Set the .TOC.
+	     sections value and the section to point to the ".toc" section,
+	     and pass the toc->vma value into bfd_set_gp_value().
+	     If the .toc section is not found, use the first section
+	     with the SEC_ALLOC flag set.   Im the unlikely case that
+	     we still do not have a section identified, fall back to using
+	     bfd_abs_section_ptr.  */
+	  asection *toc_fallback = bfd_get_section_by_name(abfd.get(), ".toc");
+	  if (toc_fallback == NULL) {
+	    for (asection *tsect = abfd->sections; tsect != nullptr;
+	         tsect = tsect->next) {
+	      if (bfd_section_flags (tsect) & SEC_ALLOC) {
+		if (compile_debug)
+		  fprintf_unfiltered (gdb_stdlog,
+				      "Using section [%s] as .toc fallback.\n",
+				      tsect->name);
+		toc_fallback = tsect;
+		break;
+	      }
+	    }
+	  }
+	  if (toc_fallback == NULL) {
+            /*  If we've gotten here, we have not found a section usable
+		as a backup for the .toc section.  Use bfd_abs_section_ptr. */
+            if (compile_debug)
+	      fprintf_unfiltered (gdb_stdlog,
+				  "Using bfd_abs_section_ptr as .toc fallback.\n");
+            toc_fallback = bfd_abs_section_ptr;
+          }
+          sym->section = toc_fallback;
+          sym->value = 0x8000;
+          bfd_set_gp_value(abfd.get(), toc_fallback->vma);
+          if (compile_debug)
+            fprintf_unfiltered (gdb_stdlog,
+                                "Connectiong ELF symbol \"%s\" to the .toc section (%s)\n",
+                                sym->name,
+                                paddress (target_gdbarch (), sym->value));
+          continue;
+        }
+
       bmsym = lookup_minimal_symbol (sym->name, NULL, NULL);
       switch (bmsym.minsym == NULL
 	      ? mst_unknown : MSYMBOL_TYPE (bmsym.minsym))
 	{
 	case mst_text:


             reply	other threads:[~2021-07-28 19:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-28 19:08 will schmidt via Gdb-patches [this message]
2021-07-29  7:18 ` Ulrich Weigand via Gdb-patches
2021-07-29  8:26   ` Alan Modra via Gdb-patches
2021-07-29 11:49     ` Ulrich Weigand via Gdb-patches
2021-08-05 17:50       ` will schmidt 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=21185e6d3118c97c9dde66df366bb9ff3b31dede.camel@vnet.ibm.com \
    --to=gdb-patches@sourceware.org \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=amodra@gmail.com \
    --cc=rogealve@br.ibm.com \
    --cc=will_schmidt@vnet.ibm.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