Re: [MiNT] libgem16: vs_color

[Eero Tamminen <oak@helsinkinet.fi>]

Hi,

On Monday 18 January 2010, Vincent Rivière wrote:
> Helmut Karlowski wrote:
> > I tried a simple prog to simulate this, but I have no libc16, and the
> > normal one had even pointers.
>
> First, if I read again your first post, the main problem is that you
> discovered the stack variables are on odd addresses. If this is really
> true, it is a very bad thing, and may be the cause of your other
> problems.
>
> Several remarks:
>
> 1) The vs_color() disassembly has been proof-readed by several
> programmers, and it seems to be good.
>
> 2) You put traces using BLOG. If I'm not wrong, BLOG is actually
> bootlog() and uses vsprintf(). Since you don't have a libc16, where does
> your vsprintf() come from ? Beware to never mix mshort/mlong libraries...
> Link using "-Wl,-t" to see where what you link come from.
>
> 3) I have just learned that the 68020+ allow word and long access on odd
> addresses. Can the stack be on an odd address, too?

What the TOS ABI says on this?  Or GCC expectations on the Atari function
call ABI conventions?  If GCC (in some gcc version used to compiled some of
the code linked to this program) does this assumption, it can with
optimizations do certain assumptions about alignment and optimize out
aligning variables etc.  And if things as result are not aligned as
expected, this can then cause buffer over or underwrites (on 020+
where such things don't cause an exception like on 68000).


	- Eero

> If it is the case, 
> the stack may have been on an odd address for a long time... You should
> trace the addresses of some local variable in the caller of vs_color(),
> and its caller... until you find where the stack becomes odd.
>
> 4) Be sure your gemlib has the latest patches for the clobber lists. A
> register not cleanly backuped can certainly cause this kind of problem.
>
> 5) The values of your pointers are at more than 62 MB from the start of
> the FastRAM, does this look good ? Could we face an out of memory ?
>
> 6) Do we face a stack overflow ? It can produce this kind of problem.
>
> 7) Beware of a6... It is that damn frame pointer (when used as is). If it
> gets corrupted (by some gem call ?) the stack value will be corrupted,
> too.
>
> 8) If a local variable overflows (array out of bouts, etc), it can alter
> a backuped stack value, and produce an odd stack.
>
> Well, a lot of questions... But I'm pretty sure the real problem is not
> at the top of vs_color().