aboutsummaryrefslogtreecommitdiff
path: root/gdb/mdebugread.c
AgeCommit message (Collapse)AuthorFilesLines
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.
2023-11-29Use C++17 [[fallthrough]] attributeTom Tromey1-3/+3
This changes gdb to use the C++17 [[fallthrough]] attribute rather than special comments. This was mostly done by script, but I neglected a few spellings and so also fixed it up by hand. I suspect this fixes the bug mentioned below, by switching to a standard approach that, presumably, clang supports. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23159 Approved-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Luis Machado <luis.machado@arm.com> Approved-By: Pedro Alves <pedro@palves.net>
2023-11-21gdb: Use std::string_view instead of gdb::string_viewLancelot Six1-9/+9
Given that GDB now requires a C++17, replace all uses of gdb::string_view with std::string_view. This change has mostly been done automatically: - gdb::string_view -> std::string_view - #include "gdbsupport/gdb_string_view.h" -> #include <string_view> One things which got brought up during review is that gdb::stging_view does support being built from "nullptr" while std::sting_view does not. Two places are manually adjusted to account for this difference: gdb/tui/tui-io.c:tui_getc_1 and gdbsupport/format.h:format_piece::format_piece. The above automatic change transformed "gdb::to_string (const gdb::string_view &)" into "gdb::to_string (const std::string_view &)". The various direct users of this function are now explicitly including "gdbsupport/gdb_string_view.h". A later patch will remove the users of gdb::to_string. The implementation and tests of gdb::string_view are unchanged, they will be removed in a following patch. Change-Id: Ibb806a7e9c79eb16a55c87c6e41ad396fecf0207 Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net>
2023-09-20Remove explanatory comments from includesTom Tromey1-3/+3
I noticed a comment by an include and remembered that I think these don't really provide much value -- sometimes they are just editorial, and sometimes they are obsolete. I think it's better to just remove them. Tested by rebuilding. Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-09-19Give a language to a typeTom Tromey1-4/+5
This changes main_type to hold a language, and updates the debug readers to set this field. This is done by adding the language to the type-allocator object. Note that the non-DWARF readers are changed on a "best effort" basis. This patch also reimplements type::is_array_like to use the type's language, and it adds a new type::is_string_like as well. This in turn lets us change the Python implementation of these methods to simply defer to the type.
2023-09-12gdb: Fix -Wuninitialized issueEnze Li1-0/+1
I see the following warning when building GDB on FreeBSD/amd64 with Clang 14, ====================================================================== CXX mdebugread.o mdebugread.c:1069:3: error: variable 'f' is uninitialized when used here [-Werror,-Wuninitialized] f->set_loc_enumval (tsym.value); ^ mdebugread.c:836:17: note: initialize the variable 'f' to silence this warning struct field *f; ^ = nullptr ====================================================================== after digging a little, I realized that we can not simply do what Clang 14 says. The root cause of this issue is that we lost the initialization of the variable 'f' in this commit, commit 2774f2dad5f05e68771c07df6ab0fb23baa2118e Date: Thu Aug 31 09:37:44 2023 +0200 [gdb/symtab] Factor out type::{alloc_fields,copy_fields} we have made these modifications, --------------------------------------------------------------------- --- a/gdb/mdebugread.c +++ b/gdb/mdebugread.c @@ -1034,9 +1034,7 @@ parse_symbol (SYMR *sh, union aux_ext *ax, char *ext_sh, int bigend, t->set_code (type_code); t->set_length (sh->value); - t->set_num_fields (nfields); - f = ((struct field *) TYPE_ALLOC (t, nfields * sizeof (struct field))); - t->set_fields (f); + t->alloc_fields (nfields, false); --------------------------------------------------------------------- The problem is that the variable 'f' is used in the second half of parse_symbol, that's why Clang complained. To fix this issue we need to ensure that the varibale 'f' is initialized. Calling the fields method is an obvious way to fix this issue. Tested on FreeBSD/amd64 by rebuilding. Approved-By: Tom de Vries <tdevries@suse.de>
2023-08-31gdb: introduce field::bitsize / field::set_bitsizeSimon Marchi1-2/+2
Add these two methods, rename the field to m_bitsize to make it pseudo private. Change-Id: Ief95e5cf106e72f2c22ae47b033d0fa47202b413 Approved-By: Tom Tromey <tom@tromey.com>
2023-08-31gdb: introduce field::is_artificial / field::set_is_artificialSimon Marchi1-1/+1
Add these two methods, rename the field to m_artificial to make it pseudo private. Change-Id: If3a3825473d1d79bb586a8a074b87bba9b43fb1a Approved-By: Tom Tromey <tom@tromey.com>
2023-08-31[gdb/symtab] Do more zero-initialization of type::fieldsTom de Vries1-2/+2
Now that we've introduced type::{alloc_fields,copy_fields}, the places where no zero-initialization of allocated fields is done are easy to spot: ... $ find gdb* -type f | grep -v ChangeLog | xargs grep alloc_fields | grep false gdb/coffread.c: type->alloc_fields (nfields, false); gdb/coffread.c: type->alloc_fields (nsyms, false); gdb/stabsread.c: ftype->alloc_fields (nsemi, false); gdb/gdbtypes.c: resolved_type->alloc_fields (nfields, false); gdb/gdbtypes.c: alloc_fields (nfields, false); gdb/gdbtypes.c: alloc_fields (nfields, false); gdb/mdebugread.c: t->alloc_fields (nfields, false); gdb/mdebugread.c: ftype->alloc_fields (nparams, false); ... All hits in gdbtypes.c are ok. There are two hits in the two variants of copy_fields, and there's already a comment for the third. AFAICT, the other ones are not ok, so fix those by dropping the "false" argument. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2023-08-31[gdb/symtab] Factor out type::{alloc_fields,copy_fields}Tom de Vries1-7/+2
After finding this code in buildsym_compunit::finish_block_internal: ... ftype->set_fields ((struct field *) TYPE_ALLOC (ftype, nparams * sizeof (struct field))); ... and fixing PR30810 by using TYPE_ZALLOC, I wondered if there were more locations that needed fixing. I decided to make things easier to spot by factoring out a new function alloc_fields: ... /* Allocate the fields array of this type, with NFIELDS elements. If INIT, zero-initialize the allocated memory. */ void type::alloc_fields (unsigned int nfields, bool init = true); ... where: - a regular use would be "alloc_fields (nfields)", and - an exceptional use that needed no initialization would be "alloc_fields (nfields, false)". Pretty soon I discovered that most of the latter cases are due to initialization by memcpy, so I added two variants of copy_fields as well. After this rewrite there are 8 uses of set_fields left: ... gdb/coffread.c: type->set_fields (nullptr); gdb/coffread.c: type->set_fields (nullptr); gdb/coffread.c: type->set_fields (nullptr); gdb/eval.c: type->set_fields gdb/gdbtypes.c: type->set_fields (args); gdb/gdbtypes.c: t->set_fields (XRESIZEVEC (struct field, t->fields (), gdb/dwarf2/read.c: type->set_fields (new_fields); gdb/dwarf2/read.c: sub_type->set_fields (sub_type->fields () + 1); ... These fall into the following categories: - set to nullptr (coffread.c), - type not owned by objfile or gdbarch (eval.c), and - modifying an existing fields array, like adding an element at the end or dropping an element at the start (the rest). Tested on x86_64-linux.
2023-08-18Merge psympriv.h into psymtab.hTom Tromey1-1/+1
psympriv.h was intended for use by code that created partial symbols. Now that no generic code needs psymtab.h any more, psympriv.h can be merged into psymtab.h.
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-06-03[gdb] Fix typosTom de Vries1-1/+1
Fix a few typos: - implemention -> implementation - convertion(s) -> conversion(s) - backlashes -> backslashes - signoring -> ignoring - (un)ambigious -> (un)ambiguous - occured -> occurred - hidding -> hiding - temporarilly -> temporarily - immediatelly -> immediately - sillyness -> silliness - similiar -> similar - porkuser -> pokeuser - thats -> that - alway -> always - supercede -> supersede - accomodate -> accommodate - aquire -> acquire - priveleged -> privileged - priviliged -> privileged - priviledges -> privileges - privilige -> privilege - recieve -> receive - (p)refered -> (p)referred - succesfully -> successfully - successfuly -> successfully - responsability -> responsibility - wether -> whether - wich -> which - disasbleable -> disableable - descriminant -> discriminant - construcstor -> constructor - underlaying -> underlying - underyling -> underlying - structureal -> structural - appearences -> appearances - terciarily -> tertiarily - resgisters -> registers - reacheable -> reachable - likelyhood -> likelihood - intepreter -> interpreter - disassemly -> disassembly - covnersion -> conversion - conviently -> conveniently - atttribute -> attribute - struction -> struct - resonable -> reasonable - popupated -> populated - namespaxe -> namespace - intialize -> initialize - identifer(s) -> identifier(s) - expection -> exception - exectuted -> executed - dungerous -> dangerous - dissapear -> disappear - completly -> completely - (inter)changable -> (inter)changeable - beakpoint -> breakpoint - automativ -> automatic - alocating -> allocating - agressive -> aggressive - writting -> writing - reguires -> requires - registed -> registered - recuding -> reducing - opeartor -> operator - ommitted -> omitted - modifing -> modifying - intances -> instances - imbedded -> embedded - gdbaarch -> gdbarch - exection -> execution - direcive -> directive - demanged -> demangled - decidely -> decidedly - argments -> arguments - agrument -> argument - amespace -> namespace - targtet -> target - supress(ed) -> suppress(ed) - startum -> stratum - squence -> sequence - prompty -> prompt - overlow -> overflow - memember -> member - languge -> language - geneate -> generate - funcion -> function - exising -> existing - dinking -> syncing - destroh -> destroy - clenaed -> cleaned - changep -> changedp (name of variable) - arround -> around - aproach -> approach - whould -> would - symobl -> symbol - recuse -> recurse - outter -> outer - freeds -> frees - contex -> context Tested on x86_64-linux. Reviewed-By: Tom Tromey <tom@tromey.com>
2023-03-28Rename "raw" to "unrelocated"Tom Tromey1-7/+7
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-7/+10
This changes minimal symbols to use unrelocated_addr. I believe this detected a latent bug in add_pe_forwarded_sym.
2023-03-28Use unrelocated_addr in psymbolsTom Tromey1-15/+28
This changes psymbols themselves to use unrelocated_addr. This transform is largely mechanical. I don't think it finds any bugs.
2023-03-28Use unrelocated_addr in partial symbol tablesTom Tromey1-13/+19
This changes partial symbol tables to use unrelocated_addr for the text_high and text_low members. This revealed some latent bugs in ctfread.c, which are fixed here.
2023-03-18Rename objfile_type to builtin_typeTom Tromey1-12/+12
This renames objfile_type to be an overload of builtin_type, in preparation for their unification. Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-18Use type allocator for array typesTom Tromey1-1/+1
This changes the array type creation functions to accept a type allocator, and updates all the callers. Note that symbol readers should generally allocate on the relevant objfile, regardless of the placement of the index type of the array, which is what this patch implements. Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-18Use type allocator for range typesTom Tromey1-2/+5
This changes the range type creation functions to accept a type allocator, and updates all the callers. Note that symbol readers should generally allocate on the relevant objfile, regardless of the underlying type of the range, which is what this patch implements. Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-18Unify arch_pointer_type and init_pointer_typeTom Tromey1-2/+2
This unifies arch_pointer_type and init_pointer_type by using a type allocator. Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-18Unify arch_float_type and init_float_typeTom Tromey1-2/+2
This unifies arch_float_type and init_float_type by using a type allocator. Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-18Unify arch_integer_type and init_integer_typeTom Tromey1-15/+15
This unifies arch_integer_type and init_integer_type by using a type allocator. Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-18Remove init_typeTom Tromey1-9/+15
This removes init_type, replacing all uses with the new type allocator. Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-18Remove alloc_typeTom Tromey1-1/+1
This removes alloc_type, replacing all uses with the new type allocator. Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-17Fix line table regressionTom Tromey1-3/+5
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-1/+4
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-5/+4
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-03-08Remove OBJF_REORDEREDTom Tromey1-29/+0
OBJF_REORDERED is set for nearly every object format. And, despite the ominous warnings here and there, it does not seem very expensive. This patch removes the flag entirely. Reviewed-By: Andrew Burgess <aburgess@redhat.com>
2023-02-19Remove allocate_block and allocate_global_blockTom Tromey1-1/+1
This removes allocate_block and allocate_global_block in favor of simply calling 'new'.
2023-02-19Fix memory leak in mdebugread.cTom Tromey1-10/+9
mdebugread.c allocates blocks on the heap. However, this is a memory leak if the corresponding objfile is ever destroyed. This patch changes this code to use allocate_block instead, fixing a FIXME from 2003. I don't know how to test this patch.
2023-02-19Remove ALL_BLOCK_SYMBOLSTom Tromey1-7/+2
This removes ALL_BLOCK_SYMBOLS in favor of foreach.
2023-02-08Do not pass section index to end_compunit_symtabTom Tromey1-3/+2
Right now, the section index passed to end_compunit_symtab is always SECT_OFF_TEXT. Remove this parameter and simply always use SECT_OFF_TEXT.
2023-02-08Set section indices when symbols are madeTom Tromey1-4/+14
Most places in gdb that create a new symbol will apply a section offset to the address. It seems to me that the choice of offset here is also an implicit choice of the section. This is particularly true if you examine fixup_section, which notes that it must be called before such offsets are applied -- meaning that if any such call has an effect, it's purely by accident. This patch cleans up this area by tracking the section index and applying it to a symbol when the address is set. This is done for nearly every case -- the remaining cases will be handled in later patches.
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-10-28Convert compunit_language to a methodTom Tromey1-1/+1
This changes compunit_language to be a method on compunit_symtab. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-09-21gdb: remove TYPE_LENGTHSimon Marchi1-3/+3
Remove the macro, replace all uses with calls to type::length. Change-Id: Ib9bdc954576860b21190886534c99103d6a47afb
2022-09-21gdb: add type::length / type::set_lengthSimon Marchi1-2/+2
Add the `length` and `set_length` methods on `struct type`, in order to remove the `TYPE_LENGTH` macro. In this patch, the macro is changed to use the getter, so all the call sites of the macro that are used as a setter are changed to use the setter method directly. The next patch will remove the macro completely. Change-Id: Id1090244f15c9856969b9be5006aefe8d8897ca4
2022-09-21gdb: remove TYPE_TARGET_TYPESimon Marchi1-2/+2
Remove the macro, replace all uses by calls to type::target_type. Change-Id: Ie51d3e1e22f94130176d6abd723255282bb6d1ed
2022-08-03Use gdb_bfd_ref_ptr in objfileTom Tromey1-3/+3
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-07-28Rewrite registry.hTom Tromey1-2/+2
This rewrites registry.h, removing all the macros and replacing it with relatively ordinary template classes. The result is less code than the previous setup. It replaces large macros with a relatively straightforward C++ class, and now manages its own cleanup. The existing type-safe "key" class is replaced with the equivalent template class. This approach ended up requiring relatively few changes to the users of the registry code in gdb -- code using the key system just required a small change to the key's declaration. All existing users of the old C-like API are now converted to use the type-safe API. This mostly involved changing explicit deletion functions to be an operator() in a deleter class. The old "save/free" two-phase process is removed, and replaced with a single "free" phase. No existing code used both phases. The old "free" callbacks took a parameter for the enclosing container object. However, this wasn't truly needed and is removed here as well.
2022-06-02ODR warnings for struct symlocTom Tromey1-5/+5
"struct symloc" is defined in multiple spots in gdb, causing ODR warnings. This patch renames these. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
2022-04-27gdb: remove BLOCKVECTOR_BLOCK and BLOCKVECTOR_NBLOCKS macrosSimon Marchi1-47/+37
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-3/+3
Replace with equivalent methods. Change-Id: If9a239c511a664f2a59fecb6d1cd579881b23dc2
2022-04-27gdb: remove BLOCK_SUPERBLOCK macroSimon Marchi1-6/+6
Replace with equivalent methods. Change-Id: I334a319909a50b5cc5570a45c38c70e10dc00630
2022-04-27gdb: remove BLOCK_FUNCTION macroSimon Marchi1-1/+1
Replace with equivalent methods. Change-Id: I31ec00f5bf85335c8b23d306ca0fe0b84d489101
2022-04-27gdb: remove BLOCK_{START,END} macrosSimon Marchi1-27/+30
Replace with equivalent methods. Change-Id: I10a6c8a2a86462d9d4a6a6409a3f07a6bea66310
2022-04-20Replace symbol_symtab with symbol::symtabTom Tromey1-1/+1
This turns symbol_symtab into a method on symbol. It also replaces symbol_set_symtab with a method.
2022-04-11gdb: remove symbol value macrosSimon Marchi1-16/+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::blockvectorSimon Marchi1-7/+9
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
generated by cgit v1.1 at 2024-09-02 09:01:08 +0000