public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "xdje42 at gmail dot com" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug symtab/17559] New: confusion on what the result of find_pc_symtab is Date: Thu, 06 Nov 2014 07:02:00 -0000 [thread overview] Message-ID: <bug-17559-4717@http.sourceware.org/bugzilla/> (raw) 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.
next reply other threads:[~2014-11-06 7:02 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-11-06 7:02 xdje42 at gmail dot com [this message] 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
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=bug-17559-4717@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@sourceware.org \ /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: linkBe 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; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).