When connecting to 3ds via Luma3ds, "Can't determine the current process's PID: you must name one."

[SirEnder125]

Hello. I am, once again, trying to debug my 3ds using Luma3ds. I have connected to WSL via SSH, and connected gdb-multiarch (v9.2) on WSL to Luma3ds. Before connecting, I set the architecture to arm, and the endianness to little. After connecting, the objects window is populated (no other windows get any info), and I get the message, "Can't determine the current process's PID: you must name one." I don't know if this is really a problem, but there is also the interpreter's output:

(gdb)set arch arm
The target architecture is assumed to be arm
 (gdb)set endian little
The target is assumed to be little endian
 (gdb)target remote 192.168.1.10:4000
Remote debugging using 192.168.1.10:4000
 warning: Target description specified unknown osabi "3DS"
 warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command. 
 0x00299cb0 in ?? ()
 (gdb) 0x00299cb0 in ?? ()
 Can't determine the current process's PID: you must name one.
 Can't determine the current process's PID: you must name one.
 stepi
 0x00299cb4 in ?? ()
 Can't determine the current process's PID: you must name one.
 (gdb)stepi
0x001b3700 in ?? ()
 Can't determine the current process's PID: you must name one.
 (gdb)stepi
0x001b3704 in ?? ()
 Can't determine the current process's PID: you must name one.
 (gdb)stepi
0x001b3708 in ?? ()
 (gdb)stepi
Can't determine the current process's PID: you must name one.
 (gdb)stepi
Can't determine the current process's PID: you must name one.
 Can't determine the current process's PID: you must name one.
 (gdb)stepi
0x07005610 in ?? ()
 (gdb)stepi
Can't determine the current process's PID: you must name one.
 (gdb)stepi
(gdb)stepi
(gdb)stepi
(gdb)stepi
(gdb)stepi
(gdb)stepi
Can't determine the current process's PID: you must name one.
 (gdb)stepi
(gdb)stepi
(gdb)stepi
(gdb)stepi
(gdb)stepi

At the end there, it got a little out of control. Of course, I've had this problem before, but what is my actual problem here? The PID not being known, or the order of what I entered in the interpreter? I am sorry if this is not too clear.

[astrelsky]

It is assuming a lot of things. One being that the target is running linux. This is exactly what I see with a gdb stub I've been working on and am glad to know the garbage seen there isn't my fault 🤣. With that said I have no idea if it is a problem or not.

[SirEnder125]

Lol. That can't be right. It's definitely not linux. Is this Ghidra's fault?

EDIT: Ah, didn't see that last sentence. Something is a problem. Probably since it assumes it is on linux, it is expecting something else than what Luma3ds is sending.

[astrelsky]

So it seems that this must be a default or something for the target. Even just running in gdb produces the same.

[d-millar]

So, this (I believe) is the message printed by gdb when the debugger issues an "info proc mappings" call and the stub doesn't know how to respond. We should probably modify our code to stop asking if the stub has failed once. I thought you fixed this for your scenario, though - are you still running your define_info_proc_mappings script?

[SirEnder125]

Oh, I did have that script. But I forget what it was. I thought that that was no longer necessary in v10.0.4. Maybe I misread. Do you remember what was in that script, as it would probably be hidden deep within the thread in which it was given?

[d-millar]

I think the answer re 10.0.4 is yes and no. I think we fixed the defaults so that, if you didn't define info_proc_mappings, we supply the correct answer, but we didn't (sigh) fix it so that, if the debugger issued that command again, the command would be defined and you wouldn't be besieged with error messages.

The default script resides in the distribution with the name define_info_proc_mappings, but I think you need to modify it because your device is not 64-bit. Should look something like:

define info proc mappings
echo 0x0 0x7FFFFFFF 0x80000000 0x0 mem \n
end

[astrelsky]

I think the answer re 10.0.4 is yes and no. I think we fixed the defaults so that, if you didn't define info_proc_mappings, we supply the correct answer, but we didn't (sigh) fix it so that, if the debugger issued that command again, the command would be defined and you wouldn't be besieged with error messages.

