aboutsummaryrefslogtreecommitdiff
path: root/gdb/guile
AgeCommit message (Collapse)AuthorFilesLines
14 daysChange file initialization to use INIT_GDB_FILE macroTom Tromey1-3/+1
This patch introduces a new macro, INIT_GDB_FILE. This is used to replace the current "_initialize_" idiom when introducing a per-file initialization function. That is, rather than write: void _initialize_something (); void _initialize_something () { ... } ... now you would write: INIT_GDB_FILE (something) { ... } The macro handles both the declaration and definition of the function. The point of this approach is that it makes it harder to accidentally cause an initializer to be omitted; see commit 2711e475 ("Ensure cooked_index_entry self-tests are run"). Specifically, the regexp now used by make-init-c seems harder to trick. New in v2: un-did some erroneous changes made by the script. The bulk of this patch was written by script. Regression tested on x86-64 Fedora 41.
2025-06-06gdb/guile: fix memory leak in gdbscm_parse_command_nameAndrew Burgess1-0/+8
For reference see the previous commit. Fix a memory leak in gdbscm_parse_command_name when a guile exception is thrown. To reveal the memory leak I placed the following content into a file 'leak.scm': (use-modules (gdb)) (register-command! (make-command "break cmd" #:command-class COMMAND_OBSCURE #:invoke (lambda (self arg from-tty) (display "Hello World")))) Then in GDB: (gdb) source leak.scm ERROR: In procedure register-command!: In procedure gdbscm_register_command_x: Out of range: 'break' is not a prefix command in position 1: "break cmd" Error while executing Scheme code. Running this under valgrind reveals a memory leak for 'result' and 'prefix_text' from gdbscm_parse_command_name. Another leak can be revealed with this input script: (use-modules (gdb)) (register-command! (make-command "unknown-prefix cmd" #:command-class COMMAND_OBSCURE #:invoke (lambda (self arg from-tty) (display "Hello World")))) This one occurs earlier in gdbscm_parse_command_name, and now only 'result' leaks. The problem is that, when guile throws an exception then a longjmp is performed from the function that raise the exception back to the guile run-time. A consequence of this is that no function local destructors will be run. In gdbscm_parse_command_name, this means that the two function locals `result` and `prefix_text` will not have their destructors run, and any memory managed by these objects will be leaked. Fix this by assigning nullptr to these two function locals before throwing an exception. This will cause the managed memory to be deallocated. I could have implemented a fix that made use of Guile's dynwind mechanism to register a cleanup callback, however, this felt like overkill. At the point the exception is being thrown we know that we no longer need the managed memory, so we might as well just free the memory at that point. With this fix in place, the two leaks are now fixed in the valgrind output. Approved-By: Tom Tromey <tom@tromey.com>
2025-06-06gdb/python/guile: remove some explicit calls to xmallocAndrew Burgess1-6/+5
In gdbpy_parse_command_name (python/py-cmd.c) there is a call to xmalloc that can easily be replaced with a call to make_unique_xstrndup, which makes the code easier to read (I think). In gdbscm_parse_command_name (guile/scm-cmd.c) the same fix can be applied to remove an identical xmalloc call. And there is an additional xmalloc call, which can also be replaced with make_unique_xstrndup in the same way. The second xmalloc call in gdbscm_parse_command_name was also present in gdbpy_parse_command_name at one point, but was replaced with a use of std::string by this commit: commit 075c55e0cc0a68eeab777027213c2f545618e844 Date: Wed Dec 26 11:05:57 2018 -0700 Remove more calls to xfree from Python I haven't changed the gdbscm_parse_command_name to use std::string though, as that doesn't work well with the guile exception model. Guile exceptions work by performing a longjmp from the function that raises the exception, back to the guile run-time. The consequence of this is that destructors are not run. For example, if gdbscm_parse_command_name calls gdbscm_out_of_range_error, then any function local objects in gdbscm_parse_command_name will not have their destructors called. What this means is that, for the existing `result` and `prefix_text` locals, any allocated memory managed by these objects will be leaked if an exception is called. However, fixing this is pretty easy, one way is to just assign nullptr to these locals before raising the exception, this would cause the allocated memory to be released. But for std::string it is harder to ensure that the managed memory has actually been released. We can call std::string::clear() and then maybe std::string::shrink_to_fit(), but this is still not guaranteed to release any managed memory. In fact, I believe the only way to ensure all managed memory is released, is to call the std::string destructor. And so, for functions that can throw a guile exception, it is easier to just avoid std::string. As for the memory leak that I identify above; I'll fix that in a follow on commit. Approved-By: Tom Tromey <tom@tromey.com>
2025-06-04gdb/python/guile: fix segfault from nested prefix command creationAndrew Burgess2-13/+26
A commit I recently pushed: commit 0b5023cc71d3af8b18e10e6599a3f9381bc15265 Date: Sat Apr 12 09:15:53 2025 +0100 gdb/python/guile: user created prefix commands get help list can trigger a segfault if a user tries to create nested prefix commands. For example, this will trigger a crash: (gdb) python gdb.ParameterPrefix("prefix-1", gdb.COMMAND_NONE) (gdb) python gdb.ParameterPrefix("prefix-1 prefix-2", gdb.COMMAND_NONE) Fatal signal: Segmentation fault ... etc ... If the user adds an actual parameter under 'prefix-1' before creating 'prefix-2', then everything is fine: (gdb) python gdb.ParameterPrefix("prefix-1", gdb.COMMAND_NONE) (gdb) python gdb.Parameter('prefix-1 param-1', gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN) (gdb) python gdb.ParameterPrefix("prefix-1 prefix-2", gdb.COMMAND_NONE) The mistake in the above patch is in how gdbpy_parse_command_name is used. The BASE_LIST output argument from this function points to the list of commands for the prefix, not to the prefix command itself. So when gdbpy_parse_command_name is called for 'prefix-1 prefix-2', BASE_LIST points to the list of commands associated with 'prefix-1', not to the actual 'prefix-1' cmd_list_element. Back in cmdpy_init, from where gdbpy_parse_command_name was called, I was walking back from the first entry in BASE_LIST to figure out if this was a "show" prefix command or not. However, if BASE_LIST is empty then there is no first item, and this would trigger the segfault. The solution it to extend gdbpy_parse_command_name to also return the prefix cmd_list_element in addition to the existing values. With this done, and cmdpy_init updated, the segfault is now avoided. There's a new test that would trigger the crash without the patch. And, of course, the above commit also broke guile in the exact same way. And the fix is exactly the same. And there's a guile test too. NOTE: We should investigate possibly sharing some of this boiler plate helper code between Python and Guile. But not in this commit. Approved-By: Tom Tromey <tom@tromey.com>
2025-06-03gdb/python/guile: user created prefix commands get help listAndrew Burgess1-7/+35
Consider GDB's builtin prefix set/show prefix sub-commands, if they are invoked with no sub-command name then they work like this: (gdb) show print print address: Printing of addresses is on. print array: Pretty formatting of arrays is off. print array-indexes: Printing of array indexes is off. print asm-demangle: Demangling of C++/ObjC names in disassembly listings is off. ... cut lots of lines ... (gdb) set print List of set print subcommands: set print address -- Set printing of addresses. set print array -- Set pretty formatting of arrays. set print array-indexes -- Set printing of array indexes. set print asm-demangle -- Set demangling of C++/ObjC names in disassembly listings. ... cut lots of lines ... Type "help set print" followed by set print subcommand name for full documentation. Type "apropos word" to search for commands related to "word". Type "apropos -v word" for full documentation of commands related to "word". Command name abbreviations are allowed if unambiguous. (gdb) That is 'show print' lists the values of all settings under the 'print' prefix, and 'set print' lists the help text for all settings under the 'set print' prefix. Now, if we try to create something similar using the Python API: (gdb) python gdb.ParameterPrefix("my-prefix", gdb.COMMAND_NONE) (gdb) python gdb.Parameter("my-prefix foo", gdb.COMMAND_OBSCURE, gdb.PARAM_BOOLEAN) (gdb) show my-prefix (gdb) set my-prefix Neither 'show my-prefix' or 'set my-prefix' gives us the same details relating to the sub-commands that we get with the builtin prefix commands. This commit aims to address this. Currently, in cmdpy_init, when a new command is created, we always set the commands callback function to cmdpy_function. It is within cmdpy_function that we spot that the command is a prefix command, and that there is no gdb.Command.invoke method, and so return early. This commit changes things so that the rules are now: 1. For NON prefix commands, we continue to use cmdpy_function. 2. For prefix commands that do have a gdb.Command.invoke method (i.e. can handle unknown sub-commands), continue to use cmdpy_function. 3. For all other prefix commands, don't use cmdpy_function, instead use GDB's normal callback function for set/show prefixes. This requires splitting the current call to add_prefix_cmd into either a call to add_prefix_cmd, add_show_prefix_cmd, or add_basic_prefix_cmd, as appropriate. After these changes, we now see this: (gdb) python gdb.ParameterPrefix("my-prefix", gdb.COMMAND_NONE) │ (gdb) python gdb.Parameter("my-prefix foo", gdb.COMMAND_OBSCURE, gdb.PARAM_BOOLEAN) (gdb) show my-prefix │ my-prefix foo: The current value of 'my-prefix foo' is "off". (gdb) set my-prefix List of "set my-prefix" subcommands: set my-prefix foo -- Set the current value of 'my-prefix foo'. Type "help set my-prefix" followed by subcommand name for full documentation. Type "apropos word" to search for commands related to "word". Type "apropos -v word" for full documentation of commands related to "word". Command name abbreviations are allowed if unambiguous. (gdb) Which matches how a prefix defined within GDB would act. I have made the same changes to the Guile API.
2025-05-13gdb/guile: generate general description string for parametersAndrew Burgess1-6/+17
This commit builds on the previous one, and auto-generates a general description string for parameters defined via the Guile API. This brings the Guile API closer inline with the Python API. It is worth reading the previous commit to see some motivating examples. This commit updates get_doc_string in guile/scm-param.c to allow for the generation of a general description string. Then in gdbscm_make_parameter, if '#:doc' was not given, get_doc_string is used to generate a suitable default. This does invalidate (and so the commit removes) this comment that was in gdbscm_make_parameter: /* If doc is NULL, leave it NULL. See add_setshow_cmd_full. */ First, Python already does exactly what I'm proposing here, and has done for a while, with no issues reported. And second, I've gone and read add_setshow_cmd_full, and some of the functions it calls, and can see no reasoning behind this comment... ... well, there is one reason that I can think of, but I'll discuss that more below. With this commit, if I define a parameter like this: (use-modules (gdb)) (register-parameter! (make-parameter "print test" #:command-class COMMAND_NONE #:parameter-type PARAM_BOOLEAN)) Then, in GDB, I now see this behaviour: (gdb) help show print test Show the current value of 'print test'. This command is not documented. (gdb) help set print test Set the current value of 'print test'. This command is not documented. (gdb) The two 'This command is not documented.' lines are new. This output is what we get from a similarly defined parameter using the Python API (see the previous commit for an example). I mentioned above that I can think of one reason for the (now deleted) comment in gdbscm_make_parameter about leaving the doc field as NULL, and that is this: consider the following GDB behaviour: (gdb) help show style filename foreground Show the foreground color for this property. (gdb) Notice there is only a single line of output. If I want to get the same behaviour from a parameter defined in Guile, I might try skipping the #:doc argument, but (after this commit), if I do that, GDB will auto-generate some text for me, giving two lines of output (see above). So, next, maybe I try setting #:doc to the empty string, but if I do that, then I get this: (use-modules (gdb)) (register-parameter! (make-parameter "print test" #:doc "" #:command-class COMMAND_NONE #:parameter-type PARAM_BOOLEAN)) (gdb) help show print test Show the current value of 'print test'. (gdb) Notice the blank line, that's not what I wanted. In fact, the only way to get rid of the second line is to leave the 'doc' variable as NULL in gdbscm_make_parameter, which, due to the new auto-generation, is no longer possible. This issue also existed in the Python API, and was addressed in commit: commit 4b68d4ac98aec7cb73a4b276ac7dd38d112786b4 Date: Fri Apr 11 23:45:51 2025 +0100 gdb/python: allow empty gdb.Parameter.__doc__ string After this commit, an empty __doc__ string for a gdb.Parameter is translated into a NULL pointer passed to the add_setshow_* command, which means the second line of output is completely skipped. And this commit includes the same solution for the Guile API. Now, with this commit, and the Guile parameter using an empty '#:doc' string, GDB has the following behaviour: (gdb) help show print test Show the current value of 'print test'. (gdb) This matches the output for a similarly defined parameter in Python.
2025-05-13gdb/guile: improve auto-generated strings for parametersAndrew Burgess1-6/+22
Consider this user defined parameter created in Python: class test_param(gdb.Parameter): def __init__(self, name): super ().__init__(name, gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN) self.value = True test_param('print test') If this is loaded into GDB, then we observe the following behaviour: (gdb) show print test The current value of 'print test' is "on". (gdb) help show print test Show the current value of 'print test'. This command is not documented. (gdb) help set print test Set the current value of 'print test'. This command is not documented. (gdb) If we now define the same parameter using Guile: (use-modules (gdb)) (register-parameter! (make-parameter "print test" #:command-class COMMAND_NONE #:parameter-type PARAM_BOOLEAN)) And load this into a fresh GDB session, we see the following: (gdb) show print test Command is not documented is off. (gdb) help show print test This command is not documented. (gdb) help set print test This command is not documented. (gdb) The output of 'show print test' doesn't make much sense, and is certainly worse than the Python equivalent. For both the 'help' commands it appears as if the first line is missing, but what is actually happening is that the first line has become 'This command is not documented.', and the second line is then missing. The problems can all be traced back to 'get_doc_string' in guile/scm-param.c. This is the guile version of this function. There is a similar function in python/py-param.c, however, the Python version returns one of three different strings depending on the use case. In contrast, the Guile version just returns 'This command is not documented.' in all cases. The three cases that the Python code handles are, the 'set' string, the 'show' string, and the general 'description' string. Right now the Guile get_doc_string only returns the general 'description' string, which is funny, because, in gdbscm_make_parameter, where get_doc_string is used, the one case that we currently don't need is the general 'description' string. Instead, right now, the general 'description' string is used for both the 'set' and 'show' cases. In this commit I plan to bring the Guile API a little more inline with the Python API. I will update get_doc_string (in scm-param.c) to return either a 'set' or 'show' string, and gdbscm_make_parameter will make use of these strings. The changes to the Guile get_doc_string are modelled on the Python version of this function. It is also worth checking out the next commit, which is related, and helps motivate how the changes have been implemented in this commit. After this commit, the same Guile parameter description shown above, now gives this behaviour: (gdb) show print test The current value of 'print test' is off. (gdb) help show print test Show the current value of 'print test'. (gdb) help set print test Set the current value of 'print test'. (gdb) The 'show print test' output now matches the Python behaviour, and is much more descriptive. The set and show 'help' output are now missing the second line when compared to the Python output, but the first line is now correct, and I think this is better than the previous Guile output. In the next commit I'll address the problem of the missing second line. Existing tests have been updated to expect the new output.
2025-05-13gdb/python/guile: check for invalid prefixes in Command/Parameter creationAndrew Burgess1-1/+1
The manual for gdb.Parameter says: If NAME consists of multiple words, and no prefix parameter group can be found, an exception is raised. This makes sense; we cannot create a parameter within a prefix group, if the prefix doesn't exist. And this almost works, so: (gdb) python gdb.Parameter("xxx foo", gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN) Python Exception <class 'RuntimeError'>: Could not find command prefix xxx. Error occurred in Python: Could not find command prefix xxx. The prefix 'xxx' doesn't exist, and we get an error. But, if we try multiple levels of prefix: (gdb) python gdb.Parameter("print xxx foo", gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN) This completes without error, however, we didn't get what we were maybe expecting: (gdb) show print xxx foo Undefined show print command: "xxx foo". Try "help show print". But we did get: (gdb) show print foo The current value of 'print foo' is "off". GDB stopped scanning the prefix string at the unknown 'xxx', and just created the parameter there. I don't think this makes sense, nor is it inline with the manual. An identical problem exists with gdb.Command creation; GDB stops parsing the prefix at the first unknown prefix, and just creates the command there. The manual for gdb.Command says: NAME is the name of the command. If NAME consists of multiple words, then the initial words are looked for as prefix commands. In this case, if one of the prefix commands does not exist, an exception is raised. So again, the correct action is, I believe, to raise an exception. The problem is in gdbpy_parse_command_name (python/py-cmd.c), GDB calls lookup_cmd_1 to look through the prefix string and return the last prefix group. If the very first prefix word is invalid then lookup_cmd_1 returns NULL, and this case is handled. However, if there is a valid prefix, followed by an invalid prefix, then lookup_cmd_1 will return a pointer to the last valid prefix list, and will update the input argument to point to the start of the invalid prefix word. This final case, where the input is left pointing to an unknown prefix, was previously not handled. I've fixed gdbpy_parse_command_name, and added tests for command and parameter creation to cover this case. The exact same error is present in the guile API too. The guile documentation for make-parameter and make-command says the same things about unknown prefixes resulting in an exception, but the same error is present in gdbscm_parse_command_name (guile/scm-cmd.c), so I've fixed that too, and added some tests.
2025-05-06gdb/python/guile: check if styling is disabled in Color.escape_sequenceAndrew Burgess1-2/+9
I noticed that the gdb.Color.escape_sequence() method would produce an escape sequence even when styling is disabled. I think this is the wrong choice. Ideally, when styling is disabled (e.g. with 'set style enabled off'), GDB should not be producing styled output. If a GDB extension is using gdb.Color to apply styling to the output, then currently, the extension should be checking 'show style enabled' any time Color.escape_sequence() is used. This means lots of code duplication, and the possibility that some locations will be missed, which means disabling styling no longer does what it says. I propose that Color.escape_sequence() should return the empty string if styling is disabled. A Python extension can then do: python c_none = gdb.Color('none') c_red = gdb.Color('red') print(c_red.escape_sequence(True) + "Text in red." + c_none.escape_sequence(True)) end If styling is enable this will print some red text. And if styling is disabled, then it will print text in the terminal's default color. I have applied the same fix to the guile API. I have extended the tests to cover this case. Approved-By: Tom Tromey <tom@tromey.com>
2025-04-29[gdb] Handle nullptr gdb_std{err,out} in {gdbpy,ioscm}_flushTom de Vries1-2/+8
Using the trigger patch described in the previous commit, I get: ... $ gdb (gdb) <q>error detected on stdin Fatal signal: Segmentation fault ----- Backtrace ----- 0x64c7b3 gdb_internal_backtrace_1 /data/vries/gdb/src/gdb/bt-utils.c:127 0x64c937 _Z22gdb_internal_backtracev /data/vries/gdb/src/gdb/bt-utils.c:196 0x94db83 handle_fatal_signal /data/vries/gdb/src/gdb/event-top.c:1021 0x94dd48 handle_sigsegv /data/vries/gdb/src/gdb/event-top.c:1098 0x7f372be578ff ??? 0x10b7c0a _Z9gdb_flushP7ui_file /data/vries/gdb/src/gdb/utils.c:1527 0xd4b938 gdbpy_flush /data/vries/gdb/src/gdb/python/python.c:1624 0x7f372d73b276 _PyCFunction_FastCallDict Objects/methodobject.c:231 0x7f372d73b276 _PyCFunction_FastCallKeywords Objects/methodobject.c:294 0x7f372d794a09 call_function Python/ceval.c:4851 0x7f372d78e838 _PyEval_EvalFrameDefault Python/ceval.c:3351 0x7f372d796e6e PyEval_EvalFrameEx Python/ceval.c:754 0x7f372d796e6e _PyFunction_FastCall Python/ceval.c:4933 0x7f372d796e6e _PyFunction_FastCallDict Python/ceval.c:5035 0x7f372d6fefc8 _PyObject_FastCallDict Objects/abstract.c:2310 0x7f372d6fefc8 _PyObject_Call_Prepend Objects/abstract.c:2373 0x7f372d6fe162 _PyObject_FastCallDict Objects/abstract.c:2331 0x7f372d700705 callmethod Objects/abstract.c:2583 0x7f372d700705 _PyObject_CallMethodId Objects/abstract.c:2640 0x7f372d812a41 flush_std_files Python/pylifecycle.c:699 0x7f372d81281d Py_FinalizeEx Python/pylifecycle.c:768 0xd4d49b finalize_python /data/vries/gdb/src/gdb/python/python.c:2308 0x9587eb _Z17ext_lang_shutdownv /data/vries/gdb/src/gdb/extension.c:330 0xfd98df _Z10quit_forcePii /data/vries/gdb/src/gdb/top.c:1817 0x6b3080 _Z12quit_commandPKci /data/vries/gdb/src/gdb/cli/cli-cmds.c:483 0x1056577 stdin_event_handler /data/vries/gdb/src/gdb/ui.c:131 0x1986970 handle_file_event /data/vries/gdb/src/gdbsupport/event-loop.cc:551 0x1986f4b gdb_wait_for_event /data/vries/gdb/src/gdbsupport/event-loop.cc:672 0x1985e0c _Z16gdb_do_one_eventi /data/vries/gdb/src/gdbsupport/event-loop.cc:263 0xb66f2e start_event_loop /data/vries/gdb/src/gdb/main.c:402 0xb670ba captured_command_loop /data/vries/gdb/src/gdb/main.c:466 0xb68b9b captured_main /data/vries/gdb/src/gdb/main.c:1344 0xb68c44 _Z8gdb_mainP18captured_main_args /data/vries/gdb/src/gdb/main.c:1363 0x41a3b1 main /data/vries/gdb/src/gdb/gdb.c:38 --------------------- A fatal error internal to GDB has been detected, further debugging is not possible. GDB will now terminate. This is a bug, please report it. For instructions, see: <https://www.gnu.org/software/gdb/bugs/>. Segmentation fault (core dumped) $ q ... Fix this in gdbpy_flush by checking for nullptr gdb_stdout/gdb_stderr (and likewise in ioscm_flush) such that we get instead: ... $ gdb (gdb) <q>error detected on stdin $ q ... Tested on x86_64-linux. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-04-08Update copyright dates to include 2025Tom Tromey36-36/+36
This updates the copyright headers to include 2025. I did this by running gdb/copyright.py and then manually modifying a few files as noted by the script. Approved-By: Eli Zaretskii <eliz@gnu.org>
2025-04-03Make gdb/guile codespell-cleanTom Tromey1-1/+1
This cleans up the last codespell reports in the Guile directory and adds gdb/guile to pre-commit. It also tells codespell to ignore URLs. I think this is warranted because many URLs don't really contain words per se; and furthermore if any URL-checking is needed at all, it would be for liveness and not spelling. Also I was wondering why the codespell config is in contrib and not gdb/setup.cfg. Approved-By: Tom de Vries <tdevries@suse.de>
2025-03-17Fix Guile pretty printer display hintsLucy Kingsbury1-2/+2
All 3 valid Guile pretty printer display hints are treated as the value "string". As a result, if a printer specifies "array" or "map", the output is instead formatted as a string. This humble patch corrects the issue.
2025-03-06[gdb/guile] Fix typosTom de Vries2-2/+2
Fix typos: ... gdb/guile/scm-lazy-string.c:41: sting ==> string gdb/guile/lib/gdb/iterator.scm:65: satify ==> satisfy ...
2025-01-28[gdb/guile] Use SCM_DEBUG_TYPING_STRICTNESS 0Tom de Vries1-11/+18
I build gdb with libguile v2.0.9, and ran into: ... In file included from /usr/include/guile/2.0/libguile.h:56, from ../../gdb/guile/guile-internal.h:30, from ../../gdb/guile/scm-arch.c:26: /usr/include/guile/2.0/libguile/inline.h: In function 'int scm_is_pair(SCM)': /usr/include/guile/2.0/libguile/tags.h:97:53: error: \ operation on '*0' may be undefined [-Werror=sequence-point] # define SCM_UNPACK(x) ((scm_t_bits) (0? (*(SCM*)0=(x)): x)) ~~~~~~~~~^~~~~ ... Fix this by using SCM_DEBUG_TYPING_STRICTNESS 0. We were already using this for c++20 due to a Werror=volatile in SCM_UNPACK when using libguile v2.0.10. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2025-01-12Add an option with a color type.Andrei Pikas4-3/+467
Colors can be specified as "none" for terminal's default color, as a name of one of the eight standard colors of ISO/IEC 6429 "black", "red", "green", etc., as an RGB hexadecimal tripplet #RRGGBB for 24-bit TrueColor, or as an integer from 0 to 255. Integers 0 to 7 are the synonyms for the standard colors. Integers 8-15 are used for the so-called bright colors from the aixterm extended 16-color palette. Integers 16-255 are the indexes into xterm extended 256-color palette (usually 6x6x6 cube plus gray ramp). In general, 256-color palette is terminal dependent and sometimes can be changed with OSC 4 sequences, e.g. "\033]4;1;rgb:00/FF/00\033\\". It is the responsibility of the user to verify that the terminal supports the specified colors. PATCH v5 changes: documentation fixed. PATCH v6 changes: documentation fixed. PATCH v7 changes: rebase onto master and fixes after review. PATCH v8 changes: fixes after review.
2025-01-10[gdb/build, c++20] Fix build with gcc 10Tom de Vries1-1/+7
With gcc 10 and -std=c++20, we run into the same problem as reported in commit 6feae66da1d ("[gdb/build, c++20] Handle deprecated std::allocator::construct"). The problem was fixed using: ... -template<typename T, typename A = std::allocator<T>> +template<typename T, + typename A +#if __cplusplus >= 202002L + = std::pmr::polymorphic_allocator<T> +#else + = std::allocator<T> +#endif + > ... but that doesn't work for gcc 10, because it defines __cplusplus differently: ... $ echo | g++-10 -E -dD -x c++ - -std=c++20 2>&1 | grep __cplusplus #define __cplusplus 201709L $ echo | g++-11 -E -dD -x c++ - -std=c++20 2>&1 | grep __cplusplus #define __cplusplus 202002L ... Fix this by using the library feature test macro __cpp_lib_polymorphic_allocator [1], which is undefined for c++17 and defined for c++20: ... $ echo | g++-10 -E -dD -x c++ - -include memory_resource -std=c++17 2>&1 \ | grep __cpp_lib_polymorphic_allocator $ echo | g++-10 -E -dD -x c++ - -include memory_resource -std=c++20 2>&1 \ | grep __cpp_lib_polymorphic_allocator #define __cpp_lib_polymorphic_allocator 201902L $ ... A similar problem exists for commit 3173529d7de ("[gdb/guile, c++20] Work around Werror=volatile in libguile.h"). Fix this by testing for 201709L instead. Tested on x86_64-linux, by building gdb with {gcc 10, clang 17.0.6} x {-std=c++17, -std=c++20}. PR build/32503 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32503 Approved-By: Tom Tromey <tom@tromey.com> [1] https://en.cppreference.com/w/cpp/feature_test#cpp_lib_polymorphic_allocator
2024-12-18Run check-include-guards.pyTom Tromey2-6/+6
This patch is the result of running check-include-guards.py on the current tree. Running it a second time causes no changes. Reviewed-By: Tom de Vries <tdevries@suse.de>
2024-11-25Convert type copying to new hash tableSimon Marchi3-6/+6
This converts the type copying code to use the new hash map. Change-Id: I35f0a4946dcc5c5eb84820126cf716b600f3302f Co-Authored-By: Tom Tromey <tom@tromey.com> Approved-By: Tom Tromey <tom@tromey.com>
2024-11-23[gdb/contrib] Add two rules in common-misspellings.txtTom de Vries2-3/+3
Eli mentioned [1] that given that we use US English spelling in our documentation, we should use "behavior" instead of "behaviour". In wikipedia-common-misspellings.txt there's a rule: ... behavour->behavior, behaviour ... which leaves this as a choice. Add an overriding rule to hardcode the choice to common-misspellings.txt: ... behavour->behavior ... and add a rule to rewrite behaviour into behavior: ... behaviour->behavior ... and re-run spellcheck.sh on gdb*. Tested on x86_64-linux. [1] https://sourceware.org/pipermail/gdb-patches/2024-November/213371.html
2024-10-21gdb/guile: add get-basic-typeAndrew Burgess1-0/+19
A question was asked on stackoverflow.com about the guile function get-basic-type[1] which is mentioned in the docs along with an example of its use. The problem is, the function was apparently never actually added to GDB. But it turns out that it's pretty easy to implement, so lets add it now. Better late than never. The implementation mirrors the Python get_basic_type function. I've added a test which is a copy of the documentation example. One issue is that the docs suggest that the type will be returned as just "int", however, I'm not sure what this actually means. It makes more sense that the function return a gdb:type object which would be represented as "#<gdb:type int>", so I've updated the docs to show this output. [1] https://stackoverflow.com/questions/79058691/unbound-variable-get-basic-type-in-gdb-guile-session Reviewed-By: Kevin Buettner <kevinb@redhat.com>
2024-10-19[gdb/guile, c++20] Work around Werror=volatile in libguile.hTom de Vries1-1/+8
When building gdb with -std=c++20, I run into: ... In file included from /usr/include/guile/2.0/libguile/__scm.h:479, from /usr/include/guile/2.0/libguile.h:31, from /data/vries/gdb/src/gdb/guile/guile-internal.h:30, from /data/vries/gdb/src/gdb/guile/guile.c:37: /usr/include/guile/2.0/libguile/gc.h: In function ‘scm_unused_struct* \ scm_cell(scm_t_bits, scm_t_bits)’: /usr/include/guile/2.0/libguile/tags.h:98:63: error: using value of \ assignment with ‘volatile’-qualified left operand is deprecated \ [-Werror=volatile] 98 | # define SCM_UNPACK(x) ((scm_t_bits) (0? (*(volatile SCM *)0=(x)): x)) | ~~~~~~~~~~~~~~~~~~~^~~~~ ... This was reported upstream [1]. Work around this by using SCM_DEBUG_TYPING_STRICTNESS == 0 instead of the default SCM_DEBUG_TYPING_STRICTNESS == 1. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com> PR guile/30767 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30767 [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65333
2024-09-07gdb: split apart two different types of filename completionAndrew Burgess1-1/+1
Unfortunately we have two different types of filename completion in GDB. The majority of commands have what I call unquoted filename completion, this is for commands like 'set logging file ...', 'target core ...', and 'add-auto-load-safe-path ...'. For these commands everything after the command name (that is not a command option) is treated as a single filename. If the filename contains white space then this does not need to be escaped, nor does the filename need to be quoted. In fact, the filename argument is not de-quoted, and does not have any escaping removed, so if a user does try to add such things, they will be treated as part of the filename. As an example: (gdb) target core "/path/that contains/some white space" Will look for a directory calls '"' (double quotes) in the local directory. A small number of commands do de-quote and remove escapes from filename arguments. These command accept what I call quoted and escaped filenames. Right now these are the commands that specify the file for GDB to debug, so: file exec-file symbol-file add-symbol-file remove-symbol-file As an example of this in action: (gdb) file "/path/that contains/some white space" In this case GDB would load the file: /path/that contains/some white space Current filename completion always assumes that filenames can be quoted, though escaping doesn't work in completion right now. But the assumption that quoting is allowed is clearly wrong. This commit splits filename completion into two. The existing filename_completer is retained, and is used for unquoted filenames. A second filename_maybe_quoted_completer is added which can be used for completing quoted filenames. The filename completion test has been extended to cover more cases. As part of the extended testing I need to know the character that should be used to separate filenames within a path. For this TCL 8.6+ has $::tcl_platform(pathSeparator). To support older versions of TCL I've added some code to testsuite/lib/gdb.exp. You might notice that after this commit the completion for unquoted files is all done in the brkchars phase, that is the function filename_completer_handle_brkchars calculates the completions and marks the completion_tracker as using a custom word point. The reason for this is that we don't want to break on white space for this completion, but if we rely on readline to find the completion word, readline will consider the entire command line, and with no white space in the word break character set, readline will end up using the entire command line as the word to complete. For now at least, the completer for quoted filenames does generate its completions during the completion phase, though this is going to change in a later commit.
2024-08-14btrace, python: Enable ptwrite filter registration.Felix Willgerodt1-0/+1
By default GDB will be printing the hex payload of the ptwrite package as auxiliary information. To customize this, the user can register a ptwrite filter function in python, that takes the payload and the PC as arguments and returns a string which will be printed instead. Registering the filter function is done using a factory pattern to make per-thread filtering easier. Approved-By: Markus Metzger <markus.t.metzger@intel.com>
2024-07-16gdb, gdbserver, gdbsupport: use [[noreturn]] instead of ATTRIBUTE_NORETURNSimon Marchi1-14/+14
C++ 11 has a built-in attribute for this, no need to use a compat macro. Change-Id: I90e4220d26e8f3949d91761f8a13cd9c37da3875 Reviewed-by: Lancelot Six <lancelot.six@amd.com>
2024-07-15gdb: make objfile::pspace privateSimon Marchi1-1/+1
Rename to m_pspace, add getter. An objfile's pspace never changes, so no setter is necessary. Change-Id: If4dfb300cb90dc0fb9776ea704ff92baebb8f626
2024-04-25gdb: remove gdbcmd.hSimon Marchi5-5/+3
Most files including gdbcmd.h currently rely on it to access things actually declared in cli/cli-cmds.h (setlist, showlist, etc). To make things easy, replace all includes of gdbcmd.h with includes of cli/cli-cmds.h. This might lead to some unused includes of cli/cli-cmds.h, but it's harmless, and much faster than going through the 170 or so files by hand. Change-Id: I11f884d4d616c12c05f395c98bbc2892950fb00f Approved-By: Tom Tromey <tom@tromey.com>
2024-03-26gdb, gdbserver, gdbsupport: remove includes of early headersSimon Marchi25-25/+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-27Add extension_language_ops::shutdownTom Tromey1-0/+1
Right now, Python is shut down via a final cleanup. However, it seems to me that it is better for extension languages to be shut down explicitly, after all the ordinary final cleanups are run. The main reason for this is that a subsequent patch adds another case like finalize_values; and rather than add a series of workarounds for Python shutdown, it seemed better to let these be done via final cleanups, and then have Python shutdown itself be the special case.
2024-01-29gdb: Use SYM_DOMAIN instead of DOMAIN when calling sym-domains.defLancelot SIX1-2/+2
Since commit 6771fc6f1d9 "Use a .def file for domain_enum", the sym-domains.def file has been introduced, and requires the user to define the DOMAIN(x) macro. On older systems (centos-7 with glibc-2.17 for example), this DOMAIN macro conflicts with another macro defined in /usr/include/math.h. Fix this conflict by changing sym-domains.def to use a macro named SYM_DOMAIN instead of DOMAIN. Change-Id: I679df30e2bd2f4333343f16bbd2a3511a37550a3 Approved-By: Tom Tromey <tom@tromey.com>
2024-01-28Use domain_search_flags in lookup_symbol et alTom Tromey2-8/+11
This changes lookup_symbol and associated APIs to accept domain_search_flags rather than a domain_enum. Note that this introduces some new constants to Python and Guile. I chose to break out the documentation patch for this, because the internals here do not change until a later patch, and it seemed simpler to patch the docs just once, rather than twice.
2024-01-28Use a .def file for domain_enumTom Tromey1-8/+10
Future patches will change and reuse the names from domain_enum. This patch makes this less error-prone by having a single point to define these names, using the typical gdb ".def" file.
2024-01-12Update copyright year range in header of all files managed by GDBAndrew Burgess35-35/+35
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-12-14gdb: change value_of_register and value_of_register_lazy to take the next frameSimon Marchi1-1/+2
Some functions related to the handling of registers in frames accept "this frame", for which we want to read or write the register values, while other functions accept "the next frame", which is the frame next to that. The later is needed because we sometimes need to read register values for a frame that does not exist yet (usually when trying to unwind that frame-to-be). value_of_register and value_of_register_lazy both take "this frame", even if what they ultimately want internally is "the next frame". This is annoying if you are in a spot that currently has "the next frame" and need to call one of these functions (which happens later in this series). You need to get the previous frame only for those functions to get the next frame again. This is more manipulations, more chances of mistake. I propose to change these functions (and a few more functions in the subsequent patches) to operate on "the next frame". Things become a bit less awkward when all these functions agree on which frame they take. So, in this patch, change value_of_register_lazy and value_of_register to take "the next frame" instead of "this frame". This adds a lot of get_next_frame_sentinel_okay, but if we convert the user registers API to also use "the next frame" instead of "this frame", it will get simple again. Change-Id: Iaa24815e648fbe5ae3c214c738758890a91819cd Reviewed-By: John Baldwin <jhb@FreeBSD.org>
2023-11-21gdb: Replace gdb::optional with std::optionalLancelot Six1-2/+2
Since GDB now requires C++17, we don't need the internally maintained gdb::optional implementation. This patch does the following replacing: - gdb::optional -> std::optional - gdb::in_place -> std::in_place - #include "gdbsupport/gdb_optional.h" -> #include <optional> This change has mostly been done automatically. One exception is gdbsupport/thread-pool.* which did not use the gdb:: prefix as it already lives in the gdb namespace. Change-Id: I19a92fa03e89637bab136c72e34fd351524f65e9 Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net>
2023-10-05gdb: add program_space parameters to some auto-load functionsSimon Marchi1-1/+2
Make the current_program_space references bubble up a bit. Change-Id: Id047a48cc8d8a45504cdbb5960bafe3e7735d652 Approved-By: Tom Tromey <tom@tromey.com>
2023-09-20Remove explanatory comments from includesTom Tromey6-8/+8
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-19Use gdb::checked_static_cast for watchpointsTom Tromey1-2/+1
This replaces some casts to 'watchpoint *' with checked_static_cast. In one spot, an unnecessary block is also removed. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-08-31gdb: remove FIELD_ARTIFICIALSimon Marchi1-1/+1
Replace uses with field::is_artificial. Change-Id: I599616fdd9f4b6d044de492e8151aa6130725cd1 Approved-By: Tom Tromey <tom@tromey.com>
2023-08-17gdb: add inferior-specific breakpointsAndrew Burgess1-1/+6
This commit extends the breakpoint mechanism to allow for inferior specific breakpoints (but not watchpoints in this commit). As GDB gains better support for multiple connections, and so for running multiple (possibly unrelated) inferiors, then it is not hard to imagine that a user might wish to create breakpoints that apply to any thread in a single inferior. To achieve this currently, the user would need to create a condition possibly making use of the $_inferior convenience variable, which, though functional, isn't the most user friendly. This commit adds a new 'inferior' keyword that allows for the creation of inferior specific breakpoints. Inferior specific breakpoints are automatically deleted when the associated inferior is removed from GDB, this is similar to how thread-specific breakpoints are deleted when the associated thread is deleted. Watchpoints are already per-program-space, which in most cases mean watchpoints are already inferior specific. There is a small window where inferior-specific watchpoints might make sense, which is after a vfork, when two processes are sharing the same address space. However, I'm leaving that as an exercise for another day. For now, attempting to use the inferior keyword with a watchpoint will give an error, like this: (gdb) watch a8 inferior 1 Cannot use 'inferior' keyword with watchpoints A final note on the implementation: currently, inferior specific breakpoints, like thread-specific breakpoints, are inserted into every inferior, GDB then checks once the inferior stops if we are in the correct thread or inferior, and resumes automatically if we stopped in the wrong thread/inferior. An obvious optimisation here is to only insert breakpoint locations into the specific program space (which mostly means inferior) that contains either the inferior or thread we are interested in. This would reduce the number times GDB has to stop and then resume again in a multi-inferior setup. I have a series on the mailing list[1] that implements this optimisation for thread-specific breakpoints. Once this series has landed I'll update that series to also handle inferior specific breakpoints in the same way. For now, inferior specific breakpoints are just slightly less optimal, but this is no different to thread-specific breakpoints in a multi-inferior debug session, so I don't see this as a huge problem. [1] https://inbox.sourceware.org/gdb-patches/cover.1685479504.git.aburgess@redhat.com/
2023-08-14[gdb/build] Fix enum param_types odr violationTom de Vries1-5/+5
When building gdb with -O2 -flto, I run into: ... gdb/guile/scm-param.c:121:6: warning: type 'param_types' violates the C++ \ One Definition Rule [-Wodr] enum param_types ^ gdb/python/py-param.c:33:6: note: an enum with different value name is \ defined in another translation unit enum param_types ^ ... Fix this by renaming to enum scm_param_types and py_param_types. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com> PR build/22395 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
2023-06-05gdb: building inferior strings from within GDBAndrew Burgess1-3/+1
History Of This Patch ===================== This commit aims to address PR gdb/21699. There have now been a couple of attempts to fix this issue. Simon originally posted two patches back in 2021: https://sourceware.org/pipermail/gdb-patches/2021-July/180894.html https://sourceware.org/pipermail/gdb-patches/2021-July/180896.html Before Pedro then posted a version of his own: https://sourceware.org/pipermail/gdb-patches/2021-July/180970.html After this the conversation halted. Then in 2023 I (Andrew) also took a look at this bug and posted two versions: https://sourceware.org/pipermail/gdb-patches/2023-April/198570.html https://sourceware.org/pipermail/gdb-patches/2023-April/198680.html The approach taken in my first patch was pretty similar to what Simon originally posted back in 2021. My second attempt was only a slight variation on the first. Pedro then pointed out his older patch, and so we arrive at this patch. The GDB changes here are mostly Pedro's work, but updated by me (Andrew), any mistakes are mine. The tests here are a combinations of everyone's work, and the commit message is new, but copies bits from everyone's earlier work. Problem Description =================== Bug PR gdb/21699 makes the observation that using $_as_string with GDB's printf can cause GDB to print unexpected data from the inferior. The reproducer is pretty simple: #include <stddef.h> static char arena[100]; /* Override malloc() so value_coerce_to_target() gets a known pointer, and we know we"ll see an error if $_as_string() gives a string that isn't null terminated. */ void *malloc (size_t size) { memset (arena, 'x', sizeof (arena)); if (size > sizeof (arena)) return NULL; return arena; } int main () { return 0; } And then in a GDB session: $ gdb -q test Reading symbols from /tmp/test... (gdb) start Temporary breakpoint 1 at 0x4004c8: file test.c, line 17. Starting program: /tmp/test Temporary breakpoint 1, main () at test.c:17 17 return 0; (gdb) printf "%s\n", $_as_string("hello") "hello"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (gdb) quit The problem above is caused by how value_cstring is used within py-value.c, but once we understand the issue then it turns out that value_cstring is used in an unexpected way in many places within GDB. Within py-value.c we have a null-terminated C-style string. We then pass a pointer to this string, along with the length of this string (so not including the null-character) to value_cstring. In value_cstring GDB allocates an array value of the given character type, and copies in requested number of characters. However value_cstring does not add a null-character of its own. This means that the value created by calling value_cstring is only null-terminated if the null-character is included in the passed in length. In py-value.c this is not the case, and indeed, in most uses of value_cstring, this is not the case. When GDB tries to print one of these strings the value contents are pushed to the inferior, and then read back as a C-style string, that is, GDB reads inferior memory until it finds a null-terminator. For the py-value.c case, no null-terminator is pushed into the inferior, so GDB will continue reading inferior memory until a null-terminator is found, with unpredictable results. Patch Description ================= The first thing this patch does is better define what the arguments for the two function value_cstring and value_string should represent. The comments in the header file are updated to describe whether the length argument should, or should not, include a null-character. Also, the data argument is changed to type gdb_byte. The functions as they currently exist will handle wide-characters, in which case more than one 'char' would be needed for each character. As such using gdb_byte seems to make more sense. To avoid adding casts throughout GDB, I've also added an overload that still takes a 'char *', but asserts that the character type being used is of size '1'. The value_cstring function is now responsible for adding a null character at the end of the string value it creates. However, once we start looking at how value_cstring is used, we realise there's another, related, problem. Not every language's strings are null terminated. Fortran and Ada strings, for example, are just an array of characters, GDB already has the function value_string which can be used to create such values. Consider this example using current GDB: (gdb) set language ada (gdb) p $_gdb_setting("arch") $1 = (97, 117, 116, 111) (gdb) ptype $ type = array (1 .. 4) of char (gdb) p $_gdb_maint_setting("test-settings string") $2 = (0) (gdb) ptype $ type = array (1 .. 1) of char This shows two problems, first, the $_gdb_setting and $_gdb_maint_setting functions are calling value_cstring using the builtin_char character, rather than a language appropriate type. In the first call, the 'arch' case, the value_cstring call doesn't include the null character, so the returned array only contains the expected characters. But, in the $_gdb_maint_setting example we do end up including the null-character, even though this is not expected for Ada strings. This commit adds a new language method language_defn::value_string, this function takes a pointer and length and creates a language appropriate value that represents the string. For C, C++, etc this will be a null-terminated string (by calling value_cstring), and for Fortran and Ada this can be a bounded array of characters with no null terminator. Additionally, this new language_defn::value_string function is responsible for selecting a language appropriate character type. After this commit the only calls to value_cstring are from the C expression evaluator and from the default language_defn::value_string. And the only calls to value_string are from Fortan, Ada, and ObjectC related code. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21699 Co-Authored-By: Simon Marchi <simon.marchi@efficios.com> Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Co-Authored-By: Pedro Alves <pedro@palves.net> Approved-By: Simon Marchi <simon.marchi@efficios.com>
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-06-03[gdb/guile] Fix doc string for value-optimized-out?Tom de Vries1-1/+1
In gdb/guile/scm-value.c, I noticed in the value_functions array initializer: ... { "value-optimized-out?", 1, 0, 0, as_a_scm_t_subr (gdbscm_value_optimized_out_p), "\ Return #t if the value has been optimizd out." }, ... There's a typo in the doc string. Fix this by using "optimized". Reviewed-By: Tom Tromey <tom@tromey.com>
2023-05-25gdb: remove breakpoint_pointer_iteratorSimon Marchi1-2/+2
Remove the breakpoint_pointer_iterator layer. Adjust all users of all_breakpoints and all_tracepoints to use references instead of pointers. Change-Id: I376826f812117cee1e6b199c384a10376973af5d Reviewed-By: Andrew Burgess <aburgess@redhat.com>
2023-05-12Add dynamic_prop::is_constantTom Tromey1-2/+2
I noticed many spots checking whether a dynamic property's kind is PROP_CONST. Some spots, I think, are doing a slightly incorrect check -- checking for != PROP_UNDEFINED where == PROP_CONST is actually required, the key thing being that const_val may only be called for PROP_CONST properties. This patch adds dynamic::is_constant and then updates these checks to use it. Regression tested on x86-64 Fedora 36.
2023-05-01gdb: move struct ui and related things to ui.{c,h}Simon Marchi2-1/+2
I'd like to move some things so they become methods on struct ui. But first, I think that struct ui and the related things are big enough to deserve their own file, instead of being scattered through top.{c,h} and event-top.c. Change-Id: I15594269ace61fd76ef80a7b58f51ff3ab6979bc
2023-03-09gdb, gdbserver, gdbsupport: fix whitespace issuesSimon Marchi1-1/+1
Replace spaces with tabs in a bunch of places. Change-Id: If0f87180f1d13028dc178e5a8af7882a067868b0
2023-02-27Guile QUIT processing updatesKevin Buettner4-0/+20
This commit contains QUIT processing updates for GDB's Guile support. As with the Python updates, we don't want to permit this code to swallow the exception, gdb_exception_forced_quit, which is associated with GDB receiving a SIGTERM. I've adopted the same solution that I used for Python; whereever a gdb_exception is caught in try/catch code in the Guile extension language support, a catch for gdb_exception_forced_quit has been added; this catch block will simply call quit_force(), which will cause the necessary cleanups to occur followed by GDB exiting. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26761 Tested-by: Tom de Vries <tdevries@suse.de> Approved-By: Pedro Alves <pedro@palves.net>
2023-02-19Convert explicit iterator uses to foreachTom Tromey1-6/+1
This converts most existing explicit uses of block_iterator to use foreach with the range iterator instead.