This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug symtab/17559] confusion on what the result of find_pc_symtab is
- From: "xdje42 at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Thu, 06 Nov 2014 07:12:48 +0000
- Subject: [Bug symtab/17559] confusion on what the result of find_pc_symtab is
- Auto-submitted: auto-generated
- References: <bug-17559-4717 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=17559
--- Comment #1 from Doug Evans <xdje42 at gmail dot com> ---
Data point:
If (hypothetically) we fix find_pc_symtab to work the way gdb_disassembly
expects it to, I suspect we'll break this usage here in frame.c:
/* We retrieve the frame's symtab by using the frame PC.
However we cannot use the frame PC as-is, because it usually
points to the instruction following the "call", which is
sometimes the first instruction of another function. So we
rely on get_frame_address_in_block() which provides us with a
PC which is guaranteed to be inside the frame's code
block. */
if (get_frame_address_in_block_if_available (fi, &pc))
{
struct symtab *s = find_pc_symtab (pc); //xyzdje
if (s
&& s->language != current_language->la_language
&& s->language != language_unknown
&& language_mode == language_mode_auto)
set_language (s->language);
}
For example, if we stop in a .h file included by a c++ file,
will this set the language to C (instead of the right answer of C++)?
An open question I have is: Is the language of non-primary symtabs (e.g.,
headers) ever useful (except as is currently used in the heuristics to try to
compute the language of the primary symtab) ?
--
You are receiving this mail because:
You are on the CC list for the bug.