Strange libc issues (Debian)
- I'm trying to port a program of mine to run on my NSLU2 running Debian Etch;
the program is Spey, an email greylisting proxy.
Spey uses coroutines a lot, and this is where I'm having the difficulties.
Firstly, Spey's native coroutines implementation use
makecontext()/getcontext()/etc, which the ARM glibc lacks. I managed to get
round this by adding support for libpcl, which is a portable coroutine library
that abuses signal handlers (apparently in a standards compliant way) to
achieve the stack-switching trick.
There are two main issues I'm seeing:
Firstly, if I try to use any code that references pthreads, then the
application dies. This includes malloc(), if the application has pulled in
libpthread. Note that it's not necessary to *use* threads --- the mere
presence of the library causes things to go wrong. In this case, my
application uses libsqlite; since Debian's version of this has been built with
threading support, trying to use libsqlite causes libpthread to be implicitly
pulled in. Boom.
(This is disturbingly similar to Debian bug #339827, which I filed --- and
they fixed --- back when I was having exactly the same issue on i386. This was
caused by Linuxthreads not coping with coroutines using stacks not owned by
Linuxthreads. More modern threading libraries, such as the one used on i386
2.6 kernels, don't have this restriction. Does ARM Linux use Linuxthreads as
After compiling my own copy of Sqlite without threading support, the second
problem has become apparent; it seems that if I throw a C++ exception from
inside a coroutine --- i.e., on a user stack --- then instead of the exception
being caught by the most-recent exception frame on the user stack, it's
instead caught by the exception frame on the main application stack. In other
words, throwing an exception inside a coroutine will completely bypass all the
exception handlers inside the coroutine and instead jump right out to my main
I have identical code that compiles on both i386 and ARM that behaves
differently, manifesting this problem.
I suspect that the correct thing to do now is to try and come up with a
minimal example and file another Debian bug report. However, in the mean time,
I'd very much like a workaround --- Spey forms a major part of my
spam-filtering arsenal, and until it works I can't use it.
Can anyone with better ARM-fu than me suggest (a) why this is happening, and
(b) what I can do to stop it?
+- David Given --McQ-+ "Gaping from its single obling socket was
| dg@... | scintillating, many fauceted scarlet emerald..."
| (dg@...) | --- Jim Theis, _The Eye of Argon_ (spelling
+- www.cowlark.com --+ original)