Memory issue ? [solved]

[Eke]

Hi,

does someone here have an idea why the exact same sourcecode, compiled with devkitppcr14+libogc20080228 and then compiled with devkitppcr12+libogc20070204, does not have the same behaviour when running on my GC ?

I mean, while testing a game in the last release of my emulator (genesis plus, compiled with last libogc), it freezed at some point... but the same game in the same version of the program but this time compiled with devkitppcr12+libogc20070204 does not

From an emulation point of view, it seems that the CPU interpreter is reading some bad opcode from ROM and is doing unexpected stuff. As the ROM image is stored in the Gamecube main RAM (5MByte of memory are allocated at init), I thought it could be some kind of memory issue...

What have been modified regarding memory that we should be aware of ? Could it be a compiler issue (previous version of gcc was 3.x) ? I am running out of idea so any help would be appreciated...

[WinterMute]

It's difficult to say without further information and, unfortunately, we don't really have the time to examine large projects in any detail. The issue is likely to be related to some code which is interpreted differently with the latest gcc version.

The first thing I'd do with a problem like this is to fix any warnings emitted by the build - often these indicate code that may be ambiguous and prone to misinterpretation. Sometimes this will "magically" fix bugs that can be difficult to track down.

Something I've noticed with gcc lately is that data alignment is becoming more important - misaligned accesses appear to be more likely to result in odd data turning up, especially when strict aliasing is enabled.

How are you allocating the 5meg buffer at init?

[Eke]

The first thing I'd do with a problem like this is to fix any warnings emitted by the build - often these indicate code that may be ambiguous and prone to misinterpretation. Sometimes this will "magically" fix bugs that can be difficult to track down.

I used -Wall and fixed all warnings I got (gcc 4.x.x seems more picky when messing with data types without casting)
but this changed nothing

Something I've noticed with gcc lately is that data alignment is becoming more important - misaligned accesses appear to be more likely to result in odd data turning up, especially when strict aliasing is enabled.

How are you allocating the 5meg buffer at init?

initially we use u8 *cart_rom = malloc(0x500000 +32) then doing some manual reallignment
I then changed this into the following declaration:
u8 cart_rom[0x500000] ATTRIBUTE_ALIGN (32);

I also added the -fno-strict-aliasing compilation option
but still have the issue

[WinterMute]

You can use memalign instead of trying to align pointers from malloc manually - that way you can free it directly if you need to instead of storing the original pointer.

Have you managed to narrow down the location of the fault any? Even finding out which source file is causing the problem can help a bit in finding what's going on.

-Wextra will switch on a few more warnings, just in case that turns up something more.

If you currently have -fomit-frame-pointer in your CFLAGS try removing that too, we've had some issues relating to that & I keep meaning to remove it from the examples/templates where it still exists.

Do you have access to USBgecko or a BBA? I've recently finished a windows build of Insight that I'll be issuing through the installer probably tomorrow. We have the gdb stub code working pretty well through either of those devices now.

[Eke]

-Wextra will switch on a few more warnings, just in case that turns up something more.

I got many warnings about : 'register' not being at beginning of declaration in cast.h and gu.h for libogc, is that serious doctor ?


seriously, the fault is very hard to track down (and no, I still haven't SD gekko yet) because the emulator is running normally with most games, I only found 3 games that produce unexpected emulation behaviour (I mean I have also done tests with a DOS port of the emulator, the same sourcecode compiled with djgpp & gcc 4.2.3 was working fine... same thing when I compile with the old devkitppc toolchain)...
I will try to trace the CPU interpreter execution to see when it is going wrong, I tried to disable/enable a lot of compiler options (even try to disable optimization completely) with no luck

I also tried to compare some of the assembler output files but it's too much work to deduce something

anyway, thanks for having taken some time to help me, if it is a compiler/code issue, there is nothing much you can do

[Eke]

some update: I reproduced the bugs with djgpp and gcc 4.2.3, so it's definitely not a libogc issue...
I also isolated the incriminated object file: it's the m68k core, which is part of the MAME project.

Indeed, if I compile the 68k emulation sourcecode (m68kxx.x) object files with gcc 3.x.x and compile the rest of my code with gcc 4.2.3, then link everything together with the new libogc, I got no issues
As soon as m68k**.o files are compiled with gcc 4.2.3, I got issues

I started to track down both 68k execution to find when they start to differ and why but it's hard task


edit: FIXED
it was indeed a compilator issue with emulated 68k instructions such as ADD (A1)+, A1
gcc 4.2.1 was interpreting the code in such way that post-increment was not properly done ...

technically, when writing something like:
A = A + oper(A) where oper(A) is a macro that modify the A value:

. gcc 4.2.1 will first store A value then add the result of oper(A) to the previously stored value
. gcc 3.x will first proceed oper(A) then increment the updated A value with the result of oper()

good to know