Segger Jlink GDB Server

[yattr]

Ghidra version 11.0.1. Jlink GDB Server version V7.94k

I start the server...

I select GDB via ssh:user@localhost"? which result in this (connected but indicating 0 connections

The I repeat the above and get this with 2 connected.

But, nothing ever goes beyond the waiting to connect at 0%?????

[d-millar]

@yattr Hey and sorry you're getting stuck! I think you're probably getting confused by the convenience methods on main Toolbar, which are not, I think, exactly what you want for your scenario. By way of example, let's say you have xclock loaded in the static listing. Hitting "Debug xclock in GDB via ssh:user@localhost is going to attempt to run /usr/bin/gdb on the local box, assuming there's an account name "user" which you can authenticate to, and then launch xclock in that gdb session. All of the specfics here are determined by the last execution.

Instead of that, go to the Objects window and hit the "Create a new connection..." button. In the dialog that comes up, use the pull-down to select "gdb", make sure the path to a local version of gdb is correct, and hit connect. This should bring up a new gdb session without a target and a new Interpreter window. In the Interpreter window, enter "target remote 127.0.01:2331" as you might normally for a gdb/gdbserver configuration. Ghidra should then connect to the JLink GDB Server.

For completeness, I should mention how "gdb via SSH" is intended to work, although the use case doesn't match yours. Had you opened the Objects window and selected "gdb via SSH", the resulting dialog would allow you to specify the path to gdb (on a potentially remote machine), the username and credentials for that machine, its IP and port, and some platform-dependent configuration options. Those parameters would be used to launch gdb over an ssh tunnel. Any subsequent launches made either from that dialog box or the main toolbar would use the same parameters.

A bit confusing I'll concede - let us know if this doesn't get you to where you want.

[yattr]

All of this is a bit over my head but I am pushing forward trying to get something to work.

1 - I am using an Apple M1 based Mac. There is no GDB for this architecture at this time from what I can tell.

2 - I pursued both the Frida and LLDB approaches I found on the web for M1x based Macs but neither completed without issues.

3 - I will attempt with LLDB yet again and reply with the issues. I will be using the instructions from Ghidra GIT...

Lastly, in the Ghidra Debugger the connection options are in the Debugger Targets window.

Thank you for the detailed and timely response...

[d-millar]

@yattr Understood - and, yes, setting up LLDB for use with Ghidra is considerably more complicated. The instructions are in Ghidra/Debug/Debugger-swig-lldb/InstructionsForBuildingLLDBInterface.txt. Before you do that, I would just make sure LLDB can attach to the JLink. The LLDB equivalent to GDB's "target remote host:port" is "gdb-remote host:port". If that works, let me know, and I can walk you through the setup instructions if they aren't clear.

Apologies re "Objects" vs "Debugger Targets" - wasn't thinking.

[yattr]

I found this on Segger's web which is what I have been using but will try again with your settings

LLDB support

J-Link can be used with LLDB. Originally, GNU toolchains provided GCC as a compiler and GDB as a debugger. Since Clang’s introduction as a compiler, LLDB was introduced (which was essentially a GDB successor). In terms of protocol, it is backward compatible to GDB whilst the API for the IDE is slightly different.

The J-Link Software and Documentation Package comes with the J-Link GDBServer. This permits the use of J-Link in LLDB-based setups.

[yattr]

Connecting lldb failed

(lldb) gdb-remote host:2331
error: Failed to connect port

(lldb) version
lldb-1500.0.200.58
Apple Swift version 5.9.2 (swiftlang-5.9.2.2.56 clang-1500.1.0.2.5)

[d-millar]

"host" should be either "localhost" or "127.0.0.1" or the IP of whatever machine you're running JLink on (if remote)

[yattr]

Tried it both ways with the following results

(lldb) gdb-remote localhost:2331
Process 57005 stopped

• thread Ghidra does not render correctly with GDK_SCALE set (HiDPI display) #1, stop reason = signal SIGTRAP
  frame #0: 0xffffffffffffffff
  Target 0: (No executable module.) stopped.

(lldb) gdb-remote 127.0.0.1:2331
Process 57005 stopped

• thread Ghidra does not render correctly with GDK_SCALE set (HiDPI display) #1, stop reason = signal SIGTRAP
  frame #0: 0xffffffffffffffff
  Target 0: (No executable module.) stopped.

From the Jlink server log

Connected to target
Waiting for GDB connection...Connected to 127.0.0.1
WARNING: Unknown packet received: "qVAttachOrWaitSupported"
WARNING: Unknown packet received: "qHostInfo"
GDB client (conn. 25) requested target.xml from GDB Server
WARNING: Unknown packet received: "qStructuredDataPlugins"
WARNING: Unknown packet received: "qShlibInfoAddr"
WARNING: Unknown packet received: "jThreadsInfo"
WARNING: Unknown packet received: "jThreadExtendedInfo:"

[d-millar]

Both of those look OK to me - not surprised by the warnings, essentially the JLink device is only supporting a subset of the Remote Serial Protocol commands.

[yattr]

OK!

Went on to the instructions. Bold are changes or updates

(2a) To install LLVM/lldb version 16:
- git clone https://github.com/llvm/llvm-project.git
- cd llvm-project
- git checkout release/16.x 17.x is the latest now

