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 On Thu, Nov 13, 2008 at 3:26 PM, Sean McNeil <[EMAIL PROTECTED]> wrote: > > 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 <[EMAIL PROTECTED] <mailto:[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] > > <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 -~----------~----~----~----~------~----~------~--~---
