Connect to luma3ds gdb stub with "GNU gdb local agent via GADP/TCP" #2721
Replies: 47 comments 312 replies
-
|
Can you connect to the stub via gdb? |
Beta Was this translation helpful? Give feedback.
-
|
Actually, I think I'm confused - the error you sent implies the agent died, but the command I suggested you run shouldn't be running an agent. Did you connect using "GNU gdb over GADP"? |
Beta Was this translation helpful? Give feedback.
-
|
Hmmm, not sure that's right either - hold off, let me consult tomorrow, maybe give you better advice |
Beta Was this translation helpful? Give feedback.
-
There isn't actually something called that. Only
Yes.
Okay. |
Beta Was this translation helpful? Give feedback.
-
|
Okay, this is where I am so far: |
Beta Was this translation helpful? Give feedback.
-
|
I keep forgetting you're on a Windows box....OK, right, so you're doing the right thing, but I probably haven't provided enough detail again. Either the "GNU gdb local agent over GADP/TCP" or the "IN-VM gdb local debugger" options should work as long as you specify the correct command in the "GDB launch command" parameter (in your case /path/to/arm-none-eabi-gdb.exe") . I would recommend the latter as it will give you more info if it dies and is easier to debug if we have to go that route. When you connect, the device may or may not be running. If it has broken, you'll be in the same state as you were with gdb.exe, and, when you select the process/inferior in the Objects Provider, the green resume/continue button should be enabled. If it's not (i.e. it's running), selecting the same object should enable the interrupt/pause button. If neither of those are true, you'll probably need to do something else in the Interpreter Console. The Interpreter Console is basically (more or less) the same environment as the gdb shell. If you are entering something like "target remote host:port" in gdb, you will have to do the same in the Interpreter. (If the Interpreter isn't visible, launch it from the Objects Provider.) You may also want to read a bit of the help - most of the windows don't display useful info until you are tracing the target. |
Beta Was this translation helpful? Give feedback.
-
|
Oh, and to clarify "GADP connection over TCP" won't work. That's really only for talking to a remote Ghidra agent running on a different box (potentially connected to a client). If you were using that, the stub was probably extremely confused because we were talking GADP to it and it only speaks RSP. Am guessing you may get the agent died message again, but, if you run from Eclipse, you may get a stack trace that'll help us figure out why. Does that all make sense? |
Beta Was this translation helpful? Give feedback.
-
|
I don't really get it. On my 2ds, I have Luma3ds and I turn on the debugger and |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for the giant image, but this is what Ghidra looks like:
The IP and port are what luma3ds gives me. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, this is definitely confusing - I appreciate your hanging in there and giving it a try! So, what I think is happening in the "GADP connection" case is you're telling it the host and port, it's doing the TCP handshake and connection, but the underlying protocol is not what it's expecting - so it hangs. Admittedly, this looks like it connected but probably not. Try this: specify your version of gdb in the IN-VM GDB pane. I think you MAY be able to also add the host:port as arguments in the same field, but I'm not sure about that. If you don't, you'll need to open that Interpreter window and enter "target remote 192.168.2.3:4000". Let me know if you get that far! |
Beta Was this translation helpful? Give feedback.
-
|
I'll try. |
Beta Was this translation helpful? Give feedback.
-
|
Is this where I am supposed to enter the stuff? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, looks good -fire away! |
Beta Was this translation helpful? Give feedback.
-
|
hit "Details" |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Ah, that's very helpful, but it may be where my expertise ends - I will grab one of the other guys tomorrow who understands the Pty implementation. Sorry, it wasn't an immediate win! |
Beta Was this translation helpful? Give feedback.
-
|
Okay, thanks. Don't worry about it, it's okay. |
Beta Was this translation helpful? Give feedback.
-
|
Oh, by the way, how do I open the interpreter? |
Beta Was this translation helpful? Give feedback.
-
|
(I say "immediate" although I realize you've been working at this for weeks!) |
Beta Was this translation helpful? Give feedback.
-
|
If it connected, it would be the little console-shaped icon in the Objects Provider at the far left of the toolbar |
Beta Was this translation helpful? Give feedback.
-
|
Ohhhhh, okay. Thanks a lot. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, I'm entering the conversation a little late. Several things to point out. First, as of now, the GDB connector (whether IN-VM or via GADP/TCP) is only supported on Linux. We use So, the simplest, though perhaps disappointing answer, is to just build and run Ghidra on Linux. Then you can use all the GDB stuff "out-of-the-box." If you insist on using Ghidra for Windows, and/or your like a good adventure, then proceed: You can use a Linux VM to host GDB, then connect to it from Ghidra on Windows. While I've not tested this myself, you might be able to forego the Linux VM for WSL. It'll probably work for WSL2, since that is essentially a Linux VM. I'm not as confident for WSL1, but it could. Note that the GADP connection over TCP cannot connect directly to a GDB stub. GADP is Ghidra's in-house protocol for communicating with its connectors. (GDB stubs use RSP, which we don't connect to directly.) We often run the actual connector in a separate "agent" process, because they are more prone to crash. Should they crash, we don't want it to take all of Ghidra with it. (the IN-VM variants loads the connector in Ghidra's process, the via GADP/TCP variants launch the agent and automatically connect via GADP). The "GADP connection over TCP" connector is used when you've already launched an agent, which is a less-common use case, but applies here. In a sense, the agent just wraps GDB as a means of translating GADP to RSP. Thus, you must build and launch the agent manually on Linux, and connect to it from your Windows Ghidra. In your ghidra repo (presumably on Windows), run: This will generate You will probably need the Now, from Ghidra on Windows, hit the connect button and select "GADP connection over TCP". Set the network address to your VM's virtual adapter's IP (again, localhost for WSL.) Set the port to 12345, and click connect. You should eventually receive the GDB prompt in Ghidra. You can then proceed as you normally would to connect GDB to your stub. |
Beta Was this translation helpful? Give feedback.
-
|
I guess I could try Linux VM, but it may take up too much ram. |
Beta Was this translation helpful? Give feedback.
-
|
Ctrl-C is surprisingly complicated on Linux. Again, I'm not sure the nuances on Windows. It might turn out to be simpler there, but we've not done it yet. Simply sending Cltr-C (character 3) down stdin does not interrupt the process. It has to be interpreted by a private/pseudo terminal (pty), which then signals the appropriate process with the interrupt. We also can't just interrupt the process ourselves, because it might be a remote target. GDB takes care of these nuances for us, if we can properly emulate a terminal and send Ctrl-C. |
Beta Was this translation helpful? Give feedback.
-
|
Well, when I open gdb (in tui mode, at least) it lets me interrupt my 2ds. |
Beta Was this translation helpful? Give feedback.
-
|
@nsadeveloper789 Windows offers an equivalent API to They've also written a detailed blog post on the new API. |
Beta Was this translation helpful? Give feedback.
-
|
What does this mean? |
Beta Was this translation helpful? Give feedback.
-
|
To emulate Linux, will I need Hyper-V? |
Beta Was this translation helpful? Give feedback.
-
|
Yes. |
Beta Was this translation helpful? Give feedback.
-
|
I do not have it. |
Beta Was this translation helpful? Give feedback.
-
|
Which version of Linux would Ghidra's debugger work well on? |
Beta Was this translation helpful? Give feedback.
-
|
Will the debugger ever work properly on windows? Or if it does now, to connect to 3ds-like devices? |
Beta Was this translation helpful? Give feedback.
-
|
"Ever" is potentially a very long time, so hard to say. Unfortunately, as indicated in the documentation, your use case is really not high on our priority list. Our primary main goals are support for user-mode debugging of Windows' targets on Windows platforms and Linux targets on Linux platforms. Happy to keep you abreast, though, of changes that might make your use case more tenable. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for your help. |
Beta Was this translation helpful? Give feedback.
-
|
@SirEnder125 yes, the post by @DrChat means there is hope - we're looking into to it! |
Beta Was this translation helpful? Give feedback.
-
|
Hey, that's great!! Please let me know if anyone gets that working. |
Beta Was this translation helpful? Give feedback.
-
|
I opened an issue for this @ #2908. |
Beta Was this translation helpful? Give feedback.
-
|
Hey, sorry to bother you guys again, but do you think that |
Beta Was this translation helpful? Give feedback.
-
|
It is not likely. That said, we've added SSH support, which brings up 3 potentially useful points:
Honestly, option 2 via WSL2 is probably your best option: |
Beta Was this translation helpful? Give feedback.
-
Oh. Well, I can wait until they get it working, if it's a planned feature. If not, fine.
I have no idea what to do with this ubuntu thingy. |
Beta Was this translation helpful? Give feedback.
-
|
This will install the SSH service and GDB in your Ubuntu distro on WSL. sudo apt install openssh-server gdbThere may be some additional setup to get it working in WSL, but there are plenty of how-tos, e.g. https://superuser.com/questions/1123552/how-to-ssh-into-wsl |
Beta Was this translation helpful? Give feedback.
-
|
I installed openssh-server and gdb. How do I open openssh-server? |
Beta Was this translation helpful? Give feedback.
-
|
Okay. I connected with PuTTY. I am about to connect with Ghidra. |
Beta Was this translation helpful? Give feedback.
-
|
Hey, Going to weigh in here just to make sure we're all on the same page - if I say anything wrong, feel free to jump in because I'm not sure I have the complete picture myself. So, as I understand your scenario, you have Ghidra running on Windows (effectively the client) and the gdbstub on luma3ds (effectively the server). The gdbstub "speaks" the RSP protocol, so to communicate with it we need something that speaks RSP on the client side. Because we do not have an RSP client for, well, anything, we typically rely on a middleman. On Linux, this is gdb, which we wrap as a gdb agent. In that scenario, Ghidra launches gdb and speaks GADP to it. Gdb translates those requests to RSP and talks to the target (in your case luma3ds). On Linux, we can also create an SSH connection to GDB, issue the commands directly, and get the same result. For Windows, gdb running under Windows proper is basically a non-starter, so your options are either (a) gdb running on WSL, or (b) gdb running on a different machine. If luma3ds had an SSH server, you could talk directly to that, but I don't think it does. (Correct me if I'm wrong on this.) So, let's say we're going WSL. I know exactly nothing about WSL so again correct me if I say something stupid, but, in this case (or even in the second machine) case, you'll want to install the openssh server and gdb on the middleman. Sounds like you have already done this. When you launch the openssh server, you can, I believe, specify a host and a port for clients to talk to it. If you don't specify, the host is localhost and the port is 22. If the server is running under WSL, can the main windows account access it as localhost? I don't know the answer to this, actually. If it can, you'll want to (a) launch the openssh server, and (b) connect from Ghidra using "GDB over SSH" with the parameters set to /path/to/gdb, localhost, 22, and your username for WSL. On a good day, this will launch gdb in the WSL environment. From there, though, you'll still have to connect to the luma3ds. Probably, easiest to do this from the Interpreter using "target remote" etc. Yell if this is unclear (or, of course, incorrect) :/ |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, that cleared up a lot. Uh, I got this error:
|
Beta Was this translation helpful? Give feedback.
-
|
FWIW, some technical clarification: GADP is not involved when you use GDB over SSH. Ghidra talks SSH to the SSH server, commands it to run GDB in a pseudo-terminal, and then speaks GDB/MI to GDB over that SSH channel. When new-ui is supported, it'll command the SSH server to open a second pseudo-terminal, so that Ghidra can acces both the console and mi2 interpreters. |
Beta Was this translation helpful? Give feedback.
-
|
OK, so am guessing you've already done this, but the first thing I would try is opening a Windows cmd window and issuing the command "ssh user125@172.28.57.51:2222". There are two reasons for doing this: (1) ssh does some set-up on the very first connection that's hard to get right any other way, and (2) it might give you some insight if the ssh connection itself is failing. Assuming you've already done this, my guess is one of two things is going wrong - either gdb is not actually at /usr/bin/gdb ("which gdb" should tell you the actual path) or the path is a link. For reasons I don't quite understand, various tools are not happy with links. If so, "ls -l" the ostensible path, get the real path, and replace the first argument with that. |
Beta Was this translation helpful? Give feedback.
-
|
OK, so is that IP address for the WSL client or a separate machine? Guessing you can't ping it either? |
Beta Was this translation helpful? Give feedback.
-
|
Looking at the screenshots, I see two potential problems.
|
Beta Was this translation helpful? Give feedback.
-
It is for a WSL client. No, I cannot ping it either. |
Beta Was this translation helpful? Give feedback.
-
Well, I installed that GDB by running |
Beta Was this translation helpful? Give feedback.
-
|
I downloaded GDB again and got |
Beta Was this translation helpful? Give feedback.
-
|
OK, hmmmm, well that's some progress. I think I need to think more about the Dynamic window issue. |
Beta Was this translation helpful? Give feedback.
-
|
I mean close a trace. A "trace" is the recording of a live target. They can be saved for offline analysis. The red dot indicates the trace is "live" or online. Without the dot, it means it's offline, i.e., no longer associated with a live target. |
Beta Was this translation helpful? Give feedback.
-
|
OK. I was able to get the full logs from your posts. GitHub's markdown is chewing up GDB's responses, but if I grab the raw post, I can see the whole thing. I'll take a moment to examine them. |
Beta Was this translation helpful? Give feedback.
-
|
OK, so in the second log (where you get a successful step), there are 18 I did want to point out an error I saw in the log: |
Beta Was this translation helpful? Give feedback.
-
|
Okay, I followed those steps 3 times and the output was the same all 3 times. |
Beta Was this translation helpful? Give feedback.
-
|
Since the output was the same, does that mean that the error is from Ghidra (or my input)? |
Beta Was this translation helpful? Give feedback.
-
|
I'm back at the "Record" window thing... again... |
Beta Was this translation helpful? Give feedback.
-
|
When I try to step the current thread: |
Beta Was this translation helpful? Give feedback.
-
|
Does this mean anything? |
Beta Was this translation helpful? Give feedback.
-
|
When you get one of those error dialog boxes with the "Detail" button on the right, if you could click that and send the stack trace, it would really help us diagnose the problem. |
Beta Was this translation helpful? Give feedback.
-
|
The |
Beta Was this translation helpful? Give feedback.
-
|
The objects list shows one thread while the Threads list shows 20. |
Beta Was this translation helpful? Give feedback.
-
|
A couple quick comments (apologies dug in on a different problem): |
Beta Was this translation helpful? Give feedback.
-
|
I got a ton of error messages saying "Ignoring packet error, continuing..."
```
.
.
MI2: -interpreter-exec console "show version"
\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law."
.\n"
."
MI2: -interpreter-exec console "show architecture"
MI2: -interpreter-exec console "show os"
MI2: -interpreter-exec console "show endian"
MI2: -list-thread-groups
MI2: -list-thread-groups
MI2: -interpreter-exec console "source /mnt/c/Users/*/Downloads/ghidra-master/ghidra-master/Ghidra/Debug/Debugger/src/main/resources/define_info_proc_mappings"
MI2: -interpreter-exec console "set arch arm"
MI2: -interpreter-exec console "set endian little"
MI2: -interpreter-exec console "target remote 192.168.2.89:4000"
MI2: -interpreter-exec console "maintenance info sections ALLOBJ nosections"
MI2: -interpreter-exec console "show architecture"
MI2: -interpreter-exec console "show os"
MI2: -interpreter-exec console "show endian"
MI2: -list-thread-groups
MI2: -thread-info 1
MI2: -thread-info 2
MI2: -thread-info 3
MI2: -thread-info 4
MI2: -thread-info 5
MI2: -thread-info 6
>MI2: -thread-info 7
MI2: -thread-info 8
MI2: -thread-info 9
MI2: -thread-info 10
MI2: -thread-info 11
>MI2: -thread-info 12
MI2: -thread-info 13
>MI2: -thread-info 14
MI2: -thread-info 15
MI2: -thread-info 16
MI2: -thread-info 17
>MI2: -thread-info 18
MI2: -thread-info 19
>MI2: -thread-info 20
MI2: -thread-info 21
MI2: -thread-info 22
MI2: -thread-info 1
>MI2: -stack-list-frames --thread 1
MI2: -thread-info 2
MI2: -stack-list-frames --thread 2
MI2: -thread-info 3
MI2: -stack-list-frames --thread 3
>MI2: -thread-info 4
MI2: -thread-info 5
>MI2: -stack-list-frames --thread 4
MI2: -stack-list-frames --thread 5
MI2: -thread-info 6
MI2: -stack-list-frames --thread 6
>MI2: -thread-info 7
MI2: -stack-list-frames --thread 7
>MI2: -thread-info 8
MI2: -thread-info 9
>MI2: -stack-list-frames --thread 8
MI2: -stack-list-frames --thread 9
>MI2: -thread-info 10
MI2: -stack-list-frames --thread 10
>MI2: -thread-info 11
MI2: -stack-list-frames --thread 11
>MI2: -thread-info 12
MI2: -stack-list-frames --thread 12
MI2: -thread-info 13
MI2: -stack-list-frames --thread 13
>MI2: -thread-info 14
MI2: -stack-list-frames --thread 14
>MI2: -thread-info 15
MI2: -thread-info 16
>MI2: -stack-list-frames --thread 15
MI2: -stack-list-frames --thread 16
>MI2: -thread-info 17
MI2: -stack-list-frames --thread 17
>MI2: -thread-info 18
MI2: -stack-list-frames --thread 18
>MI2: -thread-info 19
MI2: -stack-list-frames --thread 19
MI2: -thread-info 20
MI2: -stack-list-frames --thread 20
MI2: -thread-info 21
MI2: -thread-info 22
>MI2: -stack-list-frames --thread 21
MI2: -stack-list-frames --thread 22
MI2: -interpreter-exec console "info proc mappings"
MI2: -list-thread-groups i1
MI2: -thread-select --thread 9 9
MI2: -list-thread-groups
MI2: -list-thread-groups
|
Beta Was this translation helpful? Give feedback.
-
|
That's an error printed by GDB. It seems luma3ds is sending a packet that GDB does not understand. Above the spam, there's a message about an unexpected byte 109. It's unclear if the error is associated with a particular command. If so, we might avoid sending it, but it could also just be an incompatibility between GDB 9.2 and your version of luma3ds. If they recommend a particular version of GDB, that might be useful information. Hopefully, they list a supported version that Ghidra also supports.... If not, then maybe the error can be ignored. If that's not the case, then I'm afraid I'm out of ideas at the moment. |
Beta Was this translation helpful? Give feedback.
-
|
I can't find anything specifying a GDB version. I tried to ask via an issue, but it said that I can't at this time. Do you think that GDB could be the problem here? I guess it would be pretty hard to say. |
Beta Was this translation helpful? Give feedback.
-
|
I just came over here from #3102 that I opened about this issue. I have only skimmed through the the thread, so I am not 100% sure how you are connecting GDB to your device, but I know that WSL does not really work well with USB devices, so if you are using a USB debugger, that might be part of the problem. A possible alternative is to use a Raspberry Pi with the USB debugger plugged into it, and run the GDB server on the Raspberry Pi, then connect Ghidra to that. I'm going to be trying setting that up with a SEGGER J-Link in the next few days, and will add a comment here if that works. |
Beta Was this translation helpful? Give feedback.
-
|
For anyone reading this, it is possible to use a Raspberry Pi as a GDB server. However there seems to be some issue with Ghidra parsing the data from the session, as nothing is being populated. I am probably going to wait until Ghidra 10 leaves beta before pursuing this more. |
Beta Was this translation helpful? Give feedback.
-
|
@marsfan When you say "nothing" is that "nothing" nothing? In particular, is there anything in the Objects window? Do you have an Objects window? |
Beta Was this translation helpful? Give feedback.
-
|
@d-millar I mean completely nothing. No registers, no live view, nothing, though there is a bit of something in the objects window. I switched to using a virtual machine since I can run everything locally with that method, and much more seems to work. I still have a couple of issues, but I am going to create a new discussion for those, since I did not realize that this discussion was almost a month old when I posted here. |
Beta Was this translation helpful? Give feedback.
-
|
@marsfan Sorry to be a pest, but my questions are relevant to the solution of your problem: do you have the Objects view visible and does that have anything in it? All of the other windows depend on the trace. If the trace isn't active, all of those will be blank. There are a number of reasons why this might be - many of the discussed above - but, if the Objects view is empty, it's a whole different set of problems. |
Beta Was this translation helpful? Give feedback.
-
|
The fourth number is the initial fill, i.e. the default value (I think, if I remember correctly). The failure to track between the static and dynamic listings is tied to the fact that you have no module list. The debugger needs to know where the dynamic version of your static listing is based on memory. In your case, this means faking out the “maintenance info sections” command, similar to what you’ve done for “info proc mappings”. Arm/thumb is a little trickier - may need to talk to some folks about that and get back to you. |
Beta Was this translation helpful? Give feedback.
-
|
Correction: fourth number is offset (oops) - generally, you’ll want this to be zero. |
Beta Was this translation helpful? Give feedback.
-
|
Oh, and, wrt write-up, the Github pages are definitely best for us, either the wiki or the Discussions pages are a good spot! Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
@marsfan ARM/THUMB should depend on the trace's recorded cpsr register. Make sure that register is listed in the Registers window and/or the Interpeter, and checked (i.e. being read) in the Registers window. Also, check to make sure the endianness is not incorrect, which might cause the wrong bit in the register to be used to track ARM/THUMB. |
Beta Was this translation helpful? Give feedback.
-
|
@d-millar I'm still looking into this, but I am going to be really busy for the next week or two, so it might be a bit little bit before I can update you on if I got the modules view working. |
Beta Was this translation helpful? Give feedback.
-
|
In a pre-built distribution of Ghidra 10.0.1, how would I go about changing the |
Beta Was this translation helpful? Give feedback.
-
|
@SirEnder125 The script should be in Ghidra/Debug/Debugger-agent-gdb/data/scripts in the new release. That said, as pointed out by @marsfan, you could just write it yourself. It doesn't need to reside in any particular location, as you probably know, because you're just executing it in gdb. As long as you know the path, you should be good. Re the contents, apologies if I didn't explain the contents! The basic idea is to replace the normal gdb "info proc mappings" command for systems that don't support that command, so the first line basically says use what's between the "define xxx" and "end" lines as the return for xxx. The two "echo" lines are just regurgitating information that says, in essenc, "everywhere is defined" in the format used by most Linux gdb implementations, i.e. "start_address stop_address size offset objfile". Objfile is basically just a name for our purposes, so the default script uses "lomem" and "himem". You may be wondering why we need two regions, and the answer is technically we don't, but Java doesn't represent 64-bit unsigned numbers as longs, which is what we're using. (Probably could fix that, but...) Would also make sens for us just to give the defaults if "info proc mappings" isn't defined. Maybe I'll fix that today. :) |
Beta Was this translation helpful? Give feedback.
-
|
Ah, alright. Then |
Beta Was this translation helpful? Give feedback.
-
|
yes, I believe so! |
Beta Was this translation helpful? Give feedback.
-
|
oh, and, by the by, I added the fix to 10.0.2, so, whenever that goes out, you should be able to skip the script |
Beta Was this translation helpful? Give feedback.
-
|
Oh, nice. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Any fixes lately to any problems that may have caused the issues with using Ghidra and ssh as debugger for the 3ds? This is a very old discussion, but I was wondering if it may not be too far gone? |
Beta Was this translation helpful? Give feedback.
-
|
Hey @SirEnder125, Good to hear from you! I too am not sure where exactly we left things on the 3ds front. I think you were trying to connect from wsl, had it mostly working, but were trying to get the define_info_proc_mappings script set up? Maybe? 10.0.3 should be in better shape from a number of perspectives, but @serby2000 did ID a bug in our handling of the protocol if you try connecting to a Linux target from a Windows box using "GDB over ssh". If you want to try that out, let me know - I can probably talk you through the build. If not, it should be in 10.0.4 and in the GitHub repo before that (maybe next week?). If you're sticking with the wsl->3ds solution, that may not be a problem. Let me know what you're up for! D |
Beta Was this translation helpful? Give feedback.
-
|
I'm pretty sure I had define_info_proc_mappings working a while ago. I just thought it looked confusing, that's why I asked about it. |
Beta Was this translation helpful? Give feedback.
-
|
I might try it first without going through the build process - unless you’re feeling bored/adventurous. :) If you do decide to try building, the instructions are in the DevGuide and DebuggerDevGuide (mostly the first), which are at the top level on the Ghidra install dir. |
Beta Was this translation helpful? Give feedback.
-
|
Oh, alright. I'll just use my current installation of Ghidra? I believe the version is 10.0.1. Will that work? |
Beta Was this translation helpful? Give feedback.
-
|
Probably, although we definitely made some debugger-specific fixes in 10.0.3 |
Beta Was this translation helpful? Give feedback.
-
|
Ah, well I think the problem may have been Ghidra, but maybe not. I don't remember what happened when I opened GDB directly from Ubuntu, if the problem did not arise such as it did in Ghidra when trying to run the |
Beta Was this translation helpful? Give feedback.
-
|
So I got some things working again. WSL finally booted up, after a PC reboot. And Ghidra connects successfully. The interpreter is filled with newline characters, and no threads are showing up. Clicking 'record' on the process opens this window:
The "Debug Console" shows this: |
Beta Was this translation helpful? Give feedback.
-
|
So, when you say "Ghidra connects successfully", what do you mean, i.e. what steps exactly did you take to launch the debugger and connect to the 3ds? The stack trace just says, basically, GDB failed, so I need more to go on. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for the lack of clarity on my part. Ghidra connected to WSL, and I was able to type in the interpreter. I typed in a few commands:
Then I believe I pressed record, and the "Record" window popped up. |
Beta Was this translation helpful? Give feedback.
-
|
OK, that helps - suggests the "Error while starting GDB" message is a red herring and you're considerably further along than I thought. I'll look through the code and try to remember how the Record menu could come up empty. |
Beta Was this translation helpful? Give feedback.
-
|
@d-millar Hey! This is just me checking back foreverrrr later... I haven't been debugging 3ds for a long time, but I want to try maybe today, and I was wondering, do I still have to connect to WSL first? Or can I run gdb directly on windows yet? 🤔 |
Beta Was this translation helpful? Give feedback.
-
|
@SirEnder125 Long time! I think the issue may still be the version of gdb you need. In other words, if you need gdb-multiarch or something similar, I’m not sure Windows proper has an equivalent. That said, doesn’t hurt to try. I would use the “gdb over ssh” connector and see how you fare. |
Beta Was this translation helpful? Give feedback.
-
|
I see that, in my msys64 installation, there is a |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
Wait... Are you sure you meant "gdb over ssh?" That's what I've been using to connect to Linux. 🤔 |
Beta Was this translation helpful? Give feedback.
-
|
Ah, that's interesting - didn't realize Windows had a version of gdb-multiarch. Is that built to link against the WSL libraries or the native Windows API? In any case, I don't think that will work. We haven't implemented a version using ConPTY or any othe Windows Pseudo Console, primarily because the "GDB over SSH" option seems to fill that need. Are there shortcomings in the "GDB over SSH" solution that you feel merit time spent on a ConPTY solution? |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
How often do you have to check the state and the IP? What’s the driving cause for them changing? I.e. do they change when the game crashes? |
Beta Was this translation helpful? Give feedback.
-
|
I think the problem is that I debug like once a month and the IP changes... 😅 Today I debugged for a while and the only errors I got were my own fault I think? Also I found that the only version of Ghidra that works well with my method is 10.0.4. Later versions as for a "ssh file" and previous versions are... dated. The point is, my previous reply was written after I had not used ghidra successfully for a while. I think I got the hang of it this time. Thanks for alllllllll of your help @nsadeveloper789 @d-millar :) |
Beta Was this translation helpful? Give feedback.
-
Hey. Someone recently told me:
I'm not sure if it is compatible. But Luma3ds does have a gdb stub. But the debugger gives me this error:
Beta Was this translation helpful? Give feedback.
All reactions