The above completed as it should.

(2b) To generate the JNI for your version
- cd Ghidra/Debug/Debugger-swig-lldb
- gradle generateSwiggradle
-
resulted in this

MacBook-Pro Debugger-swig-lldb % gradle generateSwiggradle

Configure project :Debugger-swig-lldb
OS: Mac OS X
Arch: aarch64
Using platform: mac_arm_64

Configure project :Decompiler
OS: Mac OS X
Arch: aarch64
Using platform: mac_arm_64

Configure project :PDB
OS: Mac OS X
Arch: aarch64
Using platform: mac_arm_64

FAILURE: Build failed with an exception.

• What went wrong:
  Task 'generateSwiggradle' not found in project ':Debugger-swig-lldb'.

[d-millar]

Somehow you have an extra "gradle" in there - should be "gradle generateSwig"

[yattr]

MacBook-Pro Debugger-swig-lldb % echo $LLVM_HOME

/path/to/llvm

MacBook-Pro Debugger-swig-lldb % gradle generateSwig

Configure project :Debugger-swig-lldb
OS: Mac OS X
Arch: aarch64
Using platform: mac_arm_64

Configure project :Decompiler
OS: Mac OS X
Arch: aarch64
Using platform: mac_arm_64

Configure project :PDB
OS: Mac OS X
Arch: aarch64
Using platform: mac_arm_64

Task :Debugger-swig-lldb:generateSwig FAILED
Debugger-swig-lldb: using LLVM_HOME=/path/to/llvm

FAILURE: Build failed with an exception.

• What went wrong:
  Execution failed for task ':Debugger-swig-lldb:generateSwig'.

A problem occurred starting process 'command 'swig''

• Try:

Run with --stacktrace option to get the stack trace.
Run with --info or --debug option to get more log output.
Run with --scan to get full insights.
Get more help at https://help.gradle.org.

BUILD FAILED in 2s
1 actionable task: 1 executed

[d-millar]

Ah, yes, you will need to install swig.

[yattr]

" yes, setting up LLDB for use with Ghidra is considerably more complicated"

Living up to the stated expectations...about to continue......

[d-millar]

I hear ya - if it's any consolation, we're moving to a Python-based set of debuggers (hopefully, 11.1) which should remove some of these difficulties.

[yattr]

Good to know - thanks...just might wait!

I have been using Ghidra for an nRF51x based device and found that I need to interact with the running code (stepping through it) to get all the branching to worked out in Ghidra.

Segger has a Ozone which is nice but it operates independent of Ghidra. As I fumble my way through understand all the great features of Ghidra, I decided to go down the path of its debugger. I am learning a lot but not making any progress...

I thought having Jlink and Ghidra coupled would help get the branches sorted out.

I have yet to figure out how to get a branch, bx, from a register, r3, to flow to the branch address contained in r3...

[d-millar]

Will have to concede, am kind of a x64 guy, so may not be helpful on that front. That said, the big issues using Ghidra's debugger center on getting the mapping from the static images to the dynamic images. For this to work, you have to have or be able to fake the commands that report the target's memory regions and the loaded modules. For embedded devices, that usually means telling Regions to map in the entire address space and telling Modules to map your current static image to the existing dynamic space. The Debugger Help is one place to start, but the Debugger Course include with the distro is probably your best bet.

[yattr]

I have been trying a few things...

The only path to an Interpreter is via Target LLDB then Object Connector Context to server.

With the above lldb appears. Entering gdb-remote 2331 results in

(lldb)gdb-remote 2331
error: Process 57005 is currently being debugged, kill the process before connecting.

and

(lldb)gdb-remote 127.0.0.1:2331
error: Process 57005 is currently being debugged, kill the process before connecting.

I can not identify a process with the number. Any ideas?

[d-millar]

Sorry - that was my mistake! In gdb, the Interpreter starts before the session, allowing us to issue the "target remote" command. I forgot that that does NOT work for lldb, i.e. you need a Session to get the Interpreter. You've done the right thing there, and the "gdb-remote" command is baked in. The error above is basically saying, "You've already connected to this process and are trying to do it again. If you want ot reconnect, you have to start over." You do NOT need to issue the "gdb-remote" command.

[yattr]

Ok. Thanks, as always, for the quick and detailed response.

I am connected to the GBD server but still no communications between lldb and jlink

[d-millar]

Are you testing from Ghidra or from lldb proper? And what do you get if you type "process status" in the command line?

[yattr]

lldb within ghidra...

(lldb)process status
Process 57005 stopped

• thread Ghidra does not render correctly with GDK_SCALE set (HiDPI display) #1, stop reason = signal SIGTRAP
  frame #0: 0xffffffffffffffff

if I tyoe "contimue" then "process status"

(lldb)continue
Process 57005 resuming
(lldb)process status

nothing from process status

Note no executable module....

[d-millar]

Oh, ok - well, that’s reasonably encouraging!

Once the target is running, it’s unlikely any commands will receive a response. The next things I would try are:

