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