init getting SIGILL (yet another one)

[Guennadi Liakhovetski]

Hi

Trying to get Android 4.0 to run on a Cortex-A8 SoC I've built a
distribution from sources, using the wingray configuration, because it
does not use NEON commands. Tried both the mainline 3.3-rc2 kernel with
enabled Android drivers and the common branch of the android kernel
git-tree. In both cases I'm getting a kernel panic "attempted to kill
init." Trying to run init under gdb in a booted (with the same kernel)
shall I caught a SIGILL in the beginning of __vfprint() in libc at the
vpush instruction. Any ideas?

BTW, while investigating this I noticed, that libc objects (e.g.,
vfprintf.o) are built with both -fno-strict-aliasing and -fstrict-aliasing
options, which is, probably, not really desired?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

[Guennadi Liakhovetski]

[Guennadi Liakhovetski]

Hi again

On Tue, 7 Feb 2012, Guennadi Liakhovetski wrote:

> Hi
>
> Trying to get Android 4.0 to run on a Cortex-A8 SoC I've built a
> distribution from sources, using the wingray configuration, because it
> does not use NEON commands. Tried both the mainline 3.3-rc2 kernel with
> enabled Android drivers and the common branch of the android kernel
> git-tree. In both cases I'm getting a kernel panic "attempted to kill
> init." Trying to run init under gdb in a booted (with the same kernel)
> shall I caught a SIGILL in the beginning of __vfprint() in libc at the
> vpush instruction. Any ideas?

Ok, I've resolved this one, was a misconfigured kernel. OTOH

> BTW, while investigating this I noticed, that libc objects (e.g.,
> vfprintf.o) are built with both -fno-strict-aliasing and -fstrict-aliasing
> options, which is, probably, not really desired?

this still is something that wants to be fixed. As well as the next issue:
untracked Makefile dependencies. Changing flags in one of platform's *.mk
files, that affect various parts of the Android build doesn't force a
recompilation. E.g., changing the ARCH_ARM_HAVE_TLS_REGISTER variable is
ignored.

BTW, is it a good place to discuss or report such problems here or should
I report them directly to Google's bug-tracking?