aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/gdb.python/py-format-string.exp
AgeCommit message (Collapse)AuthorFilesLines
9 hoursUpdate copyright dates to include 2025Tom Tromey1-1/+1
This updates the copyright headers to include 2025. I did this by running gdb/copyright.py and then manually modifying a few files as noted by the script. Approved-By: Eli Zaretskii <eliz@gnu.org>
2024-11-14gdb/python: remove some additional PyObject_IsTrue callsAndrew Burgess1-0/+5
After the previous commit I audited all our uses of PyObject_IsTrue looking for places where we were missing an error check. I did find some that are missing error checks in places where we really should have error checks, and I'll fix those in later commits. This commit however, focuses on those locations where PyObject_IsTrue is called, there is no error check, and the error check isn't really necessary because we already know that the object we are dealing with is of type PyBool_Type. Inline with the previous commit, in these cases I have removed the PyObject_IsTrue call, and replaced it with a comparison against Py_True. In one location where it is not obvious that the object we have is PyBool_Type I've added an assert, but in the other cases the comparison to Py_True immediately follows a PyBool_Check call, so an assert would be redundant. I've added a test for the gdb.Value.format_string styling argument being passed a non-bool value as this wasn't previously being tested, though this new test will pass before and after this commit. There should be no functional change after this commit. Approved-By: Tom Tromey <tom@tromey.com>
2024-10-06[gdb] Fix common misspellingsTom de Vries1-1/+1
Fix the following common misspellings: ... accidently -> accidentally additonal -> additional addresing -> addressing adress -> address agaisnt -> against albiet -> albeit arbitary -> arbitrary artifical -> artificial auxillary -> auxiliary auxilliary -> auxiliary bcak -> back begining -> beginning cannonical -> canonical compatiblity -> compatibility completetion -> completion diferent -> different emited -> emitted emiting -> emitting emmitted -> emitted everytime -> every time excercise -> exercise existance -> existence fucntion -> function funtion -> function guarentee -> guarantee htis -> this immediatly -> immediately layed -> laid noone -> no one occurances -> occurrences occured -> occurred originaly -> originally preceeded -> preceded preceeds -> precedes propogate -> propagate publically -> publicly refering -> referring substract -> subtract substracting -> subtracting substraction -> subtraction taht -> that targetting -> targeting teh -> the thier -> their thru -> through transfered -> transferred transfering -> transferring upto -> up to vincinity -> vicinity whcih -> which whereever -> wherever wierd -> weird withing -> within writen -> written wtih -> with doesnt -> doesn't ... Tested on x86_64-linux.
2024-08-01[gdb/testsuite] Fix gdb.python/py-format-string.exp with python 3.13Tom de Vries1-1/+7
On fedora rawhide, with python 3.13, I run into: ... (gdb) python print (gdb.parse_and_eval ('a_point_t').format_string (invalid=True))^M Python Exception <class 'TypeError'>: \ this function got an unexpected keyword argument 'invalid'^M Error occurred in Python: \ this function got an unexpected keyword argument 'invalid'^M (gdb) FAIL: $exp: format_string: lang_c: test_all_common: test_invalid_args: \ a_point_t with option invalid=True ... A passing version with an older python version looks like: ... (gdb) python print (gdb.parse_and_eval ('a_point_t').format_string (invalid=True))^M Python Exception <class 'TypeError'>: \ 'invalid' is an invalid keyword argument for this function^M Error occurred in Python: \ 'invalid' is an invalid keyword argument for this function^M (gdb) PASS: $exp: format_string: lang_c: test_all_common: test_invalid_args: \ a_point_t with option invalid=True ... Fix this by accepting the updated error message. Tested on aarch64-linux. PR testsuite/31912 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31912
2024-02-27Rewrite "python" command exception handlingTom Tromey1-4/+4
The "python" command (and the Python implementation of the gdb "source" command) does not handle Python exceptions in the same way as other gdb-facing Python code. In particular, exceptions are turned into a generic error rather than being routed through gdbpy_handle_exception, which takes care of converting to 'quit' as appropriate. I think this was done this way because PyRun_SimpleFile and friends do not propagate the Python exception -- they simply indicate that one occurred. This patch reimplements these functions to respect the general gdb convention here. As a bonus, some Windows-specific code can be removed, as can the _execute_file function. The bulk of this change is tweaking the test suite to match the new way that exceptions are displayed. These changes are largely uninteresting. However, it's worth pointing out the py-error.exp change. Here, the failure changes because the test changes the host charset to something that isn't supported by Python. This then results in a weird error in the new setup. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31354 Acked-By: Tom de Vries <tdevries@suse.de> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
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-09-29Support the NO_COLOR environment variableTom Tromey1-2/+1
I ran across this site: https://no-color.org/ ... which lobbies for tools to recognize the NO_COLOR environment variable and disable any terminal styling when it is seen. This patch implements this for gdb. Regression tested on x86-64 Fedora 38. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Reviewed-by: Kevin Buettner <kevinb@redhat.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-05-16Update comments for the gdb/24331 fix.Paul Pluzhnikov1-2/+0
Approved-by: Andrew Burgess <aburgess@redhat.com>
2023-05-13Fix bad interaction between element limit and repeated values (BZ#24331).Paul Pluzhnikov1-1/+1
Currently print -elements=3 -- "AAAAAA" prints complete string, which is not what the user asked for. Fix two buggy tests exposed by the fix, and add a new test. Reviewed-by: Keith Seitz <keiths@redhat.com>
2023-01-26Use clean_restart in gdb.pythonTom Tromey1-4/+1
Change gdb.python to use clean_restart more consistently.
2023-01-19GDB/testsuite: Expand for character string limiting optionsAndrew Burgess1-16/+35
Modify test cases that verify the operation of the array element limit with character strings such that they are executed twice, once with the `set print characters' option set to `elements' and the limit controlled with the `set print elements' option, and then again with the limit controlled with the `set print characters' option instead. Similarly with the `-elements' and `-characters' options for the `print' command. Additionally verify that said `print' command options combined yield the expected result. Verify correct $_gdb_setting and $_gdb_setting_str values for the `print characters' setting, in particular the `void' value for the `elements' default, which has no corresponding integer value exposed. Add Guile and Python coverage for the `print characters' GDB setting. There are new tests for Ada and Pascal, as the string printing code for these languages is different than the generic string printing code used by other languages. Modula2 also has different string printing code, but (a) this is similar to Pascal, and (b) there are no existing modula2 tests written in Modula2, so I'm not sure how I'd even test the Modula2 string printing. Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com> Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-13Rename to allow_python_testsTom Tromey1-1/+1
This changes skip_python_tests to invert the sense, and renames it to allow_python_tests.
2023-01-13Use "require" for Python testsTom Tromey1-2/+2
This changes various tests to use "require" for the Python feature.
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-05gdb/testsuite: remove perror calls when failing to runSimon Marchi1-1/+0
I noticed that when running these two tests in sequence: Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.ada/arrayptr.exp ... ERROR: GDB process no longer exists ERROR: Couldn't run foo-all Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.ada/assign_1.exp ... The results in gdb.sum are: Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.ada/arrayptr.exp ... PASS: gdb.ada/arrayptr.exp: scenario=all: compilation foo.adb ERROR: GDB process no longer exists UNRESOLVED: gdb.ada/arrayptr.exp: scenario=all: gdb_breakpoint: set breakpoint at foo.adb:40 (eof) ERROR: Couldn't run foo-all Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.ada/assign_1.exp ... UNRESOLVED: gdb.ada/assign_1.exp: changing the language to ada PASS: gdb.ada/assign_1.exp: set convenience variable $xxx to 1 The UNRESOLVED for arrayptr.exp is fine, as GDB crashes in that test, while trying to run to main. However, the UNRESOLVED in assign_1.exp doesn't make sense, GDB behaves as expected in that test: (gdb) set lang ada^M (gdb) UNRESOLVED: gdb.ada/assign_1.exp: changing the language to ada print $xxx := 1^M $1 = 1^M (gdb) PASS: gdb.ada/assign_1.exp: set convenience variable $xxx to 1 The problem is that arrayptr.exp calls perror when failing to run to main, then returns. perror makes it so that the next test (as in pass/fail) will be recorded as UNRESOLVED. However, here, the next test (as in pass/fail) is in the next test (as in .exp). Hence the spurious UNRESOLVED in assign_1.exp. These perror when failing to run to X are not really useful, especially since runto records a FAIL on error, by default. Remove all the perrors on runto failure I could find. When there wasn't one already, add a return statement when failing to run, to avoid running the test of the test unnecessarily. I thought of adding a check ran between test (in gdb_finish probably) where we would emit a warning if errcnt > 0, meaning a test quit and left a perror "active". However, reading that variable would poke into the DejaGNU internals, not sure it's a good idea. Change-Id: I2203df6d06e199540b36f56470d1c5f1dc988f7b
2022-11-28gdb/testsuite: remove use of then keyword from gdb.python/*.expAndrew Burgess1-1/+1
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's still a bunch of places in the testsuite where we make use of the 'then' keyword, and sometimes these get copies into new tests, which just spreads poor practice. This commit removes all use of the 'then' keyword from the gdb.python/ test script directory. There should be no changes in what is tested after this commit.
2022-07-15Add 'nibbles' to gdb.print_optionsTom Tromey1-2/+4
When I rebased and updated the print_options patch, I forgot to update print_options to add the new 'nibbles' feature to the result. This patch fixes the oversight. I'm checking this in.
2022-07-15Add 'summary' mode to Value.format_stringTom Tromey1-0/+6
This adds a 'summary' mode to Value.format_string and to gdb.print_options. For the former, it lets Python code format values using this mode. For the latter, it lets a printer potentially detect if it is being called in a backtrace with 'set print frame-arguments' set to 'scalars'. I considered adding a new mode here to let a pretty-printer see whether it was being called in a 'backtrace' context at all, but I'm not sure if this is really desirable.
2022-07-15Expose current 'print' settings to PythonTom Tromey1-11/+38
PR python/17291 asks for access to the current print options. While I think this need is largely satisfied by the existence of Value.format_string, it seemed to me that a bit more could be done. First, while Value.format_string uses the user's settings, it does not react to temporary settings such as "print/x". This patch changes this. Second, there is no good way to examine the current settings (in particular the temporary ones in effect for just a single "print"). This patch adds this as well. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17291
2022-06-24gdb/testsuite: remove unneeded calls to get_compiler_infoAndrew Burgess1-4/+0
It is not necessary to call get_compiler_info before calling test_compiler_info, and, after recent commits that removed setting up the gcc_compiled, true, and false globals from get_compiler_info, there is now no longer any need for any test script to call get_compiler_info directly. As a result every call to get_compiler_info outside of lib/gdb.exp is redundant, and this commit removes them all. There should be no change in what is tested after this commit.
2022-06-18gdb/python: Export nibbles to python layerEnze Li1-0/+73
This patch makes it possible to allow Value.format_string() to return nibbles output. When we set the parameter of nibbles to True, we can achieve the displaying binary values in groups of every four bits. Here's an example: (gdb) py print (gdb.Value (1230).format_string (format='t', nibbles=True)) 0100 1100 1110 (gdb) Note that the parameter nibbles is only useful if format='t' is also used. This patch also includes update to the relevant testcase and documentation. Tested on x86_64 openSUSE Tumbleweed.
2022-04-21gdb/testsuite: add binary testcases to py-format-string.expEnze Li1-0/+37
We currently only test decimal and hexadecimal for the gdb.Value.format_string() interface, this patch adds testcases for binary format. Tested on x86_64 openSUSE Tumbleweed(VERSION_ID="20220413").
2022-02-07gdb/python: allow Value.format_string to return styled outputAndrew Burgess1-3/+17
Add a new argument to the gdb.Value.format_string method, 'styling'. This argument is False by default. When this argument is True, then the returned string can contain output styling escape sequences. When this argument is False, then the returned string will not contain any styling escape sequences. If the returned string is going to be printed to the user, then it is often nice to retain the GDB styling. For the testing, we need to adjust the TERM environment variable, as we do for all the styling tests. I'm now running all of the C tests in gdb.python/py-format-string.exp in an environment where styling could be generated, but only my new test should actually produce styled output, hopefully this will catch the case where a bug might cause format_string to always produce styled output.
2022-01-03[gdb/testsuite] Handle for loop initial decl with gcc 4.8.5Tom de Vries1-1/+7
When running test-case gdb.threads/schedlock-thread-exit.exp on a system with system compiler gcc 4.8.5, I run into: ... src/gdb/testsuite/gdb.threads/schedlock-thread-exit.c:33:3: error: \ 'for' loop initial declarations are only allowed in C99 mode ... Fix this by: - using -std=c99, or - using -std=gnu99, in case that's required, or - in the case of the jit test-cases, rewriting the for loops. Tested on x86_64-linux, both with gcc 4.8.5 and gcc 7.5.0.
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-05-14gdb: fix pretty printing max depth behaviourKent Cheung1-0/+9
The 'print max-depth' feature incorrectly causes GDB to skip printing the string representation of pretty printed variables if the variable is stored at a nested depth corresponding to the set max-depth value. This change ensures that it is always printed before checking whether the maximum print depth has been reached. Regression tested with GCC 7.3.0 on x86_64, ppc64le, aarch64. gdb/ChangeLog: * cp-valprint.c (cp_print_value): Replaced duplicate code. * guile/scm-pretty-print.c (ppscm_print_children): Check max_depth just before printing child values. (gdbscm_apply_val_pretty_printer): Don't check max_depth before printing string representation. * python/py-prettyprint.c (print_children): Check max_depth just before printing child values. (gdbpy_apply_val_pretty_printer): Don't check max_depth before printing string representation. gdb/testsuite/ChangeLog: * gdb.python/py-format-string.c: Added a variable to test. * gdb.python/py-format-string.exp: Check string representation is printed at appropriate max_depth settings. * gdb.python/py-nested-maps.exp: Likewise. * gdb.guile/scm-pretty-print.exp: Add additional tests.
2021-03-12gdb/testsuite: make test names unique in gdb.python/py-format-string.expAndrew Burgess1-18/+18
Make use of `proc_with_prefix` for every test_* proc in order to make the test names unique within this test file. gdb/testsuite/ChangeLog: * gdb.python/py-format-string.exp: Use proc_with_prefix to make test names unique.
2021-01-20[gdb/testsuite] Fix gdb.python/py-format-string.exp with -m32Tom de Vries1-2/+4
When running test-case gdb.python/py-format-string.exp with target board unix/-m32, we run into: ... (gdb) python print \ (gdb.parse_and_eval ('a_base_ref').format_string (deref_refs=True))^M @0xffffc468: {_vptr.Base = 0x80487e0 <vtable for Deriv+8>, a = 42, \ static a_static_member = 2019}^M (gdb) FAIL: gdb.python/py-format-string.exp: format_string: \ lang_cpp: a_base_ref with option deref_refs: deref_refs=true ... while with -m64, we have instead: ... @0x7fffffffd170: {_vptr.Base = 0x400910 <vtable for Deriv+16>, a = 42, \ static a_static_member = 2019}^M (gdb) PASS: gdb.python/py-format-string.exp: format_string: \ lang_cpp: a_base_ref with option deref_refs: deref_refs=true ... The vtable contains pointer entries which are 4-byte for -m32 and 8-byte for -m64, so it's not surprising the offsets (Deriv+8 vs. Deriv+16) differ. Fix this by allow Deriv+$decimal. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-01-20 Tom de Vries <tdevries@suse.de> * gdb.python/py-format-string.exp: Allow Deriv+$decimal as vtable offset.
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-18Add address keyword to Value.format_stringHannes Domani1-0/+43
This makes it possible to disable the address in the result string: const char *str = "alpha"; (gdb) py print(gdb.parse_and_eval("str").format_string()) 0x404000 "alpha" (gdb) py print(gdb.parse_and_eval("str").format_string(address=False)) "alpha" gdb/ChangeLog: 2020-12-18 Hannes Domani <ssbssa@yahoo.de> * python/py-value.c (valpy_format_string): Implement address keyword. gdb/doc/ChangeLog: 2020-12-18 Hannes Domani <ssbssa@yahoo.de> * python.texi (Values From Inferior): Document the address keyword. gdb/testsuite/ChangeLog: 2020-12-18 Hannes Domani <ssbssa@yahoo.de> * gdb.python/py-format-string.exp: Add tests for address keyword.
2020-10-27Fix gdb.python/py-format-string.exp with ClangGary Benson1-2/+2
GDB includes the virtual table pointer when formatting polymorphic C++ objects for printing, but GCC and Clang name these differently: GCC emits a DW_AT_name of "_vptr.Base" when describing the virtual table pointer of a type derived from type "Base", whereas Clang will emit "_vptr$Base" in this situation. This commit fixes a testcase which failed because of this. gdb/testsuite/ChangeLog: * gdb.python/py-format-string.exp (test_deref_refs): Treat "_vptr$Base" as correct, in addition to "_vptr.Base". (test_mixed): Likewise.
2020-06-17Fix TCL error in gdb.python/py-format-string.exp.Sandra Loosemore1-3/+5
2020-06-17 Sandra Loosemore <sandra@codesourcery.com> gdb/testsuite/ * gdb.python/py-format-string.exp: Move test for python support earlier, out of function body.
2020-04-30Adjust array pretty printer tests to the new formatHannes Domani1-3/+3
gdb/testsuite/ChangeLog: 2020-04-30 Hannes Domani <ssbssa@yahoo.de> * gdb.python/py-format-string.exp: Adjust pretty_arrays expected output to the new format.
2020-01-01Update copyright year range in all GDB files.Joel Brobecker1-1/+1
gdb/ChangeLog: Update copyright year range in all GDB files.
2019-10-02gdb/testsuite: Fix py-format-string.exp on big-endian platformsAndreas Arnez1-4/+4
GDB's py-format-string test case depends on endianness. In particular it relies on the first byte of the machine representation of 42 (as an int) to be 42 as well. While this is indeed the case for little-endian machines, big-endian machines store a zero in the first byte instead. The wrong assumption leads to lots of FAILs on such architectures. Fix this by filling the affected union with bytes of the same value, such that endianness does not matter. Use the value 42, to keep the character in the first byte unchanged. gdb/testsuite/ChangeLog: * gdb.python/py-format-string.c (string.h): New include. (main): Fill a_struct_with_union.the_union.an_int with bytes of the same value, for endianness-independence. * gdb.python/py-format-string.exp (default_regexp_dict) (test_pretty_structs, test_format): Adjust expected output to the changed initialization.
2019-04-29gdb: Introduce 'print max-depth' featureAndrew Burgess1-0/+21
Introduce a new print setting max-depth which can be set with 'set print max-depth DEPTH'. The default value of DEPTH is 20, but this can also be set to unlimited. When GDB is printing a value containing nested structures GDB will stop descending at depth DEPTH. Here is a small example: typedef struct s1 { int a; } s1; typedef struct s2 { s1 b; } s2; typedef struct s3 { s2 c; } s3; typedef struct s4 { s3 d; } s4; s4 var = { { { { 3 } } } }; The following table shows how various depth settings affect printing of 'var': | Depth Setting | Result of 'p var' | |---------------+--------------------------------| | Unlimited | $1 = {d = {c = {b = {a = 3}}}} | | 4 | $1 = {d = {c = {b = {a = 3}}}} | | 3 | $1 = {d = {c = {b = {...}}}} | | 2 | $1 = {d = {c = {...}}} | | 1 | $1 = {d = {...}} | | 0 | $1 = {...} | Only structures, unions, and arrays are replaced in this way, scalars and strings are not replaced. The replacement is counted from the level at which you print, not from the top level of the structure. So, consider the above example and this GDB session: (gdb) set print max-depth 2 (gdb) p var $1 = {d = {c = {...}}} (gdb) p var.d $2 = {c = {b = {...}}} (gdb) p var.d.c $3 = {b = {a = 3}} Setting the max-depth to 2 doesn't prevent the user from exploring deeper into 'var' by asking for specific sub-fields to be printed. The motivation behind this feature is to try and give the user more control over how much is printed when examining large, complex data structures. The default max-depth of 20 means that there is a change in GDB's default behaviour. Someone printing a data structure with 20 levels of nesting will now see '{...}' instead of their data, they would need to adjust the max depth, or call print again naming a specific field in order to dig deeper into their data structure. If this is considered a problem then we could increase the default, or even make the default unlimited. This commit relies on the previous commit, which added a new field to the language structure, this new field was a string that contained the pattern that should be used when a structure/union/array is replaced in the output, this allows languages to use a syntax that is more appropriate, mostly this will be selecting the correct types of bracket '(...)' or '{...}', both of which are currently in use. This commit should have no impact on MI output, expressions are printed through the MI using -var-create and then -var-list-children. As each use of -var-list-children only ever displays a single level of an expression then the max-depth setting will have no impact. This commit also adds the max-depth mechanism to the scripting language pretty printers following basically the same rules as for the built in value printing. One quirk is that when printing a value using the display hint 'map', if the keys of the map are structs then GDB will hide the keys one depth level after it hides the values, this ensures that GDB produces output like this: $1 = map_object = {[{key1}] = {...}, [{key2}] = {...}} Instead of this less helpful output: $1 = map_object = {[{...}] = {...}, [{...}] = {...}} This is covered by the new tests in gdb.python/py-nested-maps.exp. gdb/ChangeLog: * cp-valprint.c (cp_print_value_fields): Allow an additional level of depth when printing anonymous structs or unions. * guile/scm-pretty-print.c (gdbscm_apply_val_pretty_printer): Don't print either the top-level value, or the children if the max-depth is exceeded. (ppscm_print_children): When printing the key of a map, allow one extra level of depth. * python/py-prettyprint.c (gdbpy_apply_val_pretty_printer): Don't print either the top-level value, or the children if the max-depth is exceeded. (print_children): When printing the key of a map, allow one extra level of depth. * python/py-value.c (valpy_format_string): Add max_depth keyword. * valprint.c: (PRINT_MAX_DEPTH_DEFAULT): Define. (user_print_options): Initialise max_depth field. (val_print_scalar_or_string_type_p): New function. (val_print): Check to see if the max depth has been reached. (val_print_check_max_depth): Define new function. (show_print_max_depth): New function. (_initialize_valprint): Add 'print max-depth' option. * valprint.h (struct value_print_options) <max_depth>: New field. (val_print_check_max_depth): Declare new function. * NEWS: Document new feature. gdb/doc/ChangeLog: * gdb.texinfo (Print Settings): Document 'print max-depth'. * guile.texi (Guile Pretty Printing API): Document that 'print max-depth' can effect the display of a values children. * python.texi (Pretty Printing API): Likewise. (Values From Inferior): Document max_depth keyword. gdb/testsuite/ChangeLog: * gdb.base/max-depth.c: New file. * gdb.base/max-depth.exp: New file. * gdb.python/py-nested-maps.c: New file. * gdb.python/py-nested-maps.exp: New file. * gdb.python/py-nested-maps.py: New file. * gdb.python/py-format-string.exp (test_max_depth): New proc. (test_all_common): Call test_max_depth. * gdb.fortran/max-depth.exp: New file. * gdb.fortran/max-depth.f90: New file. * gdb.go/max-depth.exp: New file. * gdb.go/max-depth.go: New file. * gdb.modula2/max-depth.exp: New file. * gdb.modula2/max-depth.c: New file. * lib/gdb.exp (get_print_expr_at_depths): New proc.
2019-04-01Add gdb.Value.format_string ()Marco Barisione1-0/+957
The str () function, called on a gdb.Value instance, produces a string representation similar to what can be achieved with the print command, but it doesn't allow to specify additional formatting settings, for instance disabling pretty printers. This patch introduces a new format_string () method to gdb.Value which allows specifying more formatting options, thus giving access to more features provided by the internal C function common_val_print (). gdb/ChangeLog: 2019-04-01 Marco Barisione <mbarisione@undo.io> Add gdb.Value.format_string (). * python/py-value.c (copy_py_bool_obj): (valpy_format_string): Add gdb.Value.format_string (). * NEWS: Document the addition of gdb.Value.format_string (). gdb/doc/ChangeLog: 2019-04-01 Marco Barisione <mbarisione@undo.io> * python.texi (Values From Inferior): Document gdb.Value.format_string (). gdb/testsuite/ChangeLog: 2019-04-01 Marco Barisione <mbarisione@undo.io> Test gdb.Value.format_string (). * gdb.python/py-format-string.exp: New test. * gdb.python/py-format-string.c: New file. * gdb.python/py-format-string.py: New file.
generated by cgit v1.1 at 2025-04-09 01:34:07 +0000