Using GDB to debug guest code

[Eric Mugnier]

Hi

I am trying to run gdb to debug the guest-code in S2E (similar to this question)  but I did not succeed to make it work.

I looked at these different methods:

• ./launch-s2e.sh debug seems to be made for debugging S2E and not the guest code

• Debugging Guest Code seems to be outdated and triggers the following message/bug

libs2e: unknown KVM VCPU IOCTL vcpu 24 request=0x4048ae9b arg=0x7ffc3e3ac6f0 ret=0xffffffff
libs2e: unknown KVM VCPU IOCTL vcpu 24 request=0x4048ae9b arg=0x7ffc3e3ac6f0 ret=0xffffffff
Co-routine is yielding to no one
./launch-s2e.sh: line 99: 12567 Aborted                 (core dumped) LD_PRELOAD=$LIBS2E $QEMU $QEMU_DRIVE -s -k en-us $GRAPHICS -monitor null -m $QEMU_MEMORY -enable-kvm -serial file:serial.txt $QEMU_EXTRA_FLAGS -loadvm $QEMU_SNAPSHOT $*

• starting gdb in the host (which seems to be the correct method) triggers a segault with the following trace:

60 [State 0] BaseInstructions: Message from guest (0xffffc900004b7a30): elf_interpreter=/lib64/ld-linux-x86-64.so.2 interp_map_addr=7ffff7dd9000 elf_entry=0x7ffff7dd9000 interp_load_addr=0x7ffff7dd9000
60 [State 0] LinuxMonitor: ModuleDescriptor Name=ld-linux-x86-64.so.2 Path=/lib64/ld-linux-x86-64.so.2 Size=0x23fe0 AddressSpace=0xdf33000 Pid=0x4fd EntryPoint=0xc20 Checksum=0x0
60 [State 0] LinuxMonitor: ModuleDescriptor Name=postgres Path=/home/s2e/postgres Size=0x9ec044 AddressSpace=0xdf33000 Pid=0x4fd EntryPoint=0x5555556038a0 Checksum=0x0
60 [State 0] ModuleExecutionDetector: loading id mod_0
60 [State 0] LinuxMonitor: Removing task (pid=0x4ff, cr3=0x1e08000, exitCode=9).
60 [State 0] LinuxMonitor: Removing task (pid=0x4fe, cr3=0x1e08000, exitCode=9).
60 [State 0] LinuxMonitor: mmap pid=0x4fb addr=0x7fab2e9aa000 size=0x2 prot=0x3 flag=0x22 pgoff=0x0
60 [State 0] LinuxMonitor: Received segfault type=0 pagedir=0xdf31000 pid=0x500 pc=0x7fab2e9aa000 addr=0x7fab2e9aa000
60 [State 0] LinuxMonitor: Blocking searcher until state is terminated
60 [State 0] LinuxMonitor: 0xcc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x7fab2e9aa000:  int3    
0x7fab2e9aa001:  add     byte ptr [rax], al
0x7fab2e9aa003:  add     byte ptr [rax], al
...
0x7fab2e9aa0fb:  add     byte ptr [rax], al
0x7fab2e9aa0fd:  add     byte ptr [rax], al
60 [State 0] TestCaseGenerator: generating test case at address 0xffffffff8104b2d4
60 [State 0] LinuxMonitor: Terminating state: received segfault
60 [State 0] Terminating state: Segfault
60 [State 0] TestCaseGenerator: generating test case at address 0xffffffff8104b2d4
60 [State 0] TestCaseGenerator: All states were terminated
qemu-system-x86_64: terminating on signal 15 from pid 12114 (/home/em/ac_sym/s2e/install/bin/qemu-system-x86_64)
s2e-block: dirty sectors on close:544
Terminating node id 0 (instance slot 0)
Engine terminated.

Could you indicate to me the correct method to debug the guest-code in S2E and follow line by line its execution using gdb?

Thank you for help,

Eric

[Vitaly Chipounov]

Hi,

Indeed, the documentation is outdated. It was somewhat working on the old version of S2E (https://github.com/s2e/s2e-old), the new one does not support that anymore.
Note that this method uses QEMU's guest debugging capabilities. It debugs whatever code runs in the guest, which may or may not be the program you want.

Instead, you could run gdb inside the guest. Modify bootstrap.sh to call gdb with your program, then start S2E with:
$ GUI=1 ./launch-s2e.sh

./launch-s2e.sh debug is indeed made to debug S2E, it won't debug the guest code.

Vitaly

--
--
You received this message because you are a member of the S2E Developer Forum.
To post to this group, send email to s2e...@googlegroups.com
To unsubscribe from this group, send email to s2e-dev+u...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/s2e-dev

---
You received this message because you are subscribed to the Google Groups "S2E Developer Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to s2e-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/s2e-dev/68d7987d-2808-43a0-b778-c59381940c6en%40googlegroups.com.

[Eric Mugnier]

Hi Vitaly,

Thank you for your prompt answer,

Running gdb inside the guest is equivalent to the second point that I mentioned in my previous message. As you can see in the previous message, it ends up in a segfault. Do you have any idea on how I could fix this?

Eric

[Vitaly Chipounov]

Hi,

On 8/23/21 6:04 PM, 'Eric Mugnier' via S2E Developer Forum wrote:

Running gdb inside the guest is equivalent to the second point that I mentioned in my previous message. As you can see in the previous message, it ends up in a segfault. Do you have any idea on how I could fix this?

No, it's not. What I meant is to start gdb inside the guest, like you would normally do when you debug a program. What the documentation does instead is have QEMU expose through a network port a GDB target to which a GDB instance running on the host can connect. That's what the QEMU's -s switch is for. In this mode, QEMU presents the entire guest address space to GDB. It's useful, e.g., to debug the guest kernel. If you really want this mode, you could have a look at this issue [1]. I think it's easier to just write gdb --args "${TARGET}" "$@" around this line [2]. You will need to write a GDB script to preload s2e.so before it starts the target (see [3] for an example).

Vitaly

[1] https://github.com/S2E/s2e-env/issues/60
[2] https://github.com/S2E/s2e-env/blob/master/s2e_env/templates/bootstrap.linux.sh#L24
[3] https://github.com/S2E/s2e-env/blob/master/s2e_env/templates/launch-s2e.sh#L68

To view this discussion on the web visit https://groups.google.com/d/msgid/s2e-dev/eb8ac955-ba54-4612-a175-bd666cacc4d7n%40googlegroups.com.

[Eric Mugnier]

Hi,

Sorry for the last message, I mixed up the points 2 and 3 of my first message. I was actually referring to "starting gdb in the host (which seems to be the correct method) triggers a segault". As shown in the first message, when using gdb inside the host I get a segfault with a long trace error message (included in the first message). Do you know what could be a good method to debug/fix this?

Thank you for your help and sorry for the mistake in the last message,

Eric

[Vitaly Chipounov]

Hi,

You mean "terminating on signal 15 from pid 12114"? In this case, it's normal behavior. There are no more states to run, so S2E terminated itself (sigterm). The segfault you see is caused by a guest program that may have crashed. The LinuxMonitor plugin intercepts the segfault and terminates the state. You can disable this behavior with this setting [1], e.g., if the segfault is expected.

Vitaly

[1] https://github.com/S2E/s2e-env/blob/master/s2e_env/templates/s2e-config.linux.lua#L13

To view this discussion on the web visit https://groups.google.com/d/msgid/s2e-dev/1d3bc59d-fe31-4a04-963a-6b134dfcc250n%40googlegroups.com.

[Eric Mugnier]

Hi,

Thank you for clarifying that. It works well now.

Thank you for your help,

Eric