The default script resides in the distribution with the name define_info_proc_mappings, but I think you need to modify it because your device is not 64-bit. Should look something like:

define info proc mappings
echo 0x0 0x7FFFFFFF 0x80000000 0x0 mem \n
end

I log every single packet sent to my stub and it only complains about it. I don't know what it would be but I've never seen a request for such info.

[astrelsky]

Unless I'm totally missing something here.

Android app won't let me edit and windows is updating lol.

[d-millar]

Sorry, probably not clear if you haven't waded through the discussion #2721 (which is a long and admittedly winding road)....

For Ghidra to map the Dynamic Listing to the various programs in the Static Listing, it need to know where those programs have been loaded into memory so that it can convert the remapped addresses. If you have a target that never rebases, this may seem unnecessary, but many targets aren't so obliging. For gdb, the command we (Ghidra) issue to retrieve this information is "info proc mappings". We also use "maintenance info sections" in various spots. These are (probably/maybe) the only commands we issue directly, as they have now equivalents in the MI2 interface.

If your target does not support that command (or the RSP commands the agent parse them into), we don't know where your stuff lives. When the engine wrapped by our agents fails, it issues the elucidating "Can't determine the current process's PID" message. This we have no control over. We do, post 10.0.4, attempt to fake the memory layout by defining all memory as valid. We do not, however, apparently stop the requests for the failing command. Hence, the recurring and unpleasant message.

[astrelsky]

There is a lot I still don't quite understand wrt interfacing with gdb. This is what I respond with when sent qSupported: "PacketSize=2000;qXfer:features:read+;qXfer:threads:read+;QNonStop+;multiprocess-;swbreak+;hwbreak+;vCont+;vContSupported+". The still very messy implementation can be seen here. I'm thinking I may need to support qXfer:memory-map:read?

This is something I have been meaning to ask. Is there a list of the minimum required query packets that need to be supported to smoothly interface with Ghidra or that are expected to be supported? For reference qSupported.

[d-millar]

OK, will document this a little more fully and include it in the debugger docs somewhere, but thought I'd give you the short answer here....

Some commands you'll need to support are probably obvious:
$? - to relay stop reason
$g - register read
$m - memory read
$Tp - thread alive
$Z/z - breakpoints if possible

You need to support either $Hc/g or $vCont to control the target, latter better than the former.
You should probably also respond to $qSupported so that gdb isn't guessing at q/Q features. Obviously, tell gdb what you support in the response. At a minimum, supporting $qXfer:threads:read would be nice, as the recorder is really thread-base.

If you don't respond to $vFile, "info proc mappings" and "maintenance info sections" will not work (specifically "open", "pread", "close", "fstat", and "setfs", and the user will have to dummy out the response for those commands via a script as discussed here and elsewhere. Without these commands or a scripted override, the recorder is unlikely to work, and a lot of windows will be empty.

