rocket-tools/fsf-binutils-gdb.git - Unnamed repository; edit this file 'description' to name the repository.

Age	Commit message (Collapse)	Author	Files	Lines
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-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-05-31	arch-utils: Make the last endianness actually chosen sticky	Maciej W. Rozycki	1	-0/+22
	Use the last endianness explicitly selected, either by choosing a binary file or with the `set endian' command, for future automatic selection. As observed with the `gdb.base/step-over-no-symbols.exp' test case when discarding the binary file even while connected to a live target the endianness automatically selected is reset to the GDB target's default, even if it does not match the endianness of the target being talked to. For example with a little-endian MIPS target and the default endianness being big we get this: (gdb) file .../gdb/testsuite/outputs/gdb.base/step-over-no-symbols/step-over-no-symbols Reading symbols from .../gdb/testsuite/outputs/gdb.base/step-over-no-symbols/step-over-no-symbols...done. (gdb) delete breakpoints (gdb) info breakpoints No breakpoints or watchpoints. (gdb) break main Breakpoint 1 at 0x400840: file .../gdb/testsuite/gdb.base/start.c, line 34. [...] (gdb) continue Continuing. Breakpoint 1, main () at .../gdb/testsuite/gdb.base/start.c:34 34 foo(); (gdb) delete breakpoints Delete all breakpoints? (y or n) y (gdb) info breakpoints No breakpoints or watchpoints. (gdb) file A program is being debugged already. Are you sure you want to change the file? (y or n) y No executable file now. Discard symbol table from `.../gdb/testsuite/outputs/gdb.base/step-over-no-symbols/step-over-no-symbols'? (y or n) y No symbol file now. (gdb) PASS: gdb.base/step-over-no-symbols.exp: displaced=off: purging symbols p /x $pc $1 = 0x40084000 (gdb) PASS: gdb.base/step-over-no-symbols.exp: displaced=off: get before PC break $pc Breakpoint 2 at 0x40084000 (gdb) PASS: gdb.base/step-over-no-symbols.exp: displaced=off: break $pc set displaced-stepping off (gdb) PASS: gdb.base/step-over-no-symbols.exp: displaced=off: set displaced-stepping off stepi Warning: Cannot insert breakpoint 2. Cannot access memory at address 0x40084000 Command aborted. (gdb) FAIL: gdb.base/step-over-no-symbols.exp: displaced=off: stepi p /x $pc $2 = 0x40084000 (gdb) PASS: gdb.base/step-over-no-symbols.exp: displaced=off: get after PC FAIL: gdb.base/step-over-no-symbols.exp: displaced=off: advanced Remote debugging from host ... monitor exit (gdb) Killing process(es): ... testcase .../gdb/testsuite/gdb.base/step-over-no-symbols.exp completed in 2 seconds which shows that with the removal of the executable debugged the endianness of $pc still at `main' gets swapped and the value in that register is now incorrectly interpreted as 0x40084000 rather than 0x400840 as shown earlier on with the `break' command. Consequently the debug session no longer works as expected, until the endianness is overridden with an explicit `set endian little' command. This will happen while working with any target hardware whose endianness does not match the default GDB target's endianness guessed and recorded for a later use in `initialize_current_architecture'. Given that within a single run of GDB it is more likely that consecutive target connections will use the same endianness than that the endianness will be swapped between connections, it makes sense to preserve the last endianness explicitly selected as the automatic default. It will make a session like above, where an executable is removed, work correctly and will retain the endianness for a further reconnection to the target. And the new automatic default will still be overridden by subsequently choosing a binary to debug, or with an explicit `set endian' command. With the change in place the test case above completes successfully: (gdb) continue Continuing. Breakpoint 1, main () at .../gdb/testsuite/gdb.base/start.c:34 34 foo(); (gdb) delete breakpoints Delete all breakpoints? (y or n) y (gdb) info breakpoints No breakpoints or watchpoints. (gdb) file A program is being debugged already. Are you sure you want to change the file? (y or n) y No executable file now. Discard symbol table from `.../gdb/testsuite/outputs/gdb.base/step-over-no-symbols/step-over-no-symbols'? (y or n) y No symbol file now. (gdb) PASS: gdb.base/step-over-no-symbols.exp: displaced=off: purging symbols p /x $pc warning: GDB can't find the start of the function at 0x400840. GDB is unable to find the start of the function at 0x400840 and thus can't determine the size of that function's stack frame. This means that GDB may be unable to access that stack frame, or the frames below it. This problem is most likely caused by an invalid program counter or stack pointer. However, if you think GDB should simply search farther back from 0x400840 for code which looks like the beginning of a function, you can increase the range of the search using the `set heuristic-fence-post' command. $1 = 0x400840 (gdb) PASS: gdb.base/step-over-no-symbols.exp: displaced=off: get before PC break $pc Breakpoint 2 at 0x400840 (gdb) PASS: gdb.base/step-over-no-symbols.exp: displaced=off: break $pc set displaced-stepping off (gdb) PASS: gdb.base/step-over-no-symbols.exp: displaced=off: set displaced-stepping off stepi warning: GDB can't find the start of the function at 0x4007f8. 0x004007f8 in ?? () (gdb) PASS: gdb.base/step-over-no-symbols.exp: displaced=off: stepi p /x $pc $2 = 0x4007f8 (gdb) PASS: gdb.base/step-over-no-symbols.exp: displaced=off: get after PC PASS: gdb.base/step-over-no-symbols.exp: displaced=off: advanced Remote debugging from host ... monitor exit (gdb) Killing process(es): ... testcase .../gdb/testsuite/gdb.base/step-over-no-symbols.exp completed in 2 seconds gdb/ * arch-utils.c (gdbarch_info_fill): Set `default_byte_order' to the endianness selected. * NEWS: Document `set endian auto' mode operation update. gdb/doc/ * gdb.texinfo (Choosing Target Byte Order): Document endianness selection details with the `set endian auto' mode. gdb/testsuite * gdb.base/endian.exp: New test. * gdb.base/endian.c: New test source.