[Qemu-discuss] Backtrace of "git clone" running inside qemu-user-emulation based arm-chroot

[Martin Zenzes]

Hi,

I'm running a wheezy:armhf chroot using qemu user emulation [1] on my jessie:x86_64 system and trying to debug git (which hangs at some point), created an unstripped git-dbg binary. Using qemu's builtin gdb_stub inside the chroot I'm doing:

    QEMU_GDB=1234 git clone /path/to/some/repo /tmp/bla

Firing up gdb-multiarch outside the chroot, to connect:

    gdb-multiarch -q
    (gdb) set architecture arm                    # prevents "warning: Architecture rejected target-supplied description"
    (gdb) target remote localhost:1234
    (gdb) set sysroot /opt/chroots/wheezy:armhf
    (gdb) file /opt/chroots/wheezy:armhf/usr/bin/git
    Reading symbols from /opt/chroots/wheezy:armhf/usr/bin/git...done. # good! has debug symbols!
    (gdb) list                                    # works! code is not stripped
    (gdb) step
    Cannot find bounds of current function        # meh...
    (gdb) backtracke
    #0  0xf67e0c90 in ?? ()
    #1  0x00000000 in ?? ()                       # wtf?

Giving a continue to let the clone happen will result in a hang, sending a ctrl-c is ignored.

Generating a core-file and loading it into gdb (inside the chroot) will give me a corrupt stack:

    gdb -q /usr/bin/git qemu_git_20140514-160951_22373.core
    Reading symbols from /usr/bin/git...done.
    [New LWP 22373]
    Cannot access memory at address 0xf67fe948
    Cannot access memory at address 0xf67fe944
    (gdb) bt
    #0  0xf678b3e4 in ?? ()
    #1  0xf678b3d4 in ?? ()
    #2  0xf678b3d4 in ?? ()
    Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Now I'm lost.

Where is the problem? Did I miss some detail in the qemu-user-emulation? Do I have to use a completely emulated arm-machine (so slooouw...)? Thanks for any suggestions, pointers, hints, tips, comments and what-not...

My best guess in the moment is based on the fact that git does a clone (I can see two processes/threads), but the QEMU_GDB environment variable is unset by qemu after using... Hence only the initial process is going to gdb? [2]

But still: I should be able to properly debug the parent process? I can easily cross-debug a hello-world MWE...

This (stripped down) text initially appeared SE first [3] .

    Greetings Martin

---

[1] https://wiki.debian.org/QemuUserEmulation#Appendix%3a_chrooting_into_target_file_systems
[2] https://groups.google.com/forum/#!topic/proot_me/ev2rS7kma30
[3] https://unix.stackexchange.com/questions/129366/backtrace-of-program-running-inside-qemu-user-emulation-based-chroot