aboutsummaryrefslogtreecommitdiff
path: root/gdb/parse.c
diff options
context:
space:
mode:
authorPedro Alves <palves@redhat.com>2018-04-26 13:01:27 +0100
committerPedro Alves <palves@redhat.com>2018-04-26 13:09:16 +0100
commitf50776aad58a1df6b8f7f2a7d25a3b10aa074f7b (patch)
tree12fa9bfb091d97cad5718f9ed886d362e5444952 /gdb/parse.c
parent20944a6e20324cd897bf6c4c5fd20ef7224dacaa (diff)
downloadgdb-f50776aad58a1df6b8f7f2a7d25a3b10aa074f7b.zip
gdb-f50776aad58a1df6b8f7f2a7d25a3b10aa074f7b.tar.gz
gdb-f50776aad58a1df6b8f7f2a7d25a3b10aa074f7b.tar.bz2
For PPC64/ELFv1: Introduce mst_data_gnu_ifunc
Running the new tests added later in the series on PPC64 (ELFv1) revealed that the current ifunc support needs a bit of a design rework to work properly on PPC64/ELFv1, as most of the new tests fail. The ifunc support only kind of works today if the ifunc symbol and the resolver have the same name, as is currently tested by the gdb.base/gnu-ifunc.exp testcase, which is unlike how ifuncs are written nowadays. The crux of the problem is that ifunc symbols are really function descriptors, not text symbols: 44: 0000000000020060 104 FUNC GLOBAL DEFAULT 18 gnu_ifunc_resolver 54: 0000000000020060 104 GNU_IFUNC GLOBAL DEFAULT 18 gnu_ifunc But, currently GDB only knows about ifunc symbols that are text symbols. GDB's support happens to work in practice for PPC64 when the ifunc and resolver are one and only, like in the current gdb.base/gnu-ifunc.exp testcase: 15: 0000000000020060 104 GNU_IFUNC GLOBAL DEFAULT 18 gnu_ifunc because in that case, the synthetic ".gnu_ifunc" entry point text symbol that bfd creates from the actual GNU ifunc "gnu_ifunc" function (descriptor) symbol ends up with the the "is a gnu ifunc" flag set / copied over: (gdb) maint print msymbols ... [ 8] i 0x9c4 .gnu_ifunc section .text <<< mst_text_gnu_ifunc ... [29] D 0x20060 gnu_ifunc section .opd crtstuff.c <<< mst_data But, if the resolver gets a distinct symbol/name from the ifunc symbol, then we end up with this: (gdb) maint print msymbols [ 8] T 0x9e4 .gnu_ifunc_resolver section .text <<< mst_text ... [29] D 0x20060 gnu_ifunc section .opd crtstuff.c <<< mst_data [30] D 0x20060 gnu_ifunc_resolver section .opd crtstuff.c <<< mst_data I have a follow up bfd patch that turns that into: (gdb) maint print msymbols + [ 8] i 0x9e4 .gnu_ifunc section .text <<< mst_text_gnu_ifunc [ 8] T 0x9e4 .gnu_ifunc_resolver section .text <<< mst_text ... [29] D 0x20060 gnu_ifunc section .opd crtstuff.c [30] D 0x20060 gnu_ifunc_resolver section .opd crtstuff.c but that won't help everything. We still need this patch. Specifically, when we do a symbol lookup by name, like e.g., to call a function (see c-exp.y hunk), e.g., "p gnu_ifunc()", then we need to know that the found "gnu_ifunc" minimal symbol is an ifunc in order to do some special processing. But, on PPC, that lookup by name finds the function descriptor symbol, which presently is just a mst_data symbol, while at present, we look for mst_text_gnu_ifunc symbols to decide whether to do special GNU ifunc processing. In most of those places, we could try to resolve the function descriptor with gdbarch_convert_from_func_ptr_addr, and then lookup the minimal symbol at the resolved PC, see if that finds a minimal symbol of type mst_text_gnu_ifunc. If so, then we could assume that the original mst_dadta / function descriptor "gnu_ifunc" symbol was an ifunc. I tried it, and it mostly works, even if it's not the most efficient. However, there's one case that can't work with such a design -- it's that of the user calling the ifunc resolver directly to debug it, like "p gnu_ifunc_resolver(0)", expecting that to return the function pointer of the final function (which is exercised by the new tests added later). In this case, with the not-fully-working solution, we'd resolve the function descriptor, find that there's an mst_text_gnu_ifunc symbol for the resolved address, and proceed calling the function as if we tried to call "gnu_ifunc", the user-visible GNU ifunc symbol, instead of the resolver. I.e., it'd be impossible to call the resolver directly as a normal function. Introducing mst_data_gnu_ifunc eliminates the need for several gdbarch_convert_from_func_ptr_addr calls, and, fixes the "call resolver directly" use case mentioned above too. It's the cleanest approach I could think of. In sum, we make GNU ifunc function descriptor symbols get a new "mst_data_gnu_ifunc" minimal symbol type instead of the bare mst_data type. So when symbol lookup by name finds such a minimal symbol, we know we found an ifunc symbol, without resolving the entry/text symbol. If the user calls the the resolver symbol instead, like "p gnu_ifunc_resolver(0)", then we'll find the regular mst_data symbol for "gnu_ifunc_resolver", and we'll call the resolver function as just another regular function. With this, most of the GNU ifunc tests added by a later patch pass on PPC64 too. The following bfd patch fixes the remaining issues. gdb/ChangeLog: 2018-04-26 Pedro Alves <palves@redhat.com> * breakpoint.c (set_breakpoint_location_function): Handle mst_data_gnu_ifunc. * c-exp.y (variable production): Handle mst_data_gnu_ifunc. * elfread.c (elf_symtab_read): Give data symbols with BSF_GNU_INDIRECT_FUNCTION set mst_data_gnu_ifunc type. (elf_rel_plt_read): Update comment. * linespec.c (convert_linespec_to_sals): Handle mst_data_gnu_ifunc. (minsym_found): Handle mst_data_gnu_ifunc. * minsyms.c (msymbol_is_function, minimal_symbol_reader::record) (find_solib_trampoline_target): Handle mst_data_gnu_ifunc. * parse.c (find_minsym_type_and_address): Handle mst_data_gnu_ifunc. * symmisc.c (dump_msymbols): Handle mst_data_gnu_ifunc. * symtab.c (find_gnu_ifunc): Handle mst_data_gnu_ifunc. * symtab.h (minimal_symbol_type) <mst_text_gnu_ifunc>: Update comment. <mst_data_gnu_ifunc>: New enumerator.
Diffstat (limited to 'gdb/parse.c')
-rw-r--r--gdb/parse.c45
1 files changed, 19 insertions, 26 deletions
diff --git a/gdb/parse.c b/gdb/parse.c
index 3abb9d4..1d53b5a 100644
--- a/gdb/parse.c
+++ b/gdb/parse.c
@@ -461,42 +461,35 @@ find_minsym_type_and_address (minimal_symbol *msymbol,
struct gdbarch *gdbarch = get_objfile_arch (objfile);
struct obj_section *section = MSYMBOL_OBJ_SECTION (objfile, msymbol);
enum minimal_symbol_type type = MSYMBOL_TYPE (msymbol);
- CORE_ADDR pc;
bool is_tls = (section != NULL
&& section->the_bfd_section->flags & SEC_THREAD_LOCAL);
- /* Addresses of TLS symbols are really offsets into a
- per-objfile/per-thread storage block. */
- CORE_ADDR addr = (is_tls
- ? MSYMBOL_VALUE_RAW_ADDRESS (bound_msym.minsym)
- : BMSYMBOL_VALUE_ADDRESS (bound_msym));
-
/* The minimal symbol might point to a function descriptor;
resolve it to the actual code address instead. */
- pc = gdbarch_convert_from_func_ptr_addr (gdbarch, addr, &current_target);
- if (pc != addr)
+ CORE_ADDR addr;
+ if (is_tls)
{
- struct bound_minimal_symbol ifunc_msym = lookup_minimal_symbol_by_pc (pc);
-
- /* In this case, assume we have a code symbol instead of
- a data symbol. */
-
- if (ifunc_msym.minsym != NULL
- && MSYMBOL_TYPE (ifunc_msym.minsym) == mst_text_gnu_ifunc
- && BMSYMBOL_VALUE_ADDRESS (ifunc_msym) == pc)
+ /* Addresses of TLS symbols are really offsets into a
+ per-objfile/per-thread storage block. */
+ addr = MSYMBOL_VALUE_RAW_ADDRESS (bound_msym.minsym);
+ }
+ else if (msymbol_is_function (objfile, msymbol, &addr))
+ {
+ if (addr != BMSYMBOL_VALUE_ADDRESS (bound_msym))
{
- /* A function descriptor has been resolved but PC is still in the
- STT_GNU_IFUNC resolver body (such as because inferior does not
- run to be able to call it). */
-
- type = mst_text_gnu_ifunc;
+ /* This means we resolved a function descriptor, and we now
+ have an address for a code/text symbol instead of a data
+ symbol. */
+ if (MSYMBOL_TYPE (msymbol) == mst_data_gnu_ifunc)
+ type = mst_text_gnu_ifunc;
+ else
+ type = mst_text;
+ section = NULL;
}
- else
- type = mst_text;
- section = NULL;
- addr = pc;
}
+ else
+ addr = BMSYMBOL_VALUE_ADDRESS (bound_msym);
if (overlay_debugging)
addr = symbol_overlayed_address (addr, section);