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

Age	Commit message (Collapse)	Author	Files	Lines
9 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-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-01	gdb: defer warnings when loading separate debug files	Alexandra Hájková	1	-0/+20
	Currently, when GDB loads debug information from a separate debug file, there are a couple of warnings that could be produced if things go wrong. In find_separate_debug_file_by_buildid (build-id.c) GDB can give a warning if the separate debug file doesn't include any actual debug information, and in separate_debug_file_exists (symfile.c) we can warn if the CRC checksum in the separate debug file doesn't match the checksum in the original executable. The problem here is that, when looking up debug information, GDB will try several different approaches, lookup by build-id, lookup by debug-link, and then a lookup from debuginfod. GDB can potentially give a warning from an earlier attempt, and then succeed with a later attempt. In the cases I have run into this is primarily a warning about some out of date debug information on my machine, but then GDB finds the correct information using debuginfod. This can be confusing to a user, they will see warnings from GDB when really everything is working just fine. For example: warning: the debug information found in "/usr/lib/debug//lib64/ld-2.32.so.debug" \ does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch). This diagnostic was printed on Fedora 33 even when the correct debuginfo was downloaded. In this patch I propose that we defer any warnings related to looking up debug information from a separate debug file. If any of the approaches are successful then GDB will not print any of the warnings. As far as the user is concerned, everything "just worked". Only if GDB completely fails to find any suitable debug information will the warnings be printed. The crc_mismatch test compiles two executables: crc_mismatch and crc_mismatch-2 and then strips them of debuginfo creating separate debug files. The test then replaces crc_mismatch-2.debug with crc_mismatch.debug to trigger "CRC mismatch" warning. A local debuginfod server is setup to supply the correct debug file, now when GDB looks up the debug info no warning is given. The build-id-no-debug-warning.exp is similar to the previous test. It triggers the "separate debug info file has no debug info" warning by replacing the build-id based .debug file with the stripped binary and then loading it to GDB. It then also sets up local debuginfod server with the correct debug file to download to make sure no warnings are emitted.