gdb+wine - What is the expected outcome?

[rdepaoli2026]

Given are:

• Wine 8.0 (Debian 12 Bookworm)
• Ghidra 12.0.4
• 64-bit test program termmines.exe

On start of Debugger with termmines.exe:

• Listing, Decompile, Bytes, Defined Strings => show information for termmines.exe

Configure and Launch ... settings for gdb+wine:

• Image = /home/vbox/Downloads/termmines.exe
• Path to wine binary = /usr/lib/wine/wine64
• gdb command = gdb
• Architecture = i386:x86-64
• Endian = auto
• Inferior TTY = enabled

What happens on Launch:

• New gdb trace wine64 is created not termmines
• Connections => one established, gdb13.1 at /127.0.0.1:portnumber
• Terminal wine-gdb.sh -> tries to read symbols from /usr/lib/wine/wine64
• Modules, Registers, Memory, Breakpoints all empty
• Nothing else happens until a gdb command is issued in the terminal

gdb command sequence:

• b main => sets breakpoint to wine64 main
• start / starti => starts the debugging, populating Dynamic, Modules, Registers, Memory with wine64 information
• cont runs wine64 & termmines.exe with termmines output on terminal /dev/pts

Request for clarification:

• Is this the intended behaviour? gdb does not seem to know what to do with the termmines.exe?
• If this is the expected/wanted behaviour, how would one set breakpoints in termmines.exe? And get Dynamic, Modules, Registers, Memory etc to display termmines.exe information?

Thanks.

[d-millar]

@rdepaoli2026 Will ping @nsadeveloper789 (who wrote this launcher) on Monday and get back to you with answers. Must admit, looking at it now, I too am confused by the intent, i.e. you do seem to be one step removed from what you would like to be observing.

[d-millar]

Spoke with @nsadeveloper789 and what you're seeing is as intended. There are other ways to do this, but wine is essentially loading the target and relevant libraries into its process space. If you check out the wine.py file, you can see the logic for mapping the target PE(s) into the memory map. If you filter the Memory View on your executable name, you should see the relevant regions AFTER they have been loaded. Knowing the target's base address with allow you to set up a static mapping between your target program (via the Static Listing) and target (via the Dynamic Listing), set breakpoints/watchpoints, and view the target registers when executing the target code. However, the Module List, I believe, will still reflect only the wine64 library set, as wine does not expose this list to gdb. (I realize I forgot to ask him why you have to execute "starti" - maybe in the docs? Will check tomorrow.)

[rdepaoli2026]

Good afternoon @d-millar.

Spoke with @nsadeveloper789 and what you're seeing is as intended. There are other ways to do this, but wine is essentially loading the target and relevant libraries into its process space. If you check out the wine.py file, you can see the logic for mapping the target PE(s) into the memory map. If you filter the Memory View on your executable name, you should see the relevant regions AFTER they have been loaded. Knowing the target's base address with allow you to set up a static mapping between your target program (via the Static Listing) and target (via the Dynamic Listing), set breakpoints/watchpoints, and view the target registers when executing the target code. However, the Module List, I believe, will still reflect only the wine64 library set, as wine does not expose this list to gdb. (I realize I forgot to ask him why you have to execute "starti" - maybe in the docs? Will check tomorrow.)

Thanks for asking.

You mention filtering, do you mean the Window | Debugger | Memview ?
That one is always empty, shows no information at all.

As an aside, I also have a strange effect that the termmines thread seems to be mostly called wine64, but sometimes it shows up as a termmines thread, and haven't been able yet to figure out, why that is.

What setup are you using to test this?
Is there a Ghidra known good (test bench) project & setup available for the gdb + wine feature?
Maybe there is something wrong with or missing from my installation.

[d-millar]

Hey, sorry - I think of it as the Memory view, but it's really called Regions. (The Memview window is rather specialized - used for viewing trace events related to memory allocation, which you are unlikely to have.) Regions should have memory region info obviously related to your target after the target has loaded.

Re threads, I think that is expected behavior, i.e. wine64 and the target are running in the same thread from gdb's standpoint. The thread gets renamed after the target has launched. I'm not sure I've ever seen it switch back, but again my experience using this launcher is a bit limited.

Simplest test setup for gdb + wine: launch notepad.exe. As a test, it has several advantages, including (a) being obvious and easy to make active because of the GUI, and (b) not requiring any potentially missing DLLs for its launch. On the latter point, for any target you're testing, I would try running "gdb /path/to/wine64(or32) target.exe" from the command line before attempting it in Ghidra, as there may be missing DLL requirements and the Ghidra console obscures the messages a bit.

So my test recs:

• Import notepad.exe (or just type C:\Windows\notepad.exe in the Image field of gdb + wine
• execute "starti" from the Terminal
• execute "cont" or hit the Continue button from the Tool Bar
• wait for notepad.exe to pop up
• hit the "Interrupt" button
• in the odd chance a thread or frame is not activated in the Model window, open the tree and double-click one

At this point, you should have /usr/lib/wine/x86_64-windows/notepad.exe entries in Regions. You could map these to the imported prorgam by right-clicking on any given region (although, in this case, probably not a good match as the executing target is internal to wine).

[nsadeveloper789]

I think we're all on the same page, but just to add my two cents: I did examine a few different ways to try to create an out-of-the-box wine connector. Somewhat because it's an actual useful use case, but more so to demonstrate that the connector framework was extensible enough to support it.

I don't remember all the different ways I tried, but for reference, I was testing with winmine.exe, i.e., Minesweeper from Ye Olde Windows XP Game Pack. One method I tried was to run gdbserver.exe winmine.exe from inside of wine and then connect a mingw-aware copy of gdb from the Linux side to it. IIRC, the feature set of mingw's gdbserver was too reduced to be useful. Either that, or I was just having trouble finding compatible binaries on either side of the connection, and didn't want to leave the user to complete that scavenger hunt.

The method we went with is to launch wine winmine.exe from within gdb. This took the serial protocol out of the equation and gave gdb full introspection into the execution environment, whether code from a PE or an ELF, so long as it was in userland. The drawback was that gdb on Linux didn't come with any PE knowledge, and so, while we could see all the code, we couldn't take advantage of the PE metadata, at least from the gdb CLI. We were, however, able to override ghidragdb's module reader with a wine-specific one. That said, it should be enough that Ghidra's normal module mapper can find the PE files and help you make sense of things. In theory, you'd set a breakpoint on main for the actual target image using Ghidra's GUI rather than GDB's CLI. Go to the address in the Static Listing and press K. If a blue dot appears, you're good. If it's grey, then Ghidra couldn't find the target image in the memory map.

Turns out some of this overview is documented in our help. From the gdb+wine connector dialog, press F1. Not sure it offers anything new at this point, but just in case.

You shouldn't need to do start or starti from the Terminal. The target is supposed to already be running once you click the Launch button, so just continue (or the Play button in the GUI.)

I can really only speculate about what's gone wrong from here, so if the above is not enough to resolve the issue, I'd probably need you to capture text from the Terminal wine+gdb window, i.e., GDB's output. As always, start reading from the top.

[rdepaoli2026]

Good afternoon @d-millar and @nsadeveloper789.

I retried with notepad.exe following @d-millar 's sequence, attempting the most basic debugging, namely stopping at a breakpoint at the notepad's main().

The steps and Ghidra responses were as follows:

1) Setup

• Debian 12 64-bit, with the Wine 8.0 that comes with it
• Completely new project
• Import of Wine-Notepad into the project
  /home/vbox/.wine/drive_c/windows/system32/notepad.exe
• Analysis of notepad with Codebrowser
  Adding Entry Point Label "NotepadMain" in the "Global" namespace to 0x140006ca0, aka int __fastcall main(int argc, char * * argv)

2) Start of Debugger

• Open notepad in debugger
• Launch gdb+wine with the settings
  • Image: /home/vbox/.wine/drive_c/windows/system32/notepad.exe
  • Path to wine binary: /usr/lib/wine/wine64
  • gdb command: gdb
  • Architecture: i386:x86-64
  • Endian: auto
  • Inferior TTY: enabled

On launch, the Ghidra panels show the following:

• Ghidra panel "Dynamic"
  wine64(0) (nowhere)
• Ghidra panel "Regions"
  empty
• Ghidra panel "Model"
  Available = shows threads
  Breakpoints = none
  Inferiors = [1] empty

3) Starting wine

• Ghidra panel "Terminal"
  (gdb) starti
  Starting program: /usr/lib/wine/wine64 /home/vbox/.wine/drive_c/windows/system32/notepad.exe
  Program stopped.
  0x00007ffff7fe4b20 in _start () from /lib64/ld-linux-x86-64.so.2
  (gdb)

This starts Wine the Ghidra panels are updated to show the following information:

• Ghidra panel "Dynamic"
  wine64(0) /lib64/ld-linux-x86-64.so.2
  pc 0x7ffff7fe4b20
• Ghidra panel "Model"
  • Threads
    • process 8844 "wine64" 0x00007ffff7fe4b20 in _start()
    • Name: wine64
    • Stack: _start()(from /lib64/ld-linux-x86-64.so.2
• Ghidra panel "Regions"
  populated with wine64 information

4) Starting notepad.exe

• Ghidra "Continue"
  notepad.exe starts and runs

The Ghidra panels show the following:

• Ghidra panel "Terminal"
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
  process 4545 is executing new program: /usr/lib/wine/wine64
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
  [Detaching after fork from child process 5096]
  [Detaching after fork from child process 5098]
  [Detaching after fork from child process 5155]
• Ghidra panel "Dynamic"
  wine64(0) /lib64/ld-linux-x86-64.so.2
  pc 0x7ffff7fe5787
• Ghidra panel "Model"
  • Threads
    • process 8844 "wine64" (running)
    • Name: wine64
• Ghidra panel "Regions"
  populated with wine64 information

5) Interrupting notepad.exe

• Ghidra "Interrupt"

The Ghidra panels show the following:

• Ghidra panel "Terminal"
  Program received signal SIGINT, Interrupt.
  0x00007ffff7eb829d in __GI___libc_read (fd=165, buf=0x31f460, nbytes=16) at ../sysdeps/unix/sysv/linux/read.c:26
  26 ../sysdeps/unix/sysv/linux/read.c: No such file or directory.
• Ghidra panel "Dynamic"
  /usr/lib/debug/.build-id/61/96744a316dbd57c0fd8968df1680aac482cec4.debug
  pc 7ffff7eb829d
• Ghidra panel "Model"
  • Threads
    • process 8844 "wine64" (running)
    • Name: wine64
  • Memory
    • populated with notepad information
      the information is displayed red, needs double clicking of Thread/process to update
• Ghidra panel "Regions"
  • Filter for "/usr/lib/x86_64-linux-gnu/wine/x86_64-windows/notepad.exe (0x140001000-0x140007000)"
  • Execute "Map Region to notepad.exe:.text"
• Ghidra "Listing notepad.exe"
  Clicking into "Listing" updates "Dynamic" to show the same location in /usr/lib/wine/wine64 /home/vbox/.wine/drive_c/windows/system32/notepad.exe
  Setting breakpoint in either "Dynamic" or "Listing" sets a "blue" active breakpoint

6) Ghidra step into target
Ghidra "StepOneInstruction"

The Ghidra panels show the following:

• Ghidra panel "Dynamic"
  /usr/lib/debug/.build-id/61/96744a316dbd57c0fd8968df1680aac482cec4.debug
  pc 7ffff7eb829d
• Ghidra panel "Model"
  • Threads
    • Thread 0x7ffff7dbd740 (LWP 8844) "notepad.exe" (running)
    • Name: notepad.exe

Findings/Conclusions

You shouldn't need to do start or starti from the Terminal. The target is supposed to already be running once you click the Launch button

1. The target is not launched automatically, without start/starti nothing happens.

If a blue dot appears, you're good. If it's grey, then Ghidra couldn't find the target image in the memory map.

2. Setting a breakpoint in the static "Listing" panel before executing the "Map Region" has no effect, it just creates a grey breakpoint that is ignored.

3. "Map Region" appears only to be possible AFTER notepad runs/executed past main(), so having a breakpoint on notepad's main() seems to be impossible?

4. The notepad thread name seems to only appear after the "single step" of point 6; only running notepad does not seem to affect the process/thread name

I would be interested to know, if you see the identical behaviour with your setup, and also a solution for setting the breakpoint to notepad's main (or before that, maybe at the point of "switch over" from wine to notepad.

Thanks.

[aaronjamt]

I see the same behavior you've described, and am also unable to set a breakpoint to the application entrypoint. Were you able to find a solution for this?

[rdepaoli2026]

Good evening aaronjamt.
Thanks for confirming that you see the same behaviour.
No, sadly I haven't been able to set a breakpoint at the application entry so far.

[d-millar]

Apologies - this somehow dropped off our radar. Revisiting it as we type.

[d-millar]

As @aaronjamt correctly surmises, the trick is getting gdb to break AFTER the target memory is loaded but before "main" is executed. I am testing on an executable with "entry" (but not main) and shooting for a break in "entry" - without success so far. The closest I have gotten is (1) connect, (2) "start", (3) "catch fork", and (4) "cont" twice - once for wine and once for the target. This catches the target's execution very early, but, sadly, not before "entry". More as I know more....

[d-millar]

Oops - switched names there. As @rdepaoli2026 surmised…. etc

[d-millar]

Thinking about this some more, I'm not sure the bang is worth the buck on this approach. I will gen-up a launcher for winedbg, which is , I think, really what you want. (Correct me if I'm wrong.) If you'd like to test this out before I figure out the launcher, try the following:

• cp local-gdb.sh local-winedbg.sh (Ghidra/Debug/Debugger-agent-gdb/data/debugger-launchers)
• modify line 53, replacing 'compute-usermode-gdb-args' with' "OPT_GDB_PATH" "--gdb"' (or hardcode the path to winedbg)
• change the 'title' to 'winedbg'
• in the Connections window, use the "Accept a single inbound TCP connection" button to start the server on, say, port 54321
• select and run 'winedbg' from the launch menu (with 'gdb command' == /usr/local/bin/winedbg or equiv)
• in the Terminal window, issue the following commands:
  • python import ghidragdb
  • ghidra trace connect localhost:54321
  • ghidra trace start
  • ghidra trace sync-enable
  • stepi (probably needed for the moment to get everything populated)

You should then be able to set a breakpoint at the target's entry/main and 'run' to it without a problem.

Obviously, yell if you have problems or if it turns out I'm lying. :)

I don't know an obvious way to pass gdb commands to winedbg, so a bit of a headache for now. You can, of course, put all of the commands listed above in your .gdbinit. I haven't tried this, however, and am not positive winedbg picks it up. Will get back to you when I've tested this.

[d-millar]

Actually, even simpler:

• run “winedbg --gdb --no-start target.exe”
• use the gdb remote launcher to connect to the reported port (typically 12345)