[hatari-devel] Hatari patches for bitplane conversion

[Kåre Andersen]

On Wed, Jul 22, 2009 at 11:29 PM, Thomas Huth<huth at users.berlios.de> wrote:
> On Wed, 22 Jul 2009 22:43:11 +0300
> Eero Tamminen <eerot at users.berlios.de> wrote:
>
>> On Wednesday 22 July 2009, Kåre Andersen wrote:
>> > -int nFrameSkips;          /* speed up by skipping video frames */
>> > +int nFrameSkips=0;        /* speed up by skipping video frames */
>>
>> It's possible that because you explicitly set the variable, it goes
>> to a different section in the binary (.data instead of .bss)[1], but
>> that should not have any effect on it's value as globals are
>> automatically zeroed. (Apple documentation I referred in my earlier
>> mail already stated that .bss should be zeroed.)
>
> I agree with Eero here. I hardly can believe that the .bss is not
> initialized to zero on Mac OS X (it's a BSD/Unix based OS, and all such
> systems clear the BSS as far as I know).

Ok, talking to my guru gives the same answer: The C standard defines
that bss should be cleared. And Eero found the info that i could not
find, so I back down from this... Sorry for jumping the gun - again -
bad habit. I guess the fix was just too simple to be correct....

> So the real problem (a wrong memory access) might still persist, it's
> just not visible anymore since the variable has been moved to another
> location in memory.

I will try to track this down as best as I can tomorrow daytime.
Better get as much done as possible before holidays end....

>> Once we know where your compiler puts the nFrameSkips variable in BSS,
>> I could check whether e.g. any of the variables before or after it
>> could be written in a way that overwrites/corrupts nFrameSkips.
>
> For that you don't need the "gcc -S" output, but rather an
> "objdump -Drx hatari" of the whole executable (since the linker still
> might re-arrange things).
> Kåre, could you please create such an objdump of your executable to see
> which variables are placed right before the nFrameSkips variable?

Agreed, but since I have been messing with x86 assembly (urgh) all
day, optimizing my converters by looking at GCC output (with at least
theoretically some good improvements), I may as well go the whole
round and see what actually moves, put some guards in there and so on.
I guess i also need to delve deeper into your Xcodeproj, which is
converted from a very old 2.x format to the current 3.1 standard -
maybe there are some nasty switches generated there.

And since my efforts to get off the night shift seem to work fine, I
am dead tired now, so it will happen tomorrow. Patches and all.

Good night/morning :)

/Kåre