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 <[EMAIL PROTECTED]>
>
> 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
-~----------~----~----~----~------~----~------~--~---
