Re: [PATCH 2/2] btrace: avoid symbol lookup

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Fri, 07 Mar 2014 09:57:45 +0100, Markus Metzger wrote:
> --- a/gdb/btrace.c
> +++ b/gdb/btrace.c
> @@ -451,13 +451,17 @@ ftrace_update_function (struct gdbarch *gdbarch,
>    struct symbol *fun;
>    struct btrace_insn *last;
>  
> -  /* Try to determine the function we're in.  We use both types of symbols
> -     to avoid surprises when we sometimes get a full symbol and sometimes
> -     only a minimal symbol.  */
> -  fun = find_pc_function (pc);
> +  /* Try to determine the function we're in.  */
>    bmfun = lookup_minimal_symbol_by_pc (pc);
>    mfun = bmfun.minsym;
>  
> +  /* We only lookup the symbol in the debug information if we have not found
> +     a minimal symbol.  This avoids the expensive lookup for globally visible
> +     symbols.  */
> +  fun = NULL;
> +  if (mfun == NULL)
> +    fun = find_pc_function (pc);
> +
>    if (fun == NULL && mfun == NULL)
>      DEBUG_FTRACE ("no symbol at %s", core_addr_to_string_nz (pc));
>  
[...]

Behavior after the change is not the same.  DWARF functions symbols can span
over discontiguous ranges with DW_AT_ranges but their corresponding ELF
function symbols cannot, therefore those are just some approximation.

Testcase gdb.dwarf2/dw2-objfile-overlap.exp tests such a case, from:
	https://sourceware.org/ml/gdb-patches/2011-11/msg00166.html

For address of symbol "inner":
 * find_pc_function finds DWARF symbol "inner"
 * lookup_minimal_symbol_by_pc finds ELF symbol "outer_inner"

In few Fedora 20 x86_64 -O2 -g built libraries I have not found any
DW_TAG_subprogram using DW_AT_ranges, only DW_TAG_inlined_subroutine use
DW_AT_ranges.  But that is more a limitation of gcc, other compilers may
produce DW_TAG_subprogram using DW_AT_ranges with overlapping function parts.

Inlined functions are found by neither find_pc_function nor
lookup_minimal_symbol_by_pc (block_containing_function (block_for_pc ()) finds
inlined function).  Not sure if it is not a bug of find_pc_function but that
is off-topic here.

I do not think it will be hit in real world cases.  GDB would need some better
abstraction of the symbol kinds to be more systematic in what it outputs.

It would be good to know how much it helps your usecase as it is not a fully
clean/transparent change.


Thanks,
Jan


set confirm no
set trace-commands
file gdb.dwarf2/dw2-objfile-overlap-outer.x
add-symbol-file gdb.dwarf2/dw2-objfile-overlap-inner.x outer_inner
info sym inner
->
find_pc_function "inner".
lookup_minimal_symbol_by_pc "outer_inner".

diff --git a/gdb/printcmd.c b/gdb/printcmd.c
index 87b1448..f1517d2 100644
--- a/gdb/printcmd.c
+++ b/gdb/printcmd.c
@@ -1107,6 +1107,27 @@ sym_info (char *arg, int from_tty)
     error_no_arg (_("address"));
 
   addr = parse_and_eval_address (arg);
+
+{
+struct symbol *sym=find_pc_function (addr);
+if (sym) {
+  printf_filtered ("find_pc_function \"");
+  fprintf_symbol_filtered (gdb_stdout, SYMBOL_PRINT_NAME (sym),
+			   current_language->la_language, DMGL_ANSI);
+  printf_filtered ("\".\n");
+}
+}
+{
+struct bound_minimal_symbol bmfun=lookup_minimal_symbol_by_pc(addr);
+if (bmfun.minsym) {
+  printf_filtered ("lookup_minimal_symbol_by_pc \"");
+  fprintf_symbol_filtered (gdb_stdout, MSYMBOL_PRINT_NAME (bmfun.minsym),
+			   current_language->la_language, DMGL_ANSI);
+  printf_filtered ("\".\n");
+}
+}
+
+
   ALL_OBJSECTIONS (objfile, osect)
   {
     /* Only process each object file once, even if there's a separate