(1) hitting the pause button on the Interpreter and/or in Objects after you’ve said “continue” to see whether you can stop the target again. (Note: I would close the connection from Targets between experiments.)
(2) seeing what you can get a list of from the Interpreter, i.e. do “thread list”, “register read”, etc. work
(3) make note of the GUI displays corresponding to those commands that are and are not populated
(4) seeing whether you can step the target from the initial break
(5) seeing whether you can set a breakpoint, preferably a few lines forward from the break

[yattr]

(1) hitting the pause button on the Interpreter and/or in Objects after you’ve said “continue” to see whether you can stop the target again.

Starting and stopping from Objects appears to work.. The JLink GDB server app reflects the starting and stopping in its log as well as the Device status with "Executing" or "Halted".

When stopped, "process status" and "continue" function as they should. If paused from the Interpreter, start is accomplished via Objects.

(2) seeing what you can get a list of from the Interpreter, i.e. do “thread list”, “register read”, etc. work

(lldb)thread list
Process 57005 stopped

• thread Ghidra does not render correctly with GDK_SCALE set (HiDPI display) #1: tid = 0xdead, stop reason = signal SIGTRAP

Register Read doesn't appear to work. There is nothing displayed in the Register tab

(lldb)register read
error: Command requires a process, which is currently stopped.
(lldb)continue
Process 57005 resuming
(lldb)register read
Interrupt sent
error: Command requires a process, which is currently stopped.
(lldb)continue
Process 57005 resuming
(lldb)register read
Interrupt sent
error: Command requires a process, which is currently stopped.

Thge only populated windows with active menus are Listing, Interpreter, Debugger Targets and Objects. All other windows are empty with menus grayed out

[yattr]

For 1 above...

[d-millar]

OK, so a couple of things to explain and a couple of things to try....

Probably, more than you want to know but...in the Debugger, the only Windows that communicate directly with the target are Targets, Objects, and the Interpreter. Everything else is mediated by a thing we call the trace, which records everything you do and the state of your targets every time you are stopped. This allows us to do some interesting things, but also means, if the trace setup fails, all of the other windows are blank - which obviously is where we're at right now.

There are a couple of bits of your situation that are unsurprising and a couple more that strike me as odd. The fact that the only thread has tid 0xdead is definitely among the latter - not an artifact we're adding as far as I know. I'd be interested in whether you get the same values from lldb w/o ghidra. If you're up for an experiment, start lldb and then enter:

(1) gdb-remote 127.0.0.1:2331 (or maybe localhost:2332 or 0.0.0.0:2331)
(2) file mem.bin (possibly with the file path in front)
(3) process status
(4) thread list

Am wondering if the tid is still 0xdead.

The register command, I think, failed because I mis-typed it - should be "registers read". FYI, in the Interpreter or lldb command line, "help" will get you the list of commands, "help threads" those pertaining to threads, etc. Two other commands I'd be interested in "target module list" and "target module dump". If either of those fail (or have output different than what we expect), the trace startup will fail.

Another thing to try in Ghidra: while stopped, from the Regions window, use the top right pull-down to "Force Full View". Also, if that works, from the Modules window use the double-headed arrow to "Map the current trace to the current program". This may not work if the Regions thing didn't get you a trace, but....

[yattr]

I can not locate a mem.bin on my system

I'll try the balance after lunch

[d-millar]

It's the file you have loaded in Ghidra (I thought) - oh, misread - "Linear all Jmem.bin" or something like that? (My eyes not so good)

[d-millar]

In any case, looks like it's 0xdead in pure lldb, so that answers that - that's apparently chosen by the JLink.

[yattr]

[yattr]

The command is "register" -- no "s". Results the same as before

The Regions pull down items are grayed out...

The memory dump file (.bin) is just that - gathered via JLink command for the various address regions. Then merged into one file and used to start a project in ghidra. The Memory Map Display within ghidra was then used to move the bin data to the appropriate address range...

[yattr]

I am still launching ghidraDedug. There are still a few errors indicated...

Last login: Wed Mar 6 13:07:31 on ttys001
/Users/edrocha/ghidra_11.0.1_PUBLIC/support/ghidraDebug ; exit;
edrocha@MacBook-Pro ~ % /Users/edrocha/ghidra_11.0.1_PUBLIC/support/ghidraDebug ; exit;
Listening for transport dt_socket at address: 18001
java version "20.0.1" 2023-04-18
Java(TM) SE Runtime Environment (build 20.0.1+9-29)
Java HotSpot(TM) 64-Bit Server VM (build 20.0.1+9-29, mixed mode)
INFO Using log config file: file:/Users/edrocha/ghidra_11.0.1_PUBLIC/support/debug.log4j.xml (LoggingInitialization.java:50)
INFO Using log file: /Users/edrocha/.ghidra/.ghidra_11.0.1_PUBLIC/application.log (LoggingInitialization.java:51)
INFO Loading user preferences: /Users/edrocha/.ghidra/.ghidra_11.0.1_PUBLIC/preferences (Preferences.java:122)
INFO Loading previous preferences: /Users/edrocha/.ghidra/.ghidra_11.0_PUBLIC/preferences (Preferences.java:175)
INFO Searching for classes... (ClassSearcher.java:259)
INFO Class search complete (668 ms) (ClassSearcher.java:278)
INFO Initializing SSL Context (SSLContextInitializer.java:76)
INFO Initializing Random Number Generator... (SecureRandomFactory.java:37)
INFO Random Number Generator initialization complete: NativePRNGNonBlocking (SecureRandomFactory.java:41)
INFO Trust manager disabled, cacerts have not been set (ApplicationTrustManagerFactory.java:95)
INFO User edrocha started Ghidra. (GhidraRun.java:77)
DEBUG Recovery snapshot timer set to 5 minute(s) (RecoverySnapshotMgrPlugin.java:170)
INFO Opening project: /Users/edrocha/Documents/SCP3 All from J-Mem/Linear/SCP3 Linear all Jmem (DefaultProject.java:114)
DEBUG transitions state to eStateStopped (LldbManagerImpl.java:585)

