Re: [MiNT] libgem16: vs_color

["Helmut Karlowski" <helmut.karlowski@ish.de>]

Am 18.01.2010, 22:57 Uhr, schrieb Vincent Rivière  
<vincent.riviere@freesbee.fr>:

> 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.

This was directly from XaAES, where no libc16 is required, as you might  
know.

> 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 ? 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.

Yes - thanks! ;)

But the 000-version also seems not to work (not 100% sure yet).

> 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.

The inlined code isn't used - at least for VDI, and XaAES doesn't do any  
AES-traps AFAIK.
The code that's used does only backup one reg, I think.

> 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 ?

Where do you know the 62MB? And the same runs on a TT with 24MB or similar.

> 6) Do we face a stack overflow ? It can produce this kind of problem.

This would be one last resort, but I think this is unlikely, because the  
stack isn't much used at that stage (ca. 4 calls) and I don't know if the  
stack can be set for xaaes at all.

> 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().

No. But it's called from two very different places, both fail.

--
Helmut Karlowski