riscv-gnu-toolchain/binutils.git - Unnamed repository; edit this file 'description' to name the repository.

Age	Commit message (Collapse)	Author	Files	Lines
2024-04-02	Run isort	Tom Tromey	1	-0/+1
	This patch is the result of running 'isort .' in the gdb directory. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2024-01-12	Update copyright year range in header of all files managed by GDB	Andrew Burgess	1	-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-01-01	Update copyright year range in header of all files managed by GDB	Joel Brobecker	1	-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-03-23	gdb/python: remove Python 2 support	Simon Marchi	1	-8/+4
	New in this version: - Add a PY_MAJOR_VERSION check in configure.ac / AC_TRY_LIBPYTHON. If the user passes --with-python=python2, this will cause a configure failure saying that GDB only supports Python 3. Support for Python 2 is a maintenance burden for any patches touching Python support. Among others, the differences between Python 2 and 3 string and integer types are subtle. It requires a lot of effort and thinking to get something that behaves correctly on both. And that's if the author and reviewer of the patch even remember to test with Python 2. See this thread for an example: https://sourceware.org/pipermail/gdb-patches/2021-December/184260.html So, remove Python 2 support. Update the documentation to state that GDB can be built against Python 3 (as opposed to Python 2 or 3). Update all the spots that use: - sys.version_info - IS_PY3K - PY_MAJOR_VERSION - gdb_py_is_py3k ... to only keep the Python 3 portions and drop the use of some now-removed compatibility macros. I did not update the configure script more than just removing the explicit references to Python 2. We could maybe do more there, like check the Python version and reject it if that version is not supported. Otherwise (with this patch), things will only fail at compile time, so it won't really be clear to the user that they are trying to use an unsupported Python version. But I'm a bit lost in the configure code that checks for Python, so I kept that for later. Change-Id: I75b0f79c148afbe3c07ac664cfa9cade052c0c62
2022-01-01	Automatic Copyright Year update after running gdb/copyright.py	Joel Brobecker	1	-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-07	gdb: re-format Python files using black 21.4b0	Simon Marchi	1	-27/+27
	Re-format all Python files using black [1] version 21.4b0. The goal is that from now on, we keep all Python files formatted using black. And that we never have to discuss formatting during review (for these files at least) ever again. One change is needed in gdb.python/py-prettyprint.exp, because it matches the string representation of an exception, which shows source code. So the change in formatting must be replicated in the expected regexp. To document our usage of black I plan on adding this to the "GDB Python Coding Standards" wiki page [2]: --8<-- All Python source files under the `gdb/` directory must be formatted using black version 21.4b0. This specific version 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 to do: $ black gdb/ from the top-level. If you notice that black produces changes unrelated to your patch, it's probably because someone forgot to run it before you. In this case, don't include unrelated hunks in your patch. Push an obvious patch fixing the formatting and rebase your work on top of that. -->8-- Once this is merged, I plan on setting a up an `ignoreRevsFile` config so that git-blame ignores this commit, as described here: https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame I also plan on working on a git commit hook (checked in the repo) to automatically check the formatting of the Python files on commit. [1] https://pypi.org/project/black/ [2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards gdb/ChangeLog: * Re-format all Python files using black. gdb/testsuite/ChangeLog: * Re-format all Python files using black. * gdb.python/py-prettyprint.exp (run_lang_tests): Adjust. Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
2021-01-01	Update copyright year range in all GDB files	Joel Brobecker	1	-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-01	Update copyright year range in all GDB files.	Joel Brobecker	1	-1/+1
	gdb/ChangeLog: Update copyright year range in all GDB files.
2019-01-01	Update copyright year range in all GDB files.	Joel Brobecker	1	-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-31	Fix segfault when invoking -var-info-path-expression on a dynamic varobj	Jan Vrany	1	-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.