Is the debugger expected to somehow use the information from the static listing in the dynamic listing?

[shamefulCake1]

I have an app being debugged in Ghidra debugger, having an ".so" file open in the static listing, and the corresponding place in memory in the "Dynamic" listing.

However, the breakpoints in the static listing are all greyed-out, and when hovering over the parameters, I am getting a message "There is no frame for ... among the 1 frames unwound".

When hovering over the variables in the Dynamic listing, I am, instead, getting: "Instruction is not in a function, using innermost frame".

Something seems to be suggesting that the Dynamic listing should be able to get function info from the static listing, and the static listing should be able to get frame data from the Dynamic listing. Am I correct? Any suggestions on how to synchronize them?

[d-millar]

So, let's start with the Dynamic Listing. The mapping relies on, well, having a mapping, which is supplied by the module list. Question (1): do you have a module list? If the answer is yes, then, next question (2): is the name of the imported .so and exact match to the entry in the module list. (We do a little pattern matching, but really not much.) There are several reasons why they might not match, e.g. the source file has one name, was compiled to another, was renamed on the filesystem, was rename on import, etc. You can force the match several different ways in the Module View.

If the Module List is empty, there's a different problem. Some platforms don't support the region / module logic. Pretty straightforward to test this out. Connect with lldb (no ghidra), switch to the python scripting shell ("si") and try something like "lldb.SBDebugger.FindDebuggerWithID(1)..GetTargetAtIndex(0).GetNumModules()" (or GetNumRegions()). It may be failing further in the logic, but that's a good starting place. All of the logic lives in Ghidra/Debug/Debugger-agent-lldb//src/main/py/src/ghidralldb/util.py.

Let me know how far you get, and I can suggest future experiments.

Breakpoints being greyed out in the static listing also is indicative of the lack of a mapping, i.e. the breakpoints are set in the address space of the target, which may or may not corrrespond to the address space of the imported executable. Without a mapping, the debugger has not idea where to put these.

I must admit I don't recall seeing either the "no frame" message or the "instruction is not in function" but, again, sounds directly related to a missing mapping. Yes re dynamic listing getting the function from the static, and static getting the frame data from the target, but not if we don't have a mapping.

[shamefulCake1]

Okay, good point.

Indeed, I had the file named (in Ghidra) myfile.so_original, because I also had the same file binary-patched, and I will need to compare them eventually.

As soon as I renamed the file back to myfile.so, a lot of behaviour has changed, so I suspect this might be the issue. However, if I may notice, having files named differently in Ghidra seems quite a normal part of reverse-engineering, and I am not sure that "having Ghidra names identical to original file names" is documented as a requirement.

[shamefulCake1]

I confirm, renaming file to the filesystem name resolves the question.

[d-millar]

Just to follow up, the identical names things is not a requirement, but, if they don't match, you do have to do some work. In your case, with the myfile.so highlighted in the Static Listing, go to the Modules View, right click on the actualname.so, and chose "Map Module to myfile.so". The other options nearby allow to map non-selected programs or map sections to programs. This is documented (probably better than I can do here) in the "Debugger: Modules and Sections" entry.

[shamefulCake1]

I tried this and it didn't work for me.

That is, a module mapping is added to the table, but Dynamic Listing is not updated and generally Ghidra behaves as if no mapping exists.

I also tried adding a static mapping, and it also failed.

[d-millar]

Huh, interesting. I will ask the stupid question - nothing in the Dynamic Listing even with Force Full map on and a PC definitely in the address space that was mapped?