xine, ppc and illegal instructions

[Bill Fink]

> On Sun, 1 Apr 2001, Kevin B. Hendricks wrote:
>
> Hi,
>
> couple of  things:
>
> - was the shared library loaded by dlopen properly built with -fPIC or -fpic?

I assume so.  It's Franz Sirl's latest 2.1 glibc RPM.

> - could there be a cache flushing bug?  When run in gdb if you set some
> breakpoints in the shared library, it will flush the icache (to make sure the
> breakpoint gets flushed out of data cache and any preloaded instruction are
> thrown away) this in turn seems to "fix" the cache flush problem if one
> exists.

That makes sense to me.

> - can you set ulimit -c unlimited and generate a core file from xine
>   and post the resulting backtrace.
>
>   If it looks empty, try the following:
>   x/20i $lr -32
>   in gdb just in case the problem was a branch out into the weeds

I was never able to get a core dump.  My coredumpsize is unlimited.
Earlier in the xine code, I could force a core dump by doing a "*0 = 1"
before the first call to pthread_create, but I couldn't get a core dump
by doing the same thing right after that call.

> (if we are lucky lr will have the return address so that we can
> possibly see at least where the bad branch comes from).  One way to get
> an illegal instruction is to follow a calculated branch into the weeds
> (happens sometimes in some C++ code during tailcalls when compiled above -O0).

As reported in my previous message, it's now working using the latest
BenH kernel (2.4.3 final) instead of the Paulus kernel (2.4.3-pre8) I
was previously trying with, so I'm happy.

						-Thanks

						-Bill


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/