Frame is not valid

INFO *** State Changed: 1 (DebugClientImpl.java:331)
DEBUG transitions state to eStateStopped (LldbManagerImpl.java:585)

ERROR Listener ghidra.app.plugin.core.debug.gui.objects.DebuggerObjectsProvider$MyObjectListener@52585b48 caused exception processing attributesChanged(r) (DebuggerCallbackReorderer.java:116)

java.util.NoSuchElementException: No mapper for target: <LldbModelTargetProcessImpl: path=Sessions[dead].Processes[dead] model=agent.lldb.model.impl.LldbModelImpl@4d767e38 schema=Process>
at ghidra.app.plugin.core.debug.service.model.DebuggerModelServicePlugin.recordTargetBestOffer(DebuggerModelServicePlugin.java:338) ~[Debugger.jar:?]
at ghidra.app.plugin.core.debug.service.model.DebuggerModelServiceProxyPlugin.recordTargetBestOffer(DebuggerModelServiceProxyPlugin.java:591) ~[Debugger.jar:?]
at ghidra.app.plugin.core.debug.gui.objects.DebuggerObjectsProvider.startRecording(DebuggerObjectsProvider.java:1512) ~[Debugger.jar:?]
at ghidra.app.plugin.core.debug.gui.objects.DebuggerObjectsProvider$MyObjectListener.attributesChanged(DebuggerObjectsProvider.java:1844) ~[Debugger.jar:?]
at ghidra.dbg.util.DebuggerCallbackReorderer$ObjectRecord.lambda$completed$1(DebuggerCallbackReorderer.java:71) ~[Framework-Debugging.jar:?]
at ghidra.dbg.util.DebuggerCallbackReorderer.defensive(DebuggerCallbackReorderer.java:113) ~[Framework-Debugging.jar:?]
at ghidra.dbg.util.DebuggerCallbackReorderer$ObjectRecord.completed(DebuggerCallbackReorderer.java:71) ~[Framework-Debugging.jar:?]
at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:646) ~[?:?]
at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510) ~[?:?]
at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2179) ~[?:?]
at ghidra.dbg.util.DebuggerCallbackReorderer$ObjectRecord.added(DebuggerCallbackReorderer.java:84) ~[Framework-Debugging.jar:?]
at ghidra.dbg.util.DebuggerCallbackReorderer.elementsChanged(DebuggerCallbackReorderer.java:250) ~[Framework-Debugging.jar:?]
at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:578) ~[?:?]
at ghidra.util.datastruct.PrivatelyQueuedListener$ListenerHandler.lambda$invoke$0(PrivatelyQueuedListener.java:58) ~[ProposedUtils.jar:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) ~[?:?]
at java.lang.Thread.run(Thread.java:1623) [?:?]

ERROR Listener ghidra.app.plugin.core.debug.gui.objects.DebuggerObjectsProvider$MyObjectListener@52585b48 caused exception processing attributesChanged (DebuggerCallbackReorderer.java:116)

java.util.NoSuchElementException: No mapper for target: <LldbModelTargetProcessImpl: path=Sessions[dead].Processes[dead] model=agent.lldb.model.impl.LldbModelImpl@4d767e38 schema=Process>
at ghidra.app.plugin.core.debug.service.model.DebuggerModelServicePlugin.recordTargetBestOffer(DebuggerModelServicePlugin.java:338) ~[Debugger.jar:?]
at ghidra.app.plugin.core.debug.service.model.DebuggerModelServiceProxyPlugin.recordTargetBestOffer(DebuggerModelServiceProxyPlugin.java:591) ~[Debugger.jar:?]
at ghidra.app.plugin.core.debug.gui.objects.DebuggerObjectsProvider.startRecording(DebuggerObjectsProvider.java:1512) ~[Debugger.jar:?]
at ghidra.app.plugin.core.debug.gui.objects.DebuggerObjectsProvider$MyObjectListener.attributesChanged(DebuggerObjectsProvider.java:1844) ~[Debugger.jar:?]
at ghidra.dbg.util.DebuggerCallbackReorderer.lambda$attributesChanged$3(DebuggerCallbackReorderer.java:203) ~[Framework-Debugging.jar:?]
at ghidra.dbg.util.DebuggerCallbackReorderer.defensive(DebuggerCallbackReorderer.java:113) ~[Framework-Debugging.jar:?]
at ghidra.dbg.util.DebuggerCallbackReorderer.attributesChanged(DebuggerCallbackReorderer.java:203) ~[Framework-Debugging.jar:?]
at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:578) ~[?:?]
at ghidra.util.datastruct.PrivatelyQueuedListener$ListenerHandler.lambda$invoke$0(PrivatelyQueuedListener.java:58) ~[ProposedUtils.jar:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) ~[?:?]
at java.lang.Thread.run(Thread.java:1623) [?:?]
consoleOutput: Process 57005 stopped

