aboutsummaryrefslogtreecommitdiff
path: root/gdb/doc
diff options
context:
space:
mode:
authorMaciej W. Rozycki <macro@mips.com>2018-05-31 15:15:35 +0100
committerMaciej W. Rozycki <macro@mips.com>2018-05-31 15:15:35 +0100
commit4b2dfa9d877a919e05817e6bfa4eda3addaf1b34 (patch)
treeec8b2273e8b66ed97f3feddefe067fe74e1229fc /gdb/doc
parent122394f1476b1c925a281b15399119500c8231c1 (diff)
downloadgdb-4b2dfa9d877a919e05817e6bfa4eda3addaf1b34.zip
gdb-4b2dfa9d877a919e05817e6bfa4eda3addaf1b34.tar.gz
gdb-4b2dfa9d877a919e05817e6bfa4eda3addaf1b34.tar.bz2
arch-utils: Make the last endianness actually chosen sticky
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.
Diffstat (limited to 'gdb/doc')
-rw-r--r--gdb/doc/ChangeLog5
-rw-r--r--gdb/doc/gdb.texinfo9
2 files changed, 14 insertions, 0 deletions
diff --git a/gdb/doc/ChangeLog b/gdb/doc/ChangeLog
index 798ff37..1689e89 100644
--- a/gdb/doc/ChangeLog
+++ b/gdb/doc/ChangeLog
@@ -1,3 +1,8 @@
+2018-05-31 Maciej W. Rozycki <macro@mips.com>
+
+ * gdb.texinfo (Choosing Target Byte Order): Document endianness
+ selection details with the `set endian auto' mode.
+
2018-05-04 Tom Tromey <tom@tromey.com>
PR python/22731:
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index 305f21a..2920022 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -20308,6 +20308,15 @@ Display @value{GDBN}'s current idea of the target byte order.
@end table
+If the @code{set endian auto} mode is in effect and no executable has
+been selected, then the endianness used is the last one chosen either
+by one of the @code{set endian big} and @code{set endian little}
+commands or by inferring from the last executable used. If no
+endianness has been previously chosen, then the default for this mode
+is inferred from the target @value{GDBN} has been built for, and is
+@code{little} if the name of the target CPU has an @code{el} suffix
+and @code{big} otherwise.
+
Note that these commands merely adjust interpretation of symbolic
data on the host, and that they have absolutely no effect on the
target system.