You are not logged in.

Read the FAQ and Knowledge Base before posting.
We won't make a 3DS/2DS emulator.

#1 Re: Support » GameInfo reading out of buffer » 2017-10-30 08:50:41

ok.

FYI, the problem appeared while trying to use a --gbaslot-rom=self with a romsize of 302254 (which I note to be not a multiple of 4). The crash occurs when a memcpy starts reading that byte-per-byte, with a position of 302251, where "pos + 4 > romsize" occurs first.

I'm afraid I cannot tell what real hardware would do then, because on real hardware, I have some DLDI code in the play. It could very well be that using memcpy to read from the GameInfo area is a mistake, and that e.g. only 4-bytes-aligned or 2-bytes-aligned reads are allowed. It could also be that my tools are incorrect and that producing a rom that isn't a multiple of (whatever) is a mistake.

I just fixed my problem by adding some unused bits at the end of the "embedded filesystem" area of my .nds file. Not very elegant, but it will do the trick for now.

Thanks for your help.

#2 Re: Support » GameInfo reading out of buffer » 2017-10-29 09:45:38

[x]  I understand that errors have been inconsistently handled by dumping registers, or trapping with the GDB server embedded in the emulator, but I am surprised that still more errors have been inconsistently handled in a 3rd way by terminating the emulator.

Especially, before starting to hack the code by adding some calls to emu_halt here and there, I was looking for wisdom from The Builders about why there might be that third way. If i understand your check-one post correctly,  there was no reason for not invoking something more elaborate than exit(), just that noone did it so far.

So, would there be a function name I should have a look at that could trap the GDB server instead of exit() ?

#3 Support » GameInfo reading out of buffer » 2017-10-27 19:44:05

PypeBros
Replies: 4

I encountered a weird panic message while developing new homebrew with desmume. I guess it means my program is accessing something (code?) out of the allowed cartridge area. What puzzles me is why it is killing the emulator so abruptly ?

I've seen other error condition that dumped some registers, and others that could be trapped with the GDB server embedded in the emulator. Nothing alike here? Just because noone has added it yet ? or is there any other reason ?

#4 Re: Technical » --load-type and --cflash-path » 2017-02-28 22:42:04

sounds fair. If I got bored of adding one more word on the command line, I'll just find a workaround on my own copy ;-)

Live long and prosper.

#5 Re: Technical » --load-type and --cflash-path » 2017-02-28 21:31:47

As far as I've been able to see, tryPatch ended up being called, with a NULL pointer instead of romdata.

#6 Technical » --load-type and --cflash-path » 2017-02-28 21:15:55

PypeBros
Replies: 4

Hello. I just realised that trying to use a dldi-function without --load-type=1 would end up in desmume crashing (version 0.9.11, ubuntu 16.04) because there would be no ROM image to patch. I thought it could be helpful to automate the setting of load_type to 1 as soon as a --cflash-* command is found on the list of arguments.

Good job on the emulator, btw.

#7 Re: Technical » gdbstub stalling randomly. » 2010-12-14 08:45:47

I noted that there were redundant unstalls in the handling of "s" instruction, for instance. arm_cpu->unstall being called, and then nds_debug_continue. It doesn't seem correct from my point of view, although chances are very *very* slim that it could trigger a fault.

I'll keep you updated if I find another oddity.

#8 Re: Technical » gdbstub stalling randomly. » 2010-12-13 19:54:05

Hello again.

I tried the fix you proposed for step_instruction_watch on a fresh checkout of the svn and it seems to fix the "hanging GDB stub" problem. It is very likely that the race condition only occur with specific OS as it will clearly be sensitive to things such as priority inversion policies or network stack implementation.

That being said, it seems that this freshly-rebuild desmume remains more sensitive to a "reverse" issue that makes "step" behave as "cont" from times to times. Could there be a similar race condition with the "post_exec_function" ? I haven't investigated that yet.

Thanks for your help anyway.

#9 Re: Support » Problem with automake / missing Makefile.in » 2010-12-13 14:11:49

You're about to experience a *lot* of troubles in Linux if you use VFAT for any other purpose but accessing files of a Windows former installation, btw.

#10 Re: Technical » gdbstub stalling randomly. » 2010-12-12 15:40:29

there are two breakpoints, the standard list of any number of breakpoints, and the "step_instr_addr". that may be reset automatically, but the user breakpoints couldnt be or else the debugger would be puny.

That would make sense, but I only see "Z0,<address>,2" commands flowing between the debugger and the stub, regardless of whether the address is the main() function where I set a breakpoint manually in GDB of the next instruction where the breakpoint has been inserted automatically to step-over a function call.

#11 Re: Technical » gdbstub stalling randomly. » 2010-12-12 13:33:06

I took some time yesterday to depict the whole picture... I take good note of your remarks, and I will try to come with a more convincing proof of what I believe to be the root cause. Just some quick back-to-back replies meanwhile:

I conclude that since desmume is sending S05 and GDB is ignoring it, that this is GDB's fault.

That might be jumping on conclusion: all the traces end up in a situation where 's' has been received, and 'S05' isn't emitted regardless of how long we wait.

i dont see what use that semaphore does when there is only one thread calling nds_debug_continue.

I'm not using semaphore as a critical section provider here, but rather as a synchronisation mechanism: it replaces the busy waiting loop by a sem_wait(arm9_unstalled); and the gdbstub "releases" the NDS main thread by a sem_post(arm9_unstalled). That may not be appropriate way to do for non-cli implementation of DESMUME, though, as the emulation thread will be suspended until the stub has received a *s*tep or *c*ontinue command.

when you say a series of 's' commands are sent, do you mean 1) they are sent as a batch in some large number? or 2) that each one of them runs and waits for gdb to get control back?

I mean 2). You could somehow stress your stub with a program that repeatedly sends "s" as soon as it received Sxx from the tested stub.

your comment is right:
#what I don't get here is that the reply is sent (indicateCPUStop sent) before NDS_debug_break() is also sent.
it is utterly wrong (...)

I see. I will try that fix to see whether it makes any other modification unnecessary.

if you are using gdb in asynchronous mode (...)

As far as I can tell, I'm not. My regular setup is to use DDD, but for the purpose of these very tests, I just used the bare arm-eabi-gdb without any tweaks or preference modifications.

it would be nice if you could confirm that the emulator core is not proceeding AT ALL (print out something each time an instruction executes)

The instrumented NDSSystem.cpp stall-cactching-loop looks like:

            //trap the debug-stalled condition
singleStep = false;
if (NDS_ARM9.stalled || NDS_ARM7.stalled) { 
      fprintf(stderr,"debug-stall condition met. driver@%p\n",driver);
    //(gdb stub doesnt yet know how to trigger these immediately by calling reschedule)
#ifdef __UNSTALL_WITH_SEMAPHORES__
      if (NDS_ARM9.stalled) sem_wait(&arm9_unstalled);
      if (NDS_ARM7.stalled) sem_wait(&arm7_unstalled);
      NDS_ARM9.stalled = NDS_ARM7.stalled = 0;
      nds_debug_continuing[0] = nds_debug_continuing[1] = true;
#else
      while((NDS_ARM9.stalled || NDS_ARM7.stalled) && execute)
      {
          driver->EMU_DebugIdleUpdate(); noop anyway :P
          nds_debug_continuing[0] = nds_debug_continuing[1] = true;
    }
#endif            
      fprintf(stderr,"un-stalled ^_^\n");
    }

    nds.cpuloopIterationCount++;
    sequencer.execHardware();
// ...

If anything had occurred out of the busy-waiting loop, I should have seen at least an "un-stalled" message on the trace. I used stderr exactly for that purpose.

#13 Re: Technical » gdbstub stalling randomly. » 2010-12-12 08:58:48

As far as I can tell from the GDB behaviour, btw, a sequence of "s" commands are sent to proceed through the next line if there are just "regular" instructions to be executed. register state and one memory transfer at PC are used to determine whether the next instruction is a jump or a branch. that allows the stub to keep ignoring about line numbers, etc.

When a branch is seen, the debugger automatically adds a new breakpoint past that instruction and uses a "continue" command. Afaik, breakpoints aren't persistent and should be reprogrammed everytime a STOP response has been sent by the stub.

#14 Re: Technical » gdbstub stalling randomly. » 2010-12-12 08:33:41

I got confirmation of my analysis. The problem is due to a race condition between the two activities
replacing "ARM9.stalled = ARM7.stalled = 0" by a "sem_post(arm_unstalled)" in NDS_debug_continue() seems to fix it (at least, it does on Ubuntu here), although I suspect another race condition may make the emulator switch to a "continue" state in an uncontrolled fashion.

#15 Re: Technical » gdbstub stalling randomly. » 2010-12-11 21:57:49

I have instrumented gdbstub so that it reports gdb requests and responses as well. A regular "step" request will look like:

<s
UNSTALL 0xa1054e0@200060c        # unstall_cpu, processPacket_gdb (gdb thread)
now resumed                # NDS_debug_continue(), processPacket_gdb (gdb thread)
un-stalled ^_^            # after loop (nds thread)
STALL 0xa1054e0@200060c            # stall_cpu() check_breaks_gdb|break_execution|step_instruction_watch|activateStub_gdb post-execution function (on NDS thread)
>S05
now breaking 9@200060c, 7@37ffab0    # NDS_debug_break() also in check_break ...
debug-stall condition met. driver@0x9da0348

but when things get locked, we instead have:

<s
UNSTALL 0xa1054e0@2000610
now resumed
un-stalled ^_^
STALL 0xa1054e0@200754c            # so the NDS thread has triggered the stub,
#  what I don't get here is that the reply is sent (indicateCPUStop sent) before NDS_debug_break() is also sent.