• thread Ghidra does not render correctly with GDK_SCALE set (HiDPI display) #1, stop reason = signal SIGTRAP
  frame #0: 0xffffffffffffffff

consoleOutput: error: 'registers' is not a valid command.

consoleOutput: Commands to access registers for the current thread and stack frame.

Syntax: register [read|write|info] ...

The following subcommands are supported:

  info  -- View information about a register.
  read  -- Dump the contents of one or more register values from the
           current frame.  If no register is specified, dumps them all.
  write -- Modify a single register value.

For more help on any particular subcommand, type 'help '.

consoleOutput: error: Command requires a process, which is currently stopped.

INFO *** State Changed: 1 (DebugClientImpl.java:331)
DEBUG transitions state to eStateRunning (LldbManagerImpl.java:585)

ERROR Listener ghidra.app.plugin.core.debug.gui.objects.DebuggerObjectsProvider$MyObjectListener@52585b48 caused exception processing attributesChanged (DebuggerCallbackReorderer.java:116)

java.util.NoSuchElementException: No mapper for target: <LldbModelTargetProcessImpl: path=Sessions[dead].Processes[dead] model=agent.lldb.model.impl.LldbModelImpl@4d767e38 schema=Process>
at ghidra.app.plugin.core.debug.service.model.DebuggerModelServicePlugin.recordTargetBestOffer(DebuggerModelServicePlugin.java:338) ~[Debugger.jar:?]
at ghidra.app.plugin.core.debug.service.model.DebuggerModelServiceProxyPlugin.recordTargetBestOffer(DebuggerModelServiceProxyPlugin.java:591) ~[Debugger.jar:?]
at ghidra.app.plugin.core.debug.gui.objects.DebuggerObjectsProvider.startRecording(DebuggerObjectsProvider.java:1512) ~[Debugger.jar:?]
at ghidra.app.plugin.core.debug.gui.objects.DebuggerObjectsProvider$MyObjectListener.attributesChanged(DebuggerObjectsProvider.java:1844) ~[Debugger.jar:?]
at ghidra.dbg.util.DebuggerCallbackReorderer.lambda$attributesChanged$3(DebuggerCallbackReorderer.java:203) ~[Framework-Debugging.jar:?]
at ghidra.dbg.util.DebuggerCallbackReorderer.defensive(DebuggerCallbackReorderer.java:113) ~[Framework-Debugging.jar:?]
at ghidra.dbg.util.DebuggerCallbackReorderer.attributesChanged(DebuggerCallbackReorderer.java:203) ~[Framework-Debugging.jar:?]
at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:578) ~[?:?]
at ghidra.util.datastruct.PrivatelyQueuedListener$ListenerHandler.lambda$invoke$0(PrivatelyQueuedListener.java:58) ~[ProposedUtils.jar:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) ~[?:?]
at java.lang.Thread.run(Thread.java:1623) [?:?]

ERROR Listener ghidra.app.plugin.core.debug.gui.objects.DebuggerObjectsProvider$MyObjectListener@52585b48 caused exception processing attributesChanged (DebuggerCallbackReorderer.java:116)

java.util.NoSuchElementException: No mapper for target: <LldbModelTargetProcessImpl: path=Sessions[dead].Processes[dead] model=agent.lldb.model.impl.LldbModelImpl@4d767e38 schema=Process>
at ghidra.app.plugin.core.debug.service.model.DebuggerModelServicePlugin.recordTargetBestOffer(DebuggerModelServicePlugin.java:338) ~[Debugger.jar:?]
at ghidra.app.plugin.core.debug.service.model.DebuggerModelServiceProxyPlugin.recordTargetBestOffer(DebuggerModelServiceProxyPlugin.java:591) ~[Debugger.jar:?]
at ghidra.app.plugin.core.debug.gui.objects.DebuggerObjectsProvider.startRecording(DebuggerObjectsProvider.java:1512) ~[Debugger.jar:?]
at ghidra.app.plugin.core.debug.gui.objects.DebuggerObjectsProvider$MyObjectListener.attributesChanged(DebuggerObjectsProvider.java:1844) ~[Debugger.jar:?]
at ghidra.dbg.util.DebuggerCallbackReorderer.lambda$attributesChanged$3(DebuggerCallbackReorderer.java:203) ~[Framework-Debugging.jar:?]
at ghidra.dbg.util.DebuggerCallbackReorderer.defensive(DebuggerCallbackReorderer.java:113) ~[Framework-Debugging.jar:?]
at ghidra.dbg.util.DebuggerCallbackReorderer.attributesChanged(DebuggerCallbackReorderer.java:203) ~[Framework-Debugging.jar:?]
at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:578) ~[?:?]
at ghidra.util.datastruct.PrivatelyQueuedListener$ListenerHandler.lambda$invoke$0(PrivatelyQueuedListener.java:58) ~[ProposedUtils.jar:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) ~[?:?]
at java.lang.Thread.run(Thread.java:1623) [?:?]

