public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug symtab/17559] New: confusion on what the result of find_pc_symtab is
@ 2014-11-06  7:02 xdje42 at gmail dot com
  2014-11-06  7:12 ` [Bug symtab/17559] " xdje42 at gmail dot com
                   ` (8 more replies)
  0 siblings, 9 replies; 10+ messages in thread
From: xdje42 at gmail dot com @ 2014-11-06  7:02 UTC (permalink / raw)
  To: gdb-prs

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.


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2014-12-25  0:45 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-11-06  7:02 [Bug symtab/17559] New: confusion on what the result of find_pc_symtab is xdje42 at gmail dot com
2014-11-06  7:12 ` [Bug symtab/17559] " xdje42 at gmail dot com
2014-11-06  7:16 ` xdje42 at gmail dot com
2014-11-06  7:20 ` xdje42 at gmail dot com
2014-11-06  7:36 ` xdje42 at gmail dot com
2014-11-06 18:57 ` xdje42 at gmail dot com
2014-11-10  0:18 ` xdje42 at gmail dot com
2014-11-15 18:12 ` cvs-commit at gcc dot gnu.org
2014-11-15 18:15 ` xdje42 at gmail dot com
2014-12-25  0:45 ` cvs-commit at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).