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