ERROR Listener ghidra.app.plugin.core.debug.gui.objects.DebuggerObjectsProvider$MyObjectListener@52585b48 caused exception processing attributesChanged (DebuggerCallbackReorderer.java:116)

java.util.NoSuchElementException: No mapper for target: <LldbModelTargetProcessImpl: path=Sessions[dead].Processes[dead] model=agent.lldb.model.impl.LldbModelImpl@4d767e38 schema=Process>
at ghidra.app.plugin.core.debug.service.model.DebuggerModelServicePlugin.recordTargetBestOffer(DebuggerModelServicePlugin.java:338) ~[Debugger.jar:?]
at ghidra.app.plugin.core.debug.service.model.DebuggerModelServiceProxyPlugin.recordTargetBestOffer(DebuggerModelServiceProxyPlugin.java:591) ~[Debugger.jar:?]
at ghidra.app.plugin.core.debug.gui.objects.DebuggerObjectsProvider.startRecording(DebuggerObjectsProvider.java:1512) ~[Debugger.jar:?]
at ghidra.app.plugin.core.debug.gui.objects.DebuggerObjectsProvider$MyObjectListener.attributesChanged(DebuggerObjectsProvider.java:1844) ~[Debugger.jar:?]
at ghidra.dbg.util.DebuggerCallbackReorderer.lambda$attributesChanged$3(DebuggerCallbackReorderer.java:203) ~[Framework-Debugging.jar:?]
at ghidra.dbg.util.DebuggerCallbackReorderer.defensive(DebuggerCallbackReorderer.java:113) ~[Framework-Debugging.jar:?]
at ghidra.dbg.util.DebuggerCallbackReorderer.attributesChanged(DebuggerCallbackReorderer.java:203) ~[Framework-Debugging.jar:?]
at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:578) ~[?:?]
at ghidra.util.datastruct.PrivatelyQueuedListener$ListenerHandler.lambda$invoke$0(PrivatelyQueuedListener.java:58) ~[ProposedUtils.jar:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) ~[?:?]
at java.lang.Thread.run(Thread.java:1623) [?:?]
INFO Interrupting (LldbManagerImpl.java:1434)
INFO *** State Changed: 1 (DebugClientImpl.java:331)
DEBUG transitions state to eStateStopped (LldbManagerImpl.java:585)
Frame is not valid
Frame is not valid
Frame is not valid
Frame is not valid

ERROR Listener ghidra.app.plugin.core.debug.gui.objects.DebuggerObjectsProvider$MyObjectListener@52585b48 caused exception processing attributesChanged (DebuggerCallbackReorderer.java:116)

java.util.NoSuchElementException: No mapper for target: <LldbModelTargetProcessImpl: path=Sessions[dead].Processes[dead] model=agent.lldb.model.impl.LldbModelImpl@4d767e38 schema=Process>
at ghidra.app.plugin.core.debug.service.model.DebuggerModelServicePlugin.recordTargetBestOffer(DebuggerModelServicePlugin.java:338) ~[Debugger.jar:?]
at ghidra.app.plugin.core.debug.service.model.DebuggerModelServiceProxyPlugin.recordTargetBestOffer(DebuggerModelServiceProxyPlugin.java:591) ~[Debugger.jar:?]
at ghidra.app.plugin.core.debug.gui.objects.DebuggerObjectsProvider.startRecording(DebuggerObjectsProvider.java:1512) ~[Debugger.jar:?]
at ghidra.app.plugin.core.debug.gui.objects.DebuggerObjectsProvider$MyObjectListener.attributesChanged(DebuggerObjectsProvider.java:1844) ~[Debugger.jar:?]
at ghidra.dbg.util.DebuggerCallbackReorderer.lambda$attributesChanged$3(DebuggerCallbackReorderer.java:203) ~[Framework-Debugging.jar:?]
at ghidra.dbg.util.DebuggerCallbackReorderer.defensive(DebuggerCallbackReorderer.java:113) ~[Framework-Debugging.jar:?]
at ghidra.dbg.util.DebuggerCallbackReorderer.attributesChanged(DebuggerCallbackReorderer.java:203) ~[Framework-Debugging.jar:?]
at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:578) ~[?:?]
at ghidra.util.datastruct.PrivatelyQueuedListener$ListenerHandler.lambda$invoke$0(PrivatelyQueuedListener.java:58) ~[ProposedUtils.jar:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) ~[?:?]
at java.lang.Thread.run(Thread.java:1623) [?:?]

ERROR Listener ghidra.app.plugin.core.debug.gui.objects.DebuggerObjectsProvider$MyObjectListener@52585b48 caused exception processing attributesChanged (DebuggerCallbackReorderer.java:116)

