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:
next 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