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
> 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 <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>>
>
>
> 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 <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>
> > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>>
> >
> >
> > 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
> >
> >
> >
> >
> >
> > >
>
>
>
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
unsubscribe: [EMAIL PROTECTED]
website: http://groups.google.com/group/android-porting
-~----------~----~----~----~------~----~------~--~---