>S05                    # and the message has been sent.
# there is no "now breaking" message seen ... yet, it takes place in the same check_breaks_gdb
# (or the other one). So the reply is sent, but the
<g
>00000000 09710002 00407f02 24db0102 00000000 a83c000b 00000000 48960502
00407f02 24db0102 00000000 00000000 2d8a0202 103c000b 0f060002 0c060002
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003f000060
<s
UNSTALL 0xa1054e0@200754c            #armcpu :: unstall_cpu
now resumed                    # gdb thread : NDS_debug_continue
now breaking 9@200754c, 7@37ffab0        #NDSSystem :: NDS_debug_break
debug-stall condition met. driver@0x9da0348

My analysis here is that the gdbstub thread had the time to switch the "stalled" back to 0 before the "nds emulation" thread had the opportunity to enter the "wait stub" loop. It clearly only happens when the debugger replies quickly enough with a new "<s" request and it doesn't occur when a human has to type [ENTER] to proceed.
I haven't a clear idea of how to fix the situation yet.

PS : the output of svn diff of my repository and the elf file.

#16 Technical » gdbstub stalling randomly. » 2010-12-11 09:02:01

PypeBros
Replies: 16

Hello, everyone.

I've got some issues with code I recently ported to devkitarm 32 + libnds 1.4.8 and the only version of desmume that manage to run the code (I guess it's something with the FIFO support) is a version of desmume built out of the SVN release 3601. My problem is that it looks like this version stalls randomly when I use the gdb stub and use the "next" or "nexti" command.

I uploaded the troubling .nds file at http://139.165.223.2/~martin/scene/Appl … -buggy.nds . The NDS runs fairly fine and only has "logical" errors (such as background not showing up with some files and similar things that I'd like to investigate using DDD). I haven't tried yet to figure out since when the problem appeared, nor to what extent the problem appears on any DS programs.

I launch with e.g. desmume-cli AppleAssault.nds --gbaslot-rom=AppleAssault.nds --arm9gdb=9999 (under Linux), and then the GDB session would look like:

Reading symbols from /beetle/hobby/DS/dsgametools/trunk/AppleAssault/AppleAssault.elf...done.
(gdb) target remote localhost:9999
Remote debugging using localhost:9999
0x02000000 in _start ()
(gdb) break main
Breakpoint 1 at 0x20005fc: file /beetle/hobby/DS/dsgametools/trunk/AppleAssault/       
source/main.cpp, line 411.
(gdb) c
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x020005fa in main ()
    at /beetle/hobby/DS/dsgametools/trunk/AppleAssault/source/main.cpp:410
410     {
(gdb) n
main () at /beetle/hobby/DS/dsgametools/trunk/AppleAssault/source/main.cpp:414
414       MetaWindow mw;
(gdb) n
411       ge.prepare();
(gdb) n
412       ge.reganim(0);
(gdb) n
413       printf("PPP Team's runbox v 0.3 lite\n (c) sylvain 'pype' martin \n");
(gdb) n
414       MetaWindow mw;
(gdb) n

then the emulator is apparently stalled, gdb non-responding.

I got a few messages exchange with Zeromus already, before I find these forums. He f.i. suggested that

you should have better luck by attaching the gdb stub and letting it start the rom instead of starting the rom by unpausing desmume.

I can only assume that he was speaking about how to inspect desmume state from a second GDB, as I don't see how I could "let the gdb stub start the rom" otherwise.

As far as I can tell, desmume seems trapped into the following loop (in NDSSystem.cpp)

            //trap the debug-stalled condition
            #ifdef DEVELOPER
               singleStep = false;
               //(gdb stub doesnt yet know how to trigger these immediately by calling reschedule)
               while((NDS_ARM9.stalled || NDS_ARM7.stalled) && execute)
               {
=>             driver->EMU_DebugIdleUpdate();
                  nds_debug_continuing[0] = nds_debug_continuing[1] = true;
               }
            #endif

Both NDS_ARM have stalled==true and execute==true, if you ask. I proceed to some more analysis, and as far as I understand, this is a regular situation where NDS_ARM9.stalled should be cleared from the GDB stub thread that runs independently from this code. clearly, we could have use for a pthread condition or some other kind of IPC here so that there's no busy-waiting on the "emulation" thread. I suppose this is part of zeromus' plan when he says

the gdb stub is flaky and i will try to support it (...) but the code is a mess (...)

I still have to figure out what happens behind this "driver->EMU_DebugIdleUpdate()", since it looks not to do anything here. Although I was afraid that the lack of "volatile" on the .stalled fields would have led to the compiler optimizing the test away, but a disassembly of the generated desmume code shows that this isn't the root cause of the problem right now.

Any help, hints or guidance is welcome.

Board footer

Powered by FluxBB