java.util.NoSuchElementException: No mapper for target: <LldbModelTargetProcessImpl: path=Sessions[dead].Processes[dead] model=agent.lldb.model.impl.LldbModelImpl@4d767e38 schema=Process>
at ghidra.app.plugin.core.debug.service.model.DebuggerModelServicePlugin.recordTargetBestOffer(DebuggerModelServicePlugin.java:338) ~[Debugger.jar:?]
at ghidra.app.plugin.core.debug.service.model.DebuggerModelServiceProxyPlugin.recordTargetBestOffer(DebuggerModelServiceProxyPlugin.java:591) ~[Debugger.jar:?]
at ghidra.app.plugin.core.debug.gui.objects.DebuggerObjectsProvider.startRecording(DebuggerObjectsProvider.java:1512) ~[Debugger.jar:?]
at ghidra.app.plugin.core.debug.gui.objects.DebuggerObjectsProvider$MyObjectListener.attributesChanged(DebuggerObjectsProvider.java:1844) ~[Debugger.jar:?]
at ghidra.dbg.util.DebuggerCallbackReorderer.lambda$attributesChanged$3(DebuggerCallbackReorderer.java:203) ~[Framework-Debugging.jar:?]
at ghidra.dbg.util.DebuggerCallbackReorderer.defensive(DebuggerCallbackReorderer.java:113) ~[Framework-Debugging.jar:?]
at ghidra.dbg.util.DebuggerCallbackReorderer.attributesChanged(DebuggerCallbackReorderer.java:203) ~[Framework-Debugging.jar:?]
at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:578) ~[?:?]
at ghidra.util.datastruct.PrivatelyQueuedListener$ListenerHandler.lambda$invoke$0(PrivatelyQueuedListener.java:58) ~[ProposedUtils.jar:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) ~[?:?]
at java.lang.Thread.run(Thread.java:1623) [?:?]
consoleOutput: error: Command requires a process, which is currently stopped.

consoleOutput: Process 57005 stopped

• thread Ghidra does not render correctly with GDK_SCALE set (HiDPI display) #1, stop reason = signal SIGTRAP
  frame #0: 0xffffffffffffffff

consoleOutput: Process 57005 resuming

INFO *** State Changed: 1 (DebugClientImpl.java:331)
DEBUG transitions state to eStateRunning (LldbManagerImpl.java:585)

ERROR Listener ghidra.app.plugin.core.debug.gui.objects.DebuggerObjectsProvider$MyObjectListener@52585b48 caused exception processing attributesChanged (DebuggerCallbackReorderer.java:116)

java.util.NoSuchElementException: No mapper for target: <LldbModelTargetProcessImpl: path=Sessions[dead].Processes[dead] model=agent.lldb.model.impl.LldbModelImpl@4d767e38 schema=Process>
at ghidra.app.plugin.core.debug.service.model.DebuggerModelServicePlugin.recordTargetBestOffer(DebuggerModelServicePlugin.java:338) ~[Debugger.jar:?]
at ghidra.app.plugin.core.debug.service.model.DebuggerModelServiceProxyPlugin.recordTargetBestOffer(DebuggerModelServiceProxyPlugin.java:591) ~[Debugger.jar:?]
at ghidra.app.plugin.core.debug.gui.objects.DebuggerObjectsProvider.startRecording(DebuggerObjectsProvider.java:1512) ~[Debugger.jar:?]
at ghidra.app.plugin.core.debug.gui.objects.DebuggerObjectsProvider$MyObjectListener.attributesChanged(DebuggerObjectsProvider.java:1844) ~[Debugger.jar:?]
at ghidra.dbg.util.DebuggerCallbackReorderer.lambda$attributesChanged$3(DebuggerCallbackReorderer.java:203) ~[Framework-Debugging.jar:?]
at ghidra.dbg.util.DebuggerCallbackReorderer.defensive(DebuggerCallbackReorderer.java:113) ~[Framework-Debugging.jar:?]
at ghidra.dbg.util.DebuggerCallbackReorderer.attributesChanged(DebuggerCallbackReorderer.java:203) ~[Framework-Debugging.jar:?]
at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:578) ~[?:?]
at ghidra.util.datastruct.PrivatelyQueuedListener$ListenerHandler.lambda$invoke$0(PrivatelyQueuedListener.java:58) ~[ProposedUtils.jar:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) ~[?:?]
at java.lang.Thread.run(Thread.java:1623) [?:?]

ERROR Listener ghidra.app.plugin.core.debug.gui.objects.DebuggerObjectsProvider$MyObjectListener@52585b48 caused exception processing attributesChanged (DebuggerCallbackReorderer.java:116)

