Debugger: The resulting target process has no mapping to the static image

[jroimartin]

Describe the bug

When debugging a binary with GDB the following message is shown:

Launch ls - .ProgramDB: The resulting target process has no mapping to the static image ls - .ProgramDB. Intervention is required before static and dynamic addresses can be translated. Check the target's module list.

The Modules window does not show an entry for the process. The Listing and Dynamic views are not synchronized. The process does not stop at the breakpoints set in the Listing window.

To Reproduce

Steps to reproduce the behavior:

1. Import executable (in my case, /bin/ls on Linux x86_64)
2. Open executable in Debugger
3. Click on Debugger > Debug ls > in GDB locally via GADP
4. Click on Connect
5. Check "Break on first instruction (user starti)"
6. Click on Launch
7. See error (screenshot 1). Also the Modules window does not contain an entry for the process maps (screenshot 2). Although, i proc mappings shows the expected output (screenshot 3).

Thereafter,

1. Set a breakpoint at the entrypoint of the program using the Listing window
2. Click on Resume
3. The process exits without stopping at the breakpoint

Expected behavior

The error dialog is not shown. An entry for the process is shown in the Modules window. The Listing and Dynamic views are synchronized. The process stops at the breakpoint.

Screenshots

Environment:

• OS: Debian GNU/Linux bullseye (stable) x86_64
• Java Version: OpenJDK 17.0.4
• Ghidra Version: 10.2-DEV (commit 5593df495c44cddcfe1c28a666d5d250f04b248d)
• GDB version: 10.1

Additional information

The same happens when using GDB locally IN-VM.

[d-millar]

Sorry to take so long to get back to you on this, but am having trouble re-creating the issue. I think we're going to need to get a copy of Debian GNU/Linux bullseye to hunt this down. We have seen this in the past on certain flavors of Debian. I thought we had fixed it, but obviously not. Error does not occur on Ubuntu or CentOS or the Amazon workspaces variant of Debian, which are what I had immediate access to. Could possibly be the version of gdb, but that seems like a long-shot. Am using the default installs of gdb for the aforementioned OSes. Will try to get your version of gdb as well.

[d-millar]

OK, installed bullseye with gdb 10.1 and was able to re-create the issue. Haven't figured out the reason why yet, but will definitely start a ticket. As a workaround, if you open the "Modules" node in the Object View (Session->Inferriors->[1]->Modules), the Modules View will re-populate with the missing information, and you should be able to debug with the Dynamic & Static Listings synchronized. This should also fix the breakpoint issue. If you set a breakpoint in the Static Listing w/o a valid mapping, the breakpoint is recorded as pending but not applied -the debugger basically doesn't know where to actually place it - and so will never fire.

Thanks for reporting this - weird how it affects some versions and not others. Am sure it will be interesting to find out why. :)

[d-millar]

OK, well, hmmm: the problem is "maintenance info sections ALLOBJ nosections" doesn't appear to list anything at all on Debian systems, other than the file being executed. Discussing what to do about this with the team....

[jroimartin]

@d-millar thanks a lot for the quick and detailed response.

I can confirm that the workaround you mentioned (opening the "Modules" node in the Object View) works fine.

Regarding the fix, why not just removing the nosections part from the gdb command and let the regexps in agent.gdb.manager.impl.GdbInferiorImpl.nameFromLine to extract the module names? I tried and the nosections part seems to be the problem in gdb 10.1.

I mean something like this:

diff --git a/Ghidra/Debug/Debugger-agent-gdb/src/main/java/agent/gdb/manager/impl/GdbInferiorImpl.java b/Ghidra/Debug/Debugger-agent-gdb/src/main/java/agent/gdb/manager/impl/GdbInferiorImpl.java
index 9897409a9..c9460a785 100644
--- a/Ghidra/Debug/Debugger-agent-gdb/src/main/java/agent/gdb/manager/impl/GdbInferiorImpl.java
+++ b/Ghidra/Debug/Debugger-agent-gdb/src/main/java/agent/gdb/manager/impl/GdbInferiorImpl.java
@@ -245,11 +245,11 @@ public class GdbInferiorImpl implements GdbInferior {
                // "nosections" is an unlikely section name. Goal is to exclude section lines.
                // TODO: Would be nice to save this switch, or better, choose at start based on version
                CompletableFuture<String> future =
-                       consoleCapture("maintenance info sections ALLOBJ nosections",
+                       consoleCapture("maintenance info sections ALLOBJ",
                                CompletesWithRunning.CANNOT);
                return future.thenCompose(output -> {
                        if (output.split("\n").length <= 1) {
-                               return consoleCapture("maintenance info sections -all-objects nosections")
+                               return consoleCapture("maintenance info sections -all-objects")
                                                .thenApply(out2 -> parseModuleNames(out2, true));
                        }
                        return CompletableFuture.completedFuture(parseModuleNames(output, false));

At the end of the day, the regexps can be used to ignore the section lines which would remove the need for filtering them on the gdb level.

I'm not familiar with the code base of the debugger, so please bear with me if what I suggest does not really make sense.

[d-millar]

@jroimartin Completely makes sense - was thinking the same. Just trying to figure out whether we're going to run into other hiccups with that solution. Slightly exasperated by the lack of MI2-equivalents for these two commands.

[nsadeveloper789]

Yeah, that solution makes sense, and it's what I'm considering. The idea of putting 'nosections' in there was to avoid having to pipe the section names at all, but that is perhaps a bit of premature optimization. We wind up needing the sections at launch in order to compute module boundaries and map them to programs, anyway. I'll take your proposal as the solution. Thanks for the help!

[bagnongithub]

I have a similar problem, but in macOS Ventura 13.3.1, brew llvm@14, gdb@13 and Ghidra 10.3, launching debugging in LLDB locally IN-VM. Any hint?:

Launch ExampleExec - .ProgramDB: The resulting target process has no mapping to the static image ExampleExec - .ProgramDB. Intervention is required before static and dynamic addresses can be translated. Check the target's module list.

Target is live, but we haven't got a register mapper, yet

Selected first mapping offer: <Offer: 'LLDB on macOS x86_64' lang=x86:LE:64:default cs=gcc confidence=100 target=Sessions[153ce].Processes[153ce]>

Using os=macosx10.15.0 arch=x86_64

*** State Changed: 1

Value 1139807 for Sessions[153ce].Processes[153ce].Threads[11645f]._tid does not conform to required type class java.lang.Long of schema LONG

*** Module Loaded: 2 *** Module Unloaded: 4

expected TargetExecutionState for _state, but got null

[ryanmkurtz]

@bagnongithub Can you please make a new ticket?