aboutsummaryrefslogtreecommitdiff
path: root/gdb/c-lang.c
AgeCommit message (Collapse)AuthorFilesLines
2024-06-14Introduce language_defn::lookup_symbol_localTom Tromey1-0/+11
This introduces the new method language_defn::lookup_symbol_local, and then changes lookup_symbol_local to use it. This removes an explicit language check from this function, and makes it easier for other languages to hook into this code.
2024-04-22gdb: move store/extract integer functions to extract-store-integer.{c,h}Simon Marchi1-0/+1
Move the declarations out of defs.h, and the implementations out of findvar.c. I opted for a new file, because this functionality of converting integers to bytes and vice-versa seems a bit to generic to live in findvar.c. Change-Id: I524858fca33901ee2150c582bac16042148d2251 Approved-By: John Baldwin <jhb@FreeBSD.org>
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-03-19Speed up lookup of "type_specific_data"Tom Tromey1-2/+4
I noticed that "info locals" on a certain large Ada program was very slow. I tracked this down to ada_get_tsd_type expanding nearly every CU in the program. This patch fixes the problem by changing this code to use the more efficient lookup_transparent_type which, unlike the Ada-specific lookup functions, does not try to find all matching instances. Note that I first tried fixing this by changing ada_find_any_type, but this did not work -- I may revisit this approach at some later date. Also note that the copyright dates on the test files are set that way because I copied them from another test. New in v2: the new test failed on the Linaro regression tester. Looking at the logs, it seems that gdb was picking up a 'value' from libgnat: $1 = {<text variable, no debug info>} 0xf7e227a4 <ada.calendar.formatting.value> This version renames the local variable in an attempt to work around this. v3: In v2, while trying to reproduce the problem locally, I accidentally forgot to commit one of the changes.
2024-01-28Use domain_search_flags in lookup_symbol et alTom Tromey1-1/+1
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.
2023-07-07gdb: fix printf of wchar_t early in a gdb sessionAndrew Burgess1-3/+0
Given this test program: #include <wchar.h> const wchar_t wide_str[] = L"wide string"; int main (void) { return 0; } I observed this GDB behaviour: $ gdb -q /tmp/printf-wchar_t Reading symbols from /tmp/printf-wchar_t... (gdb) start Temporary breakpoint 1 at 0x40110a: file /tmp/printf-wchar_t.c, line 8. Starting program: /tmp/printf-wchar_t Temporary breakpoint 1, main () at /tmp/printf-wchar_t.c:8 25 return 0; (gdb) printf "%ls\n", wide_str (gdb) Notice that the printf results in a blank line rather than the expected 'wide string' output. I tracked the problem down to printf_wide_c_string (in printcmd.c), in this function we do this: struct type *wctype = lookup_typename (current_language, "wchar_t", NULL, 0); int wcwidth = wctype->length (); the problem here is that 'wchar_t' is a typedef. If we look at the comment on type::length() we see this: /* Note that if thistype is a TYPEDEF type, you have to call check_typedef. But check_typedef does set the TYPE_LENGTH of the TYPEDEF type, so you only have to call check_typedef once. Since value::allocate calls check_typedef, X->type ()->length () is safe. */ What this means is that after calling lookup_typename we should call check_typedef in order to ensure that the length of the typedef has been setup correctly. We are not doing this in printf_wide_c_string, and so wcwidth is incorrectly calculated as 0. This is what leads GDB to print an empty string. We can see in c_string_operation::evaluate (in c-lang.c) an example of calling check_typedef specifically to fix this exact issue. Initially I did fix this problem by adding a check_typedef call into printf_wide_c_string, but then I figured why not move the check_typedef call up into lookup_typename itself, that feels like it should be harmless when looking up a non-typedef type, but will avoid bugs like this when looking up a typedef. So that's what I did. I can then remove the extra check_typedef call from c-lang.c, I don't see any other places where we had extra check_typedef calls. This doesn't mean we definitely had bugs -- so long as we never checked the length, or, if we knew that check_typedef had already been called, then we would be fine. I don't see any test regressions after this change, and my new test case is now passing. Reviewed-By: Tom Tromey <tom@tromey.com>
2023-06-05gdb: building inferior strings from within GDBAndrew Burgess1-8/+6
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-02-13Remove deprecated_lval_hackTom Tromey1-3/+3
This removes deprecated_lval_hack and the VALUE_LVAL macro, replacing all uses with a call to value::lval. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn remaining value_contents functions into methodsTom Tromey1-1/+1
This turns the remaining value_contents functions -- value_contents, value_contents_all, value_contents_for_printing, and value_contents_for_printing_const -- into methods of value. It also converts the static functions require_not_optimized_out and require_available to be private methods. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn some value_contents functions into methodsTom Tromey1-1/+1
This turns value_contents_raw, value_contents_writeable, and value_contents_all_raw into methods on value. The remaining functions will be changed later in the series; they were a bit trickier and so I didn't include them in this patch. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn allocate_value into a static "constructor"Tom Tromey1-1/+1
This changes allocate_value to be a static "constructor" of value. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn value_address and set_value_address functions into methodsTom Tromey1-1/+1
This changes the value_address and set_value_address functions to be methods of value. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn value_type into methodTom Tromey1-1/+1
This changes value_type to be a method of value. Much of this patch was written by script. 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-19GDB: Add a character string limiting optionAndrew Burgess1-2/+2
This commit splits the `set/show print elements' option into two. We retain `set/show print elements' for controlling how many elements of an array we print, but a new `set/show print characters' setting is added which is used for controlling how many characters of a string are printed. The motivation behind this change is to allow users a finer level of control over how data is printed, reflecting that, although strings can be thought of as arrays of characters, users often want to treat these two things differently. For compatibility reasons by default the `set/show print characters' option is set to `elements', which makes the limit for character strings follow the setting of the `set/show print elements' option, as it used to. Using `set print characters' with any other value makes the limit independent from the `set/show print elements' setting, however it can be restored to the default with the `set print characters elements' command at any time. A corresponding `-characters' option for the `print' command is added, with the same semantics, i.e. one can use `elements' to make a given `print' invocation follow the limit of elements, be it set with the `-elements' option also given with the same invocation or taken from the `set/show print elements' setting, for characters as well regardless of the current setting of the `set/show print characters' option. The GDB changes are all pretty straightforward, just changing references to the old 'print_max' to use a new `get_print_max_chars' helper which figures out which of the two of `print_max' and `print_max_chars' values to use. Likewise, the documentation is just updated to reference the new setting where appropriate. To make people's life easier the message shown by `show print elements' now indicates if the setting also applies to character strings: (gdb) set print characters elements (gdb) show print elements Limit on string chars or array elements to print is 200. (gdb) set print characters unlimited (gdb) show print elements Limit on array elements to print is 200. (gdb) and the help text shows the dependency as well: (gdb) help set print elements Set limit on array elements to print. "unlimited" causes there to be no limit. This setting also applies to string chars when "print characters" is set to "elements". (gdb) In the testsuite there are two minor updates, one to add `-characters' to the list of completions now shown for the `print' command, and a bare minimum pair of checks for the right handling of `set print characters' and `show print characters', copied from the corresponding checks for `set print elements' and `show print elements' respectively. Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com> Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-01Update copyright year range in header of all files managed by GDBJoel Brobecker1-1/+1
This commit is the result of running the gdb/copyright.py script, which automated the update of the copyright year range for all source files managed by the GDB project to be updated to include year 2023.
2022-12-01Add name canonicalization for CTom Tromey1-0/+14
PR symtab/29105 shows a number of situations where symbol lookup can result in the expansion of too many CUs. What happens is that lookup_signed_typename will try to look up a type like "signed int". In cooked_index_functions::expand_symtabs_matching, when looping over languages, the C++ case will canonicalize this type name to be "int" instead. Then this method will proceed to expand every CU that has an entry for "int" -- i.e., nearly all of them. A crucial component of this is that the caller, objfile::lookup_symbol, does not do this canonicalization, so when it tries to find the symbol for "signed int", it fails -- causing the loop to continue. This patch fixes the problem by introducing name canonicalization for C. The idea here is that, by making C and C++ agree on the canonical name when a symbol name can have multiple spellings, we avoid the bad behavior in objfile::lookup_symbol (and any other such code -- I don't know if there is any). Unlike C++, C only has a few situations where canonicalization is needed. And, in particular, due to the lack of overloading (thus avoiding any issues in linespec) and due to the way c-exp.y works, I think that no canonicalization is needed during symbol lookup -- only during symtab construction. This explains why lookup_name_info is not touched. The stabs reader is modified on a "best effort" basis. The DWARF reader needed one small tweak in dwarf2_name to avoid a regression in dw2-unusual-field-names.exp. I think this is adequately explained by the comment, but basically this is a scenario that should not occur in real code, only the gdb test suite. lookup_signed_typename is simplified. It used to search for two different type names, but now gdb can search just for the canonical form. gdb.dwarf2/enum-type.exp needed a small tweak, because the canonicalizer turns "unsigned integer" into "unsigned int integer". It seems better here to use the correct C type name. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29105 Tested-by: Simon Marchi <simark@simark.ca> Reviewed-by: Andrew Burgess <aburgess@redhat.com>
2022-11-09Allow 'ptype/o' for assemblyTom Tromey1-0/+28
PR exp/28359 points out that 'ptype/o' does not work when the current language is "asm". I tracked this down to a hard-coded list of languages in typeprint.c. This patch replaces this list with a method on 'language_defn' instead. If all languages are ever updated to have this feature, the method could be removed; but in the meantime this lets each language control what happens. I looked at having each print_type method simply modify the flags itself, but this doesn't work very well with the feature that disables method-printing by default (but allows it via a flag). Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28359 Approved-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Keith Seitz <keiths@redhat.com>
2022-10-19internal_error: remove need to pass __FILE__/__LINE__Pedro Alves1-2/+2
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-4/+4
This renames c_printstr, removing a layer of indirection.
2022-10-10Remove c_emit_charTom Tromey1-2/+2
This renames c_emit_char, removing a layer of indirection.
2022-10-10Change GDB to use frame_info_ptrTom Tromey1-1/+1
This changes GDB to use frame_info_ptr instead of frame_info * The substitution was done with multiple sequential `sed` commands: sed 's/^struct frame_info;/class frame_info_ptr;/' sed 's/struct frame_info \*/frame_info_ptr /g' - which left some issues in a few files, that were manually fixed. sed 's/\<frame_info \*/frame_info_ptr /g' sed 's/frame_info_ptr $/frame_info_ptr/g' - used to remove whitespace problems. The changed files were then manually checked and some 'sed' changes undone, some constructors and some gets were added, according to what made sense, and what Tromey originally did Co-Authored-By: Bruno Larsen <blarsen@redhat.com> Approved-by: Tom Tomey <tom@tromey.com>
2022-09-21gdb: remove TYPE_LENGTHSimon Marchi1-9/+9
Remove the macro, replace all uses with calls to type::length. Change-Id: Ib9bdc954576860b21190886534c99103d6a47afb
2022-09-21gdb: remove TYPE_TARGET_TYPESimon Marchi1-7/+7
Remove the macro, replace all uses by calls to type::target_type. Change-Id: Ie51d3e1e22f94130176d6abd723255282bb6d1ed
2022-06-18gdb: Add new 'print nibbles' featureEnze Li1-0/+4
Make an introduction of a new print setting that can be set by 'set print nibbles [on|off]'. The default value if OFF, which can be changed by user manually. Of course, 'show print nibbles' is also included in the patch. The new feature displays binary values by group, with four bits per group. The motivation for this work is to enhance the readability of binary values. Here's a GDB session before this patch is applied. (gdb) print var_a $1 = 1230 (gdb) print/t var_a $2 = 10011001110 With this patch applied, we can use the new print setting to display the new form of the binary values. (gdb) print var_a $1 = 1230 (gdb) print/t var_a $2 = 10011001110 (gdb) set print nibbles on (gdb) print/t var_a $3 = 0100 1100 1110 Tested on x86_64 openSUSE Tumbleweed.
2022-05-10Always pass an explicit language down to c_type_printPedro Alves1-4/+4
The next patch will want to do language->print_type(type, ...), to print a type in a given language, avoiding a dependency on the current language. That doesn't work correctly currently, however, because most language implementations of language_defn::print_type call c_print_type without passing down the language. There are two overloads of c_print_type, one that takes a language, and one that does not. The one that does not uses the current language, defeating the point of calling language->print_type()... This commit removes the c_print_type overload that does not take a language, and adjusts the codebase throughout to always pass down a language. In most places, there's already an enum language handy. language_defn::print_type implementations naturally pass down this->la_language. In a couple spots, like in ada-typeprint.c and rust-lang.c there's no enum language handy, but the code is written for a specific language, so we just hardcode the language. In gnuv3_print_method_ptr, I wasn't sure whether we could hardcode C++ here, and we don't have an enum language handy, so I made it use the current language, just like today. Can always be improved later. Change-Id: Ib54fab4cf0fd307bfd55bf1dd5056830096a653b
2022-04-14Remove the byte order parameter to target_read_stringTom Tromey1-1/+1
target_read_string takes a byte order parameter, but only uses this to check whether a given character is zero. This is readily done without requiring the parameter, so remove it.
2022-04-14Rename read_stringTom Tromey1-2/+2
This renames read_string to be an overload of target_read_string. This makes it more consistent for the eventual merger with gdbserver.
2022-03-29Unify gdb putc functionsTom Tromey1-5/+5
Now that filtered and unfiltered output can be treated identically, we can unify the putc family of functions. This is done under the name "gdb_putc". Most of this patch was written by script.
2022-03-29Unify gdb puts functionsTom Tromey1-3/+3
Now that filtered and unfiltered output can be treated identically, we can unify the puts family of functions. This is done under the name "gdb_puts". Most of this patch was written by script.
2022-02-04Remove host_hex_valueTom Tromey1-3/+3
I noticed that host_hex_value is redundant, because gdbsupport already has fromhex. This patch removes the former in favor of the latter. Regression tested on x86-64 Fedora 34.
2022-01-18Move gdb obstack code to gdbsupportTom Tromey1-1/+1
This moves the gdb-specific obstack code -- both extensions like obconcat and obstack_strdup, and things like auto_obstack -- to gdbsupport.
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-11-29Allow DW_ATE_UTF for Rust charactersTom Tromey1-1/+1
The Rust compiler plans to change the encoding of a Rust 'char' type to use DW_ATE_UTF. You can see the discussion here: https://github.com/rust-lang/rust/pull/89887 However, this fails in gdb. I looked into this, and it turns out that the handling of DW_ATE_UTF is currently fairly specific to C++. In particular, the code here assumes the C++ type names, and it creates an integer type. This comes from commit 53e710acd ("GDB thinks char16_t and char32_t are signed in C++"). The message says: Both places need fixing. But since I couldn't tell why dwarf2read.c needs to create a new type, I've made it use the per-arch built-in types instead, so that the types are only created once per arch instead of once per objfile. That seems to work fine. ... which is fine, but it seems to me that it's also correct to make a new character type; and this approach is better because it preserves the type name as well. This does use more memory, but first we shouldn't be too concerned about the memory use of types coming from debuginfo; and second, if we are, we should implement type interning anyway. Changing this code to use a character type revealed a couple of oddities in the C/C++ handling of TYPE_CODE_CHAR. This patch fixes these as well. I filed PR rust/28637 for this issue, so that this patch can be backported to the gdb 11 branch.
2021-10-25gdb: change functions returning value contents to use gdb::array_viewSimon Marchi1-2/+2
The bug fixed by this [1] patch was caused by an out-of-bounds access to a value's content. The code gets the value's content (just a pointer) and then indexes it with a non-sensical index. This made me think of changing functions that return value contents to return array_views instead of a plain pointer. This has the advantage that when GDB is built with _GLIBCXX_DEBUG, accesses to the array_view are checked, making bugs more apparent / easier to find. This patch changes the return types of these functions, and updates callers to call .data() on the result, meaning it's not changing anything in practice. Additional work will be needed (which can be done little by little) to make callers propagate the use of array_view and reap the benefits. [1] https://sourceware.org/pipermail/gdb-patches/2021-September/182306.html Change-Id: I5151f888f169e1c36abe2cbc57620110673816f3
2021-10-04Use unique_xmalloc_ptr<char> when demanglingTom Tromey1-3/+5
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-03-08Remove EVAL_SKIPTom Tromey1-18/+3
EVAL_SKIP was needed in the old expression implementation due to its linearized tree structure. This is not needed in the new implementation, because it is trivial to not evaluate a subexpression. This patch removes the last vestiges of EVAL_SKIP. gdb/ChangeLog 2021-03-08 Tom Tromey <tom@tromey.com> * value.h (eval_skip_value): Don't declare. * opencl-lang.c (eval_opencl_assign): Update. * m2-lang.c (eval_op_m2_high, eval_op_m2_subscript): Update. * f-lang.c (eval_op_f_abs, eval_op_f_mod, eval_op_f_ceil) (eval_op_f_floor, eval_op_f_modulo, eval_op_f_cmplx): Remove. * expression.h (enum noside) <EVAL_SKIP>: Remove. * expop.h (typeof_operation::evaluate) (decltype_operation::evaluate, unop_addr_operation::evaluate) (unop_sizeof_operation::evaluate, assign_operation::evaluate) (cxx_cast_operation::evaluate): Update. * eval.c (eval_skip_value): Remove. (eval_op_scope, eval_op_var_entry_value) (eval_op_func_static_var, eval_op_string, eval_op_objc_selector) (eval_op_concat, eval_op_ternop, eval_op_structop_struct) (eval_op_structop_ptr, eval_op_member, eval_op_add, eval_op_sub) (eval_op_binary, eval_op_subscript, eval_op_equal) (eval_op_notequal, eval_op_less, eval_op_gtr, eval_op_geq) (eval_op_leq, eval_op_repeat, eval_op_plus, eval_op_neg) (eval_op_complement, eval_op_lognot, eval_op_ind) (eval_op_memval, eval_op_preinc, eval_op_predec) (eval_op_postinc, eval_op_postdec, eval_op_type) (eval_binop_assign_modify, eval_op_objc_msgcall) (eval_multi_subscript, logical_and_operation::evaluate) (logical_or_operation::evaluate, array_operation::evaluate) (operation::evaluate_for_cast) (var_msym_value_operation::evaluate_for_cast) (var_value_operation::evaluate_for_cast): Update. * c-lang.c (c_string_operation::evaluate): Update. * c-exp.h (objc_nsstring_operation::evaluate) (objc_selector_operation::evaluate): Update. * ada-lang.c (ada_assign_operation::evaluate) (eval_ternop_in_range, ada_unop_neg, ada_unop_in_range) (ada_atr_size): Update.
2021-03-08Remove union exp_elementTom Tromey1-59/+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-03-08Remove now-unused C evaluator codeTom Tromey1-180/+0
Now that the C parser has switched to the new style, there is no need for the old C evaluation code. This affects some other languages that were relying on the C code. gdb/ChangeLog 2021-03-08 Tom Tromey <tom@tromey.com> * go-lang.c (go_language::expression_ops): Don't declare. * go-lang.h (class go_language) <expression_ops>: Remove. * opencl-lang.c (evaluate_subexp_opencl, exp_descriptor_opencl): Remove. (class opencl_language) <expression_ops>: Remove. * d-lang.c (class d_language) <expression_ops>: Remove. * c-lang.h (evaluate_subexp_c, exp_descriptor_c): Don't declare. * c-lang.c (evaluate_subexp_c, exp_descriptor_c): Remove. (class c_language, class cplus_language, class asm_language) (class minimal_language) <expression_ops>: Remove.
2021-03-08Add c-exp.h and c_string_operationTom Tromey1-0/+126
This adds the new file c-exp.h, where C operation classes will be declared. The first such class, c_string_operation, is also added here. gdb/ChangeLog 2021-03-08 Tom Tromey <tom@tromey.com> * c-lang.c (c_string_operation::evaluate): New method. * c-exp.h: New file.
2021-02-05Return unique_ptr from language_defn::get_compile_contextTom Tromey1-4/+3
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.
2021-01-28gdb: rename get_type_arch to type::archSimon Marchi1-4/+4
... and update all users. gdb/ChangeLog: * gdbtypes.h (get_type_arch): Rename to... (struct type) <arch>: ... this, update all users. Change-Id: I0e3ef938a0afe798ac0da74a9976bbd1d082fc6f
2021-01-01Update copyright year range in all GDB filesJoel Brobecker1-1/+1
This commits the result of running gdb/copyright.py as per our Start of New Year procedure... gdb/ChangeLog Update copyright year range in copyright header of all GDB files.
2020-12-23gdb: remove LA_EMIT_CHAR macroAndrew Burgess1-1/+1
Now that every use of the LA_EMIT_CHAR macro is within a language_defn member function we can simply call the emitchar member function directly instead of using the LA_EMIT_CHAR macro. If we are ever inside a language object, for example, cplus_language, while current_language points at something other than cplus_language then this commit will result in a change in behaviour. However, I believe if we did have such a difference then this would be a bug in GDB. AS such I'm going to claim there _should_ be no user visible changes from this commit. gdb/ChangeLog: * c-lang.c (language_defn::printchar): Call emitchar, not LA_EMIT_CHAR. * f-lang.h (f_language::printchar): Likewise. * language.h (LA_EMIT_CHAR): Delete macro. * rust-lang.c (rust_language::printchar): Call emitchar, not LA_EMIT_CHAR.
2020-12-23gdb: rename c_printchar as language_defn::printcharAndrew Burgess1-1/+4
This commit removes the global function c_printchar and moves the implementation into language_defn::printchar. There should be no user visible changes after this commit. gdb/ChangeLog: * c-lang.c (c_printchar): Rename to... (language_defn::printchar): ...this. * c-lang.h (c_printchar): Delete declaration. * language.c (language_defn::printchar): Delete this implementation. Is now implemented in c-lang.c.
2020-12-09gdb: make get_discrete_bounds return boolSimon Marchi1-2/+2
get_discrete_bounds currently has three possible return values (see its current doc for details). It appears that for all callers, it would be sufficient to have a boolean "worked" / "didn't work" return value. Change the return type of get_discrete_bounds to bool and adjust all callers. Doing so simplifies the following patch. gdb/ChangeLog: * gdbtypes.h (get_discrete_bounds): Return bool, adjust all callers. * gdbtypes.c (get_discrete_bounds): Return bool. Change-Id: Ie51feee23c75f0cd7939742604282d745db59172
2020-11-30Remove per-language op_name functionsTom Tromey1-1/+0
enum exp_opcode is created from all the .def files, but then each language is required to implement its own op_name function to turn an enum value to a string. This seemed over-complicated to me, and this patch removes the per-language functions in favor of simply using the .def names for all languages. Note that op_name is only used for dumping expressions, which is a maintainer/debug feature. Furthermore, I don't think there was any case where the .def name and the string name differed. gdb/ChangeLog 2020-11-30 Tom Tromey <tom@tromey.com> * rust-lang.c (rust_op_name): Remove. (exp_descriptor_rust): Update. * parser-defs.h (op_name_standard): Don't declare. (struct exp_descriptor) <op_name>: Remove. * parse.c (exp_descriptor_standard): Update. * opencl-lang.c (exp_descriptor_opencl): Update. * m2-lang.c (m2_language::exp_descriptor_modula2): Update. * f-lang.c (op_name_f): Remove. (f_language::exp_descriptor_tab): Update. * expression.h (op_name): Update. * expprint.c (op_name): Rewrite. (op_name_standard): Remove. (dump_raw_expression, dump_subexp): Update. * c-lang.c (exp_descriptor_c): Update. * ax-gdb.c (gen_expr): Update. * ada-lang.c (ada_op_name): Remove. (ada_exp_descriptor): Update.
2020-11-13Use const more in c-lang.cTom Tromey1-14/+14
This changes a few functions in c-lang.c to add "const" to parameters and return types. Tested by rebuilding. gdb/ChangeLog 2020-11-13 Tom Tromey <tom@tromey.com> * c-lang.c (convert_ucn, convert_octal, convert_hex) (convert_escape, parse_one_string): Constify.
generated by cgit v1.1 at 2024-12-01 19:53:36 +0000