This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug symtab/17559] New: confusion on what the result of find_pc_symtab is


https://sourceware.org/bugzilla/show_bug.cgi?id=17559

            Bug ID: 17559
           Summary: confusion on what the result of find_pc_symtab is
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: xdje42 at gmail dot com

Reading through all callers of find_pc_symtab I found this in gdb_disassembly:

  /* Assume symtab is valid for whole PC range.  */
  symtab = find_pc_symtab (low);

  if (symtab != NULL && symtab->linetable != NULL)
    {
      /* Convert the linetable to a bunch of my_line_entry's.  */
      le = symtab->linetable->item;
      nlines = symtab->linetable->nitems;
    }

What if foo.c includes foo.h, and the function we're disassembling is in foo.h?

The bug is observed with "disas /m function_in_header", it prints nothing,
whereas "disas function_in_header" will properly print the disassembly.

The problem here is that the result of find_pc_symtab is the primary symtab
(AFAICT, and I haven't found anything to the contrary) but this function
assumes the symtab for "low" is returned, even if it's a non-primary symtab.

I have a significant change to symtab organization in progress,
and one open question is how to handle this use-case.

We want a lookup function that returns the symtab (primary or non-primary) for
a given pc.  That can either be achieved via one lookup function that returns
(for the sake of discussion) the primary symtab (blockvector really) and then
another lookup function that takes the result of that and finds the "real"
symtab (in the above example we want the symtab for foo.h), or it can be
achieved via having one lookup function that directly returns the desired
symtab.  The problem with the latter approach is that pc-based lookups don't
use the line-number part of symtabs, so we kinda have to find the blockvector
first anyway.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]