#81338 - Chris Holmes - Fri Apr 28, 2006 3:12 pm
I was digging through libnds, and I can't find the source for iprintf. I'm having a lot of problems with that particular function.. specifically, it's freezing Dualis for a lot of very simple print statements. I'm guessing that there's probably a buffer overflow or something like that in there, and I wanted to look into it.
Can someone point me to where I can actually find the source for that? I grepped through all the files in the libnds project and couldn't find it.
Thanks,
Chris
#81344 - wintermute - Fri Apr 28, 2006 4:12 pm
Can you supply some examples of simple print statements that freeze Dualis?
Does the code work on hardware?
Never assume that problems running code in emulators equates to problems with the code.
iprintf is provided by newlib - the C library used by devkitARM. Code in libnds (console.c) hooks into newlib to provide the actual output from the stdio functions.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#81345 - knight0fdragon - Fri Apr 28, 2006 4:20 pm
i had this problem too. by any chance did u rebuild libnds
_________________
http://www.myspace.com/knight0fdragonds
MK DS FC: Dragon 330772 075464
AC WW FC: Anthony SamsClub 1933-3433-9458
MPFH: Dragon 0215 4231 1206
#81347 - wintermute - Fri Apr 28, 2006 4:30 pm
| knight0fdragon wrote: |
| i had this problem too. by any chance did u rebuild libnds |
Exactly what problem did you have?
Did rebuilding cause the problem or fix it?
What source did you rebuild from?
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#81350 - Chris Holmes - Fri Apr 28, 2006 4:51 pm
I haven't tested this on hardware lately, but the code runs fine on my machine at home, but not the machine I'm running on here. I just got the latest version of devkitarm/libnds/libgba from sourceforge. I tried running the devkitpro updater, but it pulled down invalid tarballs. So, I downloaded the latest stable devkitarm and unzipped it, so I have a fresh build.
Anyway, what I'm doing is catching 10 reads from the touchpad that are different and summing up the move differences between each move (i.e. XSum += (touchPosition->X - LastX );
iprintf("XSum %d YSum %d", XSum, YSum ); // This freezes under Dualis
iprintf("XSum %04X YSum %04X", XSum, YSum ); // This does not freeze
For some reason, the first statement worked at home this morning. I think it might be something on this machine because iprintf, when the number is not zero, tends to freeze under Dualis on this machine.
Chris
#81364 - tepples - Fri Apr 28, 2006 7:10 pm
| Chris Holmes wrote: |
| iprintf("XSum %d YSum %d", XSum, YSum ); // This freezes under Dualis |
The common algorithm for converting decimal numbers to binary requires division, and if Dualis doesn't support an equivalent to the DS BIOS, then Dualis is incompatible with your toolchain and/or library.
EDIT for correctness
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
Last edited by tepples on Sat Apr 29, 2006 3:37 pm; edited 1 time in total
#81370 - Chris Holmes - Fri Apr 28, 2006 7:56 pm
Except it works under Dualis at home on an older devkitpro build and fails on this machine under Dualis with the latest devkitpro build. Therefore, it is not Dualis at fault.
Chris
#81380 - wintermute - Fri Apr 28, 2006 10:14 pm
| tepples wrote: |
| Chris Holmes wrote: | | iprintf("XSum %d YSum %d", XSum, YSum ); // This freezes under Dualis |
The common algorithm for converting decimal numbers to binary requires division, and if Dualis doesn't support the DS hardware division registers, then Dualis is incompatible with your toolchain. |
Incorrect.
1. The toolchain is a generic arm-elf compiler and knows nothing about the intended target hardware. Various linkscripts and crt0 files are provided for different targets.
2. libnds contains code which overrides the standard division routines with bios calls *not* code to use the division registers.
Dualis emulation of bios calls could potentially be at fault but I haven't experienced any trouble in that regard here.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#81382 - Chris Holmes - Fri Apr 28, 2006 10:28 pm
My point is just that the same code runs fine on Dualis on one machine and not another. That more or less exempts Dualis and the code from being the culprit of it not working.
I must have something setup wrong in my toolchain unless there is a bug in libnds somewhere. I don't understand how iprint can possibly fail though. I figure that whatever hooks it and reads it might be causing the problem. On one machine, everything is fine, but on the other, iprintf almost always freezes Dualis.
Do you have any idea of why that might happen?
Chris
#81385 - tepples - Fri Apr 28, 2006 10:44 pm
| Chris Holmes wrote: |
| My point is just that the same code runs fine on Dualis on one machine and not another. |
Are you sure that they're the same code? Have you tried computing the .nds files' md5sum?
If you're using different versions of devkitPro on the two machines, then you're probably using two different versions of libnbs. A later version of libnds may have more dependencies on (possibly unemulated) DS BIOS and DS hardware registers than an earlier version.
| Quote: |
| I must have something setup wrong in my toolchain unless there is a bug in libnds somewhere. |
If something works on a Game Boy Advance but fails on VisualBoyAdvance, then it is a bug in VisualBoyAdvance. Likewise, if something works on a Nintendo DS but fails on Dualis, then it is a bug in Dualis.
Or do you expect wintermute to make workarounds in libnds for emulator bugs?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#81386 - Chris Holmes - Fri Apr 28, 2006 10:58 pm
| Quote: |
| Are you sure that they're the same code? Have you tried computing the .nds files' md5sum? |
It's all my code and it's coming out of my subversion repository. I'm sure that all of my code is the same.
| Quote: |
| Or do you expect wintermute to make workarounds in libnds for emulator bugs? |
My point is that there is a bug somewhere and I would appreciate help tracking it down. I don't care where the bug is. I don't care if it's a Dualis bug or a libnds bug or something wrong with my setup.
The minute I said Dualis, everyone started blaming it immediately. Dualis runs one build fine and the other build does not. Maybe the newer/newest release of libnds changed something that Dualis isn't implementing correctly. Maybe libnds has a legitimate bug that Dualis is executing faithfully. Please don't get defensive about it.
Now, I dug through console.c a little, and it didn't make much sense to me. I'm not sure how iprintf links into it, so I can't start tracing the code.
Where do I start?
Chris
#81387 - tepples - Fri Apr 28, 2006 11:07 pm
| Chris Holmes wrote: |
| Quote: | | Are you sure that they're the same code? Have you tried computing the .nds files' md5sum? |
It's all my code and it's coming out of my subversion repository. I'm sure that all of my code is the same. |
All of the source code, or all of the binary code? All of your code, or all of wintermute's code?
| Quote: |
| Quote: | | Or do you expect wintermute to make workarounds in libnds for emulator bugs? |
My point is that there is a bug somewhere and I would appreciate help tracking it down. I don't care where the bug is. I don't care if it's a Dualis bug or a libnds bug or something wrong with my setup. |
If a behavior differs in any way between the Nintendo DS and Dualis, then this is a Dualis bug.
| Quote: |
| The minute I said Dualis, everyone started blaming it immediately. |
Because the current emulators are notorious for being inaccurate as libnds gains features that connect to different parts of the DS hardware.
| Quote: |
| Maybe the newer/newest release of libnds changed something that Dualis isn't implementing correctly. |
This is in fact the case.
| Quote: |
Now, I dug through console.c a little, and it didn't make much sense to me. I'm not sure how iprintf links into it, so I can't start tracing the code.
Where do I start? |
Go look for a function called __divsi3().
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#81396 - Chris Holmes - Fri Apr 28, 2006 11:45 pm
So, what you're saying is that N versions ago, libnds changed to use hardware division and that Dualis doesn't support that. Therefore,
for(int i = 0; i < 100; i++ ) {
iprintf("%d", i);
}
should fail on Dualis for all libnds after some version M until such a time as Dualis implements the hardware divide registers?
That would explain why 0 prints but larger numbers (should be greater than 9) would fail.
Correct?
Chris
#81412 - ecurtz - Sat Apr 29, 2006 1:48 am
| wintermute wrote: |
| 2. libnds contains code which overrides the standard division routines with bios calls *not* code to use the division registers. |
Why is that? Isn't the overhead of making the bios call huge compared to using the division registers, even if you wait on the busy flag? (Just curious, I'm only using divf32, which seems to use the registers.)
#81417 - DekuTree64 - Sat Apr 29, 2006 2:05 am
[quote="ecurtz"]Isn't the overhead of making the bios call huge compared to using the division registers, even if you wait on the busy flag?[quote]
Yep. Overriding / to use the registers is slightly dangerous though, because you don't really realize you're using them. An interrupt can fire off while it's waiting on the busy flag, and if that interrupt does any divides, then when you exit back out, the value you were waiting on is no longer there. Leads to some very random crashes :)
If you want to use the divider in an interrupt, be sure to read out the division regs first and restore them before returning.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#81426 - knight0fdragon - Sat Apr 29, 2006 3:01 am
my problem was when i rebuilt the source code provided, i have this topic somewhere else http://forum.gbadev.org/viewtopic.php?t=9119&highlight=
_________________
http://www.myspace.com/knight0fdragonds
MK DS FC: Dragon 330772 075464
AC WW FC: Anthony SamsClub 1933-3433-9458
MPFH: Dragon 0215 4231 1206
#81428 - wintermute - Sat Apr 29, 2006 3:31 am
| Chris Holmes wrote: |
So, what you're saying is that N versions ago, libnds changed to use hardware division and that Dualis doesn't support that. Therefore,
|
What he's saying is wrong
libnds started using the bios divide function from the 20050804 release - that's August 2005.
| Quote: |
for(int i = 0; i < 100; i++ ) {
iprintf("%d", i);
}
should fail on Dualis for all libnds after some version M until such a time as Dualis implements the hardware divide registers?
|
No, libnds does NOT use the hardware divide registers.
I've been playing around a bit with some code that appears to cause problems for Dualis, your problem appears similar to the one in this thread http://forum.gbadev.org/viewtopic.php?t=9359 .
My most recent changes to devkitARM broke the current Dualis quite badly in that everything I attempted to run would crash Dualis. I've since provided mic with some test code that breaks and he's fixed some of the issues.
With my latest iteration of the toolchain & library ( what will be devkitARM r19 and the next libnds release) the code in that thread crashes. The same code runs fine on hardware, no$gba and DeSmuME. I've mailed it to mic so hopefully it will help him find the problem.
In short, the bug probably lies with Dualis so try one of the other emulators. My personal preference would be no$gba although the current iteration requires the bios images to be present.
http://nocash.emubase.de/gba.htm
shareware debugger version - I can't recommend this highly enough if you can follow asm. The full source level version is just a bit beyond the budget of hobbyists.
http://nocash.emubase.de/gba-dev.htm
A bios dumper for gbamp
http://pepsiman.pwp.blueyonder.co.uk/bios_dumper.nds
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#81500 - Chris Holmes - Sat Apr 29, 2006 4:01 pm
| Quote: |
| In short, the bug probably lies with Dualis so try one of the other emulators. My personal preference would be no$gba although the current iteration requires the bios images to be present. |
Well, I can follow assembly, so I'll try no$gba as well as the other ones.
Hopefully Dualis will be patched up as well, but until then I'll try the other ones.
Thanks much for your help!
Chris
#81510 - knight0fdragon - Sat Apr 29, 2006 5:00 pm
the bug is most likely in dualis, becuase even for me it works on DS, not dualis. What i find weird though is even if i recompile the stable release, dualis will not use console functions
_________________
http://www.myspace.com/knight0fdragonds
MK DS FC: Dragon 330772 075464
AC WW FC: Anthony SamsClub 1933-3433-9458
MPFH: Dragon 0215 4231 1206
#81626 - Chris Holmes - Sun Apr 30, 2006 6:25 pm
Well, no$gba crashes immediately and DesMume doesn't display the 3D stuff at all. Also, no$gba claims to not handle any of the DS 3d stuff yet, so there's no point in bothering with that emulator for the time being.
Hopefully Dualis will start working again soon, but until then, I'm just going to write a custom print statement that will handle printing values for me. Besides, it won't hurt to have a custom overload to print v16 values anyway. I doubt anyone else wants it, but I'll post the code if there are any requests.
Chris
#82214 - Chris Holmes - Thu May 04, 2006 4:24 pm
This issue is resolved as of the latest build of Dualis.
Chris