CODEWITHSUNDEEP
c++gdbcross-compilingqemuwindows-subsystem-for-linux
Kristofer
Kristofer

Reputation: 3269

wsl2, gdb and cross-debug 32bit i386 - failing to map addresses to symbols ( in ?? () )

I'm having issues when trying to debug a cross compiled binary on my WSL2 host and only end up with backtraces with addresses in ?? (), any hint's on what to verify and change are welcome!

file mybin shows:

ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=..., with debug_info, not stripped

The application is started in WSL2 via qemu-i386(based on output from ps) NOTE: I was wondering a bit about this because in my prev dev env using vm-ware and ubuntu 18.04 i was not seeing qemu-i386 used but did not think more about it based on WSL2 issues regarding 32bit application support referring to qemu and binfmt solving it.

I'm running gdb-multiarch (GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2)

Loading the executable and listing symbols with info functions <a_regex> works fine but when attaching and breaking i get bt's like this (NOTE output below is taken from VSCode with a few logging flags enabled, hence the -exec bt thing for example):

-exec bt
1: (777701) <-1183-interpreter-exec console "bt"
1: (777704) ->~"#0 0x000000000047a4ea in ?? ()\n"
1: (777707) ->~"#1 0x00007ffd2dcdb1c0 in ?? ()\n"
1: (777709) ->~"#2 0x0000000000467efc in ?? ()\n"
1: (777711) ->~"#3 0x0000000000000000 in ?? ()\n"

NOTE: When attaching i get the following warning:

warning: Selected architecture i386 is not compatible with reported target architecture i386:x86-64

setting architecture to i386:x86-64 is accepted by gdb but makes no difference

Setting a breakpoint gives the following error:

1: (40020) ->&"Cannot insert breakpoint 1.\n" 
1: (40020) ->&"Cannot access memory at address 0xbce346f\n" 
1: (40020) ->&"\n" 
1: (40023) ->^error,msg="Command aborted."

UPDATE: SOLVED Thought installing gcc-multilib solved it but it seems more likely the issue was because of a bug in Docker Desktop which has been fixed in v3.2.2. See description in my own answer below.

Upvotes: 0

Views: 573

Answers (1)

Kristofer
Kristofer

Reputation: 3269

The qemu-i386 thing was bugging me so I decided to try compiling a simple .c with -m32 flag to check if it also would trigger being run via qemu, got errors because I was missing gcc-multilib so I installed it.

Started the buildt binary and noticed that it did not run via qemu-i386. Started my original application again and this time it did also not start via qemu. Started gdb-multiarch, loaded the bin and attached to the process and now suddenly everything worked fine, got a nice proper backtrace!

Upvotes: 0

Related Questions