aboutsummaryrefslogtreecommitdiff
path: root/gdb/language.c
AgeCommit message (Collapse)AuthorFilesLines
2024-11-11Add setting to control frame language mismatch warningTom Tromey1-1/+14
A customer noted that there is no way to prevent the "current language does not match this frame" warning. This patch adds a new setting to allow this warning to be suppressed. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-08-15Add another constructor to scoped_restore_current_languageTom Tromey1-0/+7
While working on something else, I noticed that this is relatively common: scoped_restore_current_language save; set_language (something); This patch adds a second constructor to scoped_restore_current_language to simplify this idiom. Reviewed-By: Tom de Vries <tdevries@suse.de>
2024-04-25gdb: remove gdbcmd.hSimon Marchi1-1/+1
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 Marchi1-1/+0
Now that defs.h, server.h and common-defs.h are included via the `-include` option, it is no longer necessary for source files to include them. Remove all the inclusions of these files I could find. Update the generation scripts where relevant. Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837 Approved-By: Pedro Alves <pedro@palves.net>
2024-01-28Use the new symbol domainsTom Tromey1-1/+1
This patch changes the DWARF reader to use the new symbol domains. It also adjusts many bits of associated code to adapt to this change. The non-DWARF readers are updated on a best-effort basis. This is somewhat simpler since most of them only support C and C++. I have no way to test a few of these. I went back and forth a few times on how to handle the "tag" situation. The basic problem is that C has a special namespace for tags, which is separate from the type namespace. Other languages don't do this. So, the question is, should a DW_TAG_structure_type end up in the tag domain, or the type domain, or should it be language-dependent? I settled on making it language-dependent using a thought experiment. Suppose there was a Rust compiler that only emitted nameless DW_TAG_structure_type objects, and specified all structure type names using DW_TAG_typedef. This DWARF would be correct, in that it faithfully represents the source language -- but would not work with a purely struct-domain implementation in gdb. Therefore gdb would be wrong. Now, this approach is a little tricky for C++, which uses tags but also enters a typedef for them. I notice that some other readers -- like stabsread -- actually emit a typedef symbol as well. And, I think this is a reasonable approach. It uses more memory, but it makes the internals simpler. However, DWARF never did this for whatever reason, and so in the interest of keeping the series slightly shorter, I've left some C++-specific hacks in place here. Note that this patch includes language_minimal as a language that uses tags. I did this to avoid regressing gdb.dwarf2/debug-names-tu.exp, which doesn't specify the language for a type unit. Arguably this test case is wrong. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30164
2024-01-28Use domain_search_flags in lookup_symbol et alTom Tromey1-1/+2
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-12Update copyright year range in header of all files managed by GDBAndrew Burgess1-1/+1
This commit is the result of the following actions: - Running gdb/copyright.py to update all of the copyright headers to include 2024, - Manually updating a few files the copyright.py script told me to update, these files had copyright headers embedded within the file, - Regenerating gdbsupport/Makefile.in to refresh it's copyright date, - Using grep to find other files that still mentioned 2023. If these files were updated last year from 2022 to 2023 then I've updated them this year to 2024. I'm sure I've probably missed some dates. Feel free to fix them up as you spot them.
2024-01-08Lazy language settingTom Tromey1-0/+35
When gdb starts up with a symbol file, it uses the program's "main" to decide the "static context" and the initial language. With background DWARF reading, this means that gdb has to wait for a significant amount of DWARF to be read synchronously. This patch introduces lazy language setting. The idea here is that in many cases, the prompt can show up early, making gdb feel more responsive.
2024-01-08Change current_language to be a macroTom Tromey1-4/+12
This changes the 'current_language' global to be a macro that wraps a function call. This change will let a subsequent patch introduce lazy language setting.
2023-11-21gdb: Use std::string_view instead of gdb::string_viewLancelot Six1-1/+1
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-06-05gdb: building inferior strings from within GDBAndrew Burgess1-0/+10
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-05-03Pass const frame_info_ptr reference for skip_[language_]trampolineMark Wielaard1-1/+1
g++ 13.1.1 produces a -Werror=dangling-pointer= In file included from ../../binutils-gdb/gdb/frame.h:75, from ../../binutils-gdb/gdb/symtab.h:40, from ../../binutils-gdb/gdb/language.c:33: In member function ‘void intrusive_list<T, AsNode>::push_empty(T&) [with T = frame_info_ptr; AsNode = intrusive_base_node<frame_info_ptr>]’, inlined from ‘void intrusive_list<T, AsNode>::push_back(reference) [with T = frame_info_ptr; AsNode = intrusive_base_node<frame_info_ptr>]’ at gdbsupport/intrusive_list.h:332:24, inlined from ‘frame_info_ptr::frame_info_ptr(const frame_info_ptr&)’ at gdb/frame.h:241:26, inlined from ‘CORE_ADDR skip_language_trampoline(frame_info_ptr, CORE_ADDR)’ at gdb/language.c:530:49: gdbsupport/intrusive_list.h:415:12: error: storing the address of local variable ‘<anonymous>’ in ‘frame_info_ptr::frame_list.intrusive_list<frame_info_ptr>::m_back’ [-Werror=dangling-pointer=] 415 | m_back = &elem; | ~~~~~~~^~~~~~~ gdb/language.c: In function ‘CORE_ADDR skip_language_trampoline(frame_info_ptr, CORE_ADDR)’: gdb/language.c:530:49: note: ‘<anonymous>’ declared here 530 | CORE_ADDR real_pc = lang->skip_trampoline (frame, pc); | ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~ gdb/frame.h:359:41: note: ‘frame_info_ptr::frame_list’ declared here 359 | static intrusive_list<frame_info_ptr> frame_list; | ^~~~~~~~~~ Each new frame_info_ptr is being pushed on a static frame list and g++ cannot see why that is safe in case the frame_info_ptr is created and destroyed immediately when passed as value. It isn't clear why only in this one place g++ sees the issue (probably because it can inline enough code in this specific case). Since passing the frame_info_ptr as const reference is cheaper, use that as workaround for this warning. PR build/30413 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30413 Tested-by: Kevin Buettner <kevinb@redhat.com> Reviewed-by: Kevin Buettner <kevinb@redhat.com> Reviewed-by: Tom Tromey <tom@tromey.com>
2023-04-27gdb: remove some trailing newlines from warning messagesAndrew Burgess1-4/+4
While working on a later patch in this series, which tightens up some of our pattern matching when using gdb_test, I ran into some failures caused by some warnings having a trailing newline character. The warning function already adds a trailing newline, and it is my understanding that we should not be adding a second by including a newline at the end of any warning message. The problem cases I found were in language.c and remote.c, in this patch I fix the cases I hit, but I also checked all the other warning calls in these two files and removed any additional trailing newlines I found. In remote.c the warning actually had a newline character in the middle of the warning message (in addition to the trailing newline), which I've removed. I don't think it's helpful to forcibly split a warning as was done here -- in the middle of a sentence. Additionally, the message isn't even that long (71 characters), so I think removing this newline is an improvement. None of the expected test result need updating with this commit, currently the patterns in gdb_test will match one or more newline sequences, so the tests are as happy with one newline (after this commit) as they are with two newlines (before this commit). A later commit will change gdb_test so that it is not so forgiving, and these warnings would have caused some failures. Reviewed-By: Tom Tromey <tom@tromey.com>
2023-04-21gdb: remove language_autoSimon Marchi1-92/+43
I think that the language_auto enumerator and the auto_language class can be removed. There isn't really an "auto" language, it's only a construct of the "set language" command to say "pick the appropriate language automatically". But "auto" is never the current language. The `current_language` points to the current effective language, and the fact that we're in "auto language" mode is noted by the language_mode global. - Change set_language to handle the "auto" (and "local", which is a synonym) early, instead of in the for loop. I think it makes the two cases (auto vs explicit language) more clearly separated anyway. - Adjust add_set_language_command to hard-code the "auto" string, instead of using the "auto" language definition. - Remove auto_language, rename auto_or_unknown_language to unknown_language and move the bits of the existing unknown_language in there. - Remove the set_language at the end of _initialize_language. I think it's not needed, because we call set_language in gdb_init, after all _initialize functions are called. There is some chance that an _initialize function that runs after _initialize_language implicitly depends on current_language being set, but my testsuite runs haven't found anything like that. - Use language_unknown instead of language_auto when creating a minimal symbol (minimal_symbol_reader::record_full). I think that this value is used to indicate that we don't know the symbol of the minimal symbol (yet), so language_unknown makes sense to me. Update a condition accordingly in ada-lang.c. symbol_find_demangled_name also appears to "normalize" this value from "unknown" to "auto", remove that part and update the condition to just check for language_unknown. Change-Id: I47bcd6c15f607d9818f2e6e413053c2dc8ec5034 Reviewed-By: Tom Tromey <tom@tromey.com>
2023-04-21gdb: switch "set language" to getter/setterSimon Marchi1-9/+19
The `language` global variable is mostly a scratch variable used for the setting. The source of truth is really current_language and language_mode (auto vs manual), which are set by the set_language_command callback. Switch the setting to use the add_setshow_enum_cmd overload that takes a value getter and setter. Change-Id: Ief5b2f93fd7337eed7ec96023639ae3dfe62250b Reviewed-By: Tom Tromey <tom@tromey.com>
2023-04-21gdb: remove return value of set_languageSimon Marchi1-12/+2
set_language returns the previous language, but nothing uses it. Remove the return value. This lets us remove the assignment to current_language, in _initialize_language. Change-Id: Ifccf9b488434c1addf4626130a74e159a37d8c17 Reviewed-By: Tom Tromey <tom@tromey.com>
2023-03-31Remove language_demangleTom Tromey1-15/+0
I noticed that language_demangle shadows the global "current_language". When I went to fix this, though, I then saw that language_demangle is only called in two places, and has a comment saying it should be removed. This patch removes it. Note that the NULL check in language_demangle is not needed by either of the existing callers. Regression tested on x86-64 Fedora 36. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-20gdb: move compile_instance to compile/compile.hSimon Marchi1-1/+0
struct compile_instance needs to be visible to users, since we use std::unique<compile_instance>. language.c and c-lang.c currently includes compile-internal.h for this reason, which kind of defeats the purpose of having an "internal" header file. Change-Id: Iedffe5f1173b3de7bdc1be533ee2a68e6f6c549f Reviewed-By: Bruno Larsen <blarsen@redhat.com>
2023-01-01Update copyright year range in header of all files managed by GDBJoel Brobecker1-1/+1
This commit is the result of running the gdb/copyright.py script, which automated the update of the copyright year range for all source files managed by the GDB project to be updated to include year 2023.
2022-12-14gdb: convert 'set debug symbol-lookup' to new debug printing schemeAndrew Burgess1-7/+5
Convert the implementation of 'set debug symbol-lookup' to the new debug printing scheme. In a few places I've updated the debug output to remove places where the printed debug message included the function name, the new debug scheme already adds that, but I haven't done all the possible updates.
2022-10-19internal_error: remove need to pass __FILE__/__LINE__Pedro Alves1-11/+6
Currently, every internal_error call must be passed __FILE__/__LINE__ explicitly, like: internal_error (__FILE__, __LINE__, "foo %d", var); The need to pass in explicit __FILE__/__LINE__ is there probably because the function predates widespread and portable variadic macros availability. We can use variadic macros nowadays, and in fact, we already use them in several places, including the related gdb_assert_not_reached. So this patch renames the internal_error function to something else, and then reimplements internal_error as a variadic macro that expands __FILE__/__LINE__ itself. The result is that we now should call internal_error like so: internal_error ("foo %d", var); Likewise for internal_warning. The patch adjusts all calls sites. 99% of the adjustments were done with a perl/sed script. The non-mechanical changes are in gdbsupport/errors.h, gdbsupport/gdb_assert.h, and gdb/gdbarch.py. Approved-By: Simon Marchi <simon.marchi@efficios.com> Change-Id: Ia6f372c11550ca876829e8fd85048f4502bdcf06
2022-10-10Remove c_printstrTom Tromey1-12/+0
This renames c_printstr, removing a layer of indirection.
2022-10-10Remove c_emit_charTom Tromey1-9/+0
This renames c_emit_char, removing a layer of indirection.
2022-10-10Change GDB to use frame_info_ptrTom Tromey1-3/+3
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-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-05[gdb/build] Fix build breaker in language.c with gcc 7.5.0Tom de Vries1-1/+1
When building gdb on openSUSE Leap 15.3, using gcc 7.5.0, I run into: ... gdb/language.c: In constructor ‘constexpr language_gdbarch::language_gdbarch()’: gdb/language.c:921:8: error: use of deleted function \ ‘language_arch_info::language_arch_info(const language_arch_info&)’ struct language_gdbarch ^~~~~~~~~~~~~~~~ In file included from gdbsupport/common-defs.h:104:0, from gdb/defs.h:28, from gdb/language.c:31: gdb/language.h:95:28: note: declared here DISABLE_COPY_AND_ASSIGN (language_arch_info); ^ include/ansidecl.h:342:3: note: in definition of macro \ ‘DISABLE_COPY_AND_ASSIGN’ TYPE (const TYPE&) = delete; \ ^~~~ gdb/language.c: In function ‘language_gdbarch* get_language_gdbarch(gdbarch*)’: gdb/language.c:936:22: note: synthesized method ‘constexpr \ language_gdbarch::language_gdbarch()’ first required here l = new struct language_gdbarch; ^~~~~~~~~~~~~~~~ ... This seems to be fixed by this change in the struct language_gdbarch definition: ... - struct language_arch_info arch_info[nr_languages] {}; + struct language_arch_info arch_info[nr_languages]; ... Tested on x86_64-linux.
2022-08-04Use registry in gdbarchTom Tromey1-21/+18
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-03-29Unify gdb printf functionsTom Tromey1-29/+29
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 vprintf functionsTom Tromey1-1/+1
Now that filtered and unfiltered output can be treated identically, we can unify the vprintf family of functions: vprintf_filtered, vprintf_unfiltered, vfprintf_filtered and vfprintf_unfiltered. (For the gdb_stdout variants, recall that only printf_unfiltered gets truly unfiltered output at this point.) This removes one such function and renames the remaining two to "gdb_vprintf". All callers are updated. Much of this patch was written by script.
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_OBJFILE_OWNED macroSimon Marchi1-1/+1
Add a getter and a setter for whether a symbol is objfile owned. Remove the corresponding macro and adjust all callers. Change-Id: Ib7ef3718d65553ae924ca04c3fd478b0f4f3147c
2022-02-06gdb: remove SYMBOL_DOMAIN macroSimon Marchi1-1/+1
Add a getter and a setter for a symbol's domain. Remove the corresponding macro and adjust all callers. Change-Id: I54465b50ac89739c663859a726aef8cdc6e4b8f3
2022-02-06gdb: remove SYMBOL_ACLASS_INDEX macro, add getter/setterSimon Marchi1-1/+1
Add a getter and a setter for a symbol's aclass index. Remove the corresponding macro and adjust all callers. Change-Id: Ie8c8d732624cfadb714aba5ddafa3d29409b3d39
2022-01-26Fix another crash with gdb parameters in PythonTom Tromey1-5/+6
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-06Avoid crash in language_infoTom Tromey1-1/+1
language_info calls: show_language_command (NULL, 1, NULL, NULL); ... "knowing" that show_language_command does not use its ui_file parameter. However, this was changed in commit 7514a661 ("Consistently Use ui_file parameter to show callbacks"). This patch changes language_info to pass a ui_file. It took a while to write the test -- this function is only called when 'verbose' is on and when switching the "expected" language in auto mode.
2022-01-05Use filtered output in language_infoTom Tromey1-1/+1
Change language_info to use filtered output. This is ok because the sole caller uses filtered output elsewhere, and because this function calls show_language_command, which also uses filtered output.
2022-01-01Automatic Copyright Year update after running gdb/copyright.pyJoel Brobecker1-1/+1
This commit brings all the changes made by running gdb/copyright.py as per GDB's Start of New Year Procedure. For the avoidance of doubt, all changes in this commits were performed by the script.
2021-12-29Consistently Use ui_file parameter to show callbacksTom Tromey1-7/+7
I happened to notice that one "show" callback was printing to gdb_stdout rather than to the passed-in ui_file parameter. I went through all such callbacks and fixed them to consistently use the ui_file. Regression tested on x86-64 Fedora 34.
2021-11-16gdb/gdbsupport: make xstrprintf and xstrvprintf return a unique_ptrAndrew Burgess1-2/+1
The motivation is to reduce the number of places where unmanaged pointers are returned from allocation type routines. All of the callers are updated. There should be no user visible changes after this commit.
2021-10-28gdb: add add_setshow_prefix_cmdSimon Marchi1-13/+10
There's a common pattern to call add_basic_prefix_cmd and add_show_prefix_cmd to add matching set and show commands. Add the add_setshow_prefix_cmd function to factor that out and use it at a few places. Change-Id: I6e9e90a30e9efb7b255bf839cac27b85d7069cfd
2021-10-04Use unique_xmalloc_ptr<char> when demanglingTom Tromey1-2/+3
I noticed that some methods in language_defn could use unique_xmalloc_ptr<char> rather than a plain 'char *'. This patch implements this change, fixing up the fallout and changing gdb_demangle to also return this type. In one spot, std::string is used to simplify some related code, and in another, an auto_obstack is used to avoid manual management. Regression tested on x86-64 Fedora 34.
2021-09-24Move value_true to value.hTom Tromey1-17/+0
I noticed that value_true is declared in language.h and defined in language.c. However, as part of the value API, I think it would be better in one of those files. And, because it is very short, I changed it to be an inline function in value.h. I've also removed a comment from the implementation, on the basis that it seems obsolete -- if the change it suggests was needed, it probably would have been done by now; and if it is needed in the future, odds are it would be done differently anyway. Finally, this patch also changes value_true and value_logical_not to return a bool, and updates some uses.
2021-09-23Change pointer_type to a method of struct typeTom Tromey1-8/+0
I noticed that pointer_type is declared in language.h and defined in language.c. However, it really has to do with types, so it should have been in gdbtypes.h all along. This patch changes it to be a method on struct type. And, I went through uses of TYPE_IS_REFERENCE and updated many spots to use the new method as well. (I didn't update ones that were in arch-specific code, as I couldn't readily test that.)
2021-07-15Avoid expression parsing crash with unknown languageTom Tromey1-2/+2
PR gdb/28093 points out that gdb crashes when language is set to "unknown" and expression parsing is attempted. At first I thought this was a regression due to the expression rewrite, but it turns out that older versions crash as well. This patch avoids the crash by changing the default expression parser to throw an exception. I think this is preferable -- the current behavior of silently doing nothing does not really make sense. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28093
2021-05-27gdb: remove add_alias_cmd overload that accepts a stringSimon Marchi1-11/+13
Same idea as previous patch, but for add_alias_cmd. Remove the overload that accepts the target command as a string (the target command name), leaving only the one that takes the cmd_list_element. gdb/ChangeLog: * command.h (add_alias_cmd): Accept target as cmd_list_element. Update callers. Change-Id: I546311f411e9e7da9302322d6ffad4e6c56df266
2021-05-12gdb: generate the prefix name for prefix commands on demandMarco Barisione1-2/+2
Previously, the prefixname field of struct cmd_list_element was manually set for prefix commands. This seems verbose and error prone as it required every single call to functions adding prefix commands to specify the prefix name while the same information can be easily generated. Historically, this was not possible as the prefix field was null for many commands, but this was fixed in commit 3f4d92ebdf7f848b5ccc9e8d8e8514c64fde1183 by Philippe Waroquiers, so we can rely on the prefix field being set when generating the prefix name. This commit also fixes a use after free in this scenario: * A command gets created via Python (using the gdb.Command class). The prefix name member is dynamically allocated. * An alias to the new command is created. The alias's prefixname is set to point to the prefixname for the original command with a direct assignment. * A new command with the same name as the Python command is created. * The object for the original Python command gets freed and its prefixname gets freed as well. * The alias is updated to point to the new command, but its prefixname is not updated so it keeps pointing to the freed one. gdb/ChangeLog: * command.h (add_prefix_cmd): Remove the prefixname argument as it can now be generated automatically. Update all callers. (add_basic_prefix_cmd): Ditto. (add_show_prefix_cmd): Ditto. (add_prefix_cmd_suppress_notification): Ditto. (add_abbrev_prefix_cmd): Ditto. * cli/cli-decode.c (add_prefix_cmd): Ditto. (add_basic_prefix_cmd): Ditto. (add_show_prefix_cmd): Ditto. (add_prefix_cmd_suppress_notification): Ditto. (add_prefix_cmd_suppress_notification): Ditto. (add_abbrev_prefix_cmd): Ditto. * cli/cli-decode.h (struct cmd_list_element): Replace the prefixname member variable with a method which generates the prefix name at runtime. Update all code reading the prefix name to use the method, and remove all code setting it. * python/py-cmd.c (cmdpy_destroyer): Remove code to free the prefixname member as it's now a method. (cmdpy_function): Determine if the command is a prefix by looking at prefixlist, not prefixname.
2021-03-29Remove parameter from language_infoTom Tromey1-12/+3
I noticed that language_info is only ever called with a value of '1'. This patch removes the parameter. 2021-03-29 Tom Tromey <tromey@adacore.com> * top.c (check_frame_language_change): Update. * language.c (language_info): Remove parameter. * language.h (language_info): Remove parameter.
2021-03-08Remove union exp_elementTom Tromey1-20/+0
This removes union exp_element functions that either create such elements or walk them. struct expression no longer holds exp_elements. A couple of language_defn methods are also removed, as they are obsolete. Note that this patch also removes the print_expression code. The only in-tree caller of this was from dump_prefix_expression, which is only called when expression debugging is enabled. Implementing this would involve a fair amount of code, and it seems to me that prefix dumping is preferable anyway, as it is unambiguous. So, I have not reimplemented this feature. gdb/ChangeLog 2021-03-08 Tom Tromey <tom@tromey.com> * value.h (evaluate_subexp_with_coercion): Don't declare. * parse.c (exp_descriptor_standard): Remove. (expr_builder::expr_builder, expr_builder::release): Update. (expression::expression): Remove size_t parameter. (expression::~expression): Simplify. (expression::resize): Remove. (write_exp_elt, write_exp_elt_opcode, write_exp_elt_sym) (write_exp_elt_msym, write_exp_elt_block, write_exp_elt_objfile) (write_exp_elt_longcst, write_exp_elt_floatcst) (write_exp_elt_type, write_exp_elt_intern, write_exp_string) (write_exp_string_vector, write_exp_bitstring): Remove. * p-lang.h (class pascal_language) <opcode_print_table, op_print_tab>: Remove. * p-lang.c (pascal_language::op_print_tab): Remove. * opencl-lang.c (class opencl_language) <opcode_print_table>: Remove. * objc-lang.c (objc_op_print_tab): Remove. (class objc_language) <opcode_print_table>: Remove. * m2-lang.h (class m2_language) <opcode_print_table, op_print_tab>: Remove. * m2-lang.c (m2_language::op_print_tab): Remove. * language.h (struct language_defn) <post_parser, expression_ops, opcode_print_table>: Remove. * language.c (language_defn::expression_ops) (auto_or_unknown_language::opcode_print_table): Remove. * go-lang.h (class go_language) <opcode_print_table, op_print_tab>: Remove. * go-lang.c (go_language::op_print_tab): Remove. * f-lang.h (class f_language) <opcode_print_table>: Remove <op_print_tab>: Remove. * f-lang.c (f_language::op_print_tab): Remove. * expression.h (union exp_element): Remove. (struct expression): Remove size_t parameter from constructor. <resize>: Remove. <first_opcode>: Update. <nelts, elts>: Remove. (EXP_ELEM_TO_BYTES, BYTES_TO_EXP_ELEM): Remove. (evaluate_subexp_standard, print_expression, op_string) (dump_raw_expression): Don't declare. * expprint.c (print_expression, print_subexp) (print_subexp_funcall, print_subexp_standard, op_string) (dump_raw_expression, dump_subexp, dump_subexp_body) (dump_subexp_body_funcall, dump_subexp_body_standard): Remove. (dump_prefix_expression): Update. * eval.c (evaluate_subexp): Remove. (evaluate_expression, evaluate_type): Update. (evaluate_subexpression_type): Remove. (fetch_subexp_value): Remove "pc" parameter. Update. (extract_field_op, evaluate_struct_tuple, evaluate_funcall) (evaluate_subexp_standard, evaluate_subexp_for_address) (evaluate_subexp_with_coercion, evaluate_subexp_for_sizeof) (evaluate_subexp_for_cast): Remove. (parse_and_eval_type): Update. * dtrace-probe.c (dtrace_probe::compile_to_ax): Update. * d-lang.c (d_op_print_tab): Remove. (class d_language) <opcode_print_table>: Remove. * c-lang.h (c_op_print_tab): Don't declare. * c-lang.c (c_op_print_tab): Remove. (class c_language, class cplus_language, class asm_language, class minimal_language) <opcode_print_table>: Remove. * breakpoint.c (update_watchpoint, watchpoint_check) (watchpoint_exp_is_const, watch_command_1): Update. * ax-gdb.h (union exp_element): Don't declare. * ax-gdb.c (const_var_ref, const_expr, maybe_const_expr) (gen_repeat, gen_sizeof, gen_expr_for_cast, gen_expr) (gen_expr_binop_rest): Remove. (gen_trace_for_expr, gen_eval_for_expr, gen_printf): Update. * ada-lang.c (ada_op_print_tab): Remove. (class ada_language) <post_parser, opcode_print_table>: Remove.
2021-02-10gdb: delete SYMBOL_SECTION and MSYMBOL_SECTION macrosAndrew Burgess1-1/+1
Delete two more symbol/section related macros. This time it's SYMBOL_SECTION and MSYMBOL_SECTION. As with general_symbol_info::m_name it is not currently possible to make general_symbol_info::m_section private as general_symbol_info must remain a POD type. But other than failing to make the new m_section private, this change does what you'd expect, adds a get and set member function and updates all users to use the new functions instead of the previous wrapper macros. There should be no user visible change after this commit. gdb/ChangeLog: * coff-pe-read.c (add_pe_forwarded_sym): Make use of section_index and set_section_index member functions where appropriate. * coffread.c (coff_symtab_read): Likewise. (process_coff_symbol): Likewise. * ctfread.c (set_symbol_address): Likewise. * dwarf2/read.c (add_partial_symbol): Likewise. (var_decode_location): Likewise. * language.c: Likewise. * minsyms.c (minimal_symbol_reader::record_full): Likewise. (compact_minimal_symbols): Likewise. (minimal_symbol_upper_bound): Likewise. * objfiles.c (relocate_one_symbol): Likewise. * psympriv.h (partial_symbol::obj_section): Likewise. (partial_symbol::address): Likewise. * psymtab.c (partial_symtab::add_psymbol): Likewise. * stabsread.c (scan_file_globals): Likewise. * symmisc.c (dump_msymbols): Likewise. * symtab.c (general_symbol_info::obj_section): Likewise. (fixup_section): Likewise. (get_msymbol_address): Likewise. * symtab.h (general_symbol_info::section): Rename to... (general_symbol_info::m_section): ...this. (general_symbol_info::set_section_index): New member function. (general_symbol_info::section_index): Likewise. (SYMBOL_SECTION): Delete. (MSYMBOL_VALUE_ADDRESS): Make use of section_index and set_section_index member functions where appropriate. (MSYMBOL_SECTION): Delete. (symbol::symbol): Update to initialize 'm_section'. * xcoffread.c (read_xcoff_symtab): Make use of set_section_index. (process_xcoff_symbol): Likewise.
2021-02-05Return unique_ptr from language_defn::get_compile_contextTom Tromey1-0/+9
This changes language_defn::get_compile_context to return a unique_ptr. This makes the ownership transfer clear. gdb/ChangeLog 2021-02-05 Tom Tromey <tom@tromey.com> * compile/compile-c-support.c (get_compile_context) (c_get_compile_context, cplus_get_compile_context): Change return type. * language.c (language_defn::get_compile_instance): New method. * language.h (language_defn::get_compile_instance): Change return type. No longer inline. * c-lang.c (c_language::get_compile_instance): Change return type. (cplus_language::get_compile_instance): Change return type. * c-lang.h (c_get_compile_context, cplus_get_compile_context): Change return type. * compile/compile.c (compile_to_object): Update.
generated by cgit v1.1 at 2024-11-26 14:36:40 +0000