I think (?) everything else is optional. Packets I see include $vMustReplyEmpty, $qAttached, $qOffsets, $qSymbol, tracepoint packets ($qTfP, $qTfV, $qTsV, $qTStatus), $QNonStop, $QPassSignal, $QProgramSignals, and $QStartNoAck, but I believe (and correct me if I'm wrong) all q/Q packets are negotiated based on $qSupported.

[d-millar]

Hmmm, that's an interesting idea, i.e. minimum packet set supported. I won't get ot it today, but will try to take a stab next week. Short answer is no, and, unfortunately, it will take a bit of work to recover that info. The old (non-public) debugger communicated using RSP directly, so I could have told you probably off the top of my head, but the current (public) debugger uses the gdb/MI2 machine interface. This has many many many advantages including better feature support and ease of configuration, but it means we're also one layer away from the raw packets. There's also going to be a difference between the minimum packet set required by the implementation of gdb being used, the packet set typically used by Ghidra as a result of the request made over MI2, and the must-have packet set that will result in failures in Ghidra if not met. I do think qXfer:memory-map:read is the RSP equivalent of "info proc mappings though.

[SirEnder125]

@d-millar Digging around in #2721. I connected successfully to Luma3ds, opened the registries of the thread that was stopped on, and looked at the registries. I used stepi to step into it and the pc changed. Here is the interpreter view:

These steps from #2721 I followed after connecting to Luma3ds:

(a) resist the temptation to hit "c"
(b) make sure a thread is selected
(c) open Memory - make sure it has a value
(d) open Threads in the Object viewer and Register below that - make sure they look good
(e) try stepping

All that to say that I have something (very little?) working. But still the Threads window is not populated. Any ideas for a next step? Sorry, sorta off-topic.

[SirEnder125]

Memory:

[d-millar]

OK, so looking good so far. As described in the help, the fact that the Threads (and presumably all windows besides the Objects view and Interpreter) are empty means the recorder is not on. Try explicitly selecting the process in the Objects view and hitting R. If the dialog that comes up is empty, you may have to write an opinion file for your platform. Also, try typing “show architecture” in the Interpreter. That will tell us what gdb believes the architecture is.

[SirEnder125]

The record window:

you may have to write an opinion file for your platform.

What is that?

[d-millar]

so an opinion is basically a description for the debugger of the architecture. in your case, however, “arm” has an opinion already written for it, so that is not the problem. i have a feeling this is related to the message you got regarding unknown osabi (“3DS”). going to have to look into this a bit before i can suggest a fix, i’m afraid.

[SirEnder125]

Oh, alright. 👍🏻

[astrelsky]

On somewhat related note, if I send multiprocess+ in the response to qSupported I receive the following output:

 warning: unable to open /proc file '/proc/42000/maps'
 warning: unable to open /proc file '/proc/42000/maps'

However these files wouldn't exist on the system running gdb but would be on the remote target if it was running linux.

[d-millar]

Alright, @nsadeveloper789 looked into this, and we're going to suggest a workaround, but anyone's guess whether it will work. If you type "set architecture" w/o "arm" or anything else, you "may" get a list of supported architectures back. I would try the one you think is closest to the 3DS's. If I remember correctly, the 3DS is "armhf", but I doubt that will be listed. Maybe try something like "armv7".

[SirEnder125]

So I tried armv7. At first it did not show anything but the Objects window. After remembering to press record, the Record window popped up and I pressed one of the options. Here is where I am now. Now I just need to learn what the arm instructions do and how to use a debugger in general. Thanks for all the help. :D

[nsadeveloper789]

Good deal!

[d-millar]

Awesome - looks good! Congratulations! I hear ya re understanding all the arm stuff - the decompiler window is my goto on arm. Keep us posted!

[SirEnder125]

I have a few questions.

1. How do I decompile to asm code in the dynamic listing?
2. How do I change the size of the addresses in the dynamic listing? (By default it shows bytes, I want 4 byte integers maybe.)
3. How do I jump to an address in the dynamic listing?

[SirEnder125]

Okay, it works inasmuch as the two views are synced, I can select an address in the dynamic listing and it will be selected in the static listing. But the values are not the same. Which is odd, because, usually, I can open the debugger, go to an address, open the .elf in the CodeBrowser go the the same address, and the instructions would be the same. Any ideas?

[SirEnder125]

I did just recreate the .elf file however. But I did it the same way as when it had the same addresses as dynamic memory.

[nsadeveloper789]

Maybe send another screenshot? You might double-check that the .elf is actually what you're debugging. It's also possible the byte values match, but the instructions are being disassembled under the wrong mode (ARM, THUMB).

[SirEnder125]

So I think it is the elf file... I had one that worked perfectly the other day, but with the .elf file I am using today, if I go to the address of a known instruction, it should be mov r0,#0 but instead it's str r0,[r4,#0x2b4]. I will get back to you with the screenshot.

[SirEnder125]

Okay, I think I'm off my rocker. I accidentally created a .elf file of an outdated version of the game. I made one of the updated version, and it works fine. Thanks.