Can't run Android's executables...

[andro...@gmail.com]

Hi,

I'm using Qualcomm 8250 platform, which comes with a linux kernel
which has android related patches. So I thought everything will be
easy, just put system.img, userdata.img and ramdisk.img to its root
filesystem, then I can try android!

But things usually not goes that way. I realized that the executables
in system.img and ramdisk.img can't be run under Qualcomm's linux bsp.

For example, the init in the ramdisk.img, the sh, toolbox in the
system.img /bin directory. Those static linked executable can't be run
under Qualcomm's linux. The result was

$ ./init
segmentation fault
$ bin/ls
ash: ls not found

I am wondering why this happened? Is this because the toolchain is
different? Should I use QCOM's toolchain to compile whole android src
tree?

Regards,
Mac

[kernel gick]

You better use Android toolchain to compile qualcomm build. Which tool chain r u using for compiling qualcomm build?

Thanks
Gicky

[Wang Mac]

Actually it's from http://www.codesourcery.com/, QCOM is using version 2006q3-27.

Which's config..

------------------------

mac@acer-desktop:~/QCOM/tools/arm-2006q3/bin$ ./arm-none-linux-gnueabi-gcc -v

Using built-in specs.

Target: arm-none-linux-gnueabi

Configured with: /scratch/paul/arm/src/gcc-2006q3/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-none-linux-gnueabi --enable-shared --enable-threads --disable-libmudflap --disable-libssp --disable-libgomp --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --prefix=/opt/codesourcery --enable-languages=c,c++ --enable-symvers=gnu --enable-__cxa_atexit --with-versuffix='CodeSourcery ARM Sourcery G++ 2006q3-26' --with-pkgversion='CodeSourcery ARM Sourcery G++ 2006q3-26' --with-bugurl=mailto:arm...@codesourcery.com --disable-nls --with-sysroot=/opt/codesourcery/arm-none-linux-gnueabi/libc --with-build-sysroot=/scratch/paul/arm/install/arm-none-linux-gnueabi/libc

Thread model: posix

gcc version 4.1.1 (CodeSourcery ARM Sourcery G++ 2006q3-26)

------------------------

Although the gcc version is older than Android toolchain, it generates armv6 code instead of armv5 generated by android toolchain.

Did android's toolchain be modified somewhere so you suggest to use this one?

Thanks,

Mac

2008/11/12 kernel gick <kernel...@gmail.com>

[kernel gick]

Although the gcc version is older than Android toolchain, it generates armv6 code instead of armv5 generated by android toolchain.

Did android's toolchain be modified somewhere so you suggest to use this one?

Thanks,

Mac

If MSM8250 can run armv5 code(qualcomm kernel) generated by android toolchain, it will be easy to run android code on it, but if you try replace android toolchain inside build with codesourcery  toolchain, you can expect lot of troubles while compiling android build.

Thanks
Gicky

[David Turner]

As far as I remember, Android toolchain uses the aapcs ABI, the CodeSourcery one uses aapcs-linux and they are not binary compatible.
There are other differences that might affect the build (e.g. in C++ support options).

As already stated previously, you should *really* use the Android-provided toolchain to build Android binaries...

[kernel gick]

I am porting android to armv7 architecture, and unable to compile linux kernel with android toolchain, as it can not generate code for armv7.
  And android toolchain compiled binaries are not running on above armv7 architecture. How can we resolve it?

Thanks
Gicky

[kernel gick]

I am porting android to armv7 architecture, and unable to compile linux kernel with android toolchain, as it can not generate code for armv7.
  And android toolchain compiled binaries are not running on above armv7 architecture. How can we resolve it?

Thanks
Gicky

On Wed, Nov 12, 2008 at 5:57 PM, David Turner <di...@android.com> wrote:

[Anson]

does you porting  android ashm driver?

[Wang Mac]

I believe 8250 can run armv5 code generated by android toolchian, because I wrote a simple "hello world" C program compiled by android toolchain can be run on 8250 platform. The way I did was,

1. cd ~/mydroid

2. prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/arm-eabi/bin/gcc test.c

3. copy a.out to my platform, and try to run it

4. the result is correct!

But I also try to compile my test.c with android's standard make way, the generated executable can be run on 8250 platform.

1. cd ~/mydroid/system/core

2. cp -a init test

3. cd test

4. edit Android.mk

LOCAL_SRC_FILES:= test.c

LOCAL_MODULE:= test

5. mm (from envsetup.sh)

6. it will generate test in ~/mydroid/out/target/product/generic/root

7. I tried to run the generated test on my platform, it produces segmentation fault (core dumped) as init did.

So I guess the reason may be the linked libraries or it's thumb code?

Regards,

Mac

2008/11/12 kernel gick <kernel...@gmail.com>

[Wang Mac]

I believe 8250 can run armv5 code generated by android toolchian, because I wrote a simple "hello world" C program compiled by android toolchain can be run on 8250 platform. The way I did was,

1. cd ~/mydroid

2. prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/arm-eabi/bin/gcc test.c

3. copy a.out to my platform, and try to run it

4. the result is correct!

But I also try to compile my test.c with android's standard make way, the generated executable can be run on 8250 platform.

1. cd ~/mydroid/system/core

2. cp -a init test

3. cd test

4. edit Android.mk

LOCAL_SRC_FILES:= test.c

LOCAL_MODULE:= test

5. mm (from envsetup.sh)

6. it will generate test in ~/mydroid/out/target/product/generic/root

7. I tried to run the generated test on my platform, it produces segmentation fault (core dumped) as init did.

So I guess the reason may be the linked libraries or it's thumb code?

Regards,

Mac

2008/11/12 kernel gick <kernel...@gmail.com>

[Sean McNeil]

The results below do not indicate armv5 support. It could and most
likely is not generating armv5 instructions for a simple "hello world"
program. You would have to do something more elaborate and check the
assembly.

Wang Mac wrote:
> I believe 8250 can run armv5 code generated by android toolchian,
> because I wrote a simple "hello world" C program compiled by android
> toolchain can be run on 8250 platform. The way I did was,
> 1. cd ~/mydroid
> 2. prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/arm-eabi/bin/gcc test.c
> 3. copy a.out to my platform, and try to run it
> 4. the result is correct!
>
> But I also try to compile my test.c with android's standard make way,
> the generated executable can be run on 8250 platform.
> 1. cd ~/mydroid/system/core
> 2. cp -a init test
> 3. cd test
> 4. edit Android.mk
> LOCAL_SRC_FILES:= test.c
> LOCAL_MODULE:= test
> 5. mm (from envsetup.sh)
> 6. it will generate test in ~/mydroid/out/target/product/generic/root
> 7. I tried to run the generated test on my platform, it produces
> segmentation fault (core dumped) as init did.
>
> So I guess the reason may be the linked libraries or it's thumb code?
>
> Regards,
> Mac
>
> 2008/11/12 kernel gick <kernel...@gmail.com

> <mailto:kernel...@gmail.com>>

[Rupesh Gujare]

Can you explain what test, we can do ? I am ready to to send back results.

Regards,
Rupesh

[Sean McNeil]

Hi Rupesh,

I guess a simple program that uses __builtin_clz() would be enough.

[Rupesh Gujare]

Sean,
  I am new to toolchain arena, can you tell what is meant by __builtin_clz() ?
Also if i try to compile with android toolchain, I am not ablr to complile code.
I am getting error like this:-

[rupesh@ws121 android]$ ./prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/arm-eabi/bin/gcc ~/workspace/hello.c
gcc: error trying to exec 'cc1': execvp: No such file or directory

Regards,
Rupesh

[Rupesh Gujare]

I mean how a test program can test __builtin_clz() instruction ?

[Sean McNeil]

__builtin_clz() is a built in function understood by the compiler that
generates the assembly instruction "clz". The error you reported seems
to indicate your compiler isn't complete.

[Rupesh Gujare]

I am just using toolchain that comes with android build, do you want say, its having problem with prebuild toolchain? My development machine runs Ubuntu .

