aboutsummaryrefslogtreecommitdiff
path: root/gdb/symmisc.c
AgeCommit message (Collapse)AuthorFilesLines
2024-03-26gdb, gdbserver, gdbsupport: remove includes of early headersSimon Marchi1-1/+0
Now that defs.h, server.h and common-defs.h are included via the `-include` option, it is no longer necessary for source files to include them. Remove all the inclusions of these files I could find. Update the generation scripts where relevant. Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837 Approved-By: Pedro Alves <pedro@palves.net>
2024-02-01Rename SEARCH_ALLTom Tromey1-1/+1
The constant SEARCH_ALL conflicts with a define in a Windows header. This patch renames the constant to SEARCH_ALL_DOMAINS to avoid the conflict. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31307
2024-01-28Use domain_search_flags in lookup_global_symbol_languageTom Tromey1-1/+0
This changes quick_symbol_functions::lookup_global_symbol_language to accept domain_search_flags rather than just a domain_enum, and fixes up the fallout. To avoid introducing any regressions, any code passing VAR_DOMAIN now uses SEARCH_VFT. That is, no visible changes should result from this patch. However, it sets the stage to refine some searches later on.
2024-01-28Replace search_domain with domain_search_flagsTom Tromey1-1/+1
This patch changes gdb to replace search_domain with domain_search_flags everywhere. search_domain is removed.
2024-01-12Update copyright year range in header of all files managed by GDBAndrew Burgess1-1/+1
This commit is the result of the following actions: - Running gdb/copyright.py to update all of the copyright headers to include 2024, - Manually updating a few files the copyright.py script told me to update, these files had copyright headers embedded within the file, - Regenerating gdbsupport/Makefile.in to refresh it's copyright date, - Using grep to find other files that still mentioned 2023. If these files were updated last year from 2022 to 2023 then I've updated them this year to 2024. I'm sure I've probably missed some dates. Feel free to fix them up as you spot them.
2024-01-02gdb/dwarf2: Add support for DW_LNS_set_epilogue_begin in line-tableGuinevere Larsen1-1/+3
This commit adds a mechanism for GDB to detect the linetable opcode DW_LNS_set_epilogue_begin. This opcode is set by compilers to indicate that a certain instruction marks the point where the frame is destroyed. While the standard allows for multiple points marked with epilogue_begin in the same function, for performance reasons, the function that searches for the epilogue address will only find the last address that sets this flag for a given block. This commit also changes amd64_stack_frame_destroyed_p_1 to attempt to use the epilogue begin directly, and only if an epilogue can't be found will it attempt heuristics based on the current instruction. Finally, this commit also changes the dwarf assembler to be able to emit epilogue-begin instructions, to make it easier to test this patch Approved-By: Tom Tromey <tom@tromey.com>
2023-08-14[gdb] Fix maint print symbols/psymbols help textTom de Vries1-2/+2
Consider the help text of "maint print symbols": ... (gdb) help maint print symbols Print dump of current symbol definitions. Usage: mt print symbols [-pc ADDRESS] [--] [OUTFILE] mt print symbols [-objfile OBJFILE] [-source SOURCE] [--] [OUTFILE] Entries in the full symbol table are dumped to file OUTFILE, or the terminal if OUTFILE is unspecified. If ADDRESS is provided, dump only the file for that address. If SOURCE is provided, dump only that file's symbols. If OBJFILE is provided, dump only that file's minimal symbols. ... and "maint print psymbols": ... (gdb) help maint print psymbols Print dump of current partial symbol definitions. Usage: mt print psymbols [-objfile OBJFILE] [-pc ADDRESS] [--] [OUTFILE] mt print psymbols [-objfile OBJFILE] [-source SOURCE] [--] [OUTFILE] Entries in the partial symbol table are dumped to file OUTFILE, or the terminal if OUTFILE is unspecified. If ADDRESS is provided, dump only the file for that address. If SOURCE is provided, dump only that file's symbols. If OBJFILE is provided, dump only that file's minimal symbols. ... The OBJFILE lines mistakingly mention minimal symbols. Fix this by reformulating as "dump only that object file's symbols". Also make the ADDRESS lines more clear by using the formulation: "dump only the symbols for the file with code at that address". Tested on x86_64-linux. Co-Authored-By: Eli Zaretskii <eliz@gnu.org> PR gdb/30742 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30742
2023-07-04gdb: have mdict_size always return a symbol countAndrew Burgess1-1/+1
In the next commit we would like to have mdict_size return the number of symbols in the dictionary, currently mdict_size is just a heuristic, sometimes it returns the number of symbols, and sometimes the number of buckets in a hashing dictionary (see size_hashed in dictionary.c). Currently this vague notion of size is good enough, the only place mdict_size is used is in a maintenance command in order to print a message containing the size of the dictionary ... so we don't really care that the value isn't correct. However, in the next commit we do want the size returned to be the number of symbols in the dictionary, so this commit makes mdict_size return the symbol count in all cases. The new use is still not on a hot path -- it's going to be a Python __repr__ method, so all I do in this commit is have size_hashed walk the dictionary and count the entries, obviously this could be slow if we have a large number of symbols, but for now I'm not worrying about that case. We could always store the symbol count if we wanted, but that would increase the size of every dictionary for a use case that isn't going to be hit that often. I've updated the text in 'maint print symbols' so that we don't talk about the size being 'syms/buckets', but just 'symbols' now.
2023-06-05Use "unrelocated" terminology in linetable_entryTom Tromey1-1/+1
I forgot to convert struct linetable_entry to use the "unrelocated" (as opposed to "raw") terminology. This patch corrects the oversight.
2023-05-07Remove ALL_DICT_SYMBOLSTom Tromey1-3/+1
This replaces ALL_DICT_SYMBOLS with an iterator so that for-each can be used.
2023-05-07Rename objfile::sectionsTom Tromey1-1/+1
I think objfile::sections makes sense as the name of the method to iterate over an objfile's sections, so this patch renames the existing field to objfile::sections_start in preparation for that.
2023-04-21gdb: remove language_autoSimon Marchi1-2/+1
I think that the language_auto enumerator and the auto_language class can be removed. There isn't really an "auto" language, it's only a construct of the "set language" command to say "pick the appropriate language automatically". But "auto" is never the current language. The `current_language` points to the current effective language, and the fact that we're in "auto language" mode is noted by the language_mode global. - Change set_language to handle the "auto" (and "local", which is a synonym) early, instead of in the for loop. I think it makes the two cases (auto vs explicit language) more clearly separated anyway. - Adjust add_set_language_command to hard-code the "auto" string, instead of using the "auto" language definition. - Remove auto_language, rename auto_or_unknown_language to unknown_language and move the bits of the existing unknown_language in there. - Remove the set_language at the end of _initialize_language. I think it's not needed, because we call set_language in gdb_init, after all _initialize functions are called. There is some chance that an _initialize function that runs after _initialize_language implicitly depends on current_language being set, but my testsuite runs haven't found anything like that. - Use language_unknown instead of language_auto when creating a minimal symbol (minimal_symbol_reader::record_full). I think that this value is used to indicate that we don't know the symbol of the minimal symbol (yet), so language_unknown makes sense to me. Update a condition accordingly in ada-lang.c. symbol_find_demangled_name also appears to "normalize" this value from "unknown" to "auto", remove that part and update the condition to just check for language_unknown. Change-Id: I47bcd6c15f607d9818f2e6e413053c2dc8ec5034 Reviewed-By: Tom Tromey <tom@tromey.com>
2023-03-28Rename "raw" to "unrelocated"Tom Tromey1-1/+1
Per an earlier discussion, this patch renames the existing "raw" APIs to use the word "unrelocated" instead.
2023-03-28Use unrelocated_addr in minimal symbolsTom Tromey1-1/+1
This changes minimal symbols to use unrelocated_addr. I believe this detected a latent bug in add_pe_forwarded_sym.
2023-03-21gdb: make "maintenance info line-table" show relocated addresses againSimon Marchi1-3/+6
Commit 1acc9dca423f ("Change linetables to be objfile-independent") changed "maintenance info line-table" to print unrelocated addresses instead of relocated. This breaks a few tests on systems where that matters. The ones I see are: Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/consecutive.exp ... FAIL: gdb.base/consecutive.exp: stopped at bp, 2nd instr (missing hex prefix) Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/async.exp ... FAIL: gdb.base/async.exp: stepi& FAIL: gdb.base/async.exp: nexti& FAIL: gdb.base/async.exp: finish& These tests run "maintenance info line-table" to record the address of some lines, and then use these addresses in expected patterns. It therefore expects these addresses to match the runtime addresses, therefore the relocated addresses. Add back the relocated addresses, next to the unrelocated addresses, like so: INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END 0 6 0x0000555555555119 0x0000000000001119 Y 1 7 0x000055555555511d 0x000000000000111d Y 2 8 0x0000555555555123 0x0000000000001123 Y 3 END 0x0000555555555125 0x0000000000001125 Y The unrelocated addresses can always be useful trying to map this information with a DWARF info dump. Adjust the is_stmt_addresses proc in the testsuite to match the new output. Change-Id: I59558f167e13e63421c9e0f2cad192e7c95c10cf
2023-03-17Fix line table regressionTom Tromey1-1/+1
Simon pointed out a line table regression, and after a couple of false starts, I was able to reproduce it by hand using his instructions. The bug is that most of the code in do_mixed_source_and_assembly uses unrelocated addresses, but one spot does: pc = low; ... after the text offset has been removed. This patch fixes the problem by introducing a new type to represent unrelocated addresses in the line table. This prevents this sort of bug to some degree (it's still possible to manipulate a CORE_ADDR in a bad way, this is unavoidable). However, this did let the compiler flag a few spots in that function, and now it's not possible to compare an unrelocated address from a line table with an ordinary CORE_ADDR. Regression tested on x86-64 Fedora 36, though note this setup never reproduced the bug in the first place. I also tested it by hand on the disasm-optim test program.
2023-03-11Constify linetablesTom Tromey1-3/+3
Linetables no longer change after they are created. This patch applies const to them. Note there is one hack to cast away const in mdebugread.c. This code allocates a linetable using 'malloc', then later copies it to the obstack. While this could be cleaned up, I chose not to do so because I have no way of testing it. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-11Change linetables to be objfile-independentTom Tromey1-2/+2
This changes linetables to not add the text offset to the addresses they contain. I did this in a few steps, necessarily combined together in one patch: I renamed the 'pc' member to 'm_pc', added the appropriate accessors, and then recompiled. Then I fixed all the errors. Where possible I generally chose to use the raw_pc accessor, as it is less expensive. Note that this patch discounts the possibility that the text section offset might cause wraparound in the addresses in the line table. However, this was already discounted -- in particular, objfile_relocate1 did not re-sort the table in this scenario. (There was a bug open about this, but as far as I can tell this has never happened, it's not even clear what inspired that bug.) Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-01Update copyright year range in header of all files managed by GDBJoel Brobecker1-1/+1
This commit is the result of running the gdb/copyright.py script, which automated the update of the copyright year range for all source files managed by the GDB project to be updated to include year 2023.
2022-09-21gdb: remove TYPE_LENGTHSimon Marchi1-2/+2
Remove the macro, replace all uses with calls to type::length. Change-Id: Ib9bdc954576860b21190886534c99103d6a47afb
2022-08-03Use gdb_bfd_ref_ptr in objfileTom Tromey1-1/+1
This changes struct objfile to use a gdb_bfd_ref_ptr. In addition to removing some manual memory management, this fixes a use-after-free that was introduced by the registry rewrite series. The issue there was that, in some cases, registry shutdown could refer to memory that had already been freed. This help fix the bug by delaying the destruction of the BFD reference (and thus the per-bfd object) until after the registry has been shut down.
2022-04-27gdb: remove BLOCKVECTOR_BLOCK and BLOCKVECTOR_NBLOCKS macrosSimon Marchi1-11/+6
Replace with calls to blockvector::blocks, and the appropriate method call on the returned array_view. Change-Id: I04d1f39603e4d4c21c96822421431d9a029d8ddd
2022-04-27gdb: remove BLOCK_MULTIDICT macroSimon Marchi1-2/+2
Replace with equivalent methods. Change-Id: If9a239c511a664f2a59fecb6d1cd579881b23dc2
2022-04-27gdb: remove BLOCK_SUPERBLOCK macroSimon Marchi1-3/+3
Replace with equivalent methods. Change-Id: I334a319909a50b5cc5570a45c38c70e10dc00630
2022-04-27gdb: remove BLOCK_FUNCTION macroSimon Marchi1-4/+4
Replace with equivalent methods. Change-Id: I31ec00f5bf85335c8b23d306ca0fe0b84d489101
2022-04-27gdb: remove BLOCK_{START,END} macrosSimon Marchi1-4/+4
Replace with equivalent methods. Change-Id: I10a6c8a2a86462d9d4a6a6409a3f07a6bea66310
2022-04-20Replace symbol_objfile with symbol::objfileTom Tromey1-1/+1
This turns symbol_objfile into a method on symbol.
2022-04-11gdb: remove MSYMBOL_TYPE macroSimon Marchi1-1/+1
Add a getter and a setter for a minimal symbol's type. Remove the corresponding macro and adjust all callers. Change-Id: I89900df5ffa5687133fe1a16b2e0d4684e67a77d
2022-04-11gdb: remove symbol value macrosSimon Marchi1-18/+16
Remove all macros related to getting and setting some symbol value: #define SYMBOL_VALUE(symbol) (symbol)->value.ivalue #define SYMBOL_VALUE_ADDRESS(symbol) \ #define SET_SYMBOL_VALUE_ADDRESS(symbol, new_value) \ #define SYMBOL_VALUE_BYTES(symbol) (symbol)->value.bytes #define SYMBOL_VALUE_COMMON_BLOCK(symbol) (symbol)->value.common_block #define SYMBOL_BLOCK_VALUE(symbol) (symbol)->value.block #define SYMBOL_VALUE_CHAIN(symbol) (symbol)->value.chain #define MSYMBOL_VALUE(symbol) (symbol)->value.ivalue #define MSYMBOL_VALUE_RAW_ADDRESS(symbol) ((symbol)->value.address + 0) #define MSYMBOL_VALUE_ADDRESS(objfile, symbol) \ #define BMSYMBOL_VALUE_ADDRESS(symbol) \ #define SET_MSYMBOL_VALUE_ADDRESS(symbol, new_value) \ #define MSYMBOL_VALUE_BYTES(symbol) (symbol)->value.bytes #define MSYMBOL_BLOCK_VALUE(symbol) (symbol)->value.block Replace them with equivalent methods on the appropriate objects. Change-Id: Iafdab3b8eefc6dc2fd895aa955bf64fafc59ed50
2022-04-07gdb: remove symtab::objfileSimon Marchi1-2/+2
Same idea as previous patch, but for symtab::objfile. I find it clearer without this wrapper, as it shows that the objfile is common to all symtabs of a given compunit. Otherwise, you could think that each symtab (of a given compunit) can have a specific objfile. Change-Id: Ifc0dbc7ec31a06eefa2787c921196949d5a6fcc6
2022-04-07gdb: remove symtab::blockvectorSimon Marchi1-1/+1
symtab::blockvector is a wrapper around compunit_symtab::blockvector. It is a bit misleadnig, as it gives the impression that a symtab has a blockvector. Remove it, change all users to fetch the blockvector through the compunit instead. Change-Id: Ibd062cd7926112a60d52899dff9224591cbdeebf
2022-04-07gdb: remove symtab::dirnameSimon Marchi1-2/+2
I think the symtab::dirname method is bogus, or at least very misleading. It makes you think that it returns the directory that was used to find that symtab's file during compilation (i.e. the directory the file refers to in the DWARF line header file table), or the directory part of the symtab's filename maybe. In fact, it returns the compilation unit's directory, which is the CWD of the compiler, at compilation time. At least for DWARF, if the symtab's filename is relative, it will be relative to that directory. But if the symtab's filename is absolute, then the directory returned by symtab::dirname has nothing to do with the symtab's filename. Remove symtab::dirname to avoid this confusion, change all users to fetch the same information through the compunit. At least, it will be clear that this is a compunit property, not a symtab property. Change-Id: I2894c3bf3789d7359a676db3c58be2c10763f5f0
2022-04-04gdb: Add support for DW_LNS_set_prologue_end in line-tableLancelot SIX1-2/+4
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-03-31gdb: print compunit_symtab name in "maint info symtabs"Simon Marchi1-0/+1
I think it would make sense to print a compunit_symtab's name in "maint info symtabs". If you are looking for a given CU in the list, that's probably the field you will be looking at. As the doc of compunit_symtab::name says, it is not meant to be a reliable file name, it is for debugging purposes (and "maint info symtabs" exists for debugging purposes). Sample output with the new field: (gdb) maintenance info symtabs { objfile /home/simark/build/binutils-gdb-one-target/gdb/a.out ((struct objfile *) 0x613000005d00) { ((struct compunit_symtab *) 0x621000131630) debugformat DWARF 5 producer GNU C17 11.2.0 -mtune=generic -march=x86-64 -g3 -O0 name test.c dirname /home/simark/build/binutils-gdb-one-target/gdb blockvector ((struct blockvector *) 0x621000131d10) user ((struct compunit_symtab *) (null)) { symtab test.c ((struct symtab *) 0x6210001316b0) fullname (null) linetable ((struct linetable *) 0x621000131d40) } { symtab /home/simark/build/binutils-gdb-one-target/gdb/test.h ((struct symtab *) 0x6210001316e0) fullname (null) linetable ((struct linetable *) 0x0) } { symtab /usr/include/stdc-predef.h ((struct symtab *) 0x621000131710) fullname (null) linetable ((struct linetable *) 0x0) } } { ((struct compunit_symtab *) 0x6210001170a0) debugformat DWARF 5 producer GNU C17 11.2.0 -mtune=generic -march=x86-64 -g3 -O0 name foo.c dirname /home/simark/build/binutils-gdb-one-target/gdb blockvector ((struct blockvector *) 0x621000131580) user ((struct compunit_symtab *) (null)) { symtab foo.c ((struct symtab *) 0x621000117120) fullname (null) linetable ((struct linetable *) 0x6210001315b0) } { symtab /usr/include/stdc-predef.h ((struct symtab *) 0x621000117150) fullname (null) linetable ((struct linetable *) 0x0) } } } Change-Id: I17b87adfac2f6551cb5bda30d59f6c6882789211
2022-03-29Rename print_spaces_filteredTom Tromey1-1/+1
print_spaces_filtered is now misnamed, because whether filtering happens is up to the stream. So, rename it.
2022-03-29Unify gdb printf functionsTom Tromey1-198/+198
Now that filtered and unfiltered output can be treated identically, we can unify the printf family of functions. This is done under the name "gdb_printf". Most of this patch was written by script.
2022-03-29Unify gdb puts functionsTom Tromey1-11/+11
Now that filtered and unfiltered output can be treated identically, we can unify the puts family of functions. This is done under the name "gdb_puts". Most of this patch was written by script.
2022-02-14Remove LA_PRINT_TYPETom Tromey1-9/+9
This removes the LA_PRINT_TYPE macro, in favor of using ordinary method calls.
2022-02-06gdb: remove SYMBOL_TYPE macroSimon Marchi1-9/+9
Add a getter and a setter for a symbol's type. Remove the corresponding macro and adjust all callers. Change-Id: Ie1a137744c5bfe1df4d4f9ae5541c5299577c8de
2022-02-06gdb: remove SYMBOL_IS_ARGUMENT macroSimon Marchi1-1/+1
Add a getter and a setter for whether a symbol is an argument. Remove the corresponding macro and adjust all callers. Change-Id: I71b4f0465f3dfd2ed8b9e140bd3f7d5eb8d9ee81
2022-02-06gdb: remove SYMBOL_OBJFILE_OWNED macroSimon Marchi1-1/+1
Add a getter and a setter for whether a symbol is objfile owned. Remove the corresponding macro and adjust all callers. Change-Id: Ib7ef3718d65553ae924ca04c3fd478b0f4f3147c
2022-02-06gdb: remove SYMBOL_DOMAIN macroSimon Marchi1-2/+2
Add a getter and a setter for a symbol's domain. Remove the corresponding macro and adjust all callers. Change-Id: I54465b50ac89739c663859a726aef8cdc6e4b8f3
2022-02-06gdb: remove SYMBOL_CLASS macro, add getterSimon Marchi1-3/+3
Change-Id: I83211d5a47efc0564386e5b5ea4a29c00b1fd46a
2022-02-06gdb: remove SYMTAB_DIRNAME macroSimon Marchi1-2/+2
Remove the macro, replace with an equivalent method. Change-Id: I46ec36b91bb734331138eb9cd086b2db01635aed
2022-02-06gdb: remove SYMTAB_OBJFILE macroSimon Marchi1-2/+2
Remove the macro, replace with an equivalent method. Change-Id: I8f9ecd290ad28502e53c1ceca5006ba78bf042eb
2022-02-06gdb: remove SYMTAB_BLOCKVECTOR macroSimon Marchi1-1/+1
Remove the macro, replace with an equivalent method. Change-Id: Id6fe2a79c04bcd6c69ccaefb7a69bc06a476288c
2022-02-06gdb: remove SYMTAB_LANGUAGE macro, add getter/setterSimon Marchi1-4/+4
Add a getter and a setter for a symtab's language. Remove the corresponding macro and adjust all callers. Change-Id: I9f4d840b11c19f80f39bac1bce020fdd1739e11f
2022-02-06gdb: remove SYMTAB_LINETABLE macro, add getter/setterSimon Marchi1-4/+5
Add a getter and a setter for a symtab's linetable. Remove the corresponding macro and adjust all callers. Change-Id: I159183fc0ccd8e18ab937b3c2f09ef2244ec6e9c
2022-02-06gdb: remove SYMTAB_COMPUNIT macro, add getter/setterSimon Marchi1-5/+5
Add a getter and a setter for a symtab's compunit_symtab. Remove the corresponding macro and adjust all callers. For brevity, I chose the name "compunit" instead of "compunit_symtab" the the field, getter and setter names. Since we are already in symtab context, the _symtab suffix seems redundant. Change-Id: I4b9b731c96e3594f7733e75af1e3d01bc0e4fe92
2022-02-06gdb: remove COMPUNIT_BLOCKVECTOR macro, add getter/setterSimon Marchi1-3/+3
Add a getter and a setter for a compunit_symtab's blockvector. Remove the corresponding macro and adjust all callers. Change-Id: I99484c6619dcbbea7c5d89c72aa660316ca62f64