aboutsummaryrefslogtreecommitdiff
path: root/gdb/guile
AgeCommit message (Collapse)AuthorFilesLines
2022-11-28gdb/disasm: mark functions passed to the disassembler noexceptAndrew Burgess1-1/+1
While working on another patch, Simon pointed out that GDB could be improved by marking the functions passed to the disassembler as noexcept. https://sourceware.org/pipermail/gdb-patches/2022-October/193084.html The reason this is important is the on some hosts, libopcodes, being C code, will not be compiled with support for handling exceptions. As such, an attempt to throw an exception over libopcodes code will cause GDB to terminate. See bug gdb/29712 for an example of when this happened. In this commit all the functions that are passed to the disassembler, and which might be used as callbacks by libopcodes are marked noexcept. Ideally, I would have liked to change these typedefs: using read_memory_ftype = decltype (disassemble_info::read_memory_func); using memory_error_ftype = decltype (disassemble_info::memory_error_func); using print_address_ftype = decltype (disassemble_info::print_address_func); using fprintf_ftype = decltype (disassemble_info::fprintf_func); using fprintf_styled_ftype = decltype (disassemble_info::fprintf_styled_func); which are declared in disasm.h, as including the noexcept keyword. However, when I tried this, I ran into this warning/error: In file included from ../../src/gdb/disasm.c:25: ../../src/gdb/disasm.h: In constructor ‘gdb_printing_disassembler::gdb_printing_disassembler(gdbarch*, ui_file*, gdb_disassemble_info::read_memory_ftype, gdb_disassemble_info::memory_error_ftype, gdb_disassemble_info::print_address_ftype)’: ../../src/gdb/disasm.h:116:3: error: mangled name for ‘gdb_printing_disassembler::gdb_printing_disassembler(gdbarch*, ui_file*, gdb_disassemble_info::read_memory_ftype, gdb_disassemble_info::memory_error_ftype, gdb_disassemble_info::print_address_ftype)’ will change in C++17 because the exception specification is part of a function type [-Werror=noexcept-type] 116 | gdb_printing_disassembler (struct gdbarch *gdbarch, | ^~~~~~~~~~~~~~~~~~~~~~~~~ So I've left that change out. This does mean that if somebody adds a new use of the disassembler classes in the future, and forgets to mark the callbacks as noexcept, this will compile fine. We'll just have to manually check for that during review.
2022-10-31Add missing TYPE_CODE_* constants to PythonTom Tromey1-29/+6
A user noticed that TYPE_CODE_FIXED_POINT was not exported by the gdb Python layer. This patch fixes the bug, and prevents future occurences of this type of bug.
2022-10-21GDB/Guile: Don't assert that an integer value is booleanMaciej W. Rozycki1-1/+1
Do not assert that a value intended for an integer parameter, of either the PARAM_UINTEGER or the PARAM_ZUINTEGER_UNLIMITED type, is boolean, causing error messages such as: ERROR: In procedure make-parameter: ERROR: In procedure gdbscm_make_parameter: Wrong type argument in position 15 (expecting integer or #:unlimited): 3 Error while executing Scheme code. when initialization with a number is attempted. Instead assert that it is integer. Keep matching `#:unlimited' keyword as an alternative. Add suitable test cases. Approved-By: Simon Marchi <simon.marchi@polymtl.ca>
2022-10-10Fix the guile buildTom Tromey3-74/+107
The frame_info_ptr patches broke the build with Guile. This patch fixes the problem. In mos cases I chose to preserve the use of frame_info_ptr, at least where I could be sure that the object lifetime did not interact with Guile's longjmp-based exception scheme. Tested on x86-64 Fedora 34.
2022-10-10Change GDB to use frame_info_ptrTom Tromey1-1/+1
This changes GDB to use frame_info_ptr instead of frame_info * The substitution was done with multiple sequential `sed` commands: sed 's/^struct frame_info;/class frame_info_ptr;/' sed 's/struct frame_info \*/frame_info_ptr /g' - which left some issues in a few files, that were manually fixed. sed 's/\<frame_info \*/frame_info_ptr /g' sed 's/frame_info_ptr $/frame_info_ptr/g' - used to remove whitespace problems. The changed files were then manually checked and some 'sed' changes undone, some constructors and some gets were added, according to what made sense, and what Tromey originally did Co-Authored-By: Bruno Larsen <blarsen@redhat.com> Approved-by: Tom Tomey <tom@tromey.com>
2022-10-10Remove frame_id_eqTom Tromey1-1/+1
This replaces frame_id_eq with operator== and operator!=. I wrote this for a version of this series that I later abandoned; but since it simplifies the code, I left this patch in. Approved-by: Tom Tomey <tom@tromey.com>
2022-09-21gdb: remove TYPE_LENGTHSimon Marchi4-7/+7
Remove the macro, replace all uses with calls to type::length. Change-Id: Ib9bdc954576860b21190886534c99103d6a47afb
2022-09-21gdb: remove TYPE_TARGET_TYPESimon Marchi4-9/+9
Remove the macro, replace all uses by calls to type::target_type. Change-Id: Ie51d3e1e22f94130176d6abd723255282bb6d1ed
2022-08-31Use ui_out_redirect_pop in more placesTom Tromey2-4/+2
This changes ui_out_redirect_pop to also perform the redirection, and then updates several sites to use this, rather than explicit redirects.
2022-08-04Use registry in gdbarchTom Tromey2-50/+29
gdbarch implements its own registry-like approach. This patch changes it to instead use registry.h. It's a rather large patch but largely uninteresting -- it's mostly a straightforward conversion from the old approach to the new one. The main benefit of this change is that it introduces type safety to the gdbarch registry. It also removes a bunch of code. One possible drawback is that, previously, the gdbarch registry differentiated between pre- and post-initialization setup. This doesn't seem very important to me, though.
2022-07-28Remove some unneeded checks in Guile codeTom Tromey5-26/+15
The Guile code generally checks to see if an htab is non-null before destroying it. However, the registry code already ensures this, so we can change these checks to asserts and simplify the code a little.
2022-07-28Rewrite registry.hTom Tromey8-266/+188
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-07-28Remove some unused functions from guile codeTom Tromey2-44/+0
The guile code has a couple of unused functions that touch on the registry API. This patch removes them.
2022-07-28Change allocation of type-copying hash tableTom Tromey1-2/+2
When an objfile is destroyed, types that are still in use and allocated on that objfile are copied. A temporary hash map is created during this process, and it is allocated on the destroyed objfile's obstack -- which normally is fine, as that is going to be destroyed shortly anyway. However, this approach requires that the objfile be passed to registry destruction, and this won't be possible in the rewritten registry. This patch changes the copied type hash table to simply use the heap instead. It also removes the 'objfile' parameter from copy_type_recursive, to make this all more clear. This patch also fixes an apparent bug in copy_type_recursive. Previously it was copying the dynamic property list to the dying objfile's obstack: - = copy_dynamic_prop_list (&objfile->objfile_obstack, However I think this is incorrect -- that obstack is about to be destroyed.
2022-07-08[gdb/build] Handle deprecation of scm_install_gmp_memory_functionsLudovic Courtès1-0/+10
When building gdb with guile 3.0.8, we run into: ... gdb/guile/guile.c: In function \ 'void gdbscm_initialize(const extension_language_defn*)': gdb/guile/guile.c:680:5: error: 'scm_install_gmp_memory_functions' is \ deprecated [-Werror=deprecated-declarations] 680 | scm_install_gmp_memory_functions = 0; | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from /usr/include/guile/3.0/libguile.h:128, from gdb/guile/guile-internal.h:30, from gdb/guile/guile.c:36: /usr/include/guile/3.0/libguile/deprecated.h:164:20: note: declared here 164 | SCM_DEPRECATED int scm_install_gmp_memory_functions; | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1plus: all warnings being treated as errors make[1]: *** [Makefile:1896: guile/guile.o] Error 1 ... The variable has been deprecated because it no longer has any effect. Fix this by disabling the specific deprecation warning. Also handle upcoming guile versions > 3.0, in which the variable will be removed, by limiting the usage of the variable to guile versions <= 3.0. This does not break anything. The variable was merely used to address a problem present in guile versions <= v3.0.5. Note that we don't limit the usage of the variable to guile versions <= 3.0.5, because we want to support f.i. building against 3.0.6 and then using a shared lib with 3.0.5. Tested on x86_64-linux. Co-Authored-By: Tom de Vries <tdevries@suse.de> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28994
2022-06-17Convert location_spec_to_string to a methodPedro Alves1-3/+2
This converts location_spec_to_string to a method of location_spec, simplifying the code using it, as it no longer has to use std::unique_ptr::get(). Change-Id: I621bdad8ea084470a2724163f614578caf8f2dd5
2022-06-17event_location -> location_specPedro Alves1-11/+11
Currently, GDB internally uses the term "location" for both the location specification the user input (linespec, explicit location, or an address location), and for actual resolved locations, like the breakpoint locations, or the result of decoding a location spec to SaLs. This is expecially confusing in the breakpoints module, as struct breakpoint has these two fields: breakpoint::location; breakpoint::loc; "location" is the location spec, and "loc" is the resolved locations. And then, we have a method called "locations()", which returns the resolved locations as range... The location spec type is presently called event_location: /* Location we used to set the breakpoint. */ event_location_up location; and it is described like this: /* The base class for all an event locations used to set a stop event in the inferior. */ struct event_location { and even that is incorrect... Location specs are used for finding actual locations in the program in scenarios that have nothing to do with stop events. E.g., "list" works with location specs. To clean all this confusion up, this patch renames "event_location" to "location_spec" throughout, and then all the variables that hold a location spec, they are renamed to include "spec" in their name, like e.g., "location" -> "locspec". Similarly, functions that work with location specs, and currently have just "location" in their name are renamed to include "spec" in their name too. Change-Id: I5814124798aa2b2003e79496e78f95c74e5eddca
2022-06-15gdb: add extension language print_insn hookAndrew Burgess1-1/+5
This commit is setup for the next commit. In the next commit I will add a Python API to intercept the print_insn calls within GDB, each print_insn call is responsible for disassembling, and printing one instruction. After the next commit it will be possible for a user to write Python code that either wraps around the existing disassembler, or even, in extreme situations, entirely replaces the existing disassembler. This commit does not add any new Python API. What this commit does is put the extension language framework in place for a print_insn hook. There's a new callback added to 'struct extension_language_ops', which is then filled in with nullptr for Python and Guile. Finally, in the disassembler, the code is restructured so that the new extension language function ext_lang_print_insn is called before we delegate to gdbarch_print_insn. After this, the next commit can focus entirely on providing a Python implementation of the new print_insn callback. There should be no user visible change after this commit.
2022-06-02ODR warning for "enum string_repr_result"Tom Tromey1-4/+4
"enum string_repr_result" is defined in multiple .c files, causing ODR warnings. This patch renames the types. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
2022-04-27gdb: remove BLOCKVECTOR_BLOCK and BLOCKVECTOR_NBLOCKS macrosSimon Marchi1-4/+2
Replace with calls to blockvector::blocks, and the appropriate method call on the returned array_view. Change-Id: I04d1f39603e4d4c21c96822421431d9a029d8ddd
2022-04-27gdb: remove BLOCK_SUPERBLOCK macroSimon Marchi2-8/+8
Replace with equivalent methods. Change-Id: I334a319909a50b5cc5570a45c38c70e10dc00630
2022-04-27gdb: remove BLOCK_FUNCTION macroSimon Marchi2-6/+6
Replace with equivalent methods. Change-Id: I31ec00f5bf85335c8b23d306ca0fe0b84d489101
2022-04-27gdb: remove BLOCK_{START,END} macrosSimon Marchi1-3/+3
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-20Replace symbol_arch with symbol::archTom Tromey1-1/+1
This turns symbol_arch into a method on symbol.
2022-04-20Replace symbol_objfile with symbol::objfileTom Tromey2-2/+2
This turns symbol_objfile into a method on symbol.
2022-04-07gdb: remove symtab::objfileSimon Marchi1-4/+4
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-2/+2
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-04Avoid undefined behavior in gdbscm_make_breakpointPedro Alves1-5/+5
Running gdb.guile/scm-breakpoint.exp against an --enable-ubsan build, we see: UNRESOLVED: gdb.guile/scm-breakpoint.exp: test_watchpoints: create a breakpoint with an invalid type number ... guile (define wp2 (make-breakpoint "result" #:wp-class WP_WRITE #:type 999)) ../../src/gdb/guile/scm-breakpoint.c:377:11: runtime error: load of value 999, which is not a valid value for type 'bptype' ERROR: GDB process no longer exists Fix this by parsing the user/guile input as plain int, and cast to internal type only after we know we have a number that would be valid. Change-Id: I03578d07db00be01b610a8f5ce72e5521aea6a4b
2022-03-29Rename print_spaces_filteredTom Tromey1-3/+3
print_spaces_filtered is now misnamed, because whether filtering happens is up to the stream. So, rename it.
2022-03-29Unify gdb printf functionsTom Tromey5-11/+11
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 putc functionsTom Tromey2-2/+2
Now that filtered and unfiltered output can be treated identically, we can unify the putc family of functions. This is done under the name "gdb_putc". Most of this patch was written by script.
2022-03-29Unify gdb puts functionsTom Tromey2-15/+15
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-1/+2
This removes the LA_PRINT_TYPE macro, in favor of using ordinary method calls.
2022-02-06gdb: remove SYMBOL_LINE macroSimon Marchi1-1/+1
Add a getter and a setter for a symbol's line. Remove the corresponding macro and adjust all callers. Change-Id: I229f2b8fcf938c07975f641361313a8761fad9a5
2022-02-06gdb: remove SYMBOL_TYPE macroSimon Marchi1-2/+2
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-2/+2
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-2/+2
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_CLASS macro, add getterSimon Marchi1-5/+5
Change-Id: I83211d5a47efc0564386e5b5ea4a29c00b1fd46a
2022-02-06gdb: remove SYMTAB_OBJFILE macroSimon Marchi1-4/+4
Remove the macro, replace with an equivalent method. Change-Id: I8f9ecd290ad28502e53c1ceca5006ba78bf042eb
2022-02-06gdb: remove SYMTAB_BLOCKVECTOR macroSimon Marchi1-2/+2
Remove the macro, replace with an equivalent method. Change-Id: Id6fe2a79c04bcd6c69ccaefb7a69bc06a476288c
2022-02-06gdb: rename compunit_primary_filetab to compunit_symtab::primary_filetabSimon Marchi1-1/+1
Make compunit_primary_filetab a method of compunit_symtab. Change-Id: Iee3c4f7e36d579bf763c5bba146e5e10d6766768
2022-02-06gdb: remove COMPUNIT_OBJFILE macroSimon Marchi1-3/+3
Remove the macro, update all users to use the getter directly. Change-Id: I3f0fd6f4455d1c4ebd5da73b561eb18a979ef1f6
2022-01-26Always call the wrap_here methodTom Tromey1-1/+1
This changes all existing calls to wrap_here to call the method on the appropriate ui_file instead. The choice of ui_file is determined by context.
2022-01-26Convert wrap_here to use integer parameterTom Tromey1-1/+1
I think it only really makes sense to call wrap_here with an argument consisting solely of spaces. Given this, it seemed better to me that the argument be an int, rather than a string. This patch is the result. Much of it was written by a script.
2022-01-26gdb: add string_file::release methodSimon Marchi1-1/+1
A common pattern for string_file is to want to move out the internal string buffer, because it is the result of the computation that we want to return. It is the reason why string_file::string returns a non-const reference, as explained in the comment. I think it would make sense to have a dedicated method for that instead and make string_file::string return a const reference. This allows removing the explicit std::move in the typical case. Note that compile_program::compute was missing a move, meaning that the resulting string was copied. With the new version, it's not possible to forget to move. Change-Id: Ieaefa35b73daa7930b2f3a26988b6e3b4121bb79
2022-01-26Fix another crash with gdb parameters in PythonTom Tromey1-2/+2
While looking into the language-capturing issue, I found another way to crash gdb using parameters from Python: (gdb) python print(gdb.parameter('endian')) (This is related to PR python/12188, though this patch isn't going to fix what that bug is really about.) The problem here is that the global variable that underlies the "endian" parameter is initialized to NULL. However, that's not a valid value for an "enum" set/show parameter. My understanding is that, in gdb, an "enum" parameter's underlying variable must have a value that is "==" (not just strcmp-equal) to one of the values coming from the enum array. This invariant is relied on in various places. I started this patch by fixing the problem with "endian". Then I added some assertions to add_setshow_enum_cmd to try to catch other problems of the same type. This patch fixes all the problems that I found. I also looked at all the calls to add_setshow_enum_cmd to ensure that they were all included in the gdb I tested. I think they are: there are no calls in nat-* files, or in remote-sim.c; and I was trying a build with all targets, Python, and Guile enabled. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12188
2022-01-25Reduce explicit use of gdb_stdoutTom Tromey1-1/+1
In an earlier version of the pager rewrite series, it was important to audit unfiltered output calls to see which were truly necessary. This is no longer necessary, but it still seems like a decent cleanup to change calls to avoid explicitly passing gdb_stdout. That is, rather than using something like fprintf_unfiltered with gdb_stdout, the code ought to use plain printf_unfiltered instead. This patch makes this change. I went ahead and converted all the _filtered calls I could find, as well, for the same clarity.
2022-01-18Move gdb_argv to gdbsupportTom Tromey1-0/+1
This moves the gdb_argv class to a new header in gdbsupport.
2022-01-05Implement putstr and putstrn in ui_fileTom Tromey1-2/+2
In my tour of the ui_file subsystem, I found that fputstr and fputstrn can be simplified. The _filtered forms are never used (and IMO unlikely to ever be used) and so can be removed. And, the interface can be simplified by removing a callback function and moving the implementation directly to ui_file. A new self-test is included. Previously, I think nothing was testing this code. Regression tested on x86-64 Fedora 34.