java.util.NoSuchElementException: No mapper for target: <LldbModelTargetProcessImpl: path=Sessions[dead].Processes[dead] model=agent.lldb.model.impl.LldbModelImpl@4d767e38 schema=Process>
at ghidra.app.plugin.core.debug.service.model.DebuggerModelServicePlugin.recordTargetBestOffer(DebuggerModelServicePlugin.java:338) ~[Debugger.jar:?]
at ghidra.app.plugin.core.debug.service.model.DebuggerModelServiceProxyPlugin.recordTargetBestOffer(DebuggerModelServiceProxyPlugin.java:591) ~[Debugger.jar:?]
at ghidra.app.plugin.core.debug.gui.objects.DebuggerObjectsProvider.startRecording(DebuggerObjectsProvider.java:1512) ~[Debugger.jar:?]
at ghidra.app.plugin.core.debug.gui.objects.DebuggerObjectsProvider$MyObjectListener.attributesChanged(DebuggerObjectsProvider.java:1844) ~[Debugger.jar:?]
at ghidra.dbg.util.DebuggerCallbackReorderer.lambda$attributesChanged$3(DebuggerCallbackReorderer.java:203) ~[Framework-Debugging.jar:?]
at ghidra.dbg.util.DebuggerCallbackReorderer.defensive(DebuggerCallbackReorderer.java:113) ~[Framework-Debugging.jar:?]
at ghidra.dbg.util.DebuggerCallbackReorderer.attributesChanged(DebuggerCallbackReorderer.java:203) ~[Framework-Debugging.jar:?]
at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:578) ~[?:?]
at ghidra.util.datastruct.PrivatelyQueuedListener$ListenerHandler.lambda$invoke$0(PrivatelyQueuedListener.java:58) ~[ProposedUtils.jar:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) ~[?:?]
at java.lang.Thread.run(Thread.java:1623) [?:?]

[d-millar]

OK, guess I was wrong about being wrong about "register". So, I think the basic problem may be that you're going to have to set the architecture by hand. Somewhere in the Connections dialog, where you entered "lldb", you may be able to change that to "lldb --arch i386" or whatever the target architecture is. You'll want to pick something from the list above.

[d-millar]

Alternatively, you can enter a command in the Interpreter - trying to find that right now....

[d-millar]

I think it's going to be something like:

set target.default-arch XXX

or

set platform.plugin.qemu-ser.architecture XXX

or possibly

platform select remote-gdb-server

If you guess correctly, I believe the "register read" command will work.

[yattr]

There is no "set target" or "set platform..."

(lldb)platform select remote-gdb-server
Platform: remote-gdb-server
Connected: no

From MacOS Activity Monitor
JLinkGUIServerExe PID =16679
SEGGER - J-Link GDB Server PID = 16678

The JLink GDB server app (16678) launches the PID 16679.

In the Objects window under Debugger Available there is a item that matches PID 16679

Here is a view of the JLink GDB app

[d-millar]

OK, may have to do some more googling to find that command syntax. Am guessing the third command did not enable “register read”. The picture of the JLink however is very interesting - it shows which gdb/RSP packets are being sent. That could be very helpful. Does something get displayed when you issue “register read”?

[yattr]

Not for register read but it does for start and stop from Objects window as shown here

    Starting target CPU...
    Debugger requested to halt target...
    ...Target halted (PC = 0x000174DC)
    Starting target CPU...
    Debugger requested to halt target...
    ...Target halted (PC = 0x0001660A)

From the Interpreter a stop (from menu) created the following in the JLink app log

  WARNING: Unknown packet received: "jThreadExtendedInfo:"

Continue generated this in the log

  Starting target CPU...

[yattr]

BTW, Here are the warnings that appear in the JLink app log when the Object Connection is established

  Waiting for GDB connection...Connected to 127.0.0.1
  WARNING: Unknown packet received: "qHostInfo"
  WARNING: Unknown packet received: "qVAttachOrWaitSupported"
  GDB client (conn. 25) requested target.xml from GDB Server
  WARNING: Unknown packet received: "qStructuredDataPlugins"
  WARNING: Unknown packet received: "qShlibInfoAddr"
  WARNING: Unknown packet received: "jThreadsInfo"
  WARNING: Unknown packet received: "qMemoryRegionInfo:0"

[d-millar]

OK, the correct syntax for the first two commands above would be "settings set ...." (vs "set ...). If it's supported "settings show", should list all the things on your target that can be set. Am hoping (a) that command is supported, and (b) it lists something related to "architecture".

[yattr]

Settings and set are the same command in the LLDB version I am using

There is this

(lldb) settings list target.default-arch
target.default-arch -- Default architecture to choose, when there's a choice.
(lldb) settings show target.default-arch
target.default-arch (arch) =
(lldb)

...but finding values for target.default-arch has all the elements of a life long task!

This is a list from the LLDB docs but the few I tried didn't work!!!!!

[d-millar]

Hmmm, yeah - dont see anything matching armv6, am assuming you tried armv7?

[d-millar]

Re "settings" vs "set", lldb accepts two-or-more letter abbreviations for every commad, e.g. "process launch --stop-at-entry" can be "pr la -s". Given that, to set target.default-arch you'd need "settings set target.default-arch" or "se se target.default-arch".

[d-millar]

Oh, "se" actually is ambigous - guess it has to be "set se target.default-arch xxx"

[yattr]

Yes tried armv7 and arm32....no dice

"help set" results in the same output as "help settings". The help listing for "set" starts off with "Commands for managing LLDB settings."

I use "set set" and that works...

Interesting that searching on " target.default-arch" doesn't produce anything helpful nor does "LLDB architecture settings"

You have to love the phrase "when there's a choice" and none are listed or help doesn't provide anything for acceptable values...

[d-millar]

Yeah, unfortunately, I believe that info would be coming from the target - doesn't seem to be forthcoming.

[yattr]

Thank you for all of your assistance. Heading back to Ozone with ghidra approach...

[d-millar]

Am sorry we couldn't get things working via lldb! Good luck!