Re: Issue with my patch to add ARM-uclibc support to LuaCoco

[Mike Pall <mikelu-0704@...>]

Hi,

Zachary P. Landau wrote:
> I recently created a patch to LuaCoco to add ARM support under uClibc.
> I'm having a problem and I was hoping someone might be able to help
> get me on the right track.

Oh, nice! Be sure to send it to me when it's finished. I'll
probably release an upgrade to Coco soon, so it patches cleanly
against Lua 5.1.2 (otherwise no functional changes).

> I looked at every case where I call coroutine.create and
> coroutine.wrap, and in none of those cases do I pass -1 for a
> cstacksize, so I would expect every coroutine to be a coco one.

Do you create any coros from C? You need to use lua_newcthread()
and not lua_newthread().

> Also, right before I call the offending yield I print the value
> of coroutine.cstacksize() and it gives me 61440, which I would
> expect.

Err, that function returns the _default_ stacksize for newly
created coros (and not any info about a particular coro).

> So at this point it thinks it is a coco coroutine as well.  But when
> the code gets to luai_userstateyield() in lua_yield(), the LHASCOCO
> macro returns false and so we try to do a non-coco yield instead.

Well, that part of the code is a one-liner. So I don't think it's
the culprit. Either the coroutine does not have a C stack to
begin with (see above) or the particular field holding the status
has been corrupted (trace modifications to it with a debugger).

> Here is the code I used for adding ARM/uclibc support.  Perhaps the
> issue lies in there.  Specifically, I am not sure why COCO_STACKADJUST
> is needed in some cases and if I need it.

Have a look at the COCO_FILL() macro. Basically you want the
stack pointer to start at the right slot below the aligned end of
the stack. This depends on the way the setjmp() function is
implemented. E.g. note the subtle differences between the Linux
and the BSD implementations of setjmp() on x86. You also need to
keep clear of any save-areas which are located above the stack
pointer and may be used by the callee (usually only if compiled
_without_ optimization -- so, test that, too).

I guess the only way to find out is to carefully read the
relevant ABI, the assembler code for setjmp() and to step through
some example function epilogues. Ensure that the stack pointer is
properly aligned when calling successive C functions, too.

Note that it may be easier (and more portable across library
versions) to add some inline assembler code than patching
setjmp() buffers. See the x86 and the MIPS entries.

Bye,
     Mike