binutils-gdb/gdb/buildsym.h

458 lines
13 KiB
C
Raw Normal View History

/* Build symbol tables in GDB's internal format.
Copyright (C) 1986-2022 Free Software Foundation, Inc.
1999-07-08 04:19:36 +08:00
This file is part of GDB.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or
1999-07-08 04:19:36 +08:00
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>. */
#if !defined (BUILDSYM_H)
#define BUILDSYM_H 1
#include "gdbsupport/gdb_obstack.h"
gdb: change subfile::line_vector to an std::vector Change this field to an std::vector to facilitate memory management. Since the linetable_entry array is copied into the symtab resulting from the subfile, it is possible to change it without changing how symtab stores the linetable entries (which would be a much larger change). There is a small change in buildsym_compunit::record_line to avoid accessing a now invalid linetable_entry. Before this patch, we keep a pointer to the last linetable entry, pop it from the vector, and then read last->line. It works with the manually-maintained array, but since we now use std::vector::pop_back, I am afraid that it could be flagged as an invalid access by the various static / dynamic analysis tools to access the linetable_entry object after popping it from the vector. Instead, record just the line number in an optional and use it. There are substantial changes in xcoffread.c that simplify the code, but I can't test them. I was hesitant to do this change because of that, but I decided to send it anyway. I don't think that an almost dead platform should hold back improving the code in the common parts of GDB. The changes in xcoffread.c are: - Make arrange_linetable "arrange" the linetable passed as a parameter, instead of returning possibly a new one, possibly the same one. - In the "Process main file's line numbers.", I'm not too sure what happens. We get the lintable from "main_subfile", "arrange" it, but then assign the result to the current subfile, obtained with get_current_subfile. I assume that the current subfile is also the main one, so now I just call arrange_linetable on the main subfile's line table. - Remove that weird "Useless if!!!" FIXME comment. It's been there forever, but the "if" is still there, so I guess the "if" can stay there. Change-Id: I11799006fd85189e8cf5bd3a168f8f38c2c27a80
2022-04-07 20:55:16 +08:00
#include "symtab.h"
#include "addrmap.h"
Don't include gdbarch.h from defs.h I touched symtab.h and was surprised to see how many files were rebuilt. I looked into it a bit, and found that defs.h includes gdbarch.h, which in turn includes many things. gdbarch.h is only needed by a minority ofthe files in gdb, so this patch removes the include from defs.h and updates the fallout. I did "wc -l" on the files in build/gdb/.deps; this patch reduces the line count from 139935 to 137030; so there are definitely future build-time savings here. Note that while I configured with --enable-targets=all, it's possible that some *-nat.c file needs an update. I could not test all of these. The buildbot caught a few problems along these lines. gdb/ChangeLog 2019-07-10 Tom Tromey <tom@tromey.com> * defs.h: Don't include gdbarch.h. * aarch64-ravenscar-thread.c, aarch64-tdep.c, alpha-bsd-tdep.h, alpha-linux-tdep.c, alpha-mdebug-tdep.c, arch-utils.h, arm-tdep.h, ax-general.c, btrace.c, buildsym-legacy.c, buildsym.h, c-lang.c, cli/cli-decode.h, cli/cli-dump.c, cli/cli-script.h, cli/cli-style.h, coff-pe-read.h, compile/compile-c-support.c, compile/compile-cplus.h, compile/compile-loc2c.c, corefile.c, cp-valprint.c, cris-linux-tdep.c, ctf.c, d-lang.c, d-namespace.c, dcache.c, dicos-tdep.c, dictionary.c, disasm-selftests.c, dummy-frame.c, dummy-frame.h, dwarf2-frame-tailcall.c, dwarf2expr.c, expression.h, f-lang.c, frame-base.c, frame-unwind.c, frv-linux-tdep.c, gdbarch-selftests.c, gdbtypes.h, go-lang.c, hppa-nbsd-tdep.c, hppa-obsd-tdep.c, i386-dicos-tdep.c, i386-tdep.h, ia64-vms-tdep.c, interps.h, language.c, linux-record.c, location.h, m2-lang.c, m32r-linux-tdep.c, mem-break.c, memattr.c, mn10300-linux-tdep.c, nios2-linux-tdep.c, objfiles.h, opencl-lang.c, or1k-linux-tdep.c, p-lang.c, parser-defs.h, ppc-tdep.h, probe.h, python/py-record-btrace.c, record-btrace.c, record.h, regcache-dump.c, regcache.h, riscv-fbsd-tdep.c, riscv-linux-tdep.c, rust-exp.y, sh-linux-tdep.c, sh-nbsd-tdep.c, source-cache.c, sparc-nbsd-tdep.c, sparc-obsd-tdep.c, sparc-ravenscar-thread.c, sparc64-fbsd-tdep.c, std-regs.c, target-descriptions.h, target-float.c, tic6x-linux-tdep.c, tilegx-linux-tdep.c, top.c, tracefile.c, trad-frame.c, type-stack.h, ui-style.c, utils.c, utils.h, valarith.c, valprint.c, varobj.c, x86-tdep.c, xml-support.h, xtensa-linux-tdep.c, cli/cli-cmds.h: Update. * s390-linux-nat.c, procfs.c, inf-ptrace.c: Likewise.
2019-06-10 05:21:02 +08:00
struct objfile;
struct symbol;
Support lexical blocks and function bodies that occupy non-contiguous address ranges. * addrmap.c, addrmap.h: New files. * block.h (struct addrmap): New forward declaration. (struct blockvector): New member, 'map'. (BLOCKVECTOR_MAP): New accessor macro. * block.c: #include "addrmap.h" (blockvector_for_pc_sect): If the blockvector we've found has an address map, use it instead of searching the blocks. * buildsym.c: #include "addrmap.h" (pending_addrmap_obstack, pending_addrmap_interesting): New static variables. (really_free_pendings): If we have a pending addrmap, free it too. (record_block_range): New function. (make_blockvector): If we have an interesting pending addrmap, record it in the new blockvector. (start_symtab, buildsym_init): Assert that there is no pending addrmap now; we should have cleaned up any addrmaps we'd built previously. (end_symtab): If there is a pending addrmap left over that didn't get included in the blockvector, free it. * buildsym.h (struct addrmap): New forward declaration. (record_block_range): New prototype. * objfiles.c: #include "addrmap.h". (objfile_relocate): Relocate the blockvector's address map, if present. * dwarf2read.c (dwarf2_record_block_ranges): New function. (read_func_scope, read_lexical_block_scope): Call it. * Makefile.in (SFILES): Add addrmap.c. (addrmap_h): New header dependency variable. (COMMON_OBS): Add addrmap.o. (addrmap.o): New rule.l (block.o, objfiles.o, buildsym.o): Depend on $(addrmap_h). * block.c (blockvector_for_pc, blockvector_for_pc_sect): Return a pointer to the block, not its index in the blockvector. (block_for_pc_sect): Use the returned block, instead of looking it up ourselves. * block.h (blockvector_for_pc, blockvector_for_pc_sect): Update declarations. * breakpoint.c (resolve_sal_pc): Use returned block, instead of looking it up ourselves. * stack.c (print_frame_label_vars): Disable function, which depends on the block's index. * buildsym.c (finish_block): Return the block we've built. * buildsym.h (finish_block): Update prototype. * defs.h (CORE_ADDR_MAX): New constant.
2007-12-05 07:43:57 +08:00
struct addrmap;
Split struct symtab into two: struct symtab and compunit_symtab. Currently "symtabs" in gdb are stored as a single linked list of struct symtab that contains both symbol symtabs (the blockvectors) and file symtabs (the linetables). This has led to confusion, bugs, and performance issues. This patch is conceptually very simple: split struct symtab into two pieces: one part containing things common across the entire compilation unit, and one part containing things specific to each source file. Example. For the case of a program built out of these files: foo.c foo1.h foo2.h bar.c foo1.h bar.h Today we have a single list of struct symtabs: objfile -> foo.c -> foo1.h -> foo2.h -> bar.c -> foo1.h -> bar.h -> NULL where "->" means the "next" pointer in struct symtab. With this patch, that turns into: objfile -> foo.c(cu) -> bar.c(cu) -> NULL | | v v foo.c bar.c | | v v foo1.h foo1.h | | v v foo2.h bar.h | | v v NULL NULL where "foo.c(cu)" and "bar.c(cu)" are struct compunit_symtab objects, and the files foo.c, etc. are struct symtab objects. So now, for example, when we want to iterate over all blockvectors we can now just iterate over the compunit_symtab list. Plus a lot of the data that was either unused or replicated for each symtab in a compilation unit now lives in struct compunit_symtab. E.g., the objfile pointer, the producer string, etc. I thought of moving "language" out of struct symtab but there is logic to try to compute the language based on previously seen files, and I think that's best left as is for now. With my standard monster benchmark with -readnow (which I can't actually do, but based on my calculations), whereas today the list requires 77MB to store all the struct symtabs, it now only requires 37MB. A modest space savings given the gigabytes needed for all the debug info, etc. Still, it's nice. Plus, whereas today we create a copy of dirname for each source file symtab in a compilation unit, we now only create one for the compunit. So this patch is basically just a data structure reorg, I don't expect significant performance improvements from it. Notes: 1) A followup patch can do a similar split for struct partial_symtab. I have left that until after I get the changes I want in to better utilize .gdb_index (it may affect how we do partial syms). 2) Another followup patch *could* rename struct symtab. The term "symtab" is ambiguous and has been a source of confusion. In this patch I'm leaving it alone, calling it the "historical" name of "filetabs", which is what they are now: just the file-name + line-table. gdb/ChangeLog: Split struct symtab into two: struct symtab and compunit_symtab. * amd64-tdep.c (amd64_skip_xmm_prologue): Fetch producer from compunit. * block.c (blockvector_for_pc_sect): Change "struct symtab *" argument to "struct compunit_symtab *". All callers updated. (set_block_compunit_symtab): Renamed from set_block_symtab. Change "struct symtab *" argument to "struct compunit_symtab *". All callers updated. (get_block_compunit_symtab): Renamed from get_block_symtab. Change result to "struct compunit_symtab *". All callers updated. (find_iterator_compunit_symtab): Renamed from find_iterator_symtab. Change result to "struct compunit_symtab *". All callers updated. * block.h (struct global_block) <compunit_symtab>: Renamed from symtab. hange type to "struct compunit_symtab *". All uses updated. (struct block_iterator) <d.compunit_symtab>: Renamed from "d.symtab". Change type to "struct compunit_symtab *". All uses updated. * buildsym.c (struct buildsym_compunit): New struct. (subfiles, buildsym_compdir, buildsym_objfile, main_subfile): Delete. (buildsym_compunit): New static global. (finish_block_internal): Update to fetch objfile from buildsym_compunit. (make_blockvector): Delete objfile argument. (start_subfile): Rewrite to use buildsym_compunit. Don't initialize debugformat, producer. (start_buildsym_compunit): New function. (free_buildsym_compunit): Renamed from free_subfiles_list. All callers updated. (patch_subfile_names): Rewrite to use buildsym_compunit. (get_compunit_symtab): New function. (get_macro_table): Delete argument comp_dir. All callers updated. (start_symtab): Change result to "struct compunit_symtab *". All callers updated. Create the subfile of the main source file. (watch_main_source_file_lossage): Rewrite to use buildsym_compunit. (reset_symtab_globals): Update. (end_symtab_get_static_block): Update to use buildsym_compunit. (end_symtab_without_blockvector): Rewrite. (end_symtab_with_blockvector): Change result to "struct compunit_symtab *". All callers updated. Update to use buildsym_compunit. Don't set symtab->dirname, instead set it in the compunit. Explicitly make sure main symtab is first in its list. Set debugformat, producer, blockvector, block_line_section, and macrotable in the compunit. (end_symtab_from_static_block): Change result to "struct compunit_symtab *". All callers updated. (end_symtab, end_expandable_symtab): Ditto. (set_missing_symtab): Change symtab argument to "struct compunit_symtab *". All callers updated. (augment_type_symtab): Ditto. (record_debugformat): Update to use buildsym_compunit. (record_producer): Update to use buildsym_compunit. * buildsym.h (struct subfile) <dirname>: Delete. <producer, debugformat>: Delete. <buildsym_compunit>: New member. (get_compunit_symtab): Declare. * dwarf2read.c (struct type_unit_group) <compunit_symtab>: Renamed from primary_symtab. Change type to "struct compunit_symtab *". All uses updated. (dwarf2_start_symtab): Change result to "struct compunit_symtab *". All callers updated. (dwarf_decode_macros): Delete comp_dir argument. All callers updated. (struct dwarf2_per_cu_quick_data) <compunit_symtab>: Renamed from symtab. Change type to "struct compunit_symtab *". All uses updated. (dw2_instantiate_symtab): Change result to "struct compunit_symtab *". All callers updated. (dw2_find_last_source_symtab): Ditto. (dw2_lookup_symbol): Ditto. (recursively_find_pc_sect_compunit_symtab): Renamed from recursively_find_pc_sect_symtab. Change result to "struct compunit_symtab *". All callers updated. (dw2_find_pc_sect_compunit_symtab): Renamed from dw2_find_pc_sect_symtab. Change result to "struct compunit_symtab *". All callers updated. (get_compunit_symtab): Renamed from get_symtab. Change result to "struct compunit_symtab *". All callers updated. (recursively_compute_inclusions): Change type of immediate_parent argument to "struct compunit_symtab *". All callers updated. (compute_compunit_symtab_includes): Renamed from compute_symtab_includes. All callers updated. Rewrite to compute includes of compunit_symtabs and not symtabs. (process_full_comp_unit): Update to work with struct compunit_symtab. (process_full_type_unit): Ditto. (dwarf_decode_lines_1): Delete argument comp_dir. All callers updated. (dwarf_decode_lines): Remove special case handling of main subfile. (macro_start_file): Delete argument comp_dir. All callers updated. (dwarf_decode_macro_bytes): Ditto. * guile/scm-block.c (bkscm_print_block_syms_progress_smob): Update to use struct compunit_symtab. * i386-tdep.c (i386_skip_prologue): Fetch producer from compunit. * jit.c (finalize_symtab): Build compunit_symtab. * jv-lang.c (get_java_class_symtab): Change result to "struct compunit_symtab *". All callers updated. * macroscope.c (sal_macro_scope): Fetch macro table from compunit. * macrotab.c (struct macro_table) <compunit_symtab>: Renamed from comp_dir. Change type to "struct compunit_symtab *". All uses updated. (new_macro_table): Change comp_dir argument to cust, "struct compunit_symtab *". All callers updated. * maint.c (struct cmd_stats) <nr_compunit_symtabs>: Renamed from nr_primary_symtabs. All uses updated. (count_symtabs_and_blocks): Update to handle compunits. (report_command_stats): Update output, "primary symtabs" renamed to "compunits". * mdebugread.c (new_symtab): Change result to "struct compunit_symtab *". All callers updated. (parse_procedure): Change type of search_symtab argument to "struct compunit_symtab *". All callers updated. * objfiles.c (objfile_relocate1): Loop over blockvectors in a separate loop. * objfiles.h (struct objfile) <compunit_symtabs>: Renamed from symtabs. Change type to "struct compunit_symtab *". All uses updated. (ALL_OBJFILE_FILETABS): Renamed from ALL_OBJFILE_SYMTABS. All uses updated. (ALL_OBJFILE_COMPUNITS): Renamed from ALL_OBJFILE_PRIMARY_SYMTABS. All uses updated. (ALL_FILETABS): Renamed from ALL_SYMTABS. All uses updated. (ALL_COMPUNITS): Renamed from ALL_PRIMARY_SYMTABS. All uses updated. * psympriv.h (struct partial_symtab) <compunit_symtab>: Renamed from symtab. Change type to "struct compunit_symtab *". All uses updated. * psymtab.c (psymtab_to_symtab): Change result type to "struct compunit_symtab *". All callers updated. (find_pc_sect_compunit_symtab_from_partial): Renamed from find_pc_sect_symtab_from_partial. Change result type to "struct compunit_symtab *". All callers updated. (lookup_symbol_aux_psymtabs): Change result type to "struct compunit_symtab *". All callers updated. (find_last_source_symtab_from_partial): Ditto. * python/py-symtab.c (stpy_get_producer): Fetch producer from compunit. * source.c (forget_cached_source_info_for_objfile): Fetch debugformat and macro_table from compunit. * symfile-debug.c (debug_qf_find_last_source_symtab): Change result type to "struct compunit_symtab *". All callers updated. (debug_qf_lookup_symbol): Ditto. (debug_qf_find_pc_sect_compunit_symtab): Renamed from debug_qf_find_pc_sect_symtab, change result type to "struct compunit_symtab *". All callers updated. * symfile.c (allocate_symtab): Delete objfile argument. New argument cust. (allocate_compunit_symtab): New function. (add_compunit_symtab_to_objfile): New function. * symfile.h (struct quick_symbol_functions) <lookup_symbol>: Change result type to "struct compunit_symtab *". All uses updated. <find_pc_sect_compunit_symtab>: Renamed from find_pc_sect_symtab. Change result type to "struct compunit_symtab *". All uses updated. * symmisc.c (print_objfile_statistics): Compute blockvector count in separate loop. (dump_symtab_1): Update test for primary source symtab. (maintenance_info_symtabs): Update to handle compunit symtabs. (maintenance_check_symtabs): Ditto. * symtab.c (set_primary_symtab): Delete. (compunit_primary_filetab): New function. (compunit_language): New function. (iterate_over_some_symtabs): Change type of arguments "first", "after_last" to "struct compunit_symtab *". All callers updated. Update to loop over symtabs in each compunit. (error_in_psymtab_expansion): Rename symtab argument to cust, and change type to "struct compunit_symtab *". All callers updated. (find_pc_sect_compunit_symtab): Renamed from find_pc_sect_symtab. Change result type to "struct compunit_symtab *". All callers updated. (find_pc_compunit_symtab): Renamed from find_pc_symtab. Change result type to "struct compunit_symtab *". All callers updated. (find_pc_sect_line): Only loop over symtabs within selected compunit instead of all symtabs in the objfile. * symtab.h (struct symtab) <blockvector>: Moved to compunit_symtab. <compunit_symtab> New member. <block_line_section>: Moved to compunit_symtab. <locations_valid>: Ditto. <epilogue_unwind_valid>: Ditto. <macro_table>: Ditto. <dirname>: Ditto. <debugformat>: Ditto. <producer>: Ditto. <objfile>: Ditto. <call_site_htab>: Ditto. <includes>: Ditto. <user>: Ditto. <primary>: Delete (SYMTAB_COMPUNIT): New macro. (SYMTAB_BLOCKVECTOR): Update definition. (SYMTAB_OBJFILE): Update definition. (SYMTAB_DIRNAME): Update definition. (struct compunit_symtab): New type. Common members among all source symtabs within a compilation unit moved here. All uses updated. (COMPUNIT_OBJFILE): New macro. (COMPUNIT_FILETABS): New macro. (COMPUNIT_DEBUGFORMAT): New macro. (COMPUNIT_PRODUCER): New macro. (COMPUNIT_DIRNAME): New macro. (COMPUNIT_BLOCKVECTOR): New macro. (COMPUNIT_BLOCK_LINE_SECTION): New macro. (COMPUNIT_LOCATIONS_VALID): New macro. (COMPUNIT_EPILOGUE_UNWIND_VALID): New macro. (COMPUNIT_CALL_SITE_HTAB): New macro. (COMPUNIT_MACRO_TABLE): New macro. (ALL_COMPUNIT_FILETABS): New macro. (compunit_symtab_ptr): New typedef. (DEF_VEC_P (compunit_symtab_ptr)): New vector type. gdb/testsuite/ChangeLog: * gdb.base/maint.exp: Update expected output.
2014-11-20 23:42:48 +08:00
struct compunit_symtab;
Per-language symbol name hashing algorithm Currently, we have a mess of symbol name hashing/comparison routines. There's msymbol_hash for mangled names, and dict_hash and msymbol_hash_iw for demangled names. Then there's strcmp_iw, strcmp_iw_ordered and Ada's full_match/wild_match, which all have to agree with the hashing routines. That's why dict_hash is really about Ada names. From the inconsistency department, minimal symbol hashing doesn't go via dict_hash, so Ada's wild matching can't ever work with minimal symbols. This patch starts fixing this, by doing two things: #1 - adds a language vector method to let each language decide how to compute a symbol name hash. #2 - makes dictionaries know the language of the symbols they hold, and then use the dictionaries language to decide which hashing method to use. For now, this is just scaffolding, since all languages install the default method. The series will make C++ install its own hashing method later on, and will add per-language symbol name comparison routines too. This patch was originally based on a patch that Keith wrote for the libcc1/C++ WIP support. gdb/ChangeLog: 2017-11-08 Keith Seitz <keiths@redhat.com> Pedro Alves <palves@redhat.com> * ada-lang.c (ada_language_defn): Install default_search_name_hash. * buildsym.c (struct buildsym_compunit): <language>: New field. (finish_block_internal): Pass language when creating dictionaries. (start_buildsym_compunit, start_symtab): New language parameters. Use them. (restart_symtab): Pass down compilation unit's language. * buildsym.h (enum language): Forward declare. (start_symtab): New 'language' parameter. * c-lang.c (c_language_defn, cplus_language_defn) (asm_language_defn, minimal_language_defn): Install default_search_name_hash. * coffread.c (coff_start_symtab): Adjust. * d-lang.c (d_language_defn): Install default_search_name_hash. * dbxread.c (struct symloc): Add 'pst_language' field. (PST_LANGUAGE): Define. (start_psymtab, read_ofile_symtab): Use it. (process_one_symbol): New 'language' parameter. Pass it down. * dictionary.c (struct dictionary) <language>: New field. (DICT_LANGUAGE): Define. (dict_create_hashed, dict_create_hashed_expandable) (dict_create_linear, dict_create_linear_expandable): New parameter 'language'. Set the dictionary's language. (iter_match_first_hashed): Adjust to rename. (insert_symbol_hashed): Assert we don't see mismatching languages. Adjust to rename. (dict_hash): Rename to ... (default_search_name_hash): ... this and make extern. * dictionary.h (struct language_defn): Forward declare. (dict_create_hashed): New parameter 'language'. * dwarf2read.c (dwarf2_start_symtab): Pass down language. * f-lang.c (f_language_defn): Install default_search_name_hash. * go-lang.c (go_language_defn): Install default_search_name_hash. * jit.c (finalize_symtab): Pass compunit's language to dictionary creation. * language.c (unknown_language_defn, auto_language_defn): * language.h (language_defn::la_search_name_hash): New field. (default_search_name_hash): Declare. * m2-lang.c (m2_language_defn): Install default_search_name_hash. * mdebugread.c (new_block): New parameter 'language'. * mdebugread.c (parse_symbol): Pass symbol language to block allocation. (psymtab_to_symtab_1): Pass down language. (new_symtab): Pass compunit's language to block allocation. * objc-lang.c (objc_language_defn): Install default_search_name_hash. * opencl-lang.c (opencl_language_defn): * p-lang.c (pascal_language_defn): Install default_search_name_hash. * rust-lang.c (rust_language_defn): Install default_search_name_hash. * stabsread.h (enum language): Forward declare. (process_one_symbol): Add 'language' parameter. * symtab.c (search_name_hash): New function. * symtab.h (search_name_hash): Declare. * xcoffread.c (read_xcoff_symtab): Pass language to start_symtab.
2017-11-08 23:07:56 +08:00
enum language;
/* This module provides definitions used for creating and adding to
the symbol table. These routines are called from various symbol-
file-reading routines.
They originated in dbxread.c of gdb-4.2, and were split out to
make xcoffread.c more maintainable by sharing code. */
2003-02-19 David Carlton <carlton@math.stanford.edu> * Makefile.in (SFILES): Add block.c. (block_h): New. (COMMON_OBS): Add block.o. (block.o): New. (x86-64-tdep.o): Add $(block_h). (values.o, valops.o, tracepoint.o, symtab.o, symmisc.o, symfile.o) (stack.o, printcmd.o, p-exp.tab.o, parse.o, objfiles.o) (objc-exp.tab.o, objc-lang.o, nlmread.o, mips-tdep.o, mdebugread.o) (m2-exp.tab.o, linespec.o, jv-lang.o, jv-exp.tab.o, infcmd.o) (f-valprint.o, findvar.o, f-exp.tab.o, expprint.o, coffread.o) (c-exp.tab.o, buildsym.o, breakpoint.o, blockframe.o, ax-gdb.o) (alpha-tdep.o, ada-lang.o, ada-exp.tab.o, mi-cmd-stack.o): Ditto. * value.h: Add opaque declaration for struct block. * parser-defs.h, objc-lang.h, buildsym.h, breakpoint.h: Ditto. * ada-lang.h: Ditto. * x86-64-tdep.c: #include "block.h" * values.c, valops.c, tracepoint.c, symtab.c, symmisc.c: Ditto. * symfile.c, stack.c, printcmd.c, p-exp.y, parse.c: Ditto. * objfiles.c, objc-exp.y, objc-lang.c, nlmread.c: Ditto. * mips-tdep.c, mdebugread.c, m2-exp.y, linespec.c: Ditto. * jv-lang.c, jv-exp.y, infcmd.c, f-valprint.c: Ditto. * findvar.c, f-exp.y, expprint.c, coffread.c, c-exp.y: Ditto. * buildsym.c, breakpoint.c, blockframe.c, ax-gdb.c: Ditto. * alpha-tdep.c, ada-lang.c, ada-exp.y: Ditto. * blockframe.c (blockvector_for_pc_sect): Move to "block.c". (blockvector_for_pc, block_for_pc_sect, block_for_pc): Ditto. * symtab.c (block_function): Ditto. (contained_in): Ditto. * frame.h: Move block_for_pc and block_for_pc_sect declarations to block.h. Add opaque declaration for struct block. * symtab.h: Move block_function and contained_in declarations to block.h. Add opaque declarations for struct block, struct blockvector. (struct block): Move to block.h. (struct blockvector): Ditto. (BLOCK_START, BLOCK_END, BLOCK_FUNCTION, BLOCK_SUPERBLOCK) (BLOCK_GCC_COMPILED, BLOCK_HASHTABLE, BLOCK_NSYMS, BLOCK_SYM) (BLOCK_BUCKETS, BLOCK_BUCKET, BLOCK_HASHTABLE_SIZE) (ALL_BLOCK_SYMBOLS, BLOCK_SHOULD_SORT, BLOCKVECTOR_NBLOCKS) (BLOCKVECTOR_BLOCK, GLOBAL_BLOCK, STATIC_BLOCK, FIRST_LOCAL_BLOCK): Ditto. * block.c: New file. * block.h: New file. 2003-02-19 David Carlton <carlton@math.stanford.edu> * mi-cmd-stack.c: #include "block.h"
2003-02-20 08:01:07 +08:00
struct block;
struct pending_block;
2003-02-19 David Carlton <carlton@math.stanford.edu> * Makefile.in (SFILES): Add block.c. (block_h): New. (COMMON_OBS): Add block.o. (block.o): New. (x86-64-tdep.o): Add $(block_h). (values.o, valops.o, tracepoint.o, symtab.o, symmisc.o, symfile.o) (stack.o, printcmd.o, p-exp.tab.o, parse.o, objfiles.o) (objc-exp.tab.o, objc-lang.o, nlmread.o, mips-tdep.o, mdebugread.o) (m2-exp.tab.o, linespec.o, jv-lang.o, jv-exp.tab.o, infcmd.o) (f-valprint.o, findvar.o, f-exp.tab.o, expprint.o, coffread.o) (c-exp.tab.o, buildsym.o, breakpoint.o, blockframe.o, ax-gdb.o) (alpha-tdep.o, ada-lang.o, ada-exp.tab.o, mi-cmd-stack.o): Ditto. * value.h: Add opaque declaration for struct block. * parser-defs.h, objc-lang.h, buildsym.h, breakpoint.h: Ditto. * ada-lang.h: Ditto. * x86-64-tdep.c: #include "block.h" * values.c, valops.c, tracepoint.c, symtab.c, symmisc.c: Ditto. * symfile.c, stack.c, printcmd.c, p-exp.y, parse.c: Ditto. * objfiles.c, objc-exp.y, objc-lang.c, nlmread.c: Ditto. * mips-tdep.c, mdebugread.c, m2-exp.y, linespec.c: Ditto. * jv-lang.c, jv-exp.y, infcmd.c, f-valprint.c: Ditto. * findvar.c, f-exp.y, expprint.c, coffread.c, c-exp.y: Ditto. * buildsym.c, breakpoint.c, blockframe.c, ax-gdb.c: Ditto. * alpha-tdep.c, ada-lang.c, ada-exp.y: Ditto. * blockframe.c (blockvector_for_pc_sect): Move to "block.c". (blockvector_for_pc, block_for_pc_sect, block_for_pc): Ditto. * symtab.c (block_function): Ditto. (contained_in): Ditto. * frame.h: Move block_for_pc and block_for_pc_sect declarations to block.h. Add opaque declaration for struct block. * symtab.h: Move block_function and contained_in declarations to block.h. Add opaque declarations for struct block, struct blockvector. (struct block): Move to block.h. (struct blockvector): Ditto. (BLOCK_START, BLOCK_END, BLOCK_FUNCTION, BLOCK_SUPERBLOCK) (BLOCK_GCC_COMPILED, BLOCK_HASHTABLE, BLOCK_NSYMS, BLOCK_SYM) (BLOCK_BUCKETS, BLOCK_BUCKET, BLOCK_HASHTABLE_SIZE) (ALL_BLOCK_SYMBOLS, BLOCK_SHOULD_SORT, BLOCKVECTOR_NBLOCKS) (BLOCKVECTOR_BLOCK, GLOBAL_BLOCK, STATIC_BLOCK, FIRST_LOCAL_BLOCK): Ditto. * block.c: New file. * block.h: New file. 2003-02-19 David Carlton <carlton@math.stanford.edu> * mi-cmd-stack.c: #include "block.h"
2003-02-20 08:01:07 +08:00
DWARF: handle non-local references in nested functions GDB's current behavior when dealing with non-local references in the context of nested fuctions is approximative: - code using valops.c:value_of_variable read the first available stack frame that holds the corresponding variable (whereas there can be multiple candidates for this); - code directly relying on read_var_value will instead read non-local variables in frames where they are not even defined. This change adds the necessary context to symbol reads (to get the block they belong to) and to blocks (the static link property, if any) so that GDB can make the proper decisions when dealing with non-local varibale references. gdb/ChangeLog: * ada-lang.c (ada_read_var_value): Add a var_block argument and pass it to default_read_var_value. * block.c (block_static_link): New accessor. * block.h (block_static_link): Declare it. * buildsym.c (finish_block_internal): Add a static_link argument. If there is a static link, associate it to the new block. (finish_block): Add a static link argument and pass it to finish_block_internal. (end_symtab_get_static_block): Update calls to finish_block and to finish_block_internal. (end_symtab_with_blockvector): Update call to finish_block_internal. * buildsym.h: Forward-declare struct dynamic_prop. (struct context_stack): Add a static_link field. (finish_block): Add a static link argument. * c-exp.y: Remove an obsolete comment (evaluation of variables already start from the selected frame, and now they climb *up* the call stack) and propagate the block information to the produced expression. * d-exp.y: Likewise. * f-exp.y: Likewise. * go-exp.y: Likewise. * jv-exp.y: Likewise. * m2-exp.y: Likewise. * p-exp.y: Likewise. * coffread.c (coff_symtab_read): Update calls to finish_block. * dbxread.c (process_one_symbol): Likewise. * xcoffread.c (read_xcoff_symtab): Likewise. * compile/compile-c-symbols.c (convert_one_symbol): Promote the "sym" parameter to struct block_symbol, update its uses and pass its block to calls to read_var_value. (convert_symbol_sym): Update the calls to convert_one_symbol. * compile/compile-loc2c.c (do_compile_dwarf_expr_to_c): Update call to read_var_value. * dwarf2loc.c (block_op_get_frame_base): New. (dwarf2_block_frame_base_locexpr_funcs): Implement the get_frame_base method. (dwarf2_block_frame_base_loclist_funcs): Likewise. (dwarf2locexpr_baton_eval): Add a frame argument and use it instead of the selected frame in order to evaluate the expression. (dwarf2_evaluate_property): Add a frame argument. Update call to dwarf2_locexpr_baton_eval to provide a frame in available and to handle the absence of address stack. * dwarf2loc.h (dwarf2_evaluate_property): Add a frame argument. * dwarf2read.c (attr_to_dynamic_prop): Add a forward declaration. (read_func_scope): Record any available static link description. Update call to finish_block. (read_lexical_block_scope): Update call to finish_block. * findvar.c (follow_static_link): New. (get_hosting_frame): New. (default_read_var_value): Add a var_block argument. Use get_hosting_frame to handle non-local references. (read_var_value): Add a var_block argument and pass it to the LA_READ_VAR_VALUE method. * gdbtypes.c (resolve_dynamic_range): Update calls to dwarf2_evaluate_property. (resolve_dynamic_type_internal): Likewise. * guile/scm-frame.c (gdbscm_frame_read_var): Update call to read_var_value, passing it the block coming from symbol lookup. * guile/scm-symbol.c (gdbscm_symbol_value): Update call to read_var_value (TODO). * infcmd.c (finish_command_continuation): Update call to read_var_value, passing it the block coming from symbol lookup. * infrun.c (insert_exception_resume_breakpoint): Likewise. * language.h (struct language_defn): Add a var_block argument to the LA_READ_VAR_VALUE method. * objfiles.c (struct static_link_htab_entry): New. (static_link_htab_entry_hash): New. (static_link_htab_entry_eq): New. (objfile_register_static_link): New. (objfile_lookup_static_link): New. (free_objfile): Free the STATIC_LINKS hashed map if needed. * objfiles.h: Include hashtab.h. (struct objfile): Add a static_links field. (objfile_register_static_link): New. (objfile_lookup_static_link): New. * printcmd.c (print_variable_and_value): Update call to read_var_value. * python/py-finishbreakpoint.c (bpfinishpy_init): Likewise. * python/py-frame.c (frapy_read_var): Update call to read_var_value, passing it the block coming from symbol lookup. * python/py-framefilter.c (extract_sym): Add a sym_block parameter and set the pointed value to NULL (TODO). (enumerate_args): Update call to extract_sym. (enumerate_locals): Update calls to extract_sym and to read_var_value. * python/py-symbol.c (sympy_value): Update call to read_var_value (TODO). * stack.c (read_frame_local): Update call to read_var_value. (read_frame_arg): Likewise. (return_command): Likewise. * symtab.h (struct symbol_block_ops): Add a get_frame_base method. (struct symbol): Add a block field. (SYMBOL_BLOCK): New accessor. * valops.c (value_of_variable): Remove frame/block handling and pass the block argument to read_var_value, which does this job now. (value_struct_elt_for_reference): Update calls to read_var_value. (value_of_this): Pass the block found to read_var_value. * value.h (read_var_value): Add a var_block argument. (default_read_var_value): Likewise. gdb/testsuite/ChangeLog: * gdb.base/nested-subp1.exp: New file. * gdb.base/nested-subp1.c: New file. * gdb.base/nested-subp2.exp: New file. * gdb.base/nested-subp2.c: New file. * gdb.base/nested-subp3.exp: New file. * gdb.base/nested-subp3.c: New file.
2015-02-06 00:00:06 +08:00
struct dynamic_prop;
/* The list of sub-source-files within the current individual
compilation. Each file gets its own symtab with its own linetable
and associated info, but they all share one blockvector. */
struct subfile
Split struct symtab into two: struct symtab and compunit_symtab. Currently "symtabs" in gdb are stored as a single linked list of struct symtab that contains both symbol symtabs (the blockvectors) and file symtabs (the linetables). This has led to confusion, bugs, and performance issues. This patch is conceptually very simple: split struct symtab into two pieces: one part containing things common across the entire compilation unit, and one part containing things specific to each source file. Example. For the case of a program built out of these files: foo.c foo1.h foo2.h bar.c foo1.h bar.h Today we have a single list of struct symtabs: objfile -> foo.c -> foo1.h -> foo2.h -> bar.c -> foo1.h -> bar.h -> NULL where "->" means the "next" pointer in struct symtab. With this patch, that turns into: objfile -> foo.c(cu) -> bar.c(cu) -> NULL | | v v foo.c bar.c | | v v foo1.h foo1.h | | v v foo2.h bar.h | | v v NULL NULL where "foo.c(cu)" and "bar.c(cu)" are struct compunit_symtab objects, and the files foo.c, etc. are struct symtab objects. So now, for example, when we want to iterate over all blockvectors we can now just iterate over the compunit_symtab list. Plus a lot of the data that was either unused or replicated for each symtab in a compilation unit now lives in struct compunit_symtab. E.g., the objfile pointer, the producer string, etc. I thought of moving "language" out of struct symtab but there is logic to try to compute the language based on previously seen files, and I think that's best left as is for now. With my standard monster benchmark with -readnow (which I can't actually do, but based on my calculations), whereas today the list requires 77MB to store all the struct symtabs, it now only requires 37MB. A modest space savings given the gigabytes needed for all the debug info, etc. Still, it's nice. Plus, whereas today we create a copy of dirname for each source file symtab in a compilation unit, we now only create one for the compunit. So this patch is basically just a data structure reorg, I don't expect significant performance improvements from it. Notes: 1) A followup patch can do a similar split for struct partial_symtab. I have left that until after I get the changes I want in to better utilize .gdb_index (it may affect how we do partial syms). 2) Another followup patch *could* rename struct symtab. The term "symtab" is ambiguous and has been a source of confusion. In this patch I'm leaving it alone, calling it the "historical" name of "filetabs", which is what they are now: just the file-name + line-table. gdb/ChangeLog: Split struct symtab into two: struct symtab and compunit_symtab. * amd64-tdep.c (amd64_skip_xmm_prologue): Fetch producer from compunit. * block.c (blockvector_for_pc_sect): Change "struct symtab *" argument to "struct compunit_symtab *". All callers updated. (set_block_compunit_symtab): Renamed from set_block_symtab. Change "struct symtab *" argument to "struct compunit_symtab *". All callers updated. (get_block_compunit_symtab): Renamed from get_block_symtab. Change result to "struct compunit_symtab *". All callers updated. (find_iterator_compunit_symtab): Renamed from find_iterator_symtab. Change result to "struct compunit_symtab *". All callers updated. * block.h (struct global_block) <compunit_symtab>: Renamed from symtab. hange type to "struct compunit_symtab *". All uses updated. (struct block_iterator) <d.compunit_symtab>: Renamed from "d.symtab". Change type to "struct compunit_symtab *". All uses updated. * buildsym.c (struct buildsym_compunit): New struct. (subfiles, buildsym_compdir, buildsym_objfile, main_subfile): Delete. (buildsym_compunit): New static global. (finish_block_internal): Update to fetch objfile from buildsym_compunit. (make_blockvector): Delete objfile argument. (start_subfile): Rewrite to use buildsym_compunit. Don't initialize debugformat, producer. (start_buildsym_compunit): New function. (free_buildsym_compunit): Renamed from free_subfiles_list. All callers updated. (patch_subfile_names): Rewrite to use buildsym_compunit. (get_compunit_symtab): New function. (get_macro_table): Delete argument comp_dir. All callers updated. (start_symtab): Change result to "struct compunit_symtab *". All callers updated. Create the subfile of the main source file. (watch_main_source_file_lossage): Rewrite to use buildsym_compunit. (reset_symtab_globals): Update. (end_symtab_get_static_block): Update to use buildsym_compunit. (end_symtab_without_blockvector): Rewrite. (end_symtab_with_blockvector): Change result to "struct compunit_symtab *". All callers updated. Update to use buildsym_compunit. Don't set symtab->dirname, instead set it in the compunit. Explicitly make sure main symtab is first in its list. Set debugformat, producer, blockvector, block_line_section, and macrotable in the compunit. (end_symtab_from_static_block): Change result to "struct compunit_symtab *". All callers updated. (end_symtab, end_expandable_symtab): Ditto. (set_missing_symtab): Change symtab argument to "struct compunit_symtab *". All callers updated. (augment_type_symtab): Ditto. (record_debugformat): Update to use buildsym_compunit. (record_producer): Update to use buildsym_compunit. * buildsym.h (struct subfile) <dirname>: Delete. <producer, debugformat>: Delete. <buildsym_compunit>: New member. (get_compunit_symtab): Declare. * dwarf2read.c (struct type_unit_group) <compunit_symtab>: Renamed from primary_symtab. Change type to "struct compunit_symtab *". All uses updated. (dwarf2_start_symtab): Change result to "struct compunit_symtab *". All callers updated. (dwarf_decode_macros): Delete comp_dir argument. All callers updated. (struct dwarf2_per_cu_quick_data) <compunit_symtab>: Renamed from symtab. Change type to "struct compunit_symtab *". All uses updated. (dw2_instantiate_symtab): Change result to "struct compunit_symtab *". All callers updated. (dw2_find_last_source_symtab): Ditto. (dw2_lookup_symbol): Ditto. (recursively_find_pc_sect_compunit_symtab): Renamed from recursively_find_pc_sect_symtab. Change result to "struct compunit_symtab *". All callers updated. (dw2_find_pc_sect_compunit_symtab): Renamed from dw2_find_pc_sect_symtab. Change result to "struct compunit_symtab *". All callers updated. (get_compunit_symtab): Renamed from get_symtab. Change result to "struct compunit_symtab *". All callers updated. (recursively_compute_inclusions): Change type of immediate_parent argument to "struct compunit_symtab *". All callers updated. (compute_compunit_symtab_includes): Renamed from compute_symtab_includes. All callers updated. Rewrite to compute includes of compunit_symtabs and not symtabs. (process_full_comp_unit): Update to work with struct compunit_symtab. (process_full_type_unit): Ditto. (dwarf_decode_lines_1): Delete argument comp_dir. All callers updated. (dwarf_decode_lines): Remove special case handling of main subfile. (macro_start_file): Delete argument comp_dir. All callers updated. (dwarf_decode_macro_bytes): Ditto. * guile/scm-block.c (bkscm_print_block_syms_progress_smob): Update to use struct compunit_symtab. * i386-tdep.c (i386_skip_prologue): Fetch producer from compunit. * jit.c (finalize_symtab): Build compunit_symtab. * jv-lang.c (get_java_class_symtab): Change result to "struct compunit_symtab *". All callers updated. * macroscope.c (sal_macro_scope): Fetch macro table from compunit. * macrotab.c (struct macro_table) <compunit_symtab>: Renamed from comp_dir. Change type to "struct compunit_symtab *". All uses updated. (new_macro_table): Change comp_dir argument to cust, "struct compunit_symtab *". All callers updated. * maint.c (struct cmd_stats) <nr_compunit_symtabs>: Renamed from nr_primary_symtabs. All uses updated. (count_symtabs_and_blocks): Update to handle compunits. (report_command_stats): Update output, "primary symtabs" renamed to "compunits". * mdebugread.c (new_symtab): Change result to "struct compunit_symtab *". All callers updated. (parse_procedure): Change type of search_symtab argument to "struct compunit_symtab *". All callers updated. * objfiles.c (objfile_relocate1): Loop over blockvectors in a separate loop. * objfiles.h (struct objfile) <compunit_symtabs>: Renamed from symtabs. Change type to "struct compunit_symtab *". All uses updated. (ALL_OBJFILE_FILETABS): Renamed from ALL_OBJFILE_SYMTABS. All uses updated. (ALL_OBJFILE_COMPUNITS): Renamed from ALL_OBJFILE_PRIMARY_SYMTABS. All uses updated. (ALL_FILETABS): Renamed from ALL_SYMTABS. All uses updated. (ALL_COMPUNITS): Renamed from ALL_PRIMARY_SYMTABS. All uses updated. * psympriv.h (struct partial_symtab) <compunit_symtab>: Renamed from symtab. Change type to "struct compunit_symtab *". All uses updated. * psymtab.c (psymtab_to_symtab): Change result type to "struct compunit_symtab *". All callers updated. (find_pc_sect_compunit_symtab_from_partial): Renamed from find_pc_sect_symtab_from_partial. Change result type to "struct compunit_symtab *". All callers updated. (lookup_symbol_aux_psymtabs): Change result type to "struct compunit_symtab *". All callers updated. (find_last_source_symtab_from_partial): Ditto. * python/py-symtab.c (stpy_get_producer): Fetch producer from compunit. * source.c (forget_cached_source_info_for_objfile): Fetch debugformat and macro_table from compunit. * symfile-debug.c (debug_qf_find_last_source_symtab): Change result type to "struct compunit_symtab *". All callers updated. (debug_qf_lookup_symbol): Ditto. (debug_qf_find_pc_sect_compunit_symtab): Renamed from debug_qf_find_pc_sect_symtab, change result type to "struct compunit_symtab *". All callers updated. * symfile.c (allocate_symtab): Delete objfile argument. New argument cust. (allocate_compunit_symtab): New function. (add_compunit_symtab_to_objfile): New function. * symfile.h (struct quick_symbol_functions) <lookup_symbol>: Change result type to "struct compunit_symtab *". All uses updated. <find_pc_sect_compunit_symtab>: Renamed from find_pc_sect_symtab. Change result type to "struct compunit_symtab *". All uses updated. * symmisc.c (print_objfile_statistics): Compute blockvector count in separate loop. (dump_symtab_1): Update test for primary source symtab. (maintenance_info_symtabs): Update to handle compunit symtabs. (maintenance_check_symtabs): Ditto. * symtab.c (set_primary_symtab): Delete. (compunit_primary_filetab): New function. (compunit_language): New function. (iterate_over_some_symtabs): Change type of arguments "first", "after_last" to "struct compunit_symtab *". All callers updated. Update to loop over symtabs in each compunit. (error_in_psymtab_expansion): Rename symtab argument to cust, and change type to "struct compunit_symtab *". All callers updated. (find_pc_sect_compunit_symtab): Renamed from find_pc_sect_symtab. Change result type to "struct compunit_symtab *". All callers updated. (find_pc_compunit_symtab): Renamed from find_pc_symtab. Change result type to "struct compunit_symtab *". All callers updated. (find_pc_sect_line): Only loop over symtabs within selected compunit instead of all symtabs in the objfile. * symtab.h (struct symtab) <blockvector>: Moved to compunit_symtab. <compunit_symtab> New member. <block_line_section>: Moved to compunit_symtab. <locations_valid>: Ditto. <epilogue_unwind_valid>: Ditto. <macro_table>: Ditto. <dirname>: Ditto. <debugformat>: Ditto. <producer>: Ditto. <objfile>: Ditto. <call_site_htab>: Ditto. <includes>: Ditto. <user>: Ditto. <primary>: Delete (SYMTAB_COMPUNIT): New macro. (SYMTAB_BLOCKVECTOR): Update definition. (SYMTAB_OBJFILE): Update definition. (SYMTAB_DIRNAME): Update definition. (struct compunit_symtab): New type. Common members among all source symtabs within a compilation unit moved here. All uses updated. (COMPUNIT_OBJFILE): New macro. (COMPUNIT_FILETABS): New macro. (COMPUNIT_DEBUGFORMAT): New macro. (COMPUNIT_PRODUCER): New macro. (COMPUNIT_DIRNAME): New macro. (COMPUNIT_BLOCKVECTOR): New macro. (COMPUNIT_BLOCK_LINE_SECTION): New macro. (COMPUNIT_LOCATIONS_VALID): New macro. (COMPUNIT_EPILOGUE_UNWIND_VALID): New macro. (COMPUNIT_CALL_SITE_HTAB): New macro. (COMPUNIT_MACRO_TABLE): New macro. (ALL_COMPUNIT_FILETABS): New macro. (compunit_symtab_ptr): New typedef. (DEF_VEC_P (compunit_symtab_ptr)): New vector type. gdb/testsuite/ChangeLog: * gdb.base/maint.exp: Update expected output.
2014-11-20 23:42:48 +08:00
{
subfile () = default;
/* There's nothing wrong with copying a subfile, but we don't need to, so use
this to avoid copying one by mistake. */
DISABLE_COPY_AND_ASSIGN (subfile);
struct subfile *next = nullptr;
std::string name;
gdb: add "id" fields to identify symtabs and subfiles Printing macros defined in the main source file doesn't work reliably using various toolchains, especially when DWARF 5 is used. For example, using the binaries produced by either of these commands: $ gcc --version gcc (GCC) 11.2.0 $ ld --version GNU ld (GNU Binutils) 2.38 $ gcc test.c -g3 -gdwarf-5 $ clang --version clang version 13.0.1 $ clang test.c -gdwarf-5 -fdebug-macro I get: $ ./gdb -nx -q --data-directory=data-directory a.out (gdb) start Temporary breakpoint 1 at 0x111d: file test.c, line 6. Starting program: /home/simark/build/binutils-gdb-one-target/gdb/a.out Temporary breakpoint 1, main () at test.c:6 6 return ZERO; (gdb) p ZERO No symbol "ZERO" in current context. When starting to investigate this (taking the gcc-compiled binary as an example), we see that GDB fails to look up the appropriate macro scope when evaluating the expression. While stopped in macro_lookup_inclusion: (top-gdb) p name $1 = 0x62100011a980 "test.c" (top-gdb) p source.filename $2 = 0x62100011a9a0 "/home/simark/build/binutils-gdb-one-target/gdb/test.c" `source` is the macro_source_file that we would expect GDB to find. `name` comes from the symtab::filename field of the symtab we are stopped in. GDB doesn't find the appropriate macro_source_file because the name of the macro_source_file doesn't match exactly the name of the symtab. The name of the main symtab comes from the compilation unit's DW_AT_name, passed to the buildsym_compunit's constructor: https://gitlab.com/gnutools/binutils-gdb/-/blob/4815d6125ec580cc02a1094d61b8c9d1cc83c0a1/gdb/dwarf2/read.c#L10627-10630 The contents of DW_AT_name, in this case, is "test.c". It is typically (what I witnessed all compilers do) the same string that was passed to the compiler on the command-line. The name of the macro_source_file comes from the line number program header's file table, from the call to the line_header::file_file_name method: https://gitlab.com/gnutools/binutils-gdb/-/blob/4815d6125ec580cc02a1094d61b8c9d1cc83c0a1/gdb/dwarf2/macro.c#L54-65 line_header::file_file_name prepends the directory path that the file entry refers to, in the file table (if the file name is not already absolute). In this case, the file name is "test.c", appended to the directory "/home/simark/build/binutils-gdb-one-target/gdb". Because the symtab's name is not created the same way as the macro_source_file's name is created, we get this mismatch. GDB fails to find the appropriate macro scope for the symtab, and we can't print macros when stopped in that symtab. To make this work, we must ensure that paths produced in these two ways end up identical. This can be tricky because of the different ways a path can be passed to the compiler by the user. Another thing to consider is that while the main symtab's name (or subfile, before it becomes a symtab) is created using DW_AT_name, the main symtab is also referred to using its entry in the line table header's file table, when processing the line table. We must therefore ensure that the same name is produced in both cases, so that a call to "start_subfile" for the main subfile will correctly find the already-created subfile, created by buildsym_compunit's constructor. If we fail to do that, things still often work, because of a fallback: the watch_main_source_file_lossage method. This method determines that if the main subfile has no symbols but there exists another subfile with the same basename (e.g. "test.c") that does have symbols, it's probably because there was some filename mismatch. So it replaces the main subfile with that other subfile. I think that heuristic is useful as a last effort to work around any bug or bad debug info, but I don't think we should design things such as to rely on it. It's a heuristic, it can get things wrong. So in my search for a fix, it is important that given some good debug info, we don't end up relying on that for things to work. A first attempt at fixing this was to try to prepend the compilation directory here or not prepend it there. In practice, because of all the possible combinations of debug info the compilers produce, it was not possible to get something that would produce reliable, consistent paths. Another attempt at fixing this was to make both macro_source_file objects and symtab objects use the most complete form of path possible. That means to prepend directories at least until we get an absolute path. In theory, we should end up with the same path in all cases. This generally worked, but because it changed the symtab names, it resulted in user-visible changes (for example, paths to source files in Breakpoint hit messages becoming always absolute). I didn't find this very good, first because there is a "set filename-display" setting that lets the user control how they want the paths to be displayed, and that would suddenly make this setting completely ineffective (although even today, it is a bit dependent on the debug info). Second, it would require a good amount of testsuite tweaks to make tests accept these suddenly absolute paths. This new patch is a slight variation of that: it adds a new field called "filename_for_id" in struct symtab and struct subfile, next to the existing filename field. The goal is to separate the internal ids used for finding objects from the names used for presentation. This field is used for identifying subfiles, symtabs and macro_source_files internally. For DWARF symtabs, this new field is meant to contain the "most complete possible" path, as discussed above. So for a given file, it must always be in the same form, everywhere. The existing symtab::filename field remains the one used for printing to the user, so there shouldn't be any change in how paths are printed. Changes in the core symtab files are: - Add "name_for_id" and "filename_for_id" fields to "struct subfile" and "struct symtab", next to existing "name" and "filename" fields. - Make buildsym_compunit::buildsym_compunit and buildsym_compunit::start_subfile accept a "name_for_id" parameter next to the existing "name" ones. - Make buildsym_compunit::start_subfile use "name_for_id" for looking up existing subfiles. This is the key thing for making calls to start_subfile for the main source file look up the existing subfile successfully, and avoid relying on watch_main_source_file_lossage. - Make sal_macro_scope pass "filename_for_id", rather than "filename", to macro_lookup_inclusion. This is the key thing to making the lookup work and macro printing work. Changes in the DWARF files are: - Make line_header::file_file_name return the "most complete possible" name. The only pre-existing user of this method is the macro code, to give the macro_source_file objects their name. And we now want them to have this "most complete possible" name, which will match the corresponding symtab's "filename_for_id". - Make dwarf2_cu::start_compunit_symtab pass the "most complete possible" name for the main symtab's "filename_for_id". In this context, where the info comes from the compilation unit's DW_AT_name / DW_AT_comp_dir, it means prepending DW_AT_comp_dir to DW_AT_name if DW_AT_name is not already absolute. - Change dwarf2_start_subfile to build a name_for_id for the subfile being started. The simplest way is to re-use line_header::file_file_name, since the callers always have a file_entry handy. This ensures that it will get the exact same path representation as the macro code does, for the same file (since it also uses line_header::file_file_name). - Update calls to allocate_symtab to pass the "name_for_id" from the subfile. Tests exercising all this are added by the following patch. Of all the cases I tried, the only one I found that ends up relying on watch_main_source_file_lossage is the following one: $ clang --version clang version 13.0.1 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin $ clang ./test.c -g3 -O0 -gdwarf-4 $ ./gdb -nx --data-directory=data-directory -q -readnow -iex "set debug symtab-create 1" a.out ... [symtab-create] start_subfile: name = test.c, name_for_id = /home/simark/build/binutils-gdb-one-target/gdb/test.c [symtab-create] start_subfile: name = ./test.c, name_for_id = /home/simark/build/binutils-gdb-one-target/gdb/./test.c [symtab-create] start_subfile: name = ./test.c, name_for_id = /home/simark/build/binutils-gdb-one-target/gdb/./test.c [symtab-create] start_subfile: found existing symtab with name_for_id /home/simark/build/binutils-gdb-one-target/gdb/./test.c (/home/simark/build/binutils-gdb-one-target/gdb/./test.c) [symtab-create] watch_main_source_file_lossage: using subfile ./test.c as the main subfile As we can see, there are two forms used for "test.c", one with a "." and one without. This comes from the fact that the compilation unit DIE contains: DW_AT_name ("test.c") DW_AT_comp_dir ("/home/simark/build/binutils-gdb-one-target/gdb") without a ".", and the line table for that file contains: include_directories[ 1] = "." file_names[ 1]: name: "test.c" dir_index: 1 When assembling the filename from that entry, we get a ".". It is a bit unexpected that the main filename resulting from the line table header does not match exactly the name in the compilation unit. For instance, gcc uses "./test.c" for the DW_AT_name, which gives identical paths in the compilation unit and in the line table header. Similarly, with DWARF 5: $ clang ./test.c -g3 -O0 -gdwarf-5 clang create two entries that refer to the same file but are of in a different form. include_directories[ 0] = "/home/simark/build/binutils-gdb-one-target/gdb" include_directories[ 1] = "." file_names[ 0]: name: "test.c" dir_index: 0 file_names[ 1]: name: "test.c" dir_index: 1 The first file name produces a path without a "." while the second does. This is not caught by watch_main_source_file_lossage, because of dwarf_decode_lines that creates a symtab for each file entry in the line table. It therefore appears as "non-empty" to watch_main_source_file_lossage. This results in two symtabs: (gdb) maintenance info symtabs { objfile /home/simark/build/binutils-gdb-one-target/gdb/a.out ((struct objfile *) 0x613000005d00) { ((struct compunit_symtab *) 0x62100011aca0) debugformat DWARF 5 producer clang version 13.0.1 name test.c dirname /home/simark/build/binutils-gdb-one-target/gdb blockvector ((struct blockvector *) 0x621000129ec0) user ((struct compunit_symtab *) (null)) { symtab test.c ((struct symtab *) 0x62100011ad20) fullname (null) linetable ((struct linetable *) 0x0) } { symtab ./test.c ((struct symtab *) 0x62100011ad60) fullname (null) linetable ((struct linetable *) 0x621000129ef0) } } } I am not sure what is the consequence of this, but this is also what happens before my patch, so I think its acceptable to leave it as-is. To handle these two cases nicely, I think we will need a function that removes the unnecessary "." from path names, something that can be done later. Finally, I made a change in find_file_and_directory is necessary to avoid breaking test gdb.dwarf2/dw2-compdir-oldgcc.exp: info source gcc42 Without that change, we would get: (gdb) info source Current source file is /dir/d/dw2-compdir-oldgcc42.S Compilation directory is /dir/d whereas the expected result is: (gdb) info source Current source file is dw2-compdir-oldgcc42.S Compilation directory is /dir/d This test was added here: https://sourceware.org/pipermail/gdb-patches/2012-November/098144.html Long story short, GCC <= 4.2 apparently had a bug where it would generate a DW_AT_name with a full path ("/dir/d/dw2-compdir-oldgcc42.S") and no DW_AT_comp_dir. The line table has one entry with filename "dw2-compdir-oldgcc42.S", which refers to directory 0. Directory 0 normally refers to the compilation unit's comp dir, but it is non-existent in this case. This caused some symtab lookup problems, and to work around them, some workaround was added, which today reads as: if (res.get_comp_dir () == nullptr && producer_is_gcc_lt_4_3 (cu) && res.get_name () != nullptr && IS_ABSOLUTE_PATH (res.get_name ())) res.set_comp_dir (ldirname (res.get_name ())); Source: https://gitlab.com/gnutools/binutils-gdb/-/blob/6577f365ebdee7dda71cb996efa29d3714cbccd0/gdb/dwarf2/read.c#L9428-9432 It extracts an artificial DW_AT_comp_dir from DW_AT_name, if there is no DW_AT_comp_dir and DW_AT_name is absolute. Prior to my patch, a subfile would get created with filename "/dir/d/dw2-compdir-oldgcc42.S", from DW_AT_name, and another would get created with filename "dw2-compdir-oldgcc42.S" from the line table's file table. Then watch_main_source_file_lossage would kick in and merge them, keeping only the "dw2-compdir-oldgcc42.S" one: [symtab-create] start_subfile: name = /dir/d/dw2-compdir-oldgcc42.S [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S [symtab-create] start_subfile: found existing symtab with name dw2-compdir-oldgcc42.S (dw2-compdir-oldgcc42.S) [symtab-create] watch_main_source_file_lossage: using subfile dw2-compdir-oldgcc42.S as the main subfile And so "info source" would show "dw2-compdir-oldgcc42.S" as the filename. With my patch applied, but without the change in find_file_and_directory, both DW_AT_name and the line table would try to start a subfile with the same filename_for_id, and there was no need for watch_main_source_file_lossage - which is what we want: [symtab-create] start_subfile: name = /dir/d/dw2-compdir-oldgcc42.S, name_for_id = /dir/d/dw2-compdir-oldgcc42.S [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S, name_for_id = /dir/d/dw2-compdir-oldgcc42.S [symtab-create] start_subfile: found existing symtab with name_for_id /dir/d/dw2-compdir-oldgcc42.S (/dir/d/dw2-compdir-oldgcc42.S) [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S, name_for_id = /dir/d/dw2-compdir-oldgcc42.S [symtab-create] start_subfile: found existing symtab with name_for_id /dir/d/dw2-compdir-oldgcc42.S (/dir/d/dw2-compdir-oldgcc42.S) But since the one with name == "/dir/d/dw2-compdir-oldgcc42.S", coming from DW_AT_name, gets created first, it wins, and the symtab ends up with "/dir/d/dw2-compdir-oldgcc42.S" as the name, "info source" shows "/dir/d/dw2-compdir-oldgcc42.S" and the test breaks. This is not wrong per-se, after all DW_AT_name is "/dir/d/dw2-compdir-oldgcc42.S", so it wouldn't be wrong to report the current source file as "/dir/d/dw2-compdir-oldgcc42.S". If you compile a file passing "/an/absolute/path.c", DW_AT_name typically contains (at least with GCC) "/an/absolute/path.c" and GDB tells you that the source file is "/an/absolute/path.c". But we can also keep the existing behavior fairly easily with a little change in find_file_and_directory. When extracting an artificial DW_AT_comp_dir from DW_AT_name, we now modify the name to just keep the file part. The result is coherent with what compilers do when you compile a file by just passing its filename ("gcc path.c -g"): DW_AT_name ("path.c") DW_AT_comp_dir ("/home/simark/build/binutils-gdb-one-target/gdb") With this change, filename_for_id is still the full name, "/dir/d/dw2-compdir-oldgcc42.S", but the filename of the subfile / symtab (what ends up shown by "info source") is just "dw2-compdir-oldgcc42.S", and that makes the test happy. Change-Id: I8b5cc4bb3052afdb172ee815c051187290566307
2022-07-29 00:34:47 +08:00
/* This field is analoguous in function to symtab::filename_for_id.
It is used to look up existing subfiles in calls to start_subfile. */
std::string name_for_id;
gdb: change subfile::line_vector to an std::vector Change this field to an std::vector to facilitate memory management. Since the linetable_entry array is copied into the symtab resulting from the subfile, it is possible to change it without changing how symtab stores the linetable entries (which would be a much larger change). There is a small change in buildsym_compunit::record_line to avoid accessing a now invalid linetable_entry. Before this patch, we keep a pointer to the last linetable entry, pop it from the vector, and then read last->line. It works with the manually-maintained array, but since we now use std::vector::pop_back, I am afraid that it could be flagged as an invalid access by the various static / dynamic analysis tools to access the linetable_entry object after popping it from the vector. Instead, record just the line number in an optional and use it. There are substantial changes in xcoffread.c that simplify the code, but I can't test them. I was hesitant to do this change because of that, but I decided to send it anyway. I don't think that an almost dead platform should hold back improving the code in the common parts of GDB. The changes in xcoffread.c are: - Make arrange_linetable "arrange" the linetable passed as a parameter, instead of returning possibly a new one, possibly the same one. - In the "Process main file's line numbers.", I'm not too sure what happens. We get the lintable from "main_subfile", "arrange" it, but then assign the result to the current subfile, obtained with get_current_subfile. I assume that the current subfile is also the main one, so now I just call arrange_linetable on the main subfile's line table. - Remove that weird "Useless if!!!" FIXME comment. It's been there forever, but the "if" is still there, so I guess the "if" can stay there. Change-Id: I11799006fd85189e8cf5bd3a168f8f38c2c27a80
2022-04-07 20:55:16 +08:00
std::vector<linetable_entry> line_vector_entries;
enum language language = language_unknown;
struct symtab *symtab = nullptr;
Split struct symtab into two: struct symtab and compunit_symtab. Currently "symtabs" in gdb are stored as a single linked list of struct symtab that contains both symbol symtabs (the blockvectors) and file symtabs (the linetables). This has led to confusion, bugs, and performance issues. This patch is conceptually very simple: split struct symtab into two pieces: one part containing things common across the entire compilation unit, and one part containing things specific to each source file. Example. For the case of a program built out of these files: foo.c foo1.h foo2.h bar.c foo1.h bar.h Today we have a single list of struct symtabs: objfile -> foo.c -> foo1.h -> foo2.h -> bar.c -> foo1.h -> bar.h -> NULL where "->" means the "next" pointer in struct symtab. With this patch, that turns into: objfile -> foo.c(cu) -> bar.c(cu) -> NULL | | v v foo.c bar.c | | v v foo1.h foo1.h | | v v foo2.h bar.h | | v v NULL NULL where "foo.c(cu)" and "bar.c(cu)" are struct compunit_symtab objects, and the files foo.c, etc. are struct symtab objects. So now, for example, when we want to iterate over all blockvectors we can now just iterate over the compunit_symtab list. Plus a lot of the data that was either unused or replicated for each symtab in a compilation unit now lives in struct compunit_symtab. E.g., the objfile pointer, the producer string, etc. I thought of moving "language" out of struct symtab but there is logic to try to compute the language based on previously seen files, and I think that's best left as is for now. With my standard monster benchmark with -readnow (which I can't actually do, but based on my calculations), whereas today the list requires 77MB to store all the struct symtabs, it now only requires 37MB. A modest space savings given the gigabytes needed for all the debug info, etc. Still, it's nice. Plus, whereas today we create a copy of dirname for each source file symtab in a compilation unit, we now only create one for the compunit. So this patch is basically just a data structure reorg, I don't expect significant performance improvements from it. Notes: 1) A followup patch can do a similar split for struct partial_symtab. I have left that until after I get the changes I want in to better utilize .gdb_index (it may affect how we do partial syms). 2) Another followup patch *could* rename struct symtab. The term "symtab" is ambiguous and has been a source of confusion. In this patch I'm leaving it alone, calling it the "historical" name of "filetabs", which is what they are now: just the file-name + line-table. gdb/ChangeLog: Split struct symtab into two: struct symtab and compunit_symtab. * amd64-tdep.c (amd64_skip_xmm_prologue): Fetch producer from compunit. * block.c (blockvector_for_pc_sect): Change "struct symtab *" argument to "struct compunit_symtab *". All callers updated. (set_block_compunit_symtab): Renamed from set_block_symtab. Change "struct symtab *" argument to "struct compunit_symtab *". All callers updated. (get_block_compunit_symtab): Renamed from get_block_symtab. Change result to "struct compunit_symtab *". All callers updated. (find_iterator_compunit_symtab): Renamed from find_iterator_symtab. Change result to "struct compunit_symtab *". All callers updated. * block.h (struct global_block) <compunit_symtab>: Renamed from symtab. hange type to "struct compunit_symtab *". All uses updated. (struct block_iterator) <d.compunit_symtab>: Renamed from "d.symtab". Change type to "struct compunit_symtab *". All uses updated. * buildsym.c (struct buildsym_compunit): New struct. (subfiles, buildsym_compdir, buildsym_objfile, main_subfile): Delete. (buildsym_compunit): New static global. (finish_block_internal): Update to fetch objfile from buildsym_compunit. (make_blockvector): Delete objfile argument. (start_subfile): Rewrite to use buildsym_compunit. Don't initialize debugformat, producer. (start_buildsym_compunit): New function. (free_buildsym_compunit): Renamed from free_subfiles_list. All callers updated. (patch_subfile_names): Rewrite to use buildsym_compunit. (get_compunit_symtab): New function. (get_macro_table): Delete argument comp_dir. All callers updated. (start_symtab): Change result to "struct compunit_symtab *". All callers updated. Create the subfile of the main source file. (watch_main_source_file_lossage): Rewrite to use buildsym_compunit. (reset_symtab_globals): Update. (end_symtab_get_static_block): Update to use buildsym_compunit. (end_symtab_without_blockvector): Rewrite. (end_symtab_with_blockvector): Change result to "struct compunit_symtab *". All callers updated. Update to use buildsym_compunit. Don't set symtab->dirname, instead set it in the compunit. Explicitly make sure main symtab is first in its list. Set debugformat, producer, blockvector, block_line_section, and macrotable in the compunit. (end_symtab_from_static_block): Change result to "struct compunit_symtab *". All callers updated. (end_symtab, end_expandable_symtab): Ditto. (set_missing_symtab): Change symtab argument to "struct compunit_symtab *". All callers updated. (augment_type_symtab): Ditto. (record_debugformat): Update to use buildsym_compunit. (record_producer): Update to use buildsym_compunit. * buildsym.h (struct subfile) <dirname>: Delete. <producer, debugformat>: Delete. <buildsym_compunit>: New member. (get_compunit_symtab): Declare. * dwarf2read.c (struct type_unit_group) <compunit_symtab>: Renamed from primary_symtab. Change type to "struct compunit_symtab *". All uses updated. (dwarf2_start_symtab): Change result to "struct compunit_symtab *". All callers updated. (dwarf_decode_macros): Delete comp_dir argument. All callers updated. (struct dwarf2_per_cu_quick_data) <compunit_symtab>: Renamed from symtab. Change type to "struct compunit_symtab *". All uses updated. (dw2_instantiate_symtab): Change result to "struct compunit_symtab *". All callers updated. (dw2_find_last_source_symtab): Ditto. (dw2_lookup_symbol): Ditto. (recursively_find_pc_sect_compunit_symtab): Renamed from recursively_find_pc_sect_symtab. Change result to "struct compunit_symtab *". All callers updated. (dw2_find_pc_sect_compunit_symtab): Renamed from dw2_find_pc_sect_symtab. Change result to "struct compunit_symtab *". All callers updated. (get_compunit_symtab): Renamed from get_symtab. Change result to "struct compunit_symtab *". All callers updated. (recursively_compute_inclusions): Change type of immediate_parent argument to "struct compunit_symtab *". All callers updated. (compute_compunit_symtab_includes): Renamed from compute_symtab_includes. All callers updated. Rewrite to compute includes of compunit_symtabs and not symtabs. (process_full_comp_unit): Update to work with struct compunit_symtab. (process_full_type_unit): Ditto. (dwarf_decode_lines_1): Delete argument comp_dir. All callers updated. (dwarf_decode_lines): Remove special case handling of main subfile. (macro_start_file): Delete argument comp_dir. All callers updated. (dwarf_decode_macro_bytes): Ditto. * guile/scm-block.c (bkscm_print_block_syms_progress_smob): Update to use struct compunit_symtab. * i386-tdep.c (i386_skip_prologue): Fetch producer from compunit. * jit.c (finalize_symtab): Build compunit_symtab. * jv-lang.c (get_java_class_symtab): Change result to "struct compunit_symtab *". All callers updated. * macroscope.c (sal_macro_scope): Fetch macro table from compunit. * macrotab.c (struct macro_table) <compunit_symtab>: Renamed from comp_dir. Change type to "struct compunit_symtab *". All uses updated. (new_macro_table): Change comp_dir argument to cust, "struct compunit_symtab *". All callers updated. * maint.c (struct cmd_stats) <nr_compunit_symtabs>: Renamed from nr_primary_symtabs. All uses updated. (count_symtabs_and_blocks): Update to handle compunits. (report_command_stats): Update output, "primary symtabs" renamed to "compunits". * mdebugread.c (new_symtab): Change result to "struct compunit_symtab *". All callers updated. (parse_procedure): Change type of search_symtab argument to "struct compunit_symtab *". All callers updated. * objfiles.c (objfile_relocate1): Loop over blockvectors in a separate loop. * objfiles.h (struct objfile) <compunit_symtabs>: Renamed from symtabs. Change type to "struct compunit_symtab *". All uses updated. (ALL_OBJFILE_FILETABS): Renamed from ALL_OBJFILE_SYMTABS. All uses updated. (ALL_OBJFILE_COMPUNITS): Renamed from ALL_OBJFILE_PRIMARY_SYMTABS. All uses updated. (ALL_FILETABS): Renamed from ALL_SYMTABS. All uses updated. (ALL_COMPUNITS): Renamed from ALL_PRIMARY_SYMTABS. All uses updated. * psympriv.h (struct partial_symtab) <compunit_symtab>: Renamed from symtab. Change type to "struct compunit_symtab *". All uses updated. * psymtab.c (psymtab_to_symtab): Change result type to "struct compunit_symtab *". All callers updated. (find_pc_sect_compunit_symtab_from_partial): Renamed from find_pc_sect_symtab_from_partial. Change result type to "struct compunit_symtab *". All callers updated. (lookup_symbol_aux_psymtabs): Change result type to "struct compunit_symtab *". All callers updated. (find_last_source_symtab_from_partial): Ditto. * python/py-symtab.c (stpy_get_producer): Fetch producer from compunit. * source.c (forget_cached_source_info_for_objfile): Fetch debugformat and macro_table from compunit. * symfile-debug.c (debug_qf_find_last_source_symtab): Change result type to "struct compunit_symtab *". All callers updated. (debug_qf_lookup_symbol): Ditto. (debug_qf_find_pc_sect_compunit_symtab): Renamed from debug_qf_find_pc_sect_symtab, change result type to "struct compunit_symtab *". All callers updated. * symfile.c (allocate_symtab): Delete objfile argument. New argument cust. (allocate_compunit_symtab): New function. (add_compunit_symtab_to_objfile): New function. * symfile.h (struct quick_symbol_functions) <lookup_symbol>: Change result type to "struct compunit_symtab *". All uses updated. <find_pc_sect_compunit_symtab>: Renamed from find_pc_sect_symtab. Change result type to "struct compunit_symtab *". All uses updated. * symmisc.c (print_objfile_statistics): Compute blockvector count in separate loop. (dump_symtab_1): Update test for primary source symtab. (maintenance_info_symtabs): Update to handle compunit symtabs. (maintenance_check_symtabs): Ditto. * symtab.c (set_primary_symtab): Delete. (compunit_primary_filetab): New function. (compunit_language): New function. (iterate_over_some_symtabs): Change type of arguments "first", "after_last" to "struct compunit_symtab *". All callers updated. Update to loop over symtabs in each compunit. (error_in_psymtab_expansion): Rename symtab argument to cust, and change type to "struct compunit_symtab *". All callers updated. (find_pc_sect_compunit_symtab): Renamed from find_pc_sect_symtab. Change result type to "struct compunit_symtab *". All callers updated. (find_pc_compunit_symtab): Renamed from find_pc_symtab. Change result type to "struct compunit_symtab *". All callers updated. (find_pc_sect_line): Only loop over symtabs within selected compunit instead of all symtabs in the objfile. * symtab.h (struct symtab) <blockvector>: Moved to compunit_symtab. <compunit_symtab> New member. <block_line_section>: Moved to compunit_symtab. <locations_valid>: Ditto. <epilogue_unwind_valid>: Ditto. <macro_table>: Ditto. <dirname>: Ditto. <debugformat>: Ditto. <producer>: Ditto. <objfile>: Ditto. <call_site_htab>: Ditto. <includes>: Ditto. <user>: Ditto. <primary>: Delete (SYMTAB_COMPUNIT): New macro. (SYMTAB_BLOCKVECTOR): Update definition. (SYMTAB_OBJFILE): Update definition. (SYMTAB_DIRNAME): Update definition. (struct compunit_symtab): New type. Common members among all source symtabs within a compilation unit moved here. All uses updated. (COMPUNIT_OBJFILE): New macro. (COMPUNIT_FILETABS): New macro. (COMPUNIT_DEBUGFORMAT): New macro. (COMPUNIT_PRODUCER): New macro. (COMPUNIT_DIRNAME): New macro. (COMPUNIT_BLOCKVECTOR): New macro. (COMPUNIT_BLOCK_LINE_SECTION): New macro. (COMPUNIT_LOCATIONS_VALID): New macro. (COMPUNIT_EPILOGUE_UNWIND_VALID): New macro. (COMPUNIT_CALL_SITE_HTAB): New macro. (COMPUNIT_MACRO_TABLE): New macro. (ALL_COMPUNIT_FILETABS): New macro. (compunit_symtab_ptr): New typedef. (DEF_VEC_P (compunit_symtab_ptr)): New vector type. gdb/testsuite/ChangeLog: * gdb.base/maint.exp: Update expected output.
2014-11-20 23:42:48 +08:00
};
using subfile_up = std::unique_ptr<subfile>;
/* Record the symbols defined for each context in a list. We don't
create a struct block for the context until we know how long to
make it. */
#define PENDINGSIZE 100
struct pending
{
struct pending *next;
int nsyms;
struct symbol *symbol[PENDINGSIZE];
};
/* Stack representing unclosed lexical contexts (that will become
blocks, eventually). */
struct context_stack
{
/* Outer locals at the time we entered */
struct pending *locals;
/* Pending using directives at the time we entered. */
[Ada] Add support for subprogram renamings Consider the following declaration: function Foo (I : Integer) return Integer renames Pack.Bar; As Foo is not materialized as a routine whose name is derived from Foo, GDB currently cannot use it: (gdb) print foo(0) No definition of "foo" in current context. However, compilers can emit DW_TAG_imported_declaration in order to materialize the fact that Foo is actually another name for Pack.Bar. This commit enhances the DWARF reader to record global renamings (it used to put global ones in a static block) and enhances the Ada engine to leverage this information during symbol lookup. gdb/ChangeLog: * ada-lang.c: Include namespace.h (aux_add_nonlocal_symbols): Fix a function name in comment. (ada_add_block_renamings): New. (add_nonlocal_symbols): Add global renamings handling. (ada_lookup_symbol_list_worker): Move the symbol lookup part to... (ada_add_all_symbols): ... this new function. (ada_add_block_symbols): Try to match the input name against the "using directives list", perform a recursive symbol lookup on the matched declarations. * block.h (struct block): Move the_namespace to top-level as namespace_info. Remove the language_specific field. (BLOCK_NAMESPACE): Update access to the namespace_info field. * buildsym.h (using_directives): Rename into... (local_using_directives): ... this. (global_using_directives): New. (struct context_stack): Rename the using_directives field into local_using_directives. * buildsym.c (finish_block_internal): Deal with the proper using directives repository (local or global). (prepare_for_building): Reset local_using_directives. Assert that there is no pending global using directive. (reset_symtab_globals): Reset global_using_directives and local_using_directives. (end_symtab_get_static_block): Don't ignore symtabs that have only using directives. (push_context): Update references to local_using_directives. (buildsym_init): Do not reset using_directives. * cp-support.c: Include namespace.h. * cp-support.h (struct using_direct): Move to namespace.h. (cp_add_using_directives): Move to namespace.h. * cp-namespace.c: Include namespace.h (cp_add_using_directive): Move to namespace.c, rename it to add_using_directive, add a "using_directives" argument and use it as the pending using directives repository. All callers updated. * dwarf2read.c (using_directives): New. (read_import_statement): Call using_directives. (read_func_scope): Update references to local_using_directives. (read_lexical_block_scope): Likewise. (read_namespace): Update the heading comment, call using_directives. * namespace.h: New file. * namespace.c: New file. * Makefile.in (SFILES): Add namespace.c. (COMMON_OBS): Add namespace.o gdb/testsuite/ChangeLog: * gdb.ada/fun_renaming.exp: New testcase. * gdb.ada/fun_renaming/fun_renaming.adb: New file. * gdb.ada/fun_renaming/pack.adb: New file. * gdb.ada/fun_renaming/pack.ads: New file. Tested on x86_64-linux. Support for this in GCC is in the pipeline: see <https://gcc.gnu.org/ml/gcc-patches/2015-07/msg02166.html>.
2015-07-22 21:30:57 +08:00
struct using_direct *local_using_directives;
/* Pointer into blocklist as of entry */
struct pending_block *old_blocks;
/* Name of function, if any, defining context */
struct symbol *name;
DWARF: handle non-local references in nested functions GDB's current behavior when dealing with non-local references in the context of nested fuctions is approximative: - code using valops.c:value_of_variable read the first available stack frame that holds the corresponding variable (whereas there can be multiple candidates for this); - code directly relying on read_var_value will instead read non-local variables in frames where they are not even defined. This change adds the necessary context to symbol reads (to get the block they belong to) and to blocks (the static link property, if any) so that GDB can make the proper decisions when dealing with non-local varibale references. gdb/ChangeLog: * ada-lang.c (ada_read_var_value): Add a var_block argument and pass it to default_read_var_value. * block.c (block_static_link): New accessor. * block.h (block_static_link): Declare it. * buildsym.c (finish_block_internal): Add a static_link argument. If there is a static link, associate it to the new block. (finish_block): Add a static link argument and pass it to finish_block_internal. (end_symtab_get_static_block): Update calls to finish_block and to finish_block_internal. (end_symtab_with_blockvector): Update call to finish_block_internal. * buildsym.h: Forward-declare struct dynamic_prop. (struct context_stack): Add a static_link field. (finish_block): Add a static link argument. * c-exp.y: Remove an obsolete comment (evaluation of variables already start from the selected frame, and now they climb *up* the call stack) and propagate the block information to the produced expression. * d-exp.y: Likewise. * f-exp.y: Likewise. * go-exp.y: Likewise. * jv-exp.y: Likewise. * m2-exp.y: Likewise. * p-exp.y: Likewise. * coffread.c (coff_symtab_read): Update calls to finish_block. * dbxread.c (process_one_symbol): Likewise. * xcoffread.c (read_xcoff_symtab): Likewise. * compile/compile-c-symbols.c (convert_one_symbol): Promote the "sym" parameter to struct block_symbol, update its uses and pass its block to calls to read_var_value. (convert_symbol_sym): Update the calls to convert_one_symbol. * compile/compile-loc2c.c (do_compile_dwarf_expr_to_c): Update call to read_var_value. * dwarf2loc.c (block_op_get_frame_base): New. (dwarf2_block_frame_base_locexpr_funcs): Implement the get_frame_base method. (dwarf2_block_frame_base_loclist_funcs): Likewise. (dwarf2locexpr_baton_eval): Add a frame argument and use it instead of the selected frame in order to evaluate the expression. (dwarf2_evaluate_property): Add a frame argument. Update call to dwarf2_locexpr_baton_eval to provide a frame in available and to handle the absence of address stack. * dwarf2loc.h (dwarf2_evaluate_property): Add a frame argument. * dwarf2read.c (attr_to_dynamic_prop): Add a forward declaration. (read_func_scope): Record any available static link description. Update call to finish_block. (read_lexical_block_scope): Update call to finish_block. * findvar.c (follow_static_link): New. (get_hosting_frame): New. (default_read_var_value): Add a var_block argument. Use get_hosting_frame to handle non-local references. (read_var_value): Add a var_block argument and pass it to the LA_READ_VAR_VALUE method. * gdbtypes.c (resolve_dynamic_range): Update calls to dwarf2_evaluate_property. (resolve_dynamic_type_internal): Likewise. * guile/scm-frame.c (gdbscm_frame_read_var): Update call to read_var_value, passing it the block coming from symbol lookup. * guile/scm-symbol.c (gdbscm_symbol_value): Update call to read_var_value (TODO). * infcmd.c (finish_command_continuation): Update call to read_var_value, passing it the block coming from symbol lookup. * infrun.c (insert_exception_resume_breakpoint): Likewise. * language.h (struct language_defn): Add a var_block argument to the LA_READ_VAR_VALUE method. * objfiles.c (struct static_link_htab_entry): New. (static_link_htab_entry_hash): New. (static_link_htab_entry_eq): New. (objfile_register_static_link): New. (objfile_lookup_static_link): New. (free_objfile): Free the STATIC_LINKS hashed map if needed. * objfiles.h: Include hashtab.h. (struct objfile): Add a static_links field. (objfile_register_static_link): New. (objfile_lookup_static_link): New. * printcmd.c (print_variable_and_value): Update call to read_var_value. * python/py-finishbreakpoint.c (bpfinishpy_init): Likewise. * python/py-frame.c (frapy_read_var): Update call to read_var_value, passing it the block coming from symbol lookup. * python/py-framefilter.c (extract_sym): Add a sym_block parameter and set the pointed value to NULL (TODO). (enumerate_args): Update call to extract_sym. (enumerate_locals): Update calls to extract_sym and to read_var_value. * python/py-symbol.c (sympy_value): Update call to read_var_value (TODO). * stack.c (read_frame_local): Update call to read_var_value. (read_frame_arg): Likewise. (return_command): Likewise. * symtab.h (struct symbol_block_ops): Add a get_frame_base method. (struct symbol): Add a block field. (SYMBOL_BLOCK): New accessor. * valops.c (value_of_variable): Remove frame/block handling and pass the block argument to read_var_value, which does this job now. (value_struct_elt_for_reference): Update calls to read_var_value. (value_of_this): Pass the block found to read_var_value. * value.h (read_var_value): Add a var_block argument. (default_read_var_value): Likewise. gdb/testsuite/ChangeLog: * gdb.base/nested-subp1.exp: New file. * gdb.base/nested-subp1.c: New file. * gdb.base/nested-subp2.exp: New file. * gdb.base/nested-subp2.c: New file. * gdb.base/nested-subp3.exp: New file. * gdb.base/nested-subp3.c: New file.
2015-02-06 00:00:06 +08:00
/* Expression that computes the frame base of the lexically enclosing
function, if any. NULL otherwise. */
struct dynamic_prop *static_link;
/* PC where this context starts */
CORE_ADDR start_addr;
/* Temp slot for exception handling. */
CORE_ADDR end_addr;
/* For error-checking matching push/pop */
int depth;
};
/* Flags associated with a linetable entry. */
enum linetable_entry_flag : unsigned
{
/* Indicates this PC is a good location to place a breakpoint at LINE. */
LEF_IS_STMT = 1 << 1,
gdb: Add support for DW_LNS_set_prologue_end in line-table Add support for DW_LNS_set_prologue_end when building line-tables. This attribute can be set by the compiler to indicate that an instruction is an adequate place to set a breakpoint just after the prologue of a function. The compiler might set multiple prologue_end, but considering how current skip_prologue_using_sal works, this commit modifies it to accept the first instruction with this marker (if any) to be the place where a breakpoint should be placed to be at the end of the prologue. The need for this support came from a problematic usecase generated by hipcc (i.e. clang). The problem is as follows: There's a function (lets call it foo) which covers PC from 0xa800 to 0xa950. The body of foo begins with a call to an inlined function, covering from 0xa800 to 0xa94c. The issue is that when placing a breakpoint at 'foo', GDB inserts the breakpoint at 0xa818. The 0x18 offset is what GDB thinks is foo's first address past the prologue. Later, when hitting the breakpoint, GDB reports the stop within the inlined function because the PC falls in its range while the user expects to stop in FOO. Looking at the line-table for this location, we have: INDEX LINE ADDRESS IS-STMT [...] 14 293 0x000000000000a66c Y 15 END 0x000000000000a6e0 Y 16 287 0x000000000000a800 Y 17 END 0x000000000000a818 Y 18 287 0x000000000000a824 Y [...] For comparison, let's look at llvm-dwarfdump's output for this CU: Address Line Column File ISA Discriminator Flags ------------------ ------ ------ ------ --- ------------- ------------- [...] 0x000000000000a66c 293 12 2 0 0 is_stmt 0x000000000000a6e0 96 43 82 0 0 is_stmt 0x000000000000a6f8 102 18 82 0 0 is_stmt 0x000000000000a70c 102 24 82 0 0 0x000000000000a710 102 18 82 0 0 0x000000000000a72c 101 16 82 0 0 is_stmt 0x000000000000a73c 2915 50 83 0 0 is_stmt 0x000000000000a74c 110 1 1 0 0 is_stmt 0x000000000000a750 110 1 1 0 0 is_stmt end_sequence 0x000000000000a800 107 0 1 0 0 is_stmt 0x000000000000a800 287 12 2 0 0 is_stmt prologue_end 0x000000000000a818 114 59 81 0 0 is_stmt 0x000000000000a824 287 12 2 0 0 is_stmt 0x000000000000a828 100 58 82 0 0 is_stmt [...] The main difference we are interested in here is that llvm-dwarfdump's output tells us that 0xa800 is an adequate place to place a breakpoint past a function prologue. Since we know that foo covers from 0xa800 to 0xa94c, 0xa800 is the address at which the breakpoint should be placed if the user wants to break in foo. This commit proposes to add support for the prologue_end flag in the line-program processing. The processing of this prologue_end flag is made in skip_prologue_sal, before it calls gdbarch_skip_prologue_noexcept. The intent is that if the compiler gave information on where the prologue ends, we should use this information and not try to rely on architecture dependent logic to guess it. The testsuite have been executed using this patch on GNU/Linux x86_64. Testcases have been compiled with both gcc/g++ (verison 9.4.0) and clang/clang++ (version 10.0.0) since at the time of writing GCC does not set the prologue_end marker. Tests done with GCC 11.2.0 (not over the entire testsuite) show that it does not emit this flag either. No regression have been observed with GCC or Clang. Note that when using Clang, this patch fixes a failure in gdb.opt/inline-small-func.exp. Change-Id: I720449a8a9b2e1fb45b54c6095d3b1e9da9152f8
2022-02-26 07:41:47 +08:00
/* Indicates this PC is a good location to place a breakpoint at the first
instruction past a function prologue. */
LEF_PROLOGUE_END = 1 << 2,
};
DEF_ENUM_FLAGS_TYPE (enum linetable_entry_flag, linetable_entry_flags);
/* Buildsym's counterpart to struct compunit_symtab. */
struct buildsym_compunit
{
/* Start recording information about a primary source file (IOW, not an
included source file).
gdb: add "id" fields to identify symtabs and subfiles Printing macros defined in the main source file doesn't work reliably using various toolchains, especially when DWARF 5 is used. For example, using the binaries produced by either of these commands: $ gcc --version gcc (GCC) 11.2.0 $ ld --version GNU ld (GNU Binutils) 2.38 $ gcc test.c -g3 -gdwarf-5 $ clang --version clang version 13.0.1 $ clang test.c -gdwarf-5 -fdebug-macro I get: $ ./gdb -nx -q --data-directory=data-directory a.out (gdb) start Temporary breakpoint 1 at 0x111d: file test.c, line 6. Starting program: /home/simark/build/binutils-gdb-one-target/gdb/a.out Temporary breakpoint 1, main () at test.c:6 6 return ZERO; (gdb) p ZERO No symbol "ZERO" in current context. When starting to investigate this (taking the gcc-compiled binary as an example), we see that GDB fails to look up the appropriate macro scope when evaluating the expression. While stopped in macro_lookup_inclusion: (top-gdb) p name $1 = 0x62100011a980 "test.c" (top-gdb) p source.filename $2 = 0x62100011a9a0 "/home/simark/build/binutils-gdb-one-target/gdb/test.c" `source` is the macro_source_file that we would expect GDB to find. `name` comes from the symtab::filename field of the symtab we are stopped in. GDB doesn't find the appropriate macro_source_file because the name of the macro_source_file doesn't match exactly the name of the symtab. The name of the main symtab comes from the compilation unit's DW_AT_name, passed to the buildsym_compunit's constructor: https://gitlab.com/gnutools/binutils-gdb/-/blob/4815d6125ec580cc02a1094d61b8c9d1cc83c0a1/gdb/dwarf2/read.c#L10627-10630 The contents of DW_AT_name, in this case, is "test.c". It is typically (what I witnessed all compilers do) the same string that was passed to the compiler on the command-line. The name of the macro_source_file comes from the line number program header's file table, from the call to the line_header::file_file_name method: https://gitlab.com/gnutools/binutils-gdb/-/blob/4815d6125ec580cc02a1094d61b8c9d1cc83c0a1/gdb/dwarf2/macro.c#L54-65 line_header::file_file_name prepends the directory path that the file entry refers to, in the file table (if the file name is not already absolute). In this case, the file name is "test.c", appended to the directory "/home/simark/build/binutils-gdb-one-target/gdb". Because the symtab's name is not created the same way as the macro_source_file's name is created, we get this mismatch. GDB fails to find the appropriate macro scope for the symtab, and we can't print macros when stopped in that symtab. To make this work, we must ensure that paths produced in these two ways end up identical. This can be tricky because of the different ways a path can be passed to the compiler by the user. Another thing to consider is that while the main symtab's name (or subfile, before it becomes a symtab) is created using DW_AT_name, the main symtab is also referred to using its entry in the line table header's file table, when processing the line table. We must therefore ensure that the same name is produced in both cases, so that a call to "start_subfile" for the main subfile will correctly find the already-created subfile, created by buildsym_compunit's constructor. If we fail to do that, things still often work, because of a fallback: the watch_main_source_file_lossage method. This method determines that if the main subfile has no symbols but there exists another subfile with the same basename (e.g. "test.c") that does have symbols, it's probably because there was some filename mismatch. So it replaces the main subfile with that other subfile. I think that heuristic is useful as a last effort to work around any bug or bad debug info, but I don't think we should design things such as to rely on it. It's a heuristic, it can get things wrong. So in my search for a fix, it is important that given some good debug info, we don't end up relying on that for things to work. A first attempt at fixing this was to try to prepend the compilation directory here or not prepend it there. In practice, because of all the possible combinations of debug info the compilers produce, it was not possible to get something that would produce reliable, consistent paths. Another attempt at fixing this was to make both macro_source_file objects and symtab objects use the most complete form of path possible. That means to prepend directories at least until we get an absolute path. In theory, we should end up with the same path in all cases. This generally worked, but because it changed the symtab names, it resulted in user-visible changes (for example, paths to source files in Breakpoint hit messages becoming always absolute). I didn't find this very good, first because there is a "set filename-display" setting that lets the user control how they want the paths to be displayed, and that would suddenly make this setting completely ineffective (although even today, it is a bit dependent on the debug info). Second, it would require a good amount of testsuite tweaks to make tests accept these suddenly absolute paths. This new patch is a slight variation of that: it adds a new field called "filename_for_id" in struct symtab and struct subfile, next to the existing filename field. The goal is to separate the internal ids used for finding objects from the names used for presentation. This field is used for identifying subfiles, symtabs and macro_source_files internally. For DWARF symtabs, this new field is meant to contain the "most complete possible" path, as discussed above. So for a given file, it must always be in the same form, everywhere. The existing symtab::filename field remains the one used for printing to the user, so there shouldn't be any change in how paths are printed. Changes in the core symtab files are: - Add "name_for_id" and "filename_for_id" fields to "struct subfile" and "struct symtab", next to existing "name" and "filename" fields. - Make buildsym_compunit::buildsym_compunit and buildsym_compunit::start_subfile accept a "name_for_id" parameter next to the existing "name" ones. - Make buildsym_compunit::start_subfile use "name_for_id" for looking up existing subfiles. This is the key thing for making calls to start_subfile for the main source file look up the existing subfile successfully, and avoid relying on watch_main_source_file_lossage. - Make sal_macro_scope pass "filename_for_id", rather than "filename", to macro_lookup_inclusion. This is the key thing to making the lookup work and macro printing work. Changes in the DWARF files are: - Make line_header::file_file_name return the "most complete possible" name. The only pre-existing user of this method is the macro code, to give the macro_source_file objects their name. And we now want them to have this "most complete possible" name, which will match the corresponding symtab's "filename_for_id". - Make dwarf2_cu::start_compunit_symtab pass the "most complete possible" name for the main symtab's "filename_for_id". In this context, where the info comes from the compilation unit's DW_AT_name / DW_AT_comp_dir, it means prepending DW_AT_comp_dir to DW_AT_name if DW_AT_name is not already absolute. - Change dwarf2_start_subfile to build a name_for_id for the subfile being started. The simplest way is to re-use line_header::file_file_name, since the callers always have a file_entry handy. This ensures that it will get the exact same path representation as the macro code does, for the same file (since it also uses line_header::file_file_name). - Update calls to allocate_symtab to pass the "name_for_id" from the subfile. Tests exercising all this are added by the following patch. Of all the cases I tried, the only one I found that ends up relying on watch_main_source_file_lossage is the following one: $ clang --version clang version 13.0.1 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin $ clang ./test.c -g3 -O0 -gdwarf-4 $ ./gdb -nx --data-directory=data-directory -q -readnow -iex "set debug symtab-create 1" a.out ... [symtab-create] start_subfile: name = test.c, name_for_id = /home/simark/build/binutils-gdb-one-target/gdb/test.c [symtab-create] start_subfile: name = ./test.c, name_for_id = /home/simark/build/binutils-gdb-one-target/gdb/./test.c [symtab-create] start_subfile: name = ./test.c, name_for_id = /home/simark/build/binutils-gdb-one-target/gdb/./test.c [symtab-create] start_subfile: found existing symtab with name_for_id /home/simark/build/binutils-gdb-one-target/gdb/./test.c (/home/simark/build/binutils-gdb-one-target/gdb/./test.c) [symtab-create] watch_main_source_file_lossage: using subfile ./test.c as the main subfile As we can see, there are two forms used for "test.c", one with a "." and one without. This comes from the fact that the compilation unit DIE contains: DW_AT_name ("test.c") DW_AT_comp_dir ("/home/simark/build/binutils-gdb-one-target/gdb") without a ".", and the line table for that file contains: include_directories[ 1] = "." file_names[ 1]: name: "test.c" dir_index: 1 When assembling the filename from that entry, we get a ".". It is a bit unexpected that the main filename resulting from the line table header does not match exactly the name in the compilation unit. For instance, gcc uses "./test.c" for the DW_AT_name, which gives identical paths in the compilation unit and in the line table header. Similarly, with DWARF 5: $ clang ./test.c -g3 -O0 -gdwarf-5 clang create two entries that refer to the same file but are of in a different form. include_directories[ 0] = "/home/simark/build/binutils-gdb-one-target/gdb" include_directories[ 1] = "." file_names[ 0]: name: "test.c" dir_index: 0 file_names[ 1]: name: "test.c" dir_index: 1 The first file name produces a path without a "." while the second does. This is not caught by watch_main_source_file_lossage, because of dwarf_decode_lines that creates a symtab for each file entry in the line table. It therefore appears as "non-empty" to watch_main_source_file_lossage. This results in two symtabs: (gdb) maintenance info symtabs { objfile /home/simark/build/binutils-gdb-one-target/gdb/a.out ((struct objfile *) 0x613000005d00) { ((struct compunit_symtab *) 0x62100011aca0) debugformat DWARF 5 producer clang version 13.0.1 name test.c dirname /home/simark/build/binutils-gdb-one-target/gdb blockvector ((struct blockvector *) 0x621000129ec0) user ((struct compunit_symtab *) (null)) { symtab test.c ((struct symtab *) 0x62100011ad20) fullname (null) linetable ((struct linetable *) 0x0) } { symtab ./test.c ((struct symtab *) 0x62100011ad60) fullname (null) linetable ((struct linetable *) 0x621000129ef0) } } } I am not sure what is the consequence of this, but this is also what happens before my patch, so I think its acceptable to leave it as-is. To handle these two cases nicely, I think we will need a function that removes the unnecessary "." from path names, something that can be done later. Finally, I made a change in find_file_and_directory is necessary to avoid breaking test gdb.dwarf2/dw2-compdir-oldgcc.exp: info source gcc42 Without that change, we would get: (gdb) info source Current source file is /dir/d/dw2-compdir-oldgcc42.S Compilation directory is /dir/d whereas the expected result is: (gdb) info source Current source file is dw2-compdir-oldgcc42.S Compilation directory is /dir/d This test was added here: https://sourceware.org/pipermail/gdb-patches/2012-November/098144.html Long story short, GCC <= 4.2 apparently had a bug where it would generate a DW_AT_name with a full path ("/dir/d/dw2-compdir-oldgcc42.S") and no DW_AT_comp_dir. The line table has one entry with filename "dw2-compdir-oldgcc42.S", which refers to directory 0. Directory 0 normally refers to the compilation unit's comp dir, but it is non-existent in this case. This caused some symtab lookup problems, and to work around them, some workaround was added, which today reads as: if (res.get_comp_dir () == nullptr && producer_is_gcc_lt_4_3 (cu) && res.get_name () != nullptr && IS_ABSOLUTE_PATH (res.get_name ())) res.set_comp_dir (ldirname (res.get_name ())); Source: https://gitlab.com/gnutools/binutils-gdb/-/blob/6577f365ebdee7dda71cb996efa29d3714cbccd0/gdb/dwarf2/read.c#L9428-9432 It extracts an artificial DW_AT_comp_dir from DW_AT_name, if there is no DW_AT_comp_dir and DW_AT_name is absolute. Prior to my patch, a subfile would get created with filename "/dir/d/dw2-compdir-oldgcc42.S", from DW_AT_name, and another would get created with filename "dw2-compdir-oldgcc42.S" from the line table's file table. Then watch_main_source_file_lossage would kick in and merge them, keeping only the "dw2-compdir-oldgcc42.S" one: [symtab-create] start_subfile: name = /dir/d/dw2-compdir-oldgcc42.S [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S [symtab-create] start_subfile: found existing symtab with name dw2-compdir-oldgcc42.S (dw2-compdir-oldgcc42.S) [symtab-create] watch_main_source_file_lossage: using subfile dw2-compdir-oldgcc42.S as the main subfile And so "info source" would show "dw2-compdir-oldgcc42.S" as the filename. With my patch applied, but without the change in find_file_and_directory, both DW_AT_name and the line table would try to start a subfile with the same filename_for_id, and there was no need for watch_main_source_file_lossage - which is what we want: [symtab-create] start_subfile: name = /dir/d/dw2-compdir-oldgcc42.S, name_for_id = /dir/d/dw2-compdir-oldgcc42.S [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S, name_for_id = /dir/d/dw2-compdir-oldgcc42.S [symtab-create] start_subfile: found existing symtab with name_for_id /dir/d/dw2-compdir-oldgcc42.S (/dir/d/dw2-compdir-oldgcc42.S) [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S, name_for_id = /dir/d/dw2-compdir-oldgcc42.S [symtab-create] start_subfile: found existing symtab with name_for_id /dir/d/dw2-compdir-oldgcc42.S (/dir/d/dw2-compdir-oldgcc42.S) But since the one with name == "/dir/d/dw2-compdir-oldgcc42.S", coming from DW_AT_name, gets created first, it wins, and the symtab ends up with "/dir/d/dw2-compdir-oldgcc42.S" as the name, "info source" shows "/dir/d/dw2-compdir-oldgcc42.S" and the test breaks. This is not wrong per-se, after all DW_AT_name is "/dir/d/dw2-compdir-oldgcc42.S", so it wouldn't be wrong to report the current source file as "/dir/d/dw2-compdir-oldgcc42.S". If you compile a file passing "/an/absolute/path.c", DW_AT_name typically contains (at least with GCC) "/an/absolute/path.c" and GDB tells you that the source file is "/an/absolute/path.c". But we can also keep the existing behavior fairly easily with a little change in find_file_and_directory. When extracting an artificial DW_AT_comp_dir from DW_AT_name, we now modify the name to just keep the file part. The result is coherent with what compilers do when you compile a file by just passing its filename ("gcc path.c -g"): DW_AT_name ("path.c") DW_AT_comp_dir ("/home/simark/build/binutils-gdb-one-target/gdb") With this change, filename_for_id is still the full name, "/dir/d/dw2-compdir-oldgcc42.S", but the filename of the subfile / symtab (what ends up shown by "info source") is just "dw2-compdir-oldgcc42.S", and that makes the test happy. Change-Id: I8b5cc4bb3052afdb172ee815c051187290566307
2022-07-29 00:34:47 +08:00
COMP_DIR is the directory in which the compilation unit was compiled
gdb: add "id" fields to identify symtabs and subfiles Printing macros defined in the main source file doesn't work reliably using various toolchains, especially when DWARF 5 is used. For example, using the binaries produced by either of these commands: $ gcc --version gcc (GCC) 11.2.0 $ ld --version GNU ld (GNU Binutils) 2.38 $ gcc test.c -g3 -gdwarf-5 $ clang --version clang version 13.0.1 $ clang test.c -gdwarf-5 -fdebug-macro I get: $ ./gdb -nx -q --data-directory=data-directory a.out (gdb) start Temporary breakpoint 1 at 0x111d: file test.c, line 6. Starting program: /home/simark/build/binutils-gdb-one-target/gdb/a.out Temporary breakpoint 1, main () at test.c:6 6 return ZERO; (gdb) p ZERO No symbol "ZERO" in current context. When starting to investigate this (taking the gcc-compiled binary as an example), we see that GDB fails to look up the appropriate macro scope when evaluating the expression. While stopped in macro_lookup_inclusion: (top-gdb) p name $1 = 0x62100011a980 "test.c" (top-gdb) p source.filename $2 = 0x62100011a9a0 "/home/simark/build/binutils-gdb-one-target/gdb/test.c" `source` is the macro_source_file that we would expect GDB to find. `name` comes from the symtab::filename field of the symtab we are stopped in. GDB doesn't find the appropriate macro_source_file because the name of the macro_source_file doesn't match exactly the name of the symtab. The name of the main symtab comes from the compilation unit's DW_AT_name, passed to the buildsym_compunit's constructor: https://gitlab.com/gnutools/binutils-gdb/-/blob/4815d6125ec580cc02a1094d61b8c9d1cc83c0a1/gdb/dwarf2/read.c#L10627-10630 The contents of DW_AT_name, in this case, is "test.c". It is typically (what I witnessed all compilers do) the same string that was passed to the compiler on the command-line. The name of the macro_source_file comes from the line number program header's file table, from the call to the line_header::file_file_name method: https://gitlab.com/gnutools/binutils-gdb/-/blob/4815d6125ec580cc02a1094d61b8c9d1cc83c0a1/gdb/dwarf2/macro.c#L54-65 line_header::file_file_name prepends the directory path that the file entry refers to, in the file table (if the file name is not already absolute). In this case, the file name is "test.c", appended to the directory "/home/simark/build/binutils-gdb-one-target/gdb". Because the symtab's name is not created the same way as the macro_source_file's name is created, we get this mismatch. GDB fails to find the appropriate macro scope for the symtab, and we can't print macros when stopped in that symtab. To make this work, we must ensure that paths produced in these two ways end up identical. This can be tricky because of the different ways a path can be passed to the compiler by the user. Another thing to consider is that while the main symtab's name (or subfile, before it becomes a symtab) is created using DW_AT_name, the main symtab is also referred to using its entry in the line table header's file table, when processing the line table. We must therefore ensure that the same name is produced in both cases, so that a call to "start_subfile" for the main subfile will correctly find the already-created subfile, created by buildsym_compunit's constructor. If we fail to do that, things still often work, because of a fallback: the watch_main_source_file_lossage method. This method determines that if the main subfile has no symbols but there exists another subfile with the same basename (e.g. "test.c") that does have symbols, it's probably because there was some filename mismatch. So it replaces the main subfile with that other subfile. I think that heuristic is useful as a last effort to work around any bug or bad debug info, but I don't think we should design things such as to rely on it. It's a heuristic, it can get things wrong. So in my search for a fix, it is important that given some good debug info, we don't end up relying on that for things to work. A first attempt at fixing this was to try to prepend the compilation directory here or not prepend it there. In practice, because of all the possible combinations of debug info the compilers produce, it was not possible to get something that would produce reliable, consistent paths. Another attempt at fixing this was to make both macro_source_file objects and symtab objects use the most complete form of path possible. That means to prepend directories at least until we get an absolute path. In theory, we should end up with the same path in all cases. This generally worked, but because it changed the symtab names, it resulted in user-visible changes (for example, paths to source files in Breakpoint hit messages becoming always absolute). I didn't find this very good, first because there is a "set filename-display" setting that lets the user control how they want the paths to be displayed, and that would suddenly make this setting completely ineffective (although even today, it is a bit dependent on the debug info). Second, it would require a good amount of testsuite tweaks to make tests accept these suddenly absolute paths. This new patch is a slight variation of that: it adds a new field called "filename_for_id" in struct symtab and struct subfile, next to the existing filename field. The goal is to separate the internal ids used for finding objects from the names used for presentation. This field is used for identifying subfiles, symtabs and macro_source_files internally. For DWARF symtabs, this new field is meant to contain the "most complete possible" path, as discussed above. So for a given file, it must always be in the same form, everywhere. The existing symtab::filename field remains the one used for printing to the user, so there shouldn't be any change in how paths are printed. Changes in the core symtab files are: - Add "name_for_id" and "filename_for_id" fields to "struct subfile" and "struct symtab", next to existing "name" and "filename" fields. - Make buildsym_compunit::buildsym_compunit and buildsym_compunit::start_subfile accept a "name_for_id" parameter next to the existing "name" ones. - Make buildsym_compunit::start_subfile use "name_for_id" for looking up existing subfiles. This is the key thing for making calls to start_subfile for the main source file look up the existing subfile successfully, and avoid relying on watch_main_source_file_lossage. - Make sal_macro_scope pass "filename_for_id", rather than "filename", to macro_lookup_inclusion. This is the key thing to making the lookup work and macro printing work. Changes in the DWARF files are: - Make line_header::file_file_name return the "most complete possible" name. The only pre-existing user of this method is the macro code, to give the macro_source_file objects their name. And we now want them to have this "most complete possible" name, which will match the corresponding symtab's "filename_for_id". - Make dwarf2_cu::start_compunit_symtab pass the "most complete possible" name for the main symtab's "filename_for_id". In this context, where the info comes from the compilation unit's DW_AT_name / DW_AT_comp_dir, it means prepending DW_AT_comp_dir to DW_AT_name if DW_AT_name is not already absolute. - Change dwarf2_start_subfile to build a name_for_id for the subfile being started. The simplest way is to re-use line_header::file_file_name, since the callers always have a file_entry handy. This ensures that it will get the exact same path representation as the macro code does, for the same file (since it also uses line_header::file_file_name). - Update calls to allocate_symtab to pass the "name_for_id" from the subfile. Tests exercising all this are added by the following patch. Of all the cases I tried, the only one I found that ends up relying on watch_main_source_file_lossage is the following one: $ clang --version clang version 13.0.1 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin $ clang ./test.c -g3 -O0 -gdwarf-4 $ ./gdb -nx --data-directory=data-directory -q -readnow -iex "set debug symtab-create 1" a.out ... [symtab-create] start_subfile: name = test.c, name_for_id = /home/simark/build/binutils-gdb-one-target/gdb/test.c [symtab-create] start_subfile: name = ./test.c, name_for_id = /home/simark/build/binutils-gdb-one-target/gdb/./test.c [symtab-create] start_subfile: name = ./test.c, name_for_id = /home/simark/build/binutils-gdb-one-target/gdb/./test.c [symtab-create] start_subfile: found existing symtab with name_for_id /home/simark/build/binutils-gdb-one-target/gdb/./test.c (/home/simark/build/binutils-gdb-one-target/gdb/./test.c) [symtab-create] watch_main_source_file_lossage: using subfile ./test.c as the main subfile As we can see, there are two forms used for "test.c", one with a "." and one without. This comes from the fact that the compilation unit DIE contains: DW_AT_name ("test.c") DW_AT_comp_dir ("/home/simark/build/binutils-gdb-one-target/gdb") without a ".", and the line table for that file contains: include_directories[ 1] = "." file_names[ 1]: name: "test.c" dir_index: 1 When assembling the filename from that entry, we get a ".". It is a bit unexpected that the main filename resulting from the line table header does not match exactly the name in the compilation unit. For instance, gcc uses "./test.c" for the DW_AT_name, which gives identical paths in the compilation unit and in the line table header. Similarly, with DWARF 5: $ clang ./test.c -g3 -O0 -gdwarf-5 clang create two entries that refer to the same file but are of in a different form. include_directories[ 0] = "/home/simark/build/binutils-gdb-one-target/gdb" include_directories[ 1] = "." file_names[ 0]: name: "test.c" dir_index: 0 file_names[ 1]: name: "test.c" dir_index: 1 The first file name produces a path without a "." while the second does. This is not caught by watch_main_source_file_lossage, because of dwarf_decode_lines that creates a symtab for each file entry in the line table. It therefore appears as "non-empty" to watch_main_source_file_lossage. This results in two symtabs: (gdb) maintenance info symtabs { objfile /home/simark/build/binutils-gdb-one-target/gdb/a.out ((struct objfile *) 0x613000005d00) { ((struct compunit_symtab *) 0x62100011aca0) debugformat DWARF 5 producer clang version 13.0.1 name test.c dirname /home/simark/build/binutils-gdb-one-target/gdb blockvector ((struct blockvector *) 0x621000129ec0) user ((struct compunit_symtab *) (null)) { symtab test.c ((struct symtab *) 0x62100011ad20) fullname (null) linetable ((struct linetable *) 0x0) } { symtab ./test.c ((struct symtab *) 0x62100011ad60) fullname (null) linetable ((struct linetable *) 0x621000129ef0) } } } I am not sure what is the consequence of this, but this is also what happens before my patch, so I think its acceptable to leave it as-is. To handle these two cases nicely, I think we will need a function that removes the unnecessary "." from path names, something that can be done later. Finally, I made a change in find_file_and_directory is necessary to avoid breaking test gdb.dwarf2/dw2-compdir-oldgcc.exp: info source gcc42 Without that change, we would get: (gdb) info source Current source file is /dir/d/dw2-compdir-oldgcc42.S Compilation directory is /dir/d whereas the expected result is: (gdb) info source Current source file is dw2-compdir-oldgcc42.S Compilation directory is /dir/d This test was added here: https://sourceware.org/pipermail/gdb-patches/2012-November/098144.html Long story short, GCC <= 4.2 apparently had a bug where it would generate a DW_AT_name with a full path ("/dir/d/dw2-compdir-oldgcc42.S") and no DW_AT_comp_dir. The line table has one entry with filename "dw2-compdir-oldgcc42.S", which refers to directory 0. Directory 0 normally refers to the compilation unit's comp dir, but it is non-existent in this case. This caused some symtab lookup problems, and to work around them, some workaround was added, which today reads as: if (res.get_comp_dir () == nullptr && producer_is_gcc_lt_4_3 (cu) && res.get_name () != nullptr && IS_ABSOLUTE_PATH (res.get_name ())) res.set_comp_dir (ldirname (res.get_name ())); Source: https://gitlab.com/gnutools/binutils-gdb/-/blob/6577f365ebdee7dda71cb996efa29d3714cbccd0/gdb/dwarf2/read.c#L9428-9432 It extracts an artificial DW_AT_comp_dir from DW_AT_name, if there is no DW_AT_comp_dir and DW_AT_name is absolute. Prior to my patch, a subfile would get created with filename "/dir/d/dw2-compdir-oldgcc42.S", from DW_AT_name, and another would get created with filename "dw2-compdir-oldgcc42.S" from the line table's file table. Then watch_main_source_file_lossage would kick in and merge them, keeping only the "dw2-compdir-oldgcc42.S" one: [symtab-create] start_subfile: name = /dir/d/dw2-compdir-oldgcc42.S [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S [symtab-create] start_subfile: found existing symtab with name dw2-compdir-oldgcc42.S (dw2-compdir-oldgcc42.S) [symtab-create] watch_main_source_file_lossage: using subfile dw2-compdir-oldgcc42.S as the main subfile And so "info source" would show "dw2-compdir-oldgcc42.S" as the filename. With my patch applied, but without the change in find_file_and_directory, both DW_AT_name and the line table would try to start a subfile with the same filename_for_id, and there was no need for watch_main_source_file_lossage - which is what we want: [symtab-create] start_subfile: name = /dir/d/dw2-compdir-oldgcc42.S, name_for_id = /dir/d/dw2-compdir-oldgcc42.S [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S, name_for_id = /dir/d/dw2-compdir-oldgcc42.S [symtab-create] start_subfile: found existing symtab with name_for_id /dir/d/dw2-compdir-oldgcc42.S (/dir/d/dw2-compdir-oldgcc42.S) [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S, name_for_id = /dir/d/dw2-compdir-oldgcc42.S [symtab-create] start_subfile: found existing symtab with name_for_id /dir/d/dw2-compdir-oldgcc42.S (/dir/d/dw2-compdir-oldgcc42.S) But since the one with name == "/dir/d/dw2-compdir-oldgcc42.S", coming from DW_AT_name, gets created first, it wins, and the symtab ends up with "/dir/d/dw2-compdir-oldgcc42.S" as the name, "info source" shows "/dir/d/dw2-compdir-oldgcc42.S" and the test breaks. This is not wrong per-se, after all DW_AT_name is "/dir/d/dw2-compdir-oldgcc42.S", so it wouldn't be wrong to report the current source file as "/dir/d/dw2-compdir-oldgcc42.S". If you compile a file passing "/an/absolute/path.c", DW_AT_name typically contains (at least with GCC) "/an/absolute/path.c" and GDB tells you that the source file is "/an/absolute/path.c". But we can also keep the existing behavior fairly easily with a little change in find_file_and_directory. When extracting an artificial DW_AT_comp_dir from DW_AT_name, we now modify the name to just keep the file part. The result is coherent with what compilers do when you compile a file by just passing its filename ("gcc path.c -g"): DW_AT_name ("path.c") DW_AT_comp_dir ("/home/simark/build/binutils-gdb-one-target/gdb") With this change, filename_for_id is still the full name, "/dir/d/dw2-compdir-oldgcc42.S", but the filename of the subfile / symtab (what ends up shown by "info source") is just "dw2-compdir-oldgcc42.S", and that makes the test happy. Change-Id: I8b5cc4bb3052afdb172ee815c051187290566307
2022-07-29 00:34:47 +08:00
(or NULL if not known).
NAME and NAME_FOR_ID have the same purpose as for the start_subfile
method. */
buildsym_compunit (struct objfile *objfile_, const char *name,
const char *comp_dir_, const char *name_for_id,
enum language language_, CORE_ADDR last_addr);
/* Same as above, but passes NAME for NAME_FOR_ID. */
buildsym_compunit (struct objfile *objfile_, const char *name,
const char *comp_dir_, enum language language_,
gdb: add "id" fields to identify symtabs and subfiles Printing macros defined in the main source file doesn't work reliably using various toolchains, especially when DWARF 5 is used. For example, using the binaries produced by either of these commands: $ gcc --version gcc (GCC) 11.2.0 $ ld --version GNU ld (GNU Binutils) 2.38 $ gcc test.c -g3 -gdwarf-5 $ clang --version clang version 13.0.1 $ clang test.c -gdwarf-5 -fdebug-macro I get: $ ./gdb -nx -q --data-directory=data-directory a.out (gdb) start Temporary breakpoint 1 at 0x111d: file test.c, line 6. Starting program: /home/simark/build/binutils-gdb-one-target/gdb/a.out Temporary breakpoint 1, main () at test.c:6 6 return ZERO; (gdb) p ZERO No symbol "ZERO" in current context. When starting to investigate this (taking the gcc-compiled binary as an example), we see that GDB fails to look up the appropriate macro scope when evaluating the expression. While stopped in macro_lookup_inclusion: (top-gdb) p name $1 = 0x62100011a980 "test.c" (top-gdb) p source.filename $2 = 0x62100011a9a0 "/home/simark/build/binutils-gdb-one-target/gdb/test.c" `source` is the macro_source_file that we would expect GDB to find. `name` comes from the symtab::filename field of the symtab we are stopped in. GDB doesn't find the appropriate macro_source_file because the name of the macro_source_file doesn't match exactly the name of the symtab. The name of the main symtab comes from the compilation unit's DW_AT_name, passed to the buildsym_compunit's constructor: https://gitlab.com/gnutools/binutils-gdb/-/blob/4815d6125ec580cc02a1094d61b8c9d1cc83c0a1/gdb/dwarf2/read.c#L10627-10630 The contents of DW_AT_name, in this case, is "test.c". It is typically (what I witnessed all compilers do) the same string that was passed to the compiler on the command-line. The name of the macro_source_file comes from the line number program header's file table, from the call to the line_header::file_file_name method: https://gitlab.com/gnutools/binutils-gdb/-/blob/4815d6125ec580cc02a1094d61b8c9d1cc83c0a1/gdb/dwarf2/macro.c#L54-65 line_header::file_file_name prepends the directory path that the file entry refers to, in the file table (if the file name is not already absolute). In this case, the file name is "test.c", appended to the directory "/home/simark/build/binutils-gdb-one-target/gdb". Because the symtab's name is not created the same way as the macro_source_file's name is created, we get this mismatch. GDB fails to find the appropriate macro scope for the symtab, and we can't print macros when stopped in that symtab. To make this work, we must ensure that paths produced in these two ways end up identical. This can be tricky because of the different ways a path can be passed to the compiler by the user. Another thing to consider is that while the main symtab's name (or subfile, before it becomes a symtab) is created using DW_AT_name, the main symtab is also referred to using its entry in the line table header's file table, when processing the line table. We must therefore ensure that the same name is produced in both cases, so that a call to "start_subfile" for the main subfile will correctly find the already-created subfile, created by buildsym_compunit's constructor. If we fail to do that, things still often work, because of a fallback: the watch_main_source_file_lossage method. This method determines that if the main subfile has no symbols but there exists another subfile with the same basename (e.g. "test.c") that does have symbols, it's probably because there was some filename mismatch. So it replaces the main subfile with that other subfile. I think that heuristic is useful as a last effort to work around any bug or bad debug info, but I don't think we should design things such as to rely on it. It's a heuristic, it can get things wrong. So in my search for a fix, it is important that given some good debug info, we don't end up relying on that for things to work. A first attempt at fixing this was to try to prepend the compilation directory here or not prepend it there. In practice, because of all the possible combinations of debug info the compilers produce, it was not possible to get something that would produce reliable, consistent paths. Another attempt at fixing this was to make both macro_source_file objects and symtab objects use the most complete form of path possible. That means to prepend directories at least until we get an absolute path. In theory, we should end up with the same path in all cases. This generally worked, but because it changed the symtab names, it resulted in user-visible changes (for example, paths to source files in Breakpoint hit messages becoming always absolute). I didn't find this very good, first because there is a "set filename-display" setting that lets the user control how they want the paths to be displayed, and that would suddenly make this setting completely ineffective (although even today, it is a bit dependent on the debug info). Second, it would require a good amount of testsuite tweaks to make tests accept these suddenly absolute paths. This new patch is a slight variation of that: it adds a new field called "filename_for_id" in struct symtab and struct subfile, next to the existing filename field. The goal is to separate the internal ids used for finding objects from the names used for presentation. This field is used for identifying subfiles, symtabs and macro_source_files internally. For DWARF symtabs, this new field is meant to contain the "most complete possible" path, as discussed above. So for a given file, it must always be in the same form, everywhere. The existing symtab::filename field remains the one used for printing to the user, so there shouldn't be any change in how paths are printed. Changes in the core symtab files are: - Add "name_for_id" and "filename_for_id" fields to "struct subfile" and "struct symtab", next to existing "name" and "filename" fields. - Make buildsym_compunit::buildsym_compunit and buildsym_compunit::start_subfile accept a "name_for_id" parameter next to the existing "name" ones. - Make buildsym_compunit::start_subfile use "name_for_id" for looking up existing subfiles. This is the key thing for making calls to start_subfile for the main source file look up the existing subfile successfully, and avoid relying on watch_main_source_file_lossage. - Make sal_macro_scope pass "filename_for_id", rather than "filename", to macro_lookup_inclusion. This is the key thing to making the lookup work and macro printing work. Changes in the DWARF files are: - Make line_header::file_file_name return the "most complete possible" name. The only pre-existing user of this method is the macro code, to give the macro_source_file objects their name. And we now want them to have this "most complete possible" name, which will match the corresponding symtab's "filename_for_id". - Make dwarf2_cu::start_compunit_symtab pass the "most complete possible" name for the main symtab's "filename_for_id". In this context, where the info comes from the compilation unit's DW_AT_name / DW_AT_comp_dir, it means prepending DW_AT_comp_dir to DW_AT_name if DW_AT_name is not already absolute. - Change dwarf2_start_subfile to build a name_for_id for the subfile being started. The simplest way is to re-use line_header::file_file_name, since the callers always have a file_entry handy. This ensures that it will get the exact same path representation as the macro code does, for the same file (since it also uses line_header::file_file_name). - Update calls to allocate_symtab to pass the "name_for_id" from the subfile. Tests exercising all this are added by the following patch. Of all the cases I tried, the only one I found that ends up relying on watch_main_source_file_lossage is the following one: $ clang --version clang version 13.0.1 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin $ clang ./test.c -g3 -O0 -gdwarf-4 $ ./gdb -nx --data-directory=data-directory -q -readnow -iex "set debug symtab-create 1" a.out ... [symtab-create] start_subfile: name = test.c, name_for_id = /home/simark/build/binutils-gdb-one-target/gdb/test.c [symtab-create] start_subfile: name = ./test.c, name_for_id = /home/simark/build/binutils-gdb-one-target/gdb/./test.c [symtab-create] start_subfile: name = ./test.c, name_for_id = /home/simark/build/binutils-gdb-one-target/gdb/./test.c [symtab-create] start_subfile: found existing symtab with name_for_id /home/simark/build/binutils-gdb-one-target/gdb/./test.c (/home/simark/build/binutils-gdb-one-target/gdb/./test.c) [symtab-create] watch_main_source_file_lossage: using subfile ./test.c as the main subfile As we can see, there are two forms used for "test.c", one with a "." and one without. This comes from the fact that the compilation unit DIE contains: DW_AT_name ("test.c") DW_AT_comp_dir ("/home/simark/build/binutils-gdb-one-target/gdb") without a ".", and the line table for that file contains: include_directories[ 1] = "." file_names[ 1]: name: "test.c" dir_index: 1 When assembling the filename from that entry, we get a ".". It is a bit unexpected that the main filename resulting from the line table header does not match exactly the name in the compilation unit. For instance, gcc uses "./test.c" for the DW_AT_name, which gives identical paths in the compilation unit and in the line table header. Similarly, with DWARF 5: $ clang ./test.c -g3 -O0 -gdwarf-5 clang create two entries that refer to the same file but are of in a different form. include_directories[ 0] = "/home/simark/build/binutils-gdb-one-target/gdb" include_directories[ 1] = "." file_names[ 0]: name: "test.c" dir_index: 0 file_names[ 1]: name: "test.c" dir_index: 1 The first file name produces a path without a "." while the second does. This is not caught by watch_main_source_file_lossage, because of dwarf_decode_lines that creates a symtab for each file entry in the line table. It therefore appears as "non-empty" to watch_main_source_file_lossage. This results in two symtabs: (gdb) maintenance info symtabs { objfile /home/simark/build/binutils-gdb-one-target/gdb/a.out ((struct objfile *) 0x613000005d00) { ((struct compunit_symtab *) 0x62100011aca0) debugformat DWARF 5 producer clang version 13.0.1 name test.c dirname /home/simark/build/binutils-gdb-one-target/gdb blockvector ((struct blockvector *) 0x621000129ec0) user ((struct compunit_symtab *) (null)) { symtab test.c ((struct symtab *) 0x62100011ad20) fullname (null) linetable ((struct linetable *) 0x0) } { symtab ./test.c ((struct symtab *) 0x62100011ad60) fullname (null) linetable ((struct linetable *) 0x621000129ef0) } } } I am not sure what is the consequence of this, but this is also what happens before my patch, so I think its acceptable to leave it as-is. To handle these two cases nicely, I think we will need a function that removes the unnecessary "." from path names, something that can be done later. Finally, I made a change in find_file_and_directory is necessary to avoid breaking test gdb.dwarf2/dw2-compdir-oldgcc.exp: info source gcc42 Without that change, we would get: (gdb) info source Current source file is /dir/d/dw2-compdir-oldgcc42.S Compilation directory is /dir/d whereas the expected result is: (gdb) info source Current source file is dw2-compdir-oldgcc42.S Compilation directory is /dir/d This test was added here: https://sourceware.org/pipermail/gdb-patches/2012-November/098144.html Long story short, GCC <= 4.2 apparently had a bug where it would generate a DW_AT_name with a full path ("/dir/d/dw2-compdir-oldgcc42.S") and no DW_AT_comp_dir. The line table has one entry with filename "dw2-compdir-oldgcc42.S", which refers to directory 0. Directory 0 normally refers to the compilation unit's comp dir, but it is non-existent in this case. This caused some symtab lookup problems, and to work around them, some workaround was added, which today reads as: if (res.get_comp_dir () == nullptr && producer_is_gcc_lt_4_3 (cu) && res.get_name () != nullptr && IS_ABSOLUTE_PATH (res.get_name ())) res.set_comp_dir (ldirname (res.get_name ())); Source: https://gitlab.com/gnutools/binutils-gdb/-/blob/6577f365ebdee7dda71cb996efa29d3714cbccd0/gdb/dwarf2/read.c#L9428-9432 It extracts an artificial DW_AT_comp_dir from DW_AT_name, if there is no DW_AT_comp_dir and DW_AT_name is absolute. Prior to my patch, a subfile would get created with filename "/dir/d/dw2-compdir-oldgcc42.S", from DW_AT_name, and another would get created with filename "dw2-compdir-oldgcc42.S" from the line table's file table. Then watch_main_source_file_lossage would kick in and merge them, keeping only the "dw2-compdir-oldgcc42.S" one: [symtab-create] start_subfile: name = /dir/d/dw2-compdir-oldgcc42.S [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S [symtab-create] start_subfile: found existing symtab with name dw2-compdir-oldgcc42.S (dw2-compdir-oldgcc42.S) [symtab-create] watch_main_source_file_lossage: using subfile dw2-compdir-oldgcc42.S as the main subfile And so "info source" would show "dw2-compdir-oldgcc42.S" as the filename. With my patch applied, but without the change in find_file_and_directory, both DW_AT_name and the line table would try to start a subfile with the same filename_for_id, and there was no need for watch_main_source_file_lossage - which is what we want: [symtab-create] start_subfile: name = /dir/d/dw2-compdir-oldgcc42.S, name_for_id = /dir/d/dw2-compdir-oldgcc42.S [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S, name_for_id = /dir/d/dw2-compdir-oldgcc42.S [symtab-create] start_subfile: found existing symtab with name_for_id /dir/d/dw2-compdir-oldgcc42.S (/dir/d/dw2-compdir-oldgcc42.S) [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S, name_for_id = /dir/d/dw2-compdir-oldgcc42.S [symtab-create] start_subfile: found existing symtab with name_for_id /dir/d/dw2-compdir-oldgcc42.S (/dir/d/dw2-compdir-oldgcc42.S) But since the one with name == "/dir/d/dw2-compdir-oldgcc42.S", coming from DW_AT_name, gets created first, it wins, and the symtab ends up with "/dir/d/dw2-compdir-oldgcc42.S" as the name, "info source" shows "/dir/d/dw2-compdir-oldgcc42.S" and the test breaks. This is not wrong per-se, after all DW_AT_name is "/dir/d/dw2-compdir-oldgcc42.S", so it wouldn't be wrong to report the current source file as "/dir/d/dw2-compdir-oldgcc42.S". If you compile a file passing "/an/absolute/path.c", DW_AT_name typically contains (at least with GCC) "/an/absolute/path.c" and GDB tells you that the source file is "/an/absolute/path.c". But we can also keep the existing behavior fairly easily with a little change in find_file_and_directory. When extracting an artificial DW_AT_comp_dir from DW_AT_name, we now modify the name to just keep the file part. The result is coherent with what compilers do when you compile a file by just passing its filename ("gcc path.c -g"): DW_AT_name ("path.c") DW_AT_comp_dir ("/home/simark/build/binutils-gdb-one-target/gdb") With this change, filename_for_id is still the full name, "/dir/d/dw2-compdir-oldgcc42.S", but the filename of the subfile / symtab (what ends up shown by "info source") is just "dw2-compdir-oldgcc42.S", and that makes the test happy. Change-Id: I8b5cc4bb3052afdb172ee815c051187290566307
2022-07-29 00:34:47 +08:00
CORE_ADDR last_addr)
: buildsym_compunit (objfile_, name, comp_dir_, name, language_, last_addr)
{}
/* Reopen an existing compunit_symtab so that additional symbols can
be added to it. Arguments are as for the main constructor. CUST
is the expandable compunit_symtab to be reopened. */
buildsym_compunit (struct objfile *objfile_, const char *name,
const char *comp_dir_, enum language language_,
CORE_ADDR last_addr, struct compunit_symtab *cust)
: m_objfile (objfile_),
m_last_source_file (name == nullptr ? nullptr : xstrdup (name)),
m_comp_dir (comp_dir_ == nullptr ? "" : comp_dir_),
m_compunit_symtab (cust),
m_language (language_),
m_last_source_start_addr (last_addr)
{
}
~buildsym_compunit ();
DISABLE_COPY_AND_ASSIGN (buildsym_compunit);
void set_last_source_file (const char *name)
{
char *new_name = name == NULL ? NULL : xstrdup (name);
m_last_source_file.reset (new_name);
}
const char *get_last_source_file ()
{
return m_last_source_file.get ();
}
struct macro_table *get_macro_table ();
struct macro_table *release_macros ()
{
struct macro_table *result = m_pending_macros;
m_pending_macros = nullptr;
return result;
}
/* This function is called to discard any pending blocks. */
void free_pending_blocks ()
{
m_pending_block_obstack.clear ();
m_pending_blocks = nullptr;
}
struct block *finish_block (struct symbol *symbol,
struct pending_block *old_blocks,
const struct dynamic_prop *static_link,
CORE_ADDR start, CORE_ADDR end);
void record_block_range (struct block *block,
CORE_ADDR start, CORE_ADDR end_inclusive);
gdb: add "id" fields to identify symtabs and subfiles Printing macros defined in the main source file doesn't work reliably using various toolchains, especially when DWARF 5 is used. For example, using the binaries produced by either of these commands: $ gcc --version gcc (GCC) 11.2.0 $ ld --version GNU ld (GNU Binutils) 2.38 $ gcc test.c -g3 -gdwarf-5 $ clang --version clang version 13.0.1 $ clang test.c -gdwarf-5 -fdebug-macro I get: $ ./gdb -nx -q --data-directory=data-directory a.out (gdb) start Temporary breakpoint 1 at 0x111d: file test.c, line 6. Starting program: /home/simark/build/binutils-gdb-one-target/gdb/a.out Temporary breakpoint 1, main () at test.c:6 6 return ZERO; (gdb) p ZERO No symbol "ZERO" in current context. When starting to investigate this (taking the gcc-compiled binary as an example), we see that GDB fails to look up the appropriate macro scope when evaluating the expression. While stopped in macro_lookup_inclusion: (top-gdb) p name $1 = 0x62100011a980 "test.c" (top-gdb) p source.filename $2 = 0x62100011a9a0 "/home/simark/build/binutils-gdb-one-target/gdb/test.c" `source` is the macro_source_file that we would expect GDB to find. `name` comes from the symtab::filename field of the symtab we are stopped in. GDB doesn't find the appropriate macro_source_file because the name of the macro_source_file doesn't match exactly the name of the symtab. The name of the main symtab comes from the compilation unit's DW_AT_name, passed to the buildsym_compunit's constructor: https://gitlab.com/gnutools/binutils-gdb/-/blob/4815d6125ec580cc02a1094d61b8c9d1cc83c0a1/gdb/dwarf2/read.c#L10627-10630 The contents of DW_AT_name, in this case, is "test.c". It is typically (what I witnessed all compilers do) the same string that was passed to the compiler on the command-line. The name of the macro_source_file comes from the line number program header's file table, from the call to the line_header::file_file_name method: https://gitlab.com/gnutools/binutils-gdb/-/blob/4815d6125ec580cc02a1094d61b8c9d1cc83c0a1/gdb/dwarf2/macro.c#L54-65 line_header::file_file_name prepends the directory path that the file entry refers to, in the file table (if the file name is not already absolute). In this case, the file name is "test.c", appended to the directory "/home/simark/build/binutils-gdb-one-target/gdb". Because the symtab's name is not created the same way as the macro_source_file's name is created, we get this mismatch. GDB fails to find the appropriate macro scope for the symtab, and we can't print macros when stopped in that symtab. To make this work, we must ensure that paths produced in these two ways end up identical. This can be tricky because of the different ways a path can be passed to the compiler by the user. Another thing to consider is that while the main symtab's name (or subfile, before it becomes a symtab) is created using DW_AT_name, the main symtab is also referred to using its entry in the line table header's file table, when processing the line table. We must therefore ensure that the same name is produced in both cases, so that a call to "start_subfile" for the main subfile will correctly find the already-created subfile, created by buildsym_compunit's constructor. If we fail to do that, things still often work, because of a fallback: the watch_main_source_file_lossage method. This method determines that if the main subfile has no symbols but there exists another subfile with the same basename (e.g. "test.c") that does have symbols, it's probably because there was some filename mismatch. So it replaces the main subfile with that other subfile. I think that heuristic is useful as a last effort to work around any bug or bad debug info, but I don't think we should design things such as to rely on it. It's a heuristic, it can get things wrong. So in my search for a fix, it is important that given some good debug info, we don't end up relying on that for things to work. A first attempt at fixing this was to try to prepend the compilation directory here or not prepend it there. In practice, because of all the possible combinations of debug info the compilers produce, it was not possible to get something that would produce reliable, consistent paths. Another attempt at fixing this was to make both macro_source_file objects and symtab objects use the most complete form of path possible. That means to prepend directories at least until we get an absolute path. In theory, we should end up with the same path in all cases. This generally worked, but because it changed the symtab names, it resulted in user-visible changes (for example, paths to source files in Breakpoint hit messages becoming always absolute). I didn't find this very good, first because there is a "set filename-display" setting that lets the user control how they want the paths to be displayed, and that would suddenly make this setting completely ineffective (although even today, it is a bit dependent on the debug info). Second, it would require a good amount of testsuite tweaks to make tests accept these suddenly absolute paths. This new patch is a slight variation of that: it adds a new field called "filename_for_id" in struct symtab and struct subfile, next to the existing filename field. The goal is to separate the internal ids used for finding objects from the names used for presentation. This field is used for identifying subfiles, symtabs and macro_source_files internally. For DWARF symtabs, this new field is meant to contain the "most complete possible" path, as discussed above. So for a given file, it must always be in the same form, everywhere. The existing symtab::filename field remains the one used for printing to the user, so there shouldn't be any change in how paths are printed. Changes in the core symtab files are: - Add "name_for_id" and "filename_for_id" fields to "struct subfile" and "struct symtab", next to existing "name" and "filename" fields. - Make buildsym_compunit::buildsym_compunit and buildsym_compunit::start_subfile accept a "name_for_id" parameter next to the existing "name" ones. - Make buildsym_compunit::start_subfile use "name_for_id" for looking up existing subfiles. This is the key thing for making calls to start_subfile for the main source file look up the existing subfile successfully, and avoid relying on watch_main_source_file_lossage. - Make sal_macro_scope pass "filename_for_id", rather than "filename", to macro_lookup_inclusion. This is the key thing to making the lookup work and macro printing work. Changes in the DWARF files are: - Make line_header::file_file_name return the "most complete possible" name. The only pre-existing user of this method is the macro code, to give the macro_source_file objects their name. And we now want them to have this "most complete possible" name, which will match the corresponding symtab's "filename_for_id". - Make dwarf2_cu::start_compunit_symtab pass the "most complete possible" name for the main symtab's "filename_for_id". In this context, where the info comes from the compilation unit's DW_AT_name / DW_AT_comp_dir, it means prepending DW_AT_comp_dir to DW_AT_name if DW_AT_name is not already absolute. - Change dwarf2_start_subfile to build a name_for_id for the subfile being started. The simplest way is to re-use line_header::file_file_name, since the callers always have a file_entry handy. This ensures that it will get the exact same path representation as the macro code does, for the same file (since it also uses line_header::file_file_name). - Update calls to allocate_symtab to pass the "name_for_id" from the subfile. Tests exercising all this are added by the following patch. Of all the cases I tried, the only one I found that ends up relying on watch_main_source_file_lossage is the following one: $ clang --version clang version 13.0.1 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin $ clang ./test.c -g3 -O0 -gdwarf-4 $ ./gdb -nx --data-directory=data-directory -q -readnow -iex "set debug symtab-create 1" a.out ... [symtab-create] start_subfile: name = test.c, name_for_id = /home/simark/build/binutils-gdb-one-target/gdb/test.c [symtab-create] start_subfile: name = ./test.c, name_for_id = /home/simark/build/binutils-gdb-one-target/gdb/./test.c [symtab-create] start_subfile: name = ./test.c, name_for_id = /home/simark/build/binutils-gdb-one-target/gdb/./test.c [symtab-create] start_subfile: found existing symtab with name_for_id /home/simark/build/binutils-gdb-one-target/gdb/./test.c (/home/simark/build/binutils-gdb-one-target/gdb/./test.c) [symtab-create] watch_main_source_file_lossage: using subfile ./test.c as the main subfile As we can see, there are two forms used for "test.c", one with a "." and one without. This comes from the fact that the compilation unit DIE contains: DW_AT_name ("test.c") DW_AT_comp_dir ("/home/simark/build/binutils-gdb-one-target/gdb") without a ".", and the line table for that file contains: include_directories[ 1] = "." file_names[ 1]: name: "test.c" dir_index: 1 When assembling the filename from that entry, we get a ".". It is a bit unexpected that the main filename resulting from the line table header does not match exactly the name in the compilation unit. For instance, gcc uses "./test.c" for the DW_AT_name, which gives identical paths in the compilation unit and in the line table header. Similarly, with DWARF 5: $ clang ./test.c -g3 -O0 -gdwarf-5 clang create two entries that refer to the same file but are of in a different form. include_directories[ 0] = "/home/simark/build/binutils-gdb-one-target/gdb" include_directories[ 1] = "." file_names[ 0]: name: "test.c" dir_index: 0 file_names[ 1]: name: "test.c" dir_index: 1 The first file name produces a path without a "." while the second does. This is not caught by watch_main_source_file_lossage, because of dwarf_decode_lines that creates a symtab for each file entry in the line table. It therefore appears as "non-empty" to watch_main_source_file_lossage. This results in two symtabs: (gdb) maintenance info symtabs { objfile /home/simark/build/binutils-gdb-one-target/gdb/a.out ((struct objfile *) 0x613000005d00) { ((struct compunit_symtab *) 0x62100011aca0) debugformat DWARF 5 producer clang version 13.0.1 name test.c dirname /home/simark/build/binutils-gdb-one-target/gdb blockvector ((struct blockvector *) 0x621000129ec0) user ((struct compunit_symtab *) (null)) { symtab test.c ((struct symtab *) 0x62100011ad20) fullname (null) linetable ((struct linetable *) 0x0) } { symtab ./test.c ((struct symtab *) 0x62100011ad60) fullname (null) linetable ((struct linetable *) 0x621000129ef0) } } } I am not sure what is the consequence of this, but this is also what happens before my patch, so I think its acceptable to leave it as-is. To handle these two cases nicely, I think we will need a function that removes the unnecessary "." from path names, something that can be done later. Finally, I made a change in find_file_and_directory is necessary to avoid breaking test gdb.dwarf2/dw2-compdir-oldgcc.exp: info source gcc42 Without that change, we would get: (gdb) info source Current source file is /dir/d/dw2-compdir-oldgcc42.S Compilation directory is /dir/d whereas the expected result is: (gdb) info source Current source file is dw2-compdir-oldgcc42.S Compilation directory is /dir/d This test was added here: https://sourceware.org/pipermail/gdb-patches/2012-November/098144.html Long story short, GCC <= 4.2 apparently had a bug where it would generate a DW_AT_name with a full path ("/dir/d/dw2-compdir-oldgcc42.S") and no DW_AT_comp_dir. The line table has one entry with filename "dw2-compdir-oldgcc42.S", which refers to directory 0. Directory 0 normally refers to the compilation unit's comp dir, but it is non-existent in this case. This caused some symtab lookup problems, and to work around them, some workaround was added, which today reads as: if (res.get_comp_dir () == nullptr && producer_is_gcc_lt_4_3 (cu) && res.get_name () != nullptr && IS_ABSOLUTE_PATH (res.get_name ())) res.set_comp_dir (ldirname (res.get_name ())); Source: https://gitlab.com/gnutools/binutils-gdb/-/blob/6577f365ebdee7dda71cb996efa29d3714cbccd0/gdb/dwarf2/read.c#L9428-9432 It extracts an artificial DW_AT_comp_dir from DW_AT_name, if there is no DW_AT_comp_dir and DW_AT_name is absolute. Prior to my patch, a subfile would get created with filename "/dir/d/dw2-compdir-oldgcc42.S", from DW_AT_name, and another would get created with filename "dw2-compdir-oldgcc42.S" from the line table's file table. Then watch_main_source_file_lossage would kick in and merge them, keeping only the "dw2-compdir-oldgcc42.S" one: [symtab-create] start_subfile: name = /dir/d/dw2-compdir-oldgcc42.S [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S [symtab-create] start_subfile: found existing symtab with name dw2-compdir-oldgcc42.S (dw2-compdir-oldgcc42.S) [symtab-create] watch_main_source_file_lossage: using subfile dw2-compdir-oldgcc42.S as the main subfile And so "info source" would show "dw2-compdir-oldgcc42.S" as the filename. With my patch applied, but without the change in find_file_and_directory, both DW_AT_name and the line table would try to start a subfile with the same filename_for_id, and there was no need for watch_main_source_file_lossage - which is what we want: [symtab-create] start_subfile: name = /dir/d/dw2-compdir-oldgcc42.S, name_for_id = /dir/d/dw2-compdir-oldgcc42.S [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S, name_for_id = /dir/d/dw2-compdir-oldgcc42.S [symtab-create] start_subfile: found existing symtab with name_for_id /dir/d/dw2-compdir-oldgcc42.S (/dir/d/dw2-compdir-oldgcc42.S) [symtab-create] start_subfile: name = dw2-compdir-oldgcc42.S, name_for_id = /dir/d/dw2-compdir-oldgcc42.S [symtab-create] start_subfile: found existing symtab with name_for_id /dir/d/dw2-compdir-oldgcc42.S (/dir/d/dw2-compdir-oldgcc42.S) But since the one with name == "/dir/d/dw2-compdir-oldgcc42.S", coming from DW_AT_name, gets created first, it wins, and the symtab ends up with "/dir/d/dw2-compdir-oldgcc42.S" as the name, "info source" shows "/dir/d/dw2-compdir-oldgcc42.S" and the test breaks. This is not wrong per-se, after all DW_AT_name is "/dir/d/dw2-compdir-oldgcc42.S", so it wouldn't be wrong to report the current source file as "/dir/d/dw2-compdir-oldgcc42.S". If you compile a file passing "/an/absolute/path.c", DW_AT_name typically contains (at least with GCC) "/an/absolute/path.c" and GDB tells you that the source file is "/an/absolute/path.c". But we can also keep the existing behavior fairly easily with a little change in find_file_and_directory. When extracting an artificial DW_AT_comp_dir from DW_AT_name, we now modify the name to just keep the file part. The result is coherent with what compilers do when you compile a file by just passing its filename ("gcc path.c -g"): DW_AT_name ("path.c") DW_AT_comp_dir ("/home/simark/build/binutils-gdb-one-target/gdb") With this change, filename_for_id is still the full name, "/dir/d/dw2-compdir-oldgcc42.S", but the filename of the subfile / symtab (what ends up shown by "info source") is just "dw2-compdir-oldgcc42.S", and that makes the test happy. Change-Id: I8b5cc4bb3052afdb172ee815c051187290566307
2022-07-29 00:34:47 +08:00
/* Start recording information about source code that comes from a source
file. This sets the current subfile, creating it if necessary.
NAME is the user-visible name of the subfile.
NAME_FOR_ID is a name that must be stable between the different calls to
start_subfile referring to the same file (it is used for looking up
existing subfiles). It can be equal to NAME if NAME follows that rule. */
void start_subfile (const char *name, const char *name_for_id);
/* Same as above, but passes NAME for NAME_FOR_ID. */
void start_subfile (const char *name)
{
return start_subfile (name, name);
}
void patch_subfile_names (struct subfile *subfile, const char *name);
void push_subfile ();
const char *pop_subfile ();
gdb: Add support for tracking the DWARF line table is-stmt field This commit brings support for the DWARF line table is_stmt field to GDB. The is_stmt field is used by the compiler when a single source line is split into multiple assembler instructions, especially if the assembler instructions are interleaved with instruction from other source lines. The compiler will set the is_stmt flag false from some instructions from the source lines, these instructions are not a good place to insert a breakpoint in order to stop at the source line. Instructions which are marked with the is_stmt flag true are a good place to insert a breakpoint for that source line. Currently GDB ignores all instructions for which is_stmt is false. This is fine in a lot of cases, however, there are some cases where this means the debug experience is not as good as it could be. Consider stopping at a random instruction, currently this instruction will be attributed to the last line table entry before this point for which is_stmt was true - as these are the only line table entries that GDB tracks. This can easily be incorrect in code with even a low level of optimisation. With is_stmt tracking in place, when stopping at a random instruction we now attribute the instruction back to the real source line, even when is_stmt is false for that instruction in the line table. When inserting breakpoints we still select line table entries for which is_stmt is true, so the breakpoint placing behaviour should not change. When stepping though code (at the line level, not the instruction level) we will still stop at instruction where is_stmt is true, I think this is more likely to be the desired behaviour. Instruction stepping is, of course, unchanged, stepping one instruction at a time, but we should now report more accurate line table information with each instruction step. The original motivation for this work was a patch posted by Bernd here: https://sourceware.org/ml/gdb-patches/2019-11/msg00792.html As part of that thread it was suggested that many issues would be resolved if GDB supported line table views, this isn't something I've attempted in this patch, though reading the spec, it seems like this would be a useful feature to support in GDB in the future. The spec is here: http://dwarfstd.org/ShowIssue.php?issue=170427.1 And Bernd gives a brief description of the benefits here: https://sourceware.org/ml/gdb-patches/2020-01/msg00147.html With that all said, I think that there is benefit to having proper is_stmt support regardless of whether we have views support, so I think we should consider getting this in first, and then building view support on top of this. The gdb.cp/step-and-next-inline.exp test is based off a test proposed by Bernd Edlinger in this message: https://sourceware.org/ml/gdb-patches/2019-12/msg00842.html gdb/ChangeLog: * buildsym-legacy.c (record_line): Pass extra parameter to record_line. * buildsym.c (buildsym_compunit::record_line): Take an extra parameter, reduce duplication in the line table, and record the is_stmt flag in the line table. * buildsym.h (buildsym_compunit::record_line): Add extra parameter. * disasm.c (do_mixed_source_and_assembly_deprecated): Ignore non-statement lines. * dwarf2/read.c (dwarf_record_line_1): Add extra parameter, pass this to the symtab builder. (dwarf_finish_line): Pass extra parameter to dwarf_record_line_1. (lnp_state_machine::record_line): Pass a suitable is_stmt flag through to dwarf_record_line_1. * infrun.c (process_event_stop_test): When stepping, don't stop at a non-statement instruction, and only refresh the step info when we land in the middle of a line's range. Also add an extra comment. * jit.c (jit_symtab_line_mapping_add_impl): Initialise is_stmt field. * record-btrace.c (btrace_find_line_range): Only record lines marked as is-statement. * stack.c (frame_show_address): Show the frame address if we are in a non-statement sal. * symmisc.c (dump_symtab_1): Print the is_stmt flag. (maintenance_print_one_line_table): Print a header for the is_stmt column, and include is_stmt information in the output. * symtab.c (find_pc_sect_line): Find lines marked as statements in preference to non-statements. (find_pcs_for_symtab_line): Prefer is-statement entries. (find_line_common): Likewise. * symtab.h (struct linetable_entry): Add is_stmt field. (struct symtab_and_line): Likewise. * xcoffread.c (arrange_linetable): Initialise is_stmt field when arranging the line table. gdb/testsuite/ChangeLog: * gdb.cp/step-and-next-inline.cc: New file. * gdb.cp/step-and-next-inline.exp: New file. * gdb.cp/step-and-next-inline.h: New file. * gdb.dwarf2/dw2-is-stmt.c: New file. * gdb.dwarf2/dw2-is-stmt.exp: New file. * gdb.dwarf2/dw2-is-stmt-2.c: New file. * gdb.dwarf2/dw2-is-stmt-2.exp: New file. * gdb.dwarf2/dw2-ranges-base.exp: Update line table pattern.
2019-12-31 05:04:51 +08:00
void record_line (struct subfile *subfile, int line, CORE_ADDR pc,
linetable_entry_flags flags);
struct compunit_symtab *get_compunit_symtab ()
{
return m_compunit_symtab;
}
void set_last_source_start_addr (CORE_ADDR addr)
{
m_last_source_start_addr = addr;
}
CORE_ADDR get_last_source_start_addr ()
{
return m_last_source_start_addr;
}
struct using_direct **get_local_using_directives ()
{
return &m_local_using_directives;
}
void set_local_using_directives (struct using_direct *new_local)
{
m_local_using_directives = new_local;
}
struct using_direct **get_global_using_directives ()
{
return &m_global_using_directives;
}
bool outermost_context_p () const
{
return m_context_stack.empty ();
}
struct context_stack *get_current_context_stack ()
{
if (m_context_stack.empty ())
return nullptr;
return &m_context_stack.back ();
}
int get_context_stack_depth () const
{
return m_context_stack.size ();
}
struct subfile *get_current_subfile ()
{
return m_current_subfile;
}
struct pending **get_local_symbols ()
{
return &m_local_symbols;
}
struct pending **get_file_symbols ()
{
return &m_file_symbols;
}
struct pending **get_global_symbols ()
{
return &m_global_symbols;
}
void record_debugformat (const char *format)
{
m_debugformat = format;
}
void record_producer (const char *producer)
{
m_producer = producer;
}
struct context_stack *push_context (int desc, CORE_ADDR valu);
struct context_stack pop_context ();
struct block *end_compunit_symtab_get_static_block
(CORE_ADDR end_addr, int expandable, int required);
struct compunit_symtab *end_compunit_symtab_from_static_block
(struct block *static_block, int section, int expandable);
struct compunit_symtab *end_compunit_symtab (CORE_ADDR end_addr, int section);
struct compunit_symtab *end_expandable_symtab (CORE_ADDR end_addr,
int section);
void augment_type_symtab ();
private:
void record_pending_block (struct block *block, struct pending_block *opblock);
struct block *finish_block_internal (struct symbol *symbol,
struct pending **listhead,
struct pending_block *old_blocks,
const struct dynamic_prop *static_link,
CORE_ADDR start, CORE_ADDR end,
int is_global, int expandable);
struct blockvector *make_blockvector ();
void watch_main_source_file_lossage ();
struct compunit_symtab *end_compunit_symtab_with_blockvector
(struct block *static_block, int section, int expandable);
/* The objfile we're reading debug info from. */
struct objfile *m_objfile;
/* List of subfiles (source files).
Files are added to the front of the list.
This is important mostly for the language determination hacks we use,
which iterate over previously added files. */
struct subfile *m_subfiles = nullptr;
/* The subfile of the main source file. */
struct subfile *m_main_subfile = nullptr;
/* Name of source file whose symbol data we are now processing. This
comes from a symbol of type N_SO for stabs. For DWARF it comes
from the DW_AT_name attribute of a DW_TAG_compile_unit DIE. */
gdb::unique_xmalloc_ptr<char> m_last_source_file;
/* E.g., DW_AT_comp_dir if DWARF. Space for this is malloc'd. */
std::string m_comp_dir;
/* Space for this is not malloc'd, and is assumed to have at least
the same lifetime as objfile. */
const char *m_producer = nullptr;
/* Space for this is not malloc'd, and is assumed to have at least
the same lifetime as objfile. */
const char *m_debugformat = nullptr;
/* The compunit we are building. */
struct compunit_symtab *m_compunit_symtab = nullptr;
/* Language of this compunit_symtab. */
enum language m_language;
/* The macro table for the compilation unit whose symbols we're
currently reading. */
struct macro_table *m_pending_macros = nullptr;
/* True if symtab has line number info. This prevents an otherwise
empty symtab from being tossed. */
bool m_have_line_numbers = false;
/* Core address of start of text of current source file. This too
comes from the N_SO symbol. For Dwarf it typically comes from the
DW_AT_low_pc attribute of a DW_TAG_compile_unit DIE. */
CORE_ADDR m_last_source_start_addr;
/* Stack of subfile names. */
std::vector<const char *> m_subfile_stack;
/* The "using" directives local to lexical context. */
struct using_direct *m_local_using_directives = nullptr;
/* Global "using" directives. */
struct using_direct *m_global_using_directives = nullptr;
/* The stack of contexts that are pushed by push_context and popped
by pop_context. */
std::vector<struct context_stack> m_context_stack;
struct subfile *m_current_subfile = nullptr;
/* The mutable address map for the compilation unit whose symbols
we're currently reading. The symtabs' shared blockvector will
point to a fixed copy of this. */
struct addrmap_mutable m_pending_addrmap;
/* True if we recorded any ranges in the addrmap that are different
from those in the blockvector already. We set this to false when
we start processing a symfile, and if it's still false at the
end, then we just toss the addrmap. */
bool m_pending_addrmap_interesting = false;
/* An obstack used for allocating pending blocks. */
auto_obstack m_pending_block_obstack;
/* Pointer to the head of a linked list of symbol blocks which have
already been finalized (lexical contexts already closed) and which
are just waiting to be built into a blockvector when finalizing the
associated symtab. */
struct pending_block *m_pending_blocks = nullptr;
/* Pending static symbols and types at the top level. */
struct pending *m_file_symbols = nullptr;
/* Pending global functions and variables. */
struct pending *m_global_symbols = nullptr;
/* Pending symbols that are local to the lexical context. */
struct pending *m_local_symbols = nullptr;
};
extern void add_symbol_to_list (struct symbol *symbol,
struct pending **listhead);
extern struct symbol *find_symbol_in_list (struct pending *list,
char *name, int length);
#endif /* defined (BUILDSYM_H) */