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
-~----------~----~----~----~------~----~------~--~---
