aboutsummaryrefslogtreecommitdiff
path: root/gdb/value.h
AgeCommit message (Collapse)AuthorFilesLines
2023-09-20Remove explanatory comments from includesTom Tromey1-1/+1
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-05Introduce type::is_array_like and value_to_arrayTom Tromey1-0/+4
This adds the type::is_array_like method and the value_to_array function. The former can be used to see whether a given type is known to be "array-like". This is the currently the case for certain compiler-generated structure types; in particular both the Ada and Rust compilers do this.
2023-08-29Remove "highbound" parameter from value_arrayTom Tromey1-1/+1
value_array requires the passed-in bounds to match the length of the array_view it is given. This patch removes the redundant "highbound" parameter. Reviewed-by: John Baldwin <jhb@FreeBSD.org> Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-08-29Use gdb::array_view for value_arrayTom Tromey1-1/+1
This changes value_array to accept an array view. I also replaced an alloca with a std::vector in array_operation::evaluate. This function can work on any size of array, so it seems bad to use alloca. Reviewed-by: John Baldwin <jhb@FreeBSD.org> Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-07-07gdb: check max-value-size when reading strings for printfAndrew Burgess1-0/+5
I noticed that the printf code for strings, printf_c_string and printf_wide_c_string, don't take max-value-size into account, but do load a complete string from the inferior into a GDB buffer. As such it would be possible for an badly behaved inferior to cause GDB to try and allocate an excessively large buffer, potentially crashing GDB, or at least causing GDB to swap lots, which isn't great. We already have a setting to protect against this sort of thing, the 'max-value-size'. So this commit updates the two function mentioned above to check the max-value-size and give an error if the max-value-size is exceeded. If the max-value-size is exceeded, I chose to continue reading inferior memory to figure out how long the string actually is, we just don't store the results. The benefit of this is that when we give the user an error we can tell the user how big the string actually is, which would allow them to correctly adjust max-value-size, if that's what they choose to do. The default for max-value-size is 64k so there should be no user visible changes after this commit, unless the user was previously printing very large strings. If that is the case then the user will now need to increase max-value-size.
2023-06-05gdb: building inferior strings from within GDBAndrew Burgess1-2/+39
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-25Fix scoped_value_mark not working with empty value chainCiaran Woodward1-2/+3
The scoped_value_mark helper class was setting its internal mark value to NULL to indicate that the value chain had already been freed to mark. However, value_mark() also returns NULL if the value chain is empty at the time of call. This lead to the situation that if the value chain was empty at the time the scoped_value_mark was created, the class would not correctly clean up the state when it was destroyed, because it believed it had already been freed. I noticed this because I was setting a watchpoint very early in my debug session, and it was becoming a software watchpoint rather than hardware. Running any command that called evaluate() beforehand (such as 'x 0') would mean that a hardware watchpoint was correctly used. After some careful examination of the differences in execution, I noticed that values were being freed later in the 'bad case', which lead me to notice the issue with scoped_value_mark.
2023-05-23Add flags to parse_and_evalTom Tromey1-1/+1
This adds a flags parameter to parse_and_eval.
2023-05-01Remove evaluate_typeTom Tromey1-2/+0
Like evaluate_expression, evaluate_type is also just a simple wrapper. Removing it makes the code a little nicer.
2023-05-01Remove evaluate_expressionTom Tromey1-9/+0
evaluate_expression is just a little wrapper for a method on expression. Removing it also removes a lot of ugly (IMO) calls to get().
2023-03-29Pass a frame to value_at_lazy and value_from_contents_and_addressTom Tromey1-4/+10
This patch adds a 'frame' parameter to value_at_lazy and ensures that it is passed down to the call to resolve_dynamic_type. This required also adding a frame parameter to value_from_contents_and_address. Nothing passes this parameter to value_at_lazy yet, so this patch should have no visible effect.
2023-03-27Add value_as_mpz and value_from_mpzTom Tromey1-0/+7
This adds the two new functions, value_as_mpz and value_from_mpz, useful for manipulation values via gdb_mpz.
2023-03-02Fix some value commentsTom Tromey1-0/+5
I noticed a very stale comment in valarith.c. This patch fixes a few comments in this area. Reviewed-By: Andrew Burgess <aburgess@redhat.com>
2023-02-28Remove value_inTom Tromey1-2/+0
value_in is unused. From git log, it seems to have been part of the Chill language, which was removed from gdb eons ago. This patch removes the function. Tested by rebuilding.
2023-02-15Return bool from more value methodsTom Tromey1-11/+11
There are several more value methods that currently return 'int' but that should return 'bool'. This patch updates these. Reviewed-By: Bruno Larsen <blarsen@redhat.com>
2023-02-15Have value::bits_synthetic_pointer return boolTom Tromey1-3/+3
This changes value::bits_synthetic_pointer to return bool and fixes up some fallout from this. Reviewed-By: Bruno Larsen <blarsen@redhat.com>
2023-02-15Change value::m_stack to boolTom Tromey1-5/+5
This changes value::m_stack to be a bool and updates the various uses. Reviewed-By: Bruno Larsen <blarsen@redhat.com>
2023-02-15Change value::m_initialized to boolTom Tromey1-5/+5
This changes value::m_initialized to be a bool and updates the various uses. Reviewed-By: Bruno Larsen <blarsen@redhat.com>
2023-02-15Change value::m_lazy to boolTom Tromey1-8/+8
This changes value::m_lazy to be a bool and updates the various uses. Reviewed-By: Bruno Larsen <blarsen@redhat.com>
2023-02-15Change value::m_modifiable to boolTom Tromey1-4/+4
This changes value::m_modifiable to be a bool and updates the various uses. Reviewed-By: Bruno Larsen <blarsen@redhat.com>
2023-02-13Remove deprecated_lval_hackTom Tromey1-10/+0
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-13Introduce set_lval method on valueTom Tromey1-0/+4
This introduces the set_lval method on value, one step toward removing deprecated_lval_hack. Ultimately I think the goal should be for some of these set_* methods to be replaced with constructors; but I haven't done this, as the series is already too long. Other 'deprecated' methods can probably be handled the same way. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Make ~value privateTom Tromey1-4/+6
At the end of this series, I belatedly realized that values should only be destroyed by value_decref. This patch marks the the destructor private to enforce this. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Make struct value data members privateTom Tromey1-6/+2
This hoists the 'private' in struct value to also encompass the data members. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn record_latest_value into a methodTom Tromey1-2/+3
record_latest_value now access some internals of struct value, so turn it into a method. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Add value::set_modifiableTom Tromey1-0/+4
This introduces a value::set_modifiable and changes a couple of spots to use it. I'm not completely sure the comments by deprecated_modifiable are correct any more. Perhaps they should be removed and the method renamed. Like so many before me, though, I've deferred investigation of the issue. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn various value copying-related functions into methodsTom Tromey1-29/+66
This patch turns a grab bag of value functions to methods of value. These are done together because their implementations are interrelated. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn preserve_one_value into methodTom Tromey1-2/+4
This changes preserve_one_value to be a method of value. Much of this patch was written by script. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn some xmethod functions into methodsTom Tromey1-11/+11
This turns value_from_xmethod, result_type_of_xmethod, and call_xmethod to be methods of value. value_from_xmethod is a static "constructor" now. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn set_value_component_location into methodTom Tromey1-5/+4
This turns set_value_component_location into a method of value. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn value_non_lval and value_force_lval into methodsTom Tromey1-4/+7
This changes value_non_lval and value_force_lval to be methods of value. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn many optimized-out value functions into methodsTom Tromey1-65/+59
This turns many functions that are related to optimized-out or availability-checking to be methods of value. The static function value_entirely_covered_by_range_vector is also converted to be a private method. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn value_copy into a methodTom Tromey1-2/+5
This turns value_copy into a method of value. Much of this was written by script. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn remaining value_contents functions into methodsTom Tromey1-27/+28
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 value_incref and value_decref into methodsTom Tromey1-11/+10
This changes value_incref and value_decref to be methods of value. Much of this patch was written by script. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Move value_ref_policy methods out-of-lineTom Tromey1-9/+14
This moves the value_ref_policy methods to be defined out-of-line. This is a necessary step to change value_incref and value_decref to be methods of value. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn value_bits_synthetic_pointer into a methodTom Tromey1-6/+5
This changes value_bits_synthetic_pointer to be a method of value. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn value_contents_eq into a methodTom Tromey1-63/+71
This changes value_contents_eq to be a method of value. It also converts the static function value_contents_bits_eq into a private method. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn allocate_value_contents into a methodTom Tromey1-0/+13
This turns the static function allocate_value_contents into a method on value. It is temporarily public, until some users are converted. set_limited_array_length is converted as well. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn value_fetch_lazy into a methodTom Tromey1-2/+18
This changes value_fetch_lazy to be a method of value. A few helper functions are converted as well, to avoid problems in later patches when the data members are all made private. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn some value_contents functions into methodsTom Tromey1-18/+16
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 value_zero into static "constructor"Tom Tromey1-3/+4
This turns value_zero into a static "constructor" of value. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn allocate_optimized_out_value into static "constructor"Tom Tromey1-2/+3
This turns allocate_optimized_out_value into a static "constructor" of value. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn allocate_computed_value into static "constructor"Tom Tromey1-7/+6
This turns allocate_computed_value into a static "constructor" of value. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn allocate_value into a static "constructor"Tom Tromey1-2/+9
This changes allocate_value to be a static "constructor" of value. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn allocate_value_lazy into a static "constructor"Tom Tromey1-1/+11
This changes allocate_value_lazy to be a static "constructor" of struct value. I considered trying to change value to use ordinary new/delete, but it seems to me that due to reference counting, we may someday want to change these static constructors to return value_ref_ptr instead. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn more deprecated_* functions into methodsTom Tromey1-6/+10
This changes deprecated_value_internalvar_hack, deprecated_value_internalvar_hack, and deprecated_value_regnum_hack into methods on value. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn value_address and set_value_address functions into methodsTom Tromey1-13/+13
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_initialized and set_value_initialized functions into methodsTom Tromey1-6/+9
This changes the value_initialized and set_value_initialized functions to be methods of value. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Convert value_lval_const and deprecated_lval_hack to methodsTom Tromey1-5/+7
This converts the value_lval_const and deprecated_lval_hack functions to be methods on value. Approved-By: Simon Marchi <simon.marchi@efficios.com>