aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/gdb.python/py-mi-var-info-path-expression.py
AgeCommit message (Collapse)AuthorFilesLines
2021-04-26gdb: re-format Python files using black 21.4b0users/simark/blackSimon Marchi1-27/+27
Re-format all Python files using black [1] version 21.4b0. This specific version (currently the latest) can be installed using: $ pip3 install 'black == 21.4b0' All you need to do to re-format files is run `black <file/directory>`, and black will re-format any Python file it finds in there. It runs quite fast, so the simplest is probably to do: $ black gdb/ from the top-level. Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
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-01-01Update copyright year range in all GDB files.Joel Brobecker1-1/+1
gdb/ChangeLog: Update copyright year range in all GDB files.
2019-01-01Update copyright year range in all GDB files.Joel Brobecker1-1/+1
This commit applies all changes made after running the gdb/copyright.py script. Note that one file was flagged by the script, due to an invalid copyright header (gdb/unittests/basic_string_view/element_access/char/empty.cc). As the file was copied from GCC's libstdc++-v3 testsuite, this commit leaves this file untouched for the time being; a patch to fix the header was sent to gcc-patches first. gdb/ChangeLog: Update copyright year range in all GDB files.
2018-07-31Fix segfault when invoking -var-info-path-expression on a dynamic varobjJan Vrany1-0/+57
Invoking -var-info-path-expression on a dynamic varobj lead either in wrong (nonsense) result or to a segmentation fault in cplus_describe_child(). This was caused by the fact that varobj_get_path_expr() called cplus_path_expr_of_child() ignoring the fact the parent of the variable is dynamic. Then, cplus_describe_child() accessed the underlaying C type members by index, causing (i) either wrong (nonsense) expression being returned (since dynamic child may be completely arbibtrary value) or (ii) segmentation fault (in case the index higher than number of underlaying C type members. This fixes the problem by checking whether a varobj is a child of a dynamic varobj and, if so, reporting an error as described in documentation. gdb/ChangeLog: * varobj.c (varobj_get_path_expr_parent): Report an error if parent is a dynamic varobj. gdb/testsuite/Changelog: * gdb.python/py-mi-var-info-path-expression.c: New file. * gdb.python/py-mi-var-info-path-expression.py: New file. * gdb.python/py-mi-var-info-path-expression.exp: New file.