Default to full gdb backtraces (#21)

Receiving a dump of local variables often reduces the number of requests
for more information in bug reports and speeds up triage. The downsides
(i.e. more output, slightly higher risk of exposing sensitive
information, and hypothetical lack of support in very old gdb) are not
significant enough to preserve the old "less info" default.

AFAICT, gdb supports `backtrace full` since 1998 commit 65b07dd (at
least). Since 2019, gdb prefers `backtrace -full` to `backtrace full`,
but we are not upgrading yet to accommodate older/more environments.
Other debuggers may not support "full", but our instructions are already
gdb-specific, and most folks folks can adapt them as needed.

Also do not distract the reader with an out-of-scope explanation on how
gdb commands may be abbreviated (e.g., "bt" instead of "backtrace").

Author: rousskov

docs/SquidFaq/BugReporting.md

@@ -33,12 +33,11 @@ checks. If one of those checks fail, Squid calls abort() to generate a
 core dump.
 
 If you have a core dump file, then use gdb to extract a stack trace from
-the core using a "bt full" command (if supported) or a "backtrace"
-command (can be typed as "bt" and is always supported, but gives less
-information):
+the core using a `backtrace full` command (if supported) or a `backtrace`
+command (always supported, but gives less information):
 
     % gdb /usr/local/squid/sbin/squid core
-    gdb> backtrace
+    gdb> backtrace full
 
 Many people report that Squid doesn't leave a coredump anywhere. This
 may be due to one of the following reasons:
@@ -67,7 +66,7 @@ may be due to one of the following reasons:
     Core was generated by `(squid) -D'.
     Program terminated with signal 6, Aborted.
 
-    (gdb) bt
+    (gdb) backtrace full
     #0  0x006ad7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
     #1  0x006ed7a5 in raise () from /lib/tls/libc.so.6
     #2  0x006ef209 in abort () from /lib/tls/libc.so.6
@@ -163,7 +162,7 @@ Once you have located the core dump file, use a debugger such as *dbx*
 or *gdb* to generate a stack trace:
 
     % gdb /usr/local/squid/sbin/squid core
-    gdb> backtrace
+    gdb> backtrace full
 
 If possible, you might keep the coredump file around for a day or two.
 It is often helpful if we can ask you to send additional debugger
@@ -225,7 +224,7 @@ handle SIGSEGV stop
 handle SIGABRT stop
 run -NYCX
 [wait for crash]
-backtrace
+backtrace full
 quit
 ```
 
@@ -248,7 +247,7 @@ handle SIGKILL pass
 handle SIGSEGV stop
 handle SIGABRT stop
 run -NYCd3
-backtrace
+backtrace full
 quit
 EOF
 while sleep 2; do
@@ -283,7 +282,7 @@ handle SIGABRT stop
 
 attach [worker PID]
 [wait for crash]
-backtrace
+backtrace full
 detach
 quit
 ```
@@ -296,11 +295,10 @@ stuck in a busy loop, and/or you want to know what your Squid is doing
 
 1. To dump the current stack using gdb:
 ```
-        sudo gdb -n -batch -ex backtrace -pid <PID>
+        sudo gdb -n -batch -ex 'backtrace full' -pid <PID>
 ```
     You may not need/want the `-n` (i.e. do not load gdb initialization
-    files) option. Using `'backtrace full'` instead of `backtrace` will
-    give even more info but might be a tad slower.
+    files) option.
 1. To dump the current stack using pstack(1):
 ```
         sudo pstack <PID>