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

Age	Commit message (Collapse)	Author	Files	Lines
7 days	Update copyright dates to include 2025	Tom Tromey	1	-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-04-02	Run isort	Tom Tromey	1	-1/+2
	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-02-27	gdb: reformat Python files with black 23.1.0	Simon Marchi	1	-0/+2
	Change-Id: Ie8ec8870a16d71c5858f5d08958309d23c318302 Reviewed-By: Tom Tromey <tom@tromey.com> Reviewed-By: Andrew Burgess <aburgess@redhat.com>
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-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-10-05	gdb/python: fix memory leak in python inferior code	Andrew Burgess	1	-0/+109
	When a user creates a gdb.Inferior object for the first time a new Python object is created. This object is then cached within GDB's inferior object using the registry mechanism (see inferior_to_inferior_object in py-inferior.c, specifically the calls to inferior_data and set_inferior_data). The Python Reference to the gdb.Inferior object held within the real inferior object ensures that the reference count on the Python gdb.Inferior object never reaches zero while the GDB inferior object continues to exist. At the same time, the gdb.Inferior object maintains a C++ pointer back to GDB's real inferior object. We therefore end up with a system that looks like this: Python Reference \| \| .----------. \| .--------------. \| \|------------------->\| \| \| inferior \| \| gdb.Inferior \| \| \|<-------------------\| \| '----------' \| '--------------' \| \| C++ Pointer When GDB's inferior object is deleted (say the inferior exits) then py_free_inferior is called (thanks to the registry system), this function looks up the Python gdb.Inferior object and sets the C++ pointer to nullptr and finally reduces the reference count on the Python gdb.Inferior object. If at this point the user still holds a reference to the Python gdb.Inferior object then nothing happens. However, the gdb.Inferior object is now in the non-valid state (see infpy_is_valid in py-inferior.c), but otherwise, everything is fine. However, if there are no further references to the Python gdb.Inferior object, or, once the user has given up all their references to the gdb.Inferior object, then infpy_dealloc is called. This function currently checks to see if the inferior pointer within the gdb.Inferior object is nullptr or not. If the pointer is nullptr then infpy_dealloc immediately returns. Only when the inferior point in the gdb.Inferior is not nullptr do we (a) set the gdb.Inferior reference inside GDB's inferior to nullptr, and (b) call the underlying Python tp_free function. There are a number things wrong here: 1. The Python gdb.Inferior reference within GDB's inferior object holds a reference count, thus, setting this reference to nullptr without first decrementing the reference count would leak a reference, however... 2. As GDB's inferior holds a reference then infpy_dealloc will never be called until GDB's inferior object is deleted. Deleting a GDB inferior ohject calls py_free_inferior, and so gives up the reference. At this point there is no longer a need to call set_inferior_data to set the field back to NULL, that field must have been cleared in order to get the reference count to zero, which means... 3. If we know that py_free_inferior must be called before infpy_dealloc, then we know that the inferior pointer in gdb.Inferior will always be nullptr when infpy_dealloc is called, this means that the call to the underlying tp_free function will always be skipped. Skipping this call will cause Python to leak the memory associated with the gdb.Inferior object, which is what we currently always do. Given all of the above, I assert that the C++ pointer within gdb.Inferior will always be nullptr when infpy_dealloc is called. That's what this patch does. I wrote a test for this issue making use of Pythons tracemalloc module, which allows us to spot this memory leak.