[Pkg-libvirt-commits] [libguestfs] 12/165: launch: direct: Turn gdb into a backend setting.

[Hilko Bengen]

This is an automated email from the git hooks/post-receive script.

bengen pushed a commit to branch experimental
in repository libguestfs.

commit 0c1a4b1781447d5b485b38e06fe3dcf486ab009d
Author: Richard W.M. Jones <rjones at redhat.com>
Date:   Fri May 2 10:55:21 2014 +0100

    launch: direct: Turn gdb into a backend setting.
    
    You can now use LIBGUESTFS_BACKEND_SETTINGS=gdb in order to enable gdb
    debugging of the appliance.  This only works with the direct backend.
---
 src/guestfs.pod     | 28 ++++++++++++++++++++++++++--
 src/launch-direct.c | 28 ++++++----------------------
 2 files changed, 32 insertions(+), 24 deletions(-)

diff --git a/src/guestfs.pod b/src/guestfs.pod
index 0f54625..eb56631 100644
--- a/src/guestfs.pod
+++ b/src/guestfs.pod
@@ -1488,13 +1488,37 @@ either call L</guestfs_set_backend_settings> with a list of strings,
 or set the C<LIBGUESTFS_BACKEND_SETTINGS> environment variable to a
 colon-separated list of strings (before creating the handle).
 
-Currently the only backend setting is:
+=head3 force_tcg
+
+Using:
 
  export LIBGUESTFS_BACKEND_SETTINGS=force_tcg
 
-which will force the direct and libvirt backends to use TCG (software
+will force the direct and libvirt backends to use TCG (software
 emulation) instead of KVM (hardware accelerated virtualization).
 
+=head3 gdb
+
+The direct backend supports:
+
+ export LIBGUESTFS_BACKEND_SETTINGS=gdb
+
+When this is set, qemu will not start running the appliance
+immediately.  It will wait for you to connect to it using gdb:
+
+ $ gdb
+ (gdb) symbol-file /path/to/vmlinux
+ (gdb) target remote tcp::1234
+ (gdb) cont
+
+You can then debug the appliance kernel, which is useful to debug boot
+failures (especially ones where there are no debug messages printed -
+tip: look in the kernel C<log_buf>).
+
+On Fedora, install C<kernel-debuginfo> for the C<vmlinux> file
+(containing symbols).  Make sure the symbols precisely match the
+kernel being used.
+
 =head2 ATTACHING TO RUNNING DAEMONS
 
 I<Note (1):> This is B<highly experimental> and has a tendency to eat
diff --git a/src/launch-direct.c b/src/launch-direct.c
index 90dc646..0fd84b7 100644
--- a/src/launch-direct.c
+++ b/src/launch-direct.c
@@ -403,28 +403,12 @@ launch_direct (guestfs_h *g, void *datav, const char *arg)
   ADD_CMDLINE (MACHINE_TYPE);
 #endif
 
-  /* If this is uncommented, then qemu won't start running the
-   * appliance immediately.  It will wait for you to connect to it
-   * using gdb:
-   *
-   *   $ gdb
-   *   (gdb) symbol-file /path/to/vmlinux
-   *   (gdb) target remote tcp::1234
-   *   (gdb) cont
-   *
-   * You can then debug the appliance kernel, which is useful to debug
-   * boot failures (especially ones where there are no debug messages
-   * printed - tip: look in the kernel log_buf).
-   *
-   * On Fedora, install kernel-debuginfo for the vmlinux file
-   * (containing symbols).  Make sure the symbols precisely match the
-   * kernel being used.
-   */
-#if 0
-  ADD_CMDLINE ("-S");
-  ADD_CMDLINE ("-s");
-  warning (g, "qemu debugging is enabled, connect gdb to tcp::1234 to begin");
-#endif
+  /* See guestfs.pod / gdb */
+  if (guestfs___get_backend_setting_bool (g, "gdb") > 0) {
+    ADD_CMDLINE ("-S");
+    ADD_CMDLINE ("-s");
+    warning (g, "qemu debugging is enabled, connect gdb to tcp::1234 to begin");
+  }
 
   /* Try to guess if KVM is available.  We are just checking that
    * /dev/kvm is openable.  That's not reliable, since /dev/kvm

-- 
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/pkg-libvirt/libguestfs.git