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

["xdje42 at gmail dot com" <sourceware-bugzilla@sourceware.org>]

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.