[Wang Mac]

Hi Sean,

I tried __builtin_clz() test. It can be run and the results are correct on my QCOM8250 board.

Basically QCOM8250 supports armv7 instruction set, it's not surprising that it can execute armv5 inst.
I mentioned armv6 and armv5 toolchain before is because I don't want to "downgrade" the toolchain. Right now I want to make them co-exist. Using qcom's toolchain to compile kernel while using android's toolchain to compile android binaries, since qcom is also toolchain sensitive(it specifically said to use THAT version of codesourcery toolchain).

What I'm wondering right now is why android's static linked executables can't run on my platform.
Now I have new clue, but I don't know how to interpret it.

Below are the results I ran strace clz_test (clz_test is the clz test program), seems quite normal.
====================
# strace /mnt/clz_test
uname({sys="Linux", node="192.168.0.100", ...}) = 0
brk(0)                                  = 0x80000
brk(0x80c70)                            = 0x80c70
syscall_983045(0x80430, 0x7db20, 0, 0x10, 0x80430, 0x7e4cc, 0x7e7d0, 0xf0005, 0x28, 0x8, 0x4, 0x10, 0, 0xbe966b48, 0x11b58, 0x8874, 0x60000010, 0x80430, 0, 0, 0, 0xda4c, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = 0
brk(0xa1c70)                            = 0xa1c70
brk(0xa2000)                            = 0xa2000
fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40000000
write(1, "__builtin_clz test: 18\n", 23__builtin_clz test: 18
) = 23
...
====================

Below are the results I ran strace init, stuck at syscall_983045()
====================
# strace /mnt/init
gettid()                                = 696
syscall_983045(0xbebf5d14, 0, 0x40, 0, 0xbebd6000, 0xbebf5e50, 0xbebf5e14, 0xf0005, 0, 0, 0, 0, 0, 0xbebf5cf8, 0x1209b, 0x1790c, 0x60000010, 0xbebf5d14, 0, 0, 0, 0xda4c, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV (core dumped) +++
Process 696 detached
====================
1. I don't know what syscall_983045() is, why it has no reasonable name.
2. I noticied the first parameter value is not reasonable, seems it should be an address? Compare to the value I ran clz_test, 0xbebf5d14 is too large.

Any suggestions? Thanks!

Regards,
Mac

2008/11/13 Sean McNeil <seanm...@gmail.com>

[Sean McNeil]

Oh, I see...

Does your target have support for a TLS register? Google stubbornly
won't change the code that fetched the TLS to use the function (which
works fine with or without register store). Instead, they read the high
memory address. You can either use my patch to call the function
instead, or you can configure your kernel to use the high-mem address
instead of register.

Wang Mac wrote:
> Hi Sean,
>
> I tried __builtin_clz() test. It can be run and the results are
> correct on my QCOM8250 board.
>
> Basically QCOM8250 supports armv7 instruction set, it's not surprising
> that it can execute armv5 inst.
> I mentioned armv6 and armv5 toolchain before is because I don't want
> to "downgrade" the toolchain. Right now I want to make them co-exist.
> Using qcom's toolchain to compile kernel while using android's
> toolchain to compile android binaries, since qcom is also toolchain
> sensitive(it specifically said to use THAT version of codesourcery
> toolchain).
>
> What I'm wondering right now is why android's static linked
> executables can't run on my platform.
> Now I have new clue, but I don't know how to interpret it.
>
> Below are the results I ran strace clz_test (clz_test is the clz test
> program), seems quite normal.
> ====================
> # strace /mnt/clz_test

> uname({sys="Linux", node="192.168.0.100 <http://192.168.0.100>", ...}) = 0

> <mailto:seanm...@gmail.com>>

> > <mailto:kernel...@gmail.com <mailto:kernel...@gmail.com>>>

[Wang Mac]

WOW, you've said a lot things I don't familiar with.
I checked the qcom kernel config, it has CONFIG_HAS_TLS_REG=y.
Do you mean I should disable it?

And it seems that you've contributed a lot of patches (I googled), could you please tell me where is your main patches resource. (openmoko? or where?). I'll try it...

Thanks,

[Sean McNeil]

Yes, that is exactly the config you should turn off. I've submitted my
changes, but been a little too busy to respond to comments and fix
issues. Changes that aren't accepted will be hosted somewhere, but I
don't have them up anywhere at the moment. Only posted to the devel list
at openmoko.org.

Wang Mac wrote:
> WOW, you've said a lot things I don't familiar with.
> I checked the qcom kernel config, it has CONFIG_HAS_TLS_REG=y.
> Do you mean I should disable it?
>
> And it seems that you've contributed a lot of patches (I googled),
> could you please tell me where is your main patches resource.
> (openmoko? or where?). I'll try it...
>
> Thanks,
> Mac
>
> 2008/11/13 Sean McNeil <seanm...@gmail.com

> <mailto:seanm...@gmail.com>>

> > <mailto:seanm...@gmail.com <mailto:seanm...@gmail.com>>>

[Wang Mac]

It seems that CONFIG_HAS_TLS_REG can't be disabled while "Support ARM V7 processor" is selected. I need to try your patches... :P

2008/11/13 Wang Mac <andro...@gmail.com>

[Sean McNeil]

Wang Mac wrote:
> It seems that CONFIG_HAS_TLS_REG can't be disabled while "Support ARM
> V7 processor" is selected. I need to try your patches... :P

OK. You need in bionic,

diff --git a/libc/include/sys/tls.h b/libc/include/sys/tls.h
index d59f1c3..9053f7f 100644
--- a/libc/include/sys/tls.h
+++ b/libc/include/sys/tls.h
@@ -70,7 +70,8 @@ extern int __set_tls(void *ptr);

/* get the TLS */
#ifdef __arm__
-# define __get_tls() ( *((volatile void **) 0xffff0ff0) )
+typedef void* (__get_tls_t)(void);
+static const __get_tls_t* __get_tls = (const __get_tls_t *)0xffff0fe0;
#else
extern void* __get_tls( void );
#endif

And here is a hacked (aka incorrect) patch for frameworks/base:

diff --git a/opengl/libGLES_CM/gl_wrapper.cpp
b/opengl/libGLES_CM/gl_wrapper.cpp
index 5da4f9a..21c751c 100644
--- a/opengl/libGLES_CM/gl_wrapper.cpp
+++ b/opengl/libGLES_CM/gl_wrapper.cpp
@@ -616,7 +616,7 @@ void glVertexPointerBounds(GLint size, GLenum type,
// Actual GL wrappers
//
----------------------------------------------------------------------------

-#if __OPTIMIZE__ && defined(__arm__) && !defined(__thumb__) &&
!USE_SLOW_BINDIN
+#if 0 && __OPTIMIZE__ && defined(__arm__) && !defined(__thumb__) &&
!USE_SLOW_B

#define API_ENTRY(_api) __attribute__((naked)) _api
#define CALL_GL_API(_api, ...) \


>
> 2008/11/13 Wang Mac <andro...@gmail.com <mailto:andro...@gmail.com>>

>
> WOW, you've said a lot things I don't familiar with.
> I checked the qcom kernel config, it has CONFIG_HAS_TLS_REG=y.
> Do you mean I should disable it?
>
> And it seems that you've contributed a lot of patches (I googled),
> could you please tell me where is your main patches resource.
> (openmoko? or where?). I'll try it...
>
> Thanks,
>
> Mac
>
> 2008/11/13 Sean McNeil <seanm...@gmail.com

> <mailto:seanm...@gmail.com>>

> <http://192.168.0.100> <http://192.168.0.100>", ...}) = 0

> > <mailto:seanm...@gmail.com <mailto:seanm...@gmail.com>>>

[Rupesh Gujare]

Sean,
  second patch for
diff --git a/opengl/libGLES_CM/gl_wrapper.cpp
is deformed and can not be cleanly applied. Can you resend patch or tell where can I find second patch.

Regards,
Rupesh