Re: Improved use of vst1 via vec_extract (PR 51819 test case)
On 1 February 2012 19:33, Ulrich Weigand wrote: > > Ramana Radhakrishnan wrote on 01.02.2012 > 16:28:04: > >> This patch should be queued for 4.8 .Sounds sensible to me. > > OK, thanks for the review! > >> > (As an aside, it might likewise be helpful to update the vec_set > patterns >> > to allow for memory operands, implemented via vld1.) >> >> Agreed. > > The attached patch adds support for vld1 in vec_set as well. > (See attached file: diff-gcc-arm-vecsetextractmem) > > As a side note, I noticed that the vmov instructions output via > vec_set and vec_extract use %? to support conditions in ARM mode; > most of the rest of neon.md doesn't use %?, in particular, the > patterns where I copied vst1/vld1 from didn't ... To follow up from last night - please remove the "predicable" attribute on these patterns. Conditional neon is deprecated. The patterns affected are from a quick grep : (vec_set_internal, (vec_setv2di_internal) (vec_set) (vec_extract) (vec_extractv2di) (vec_init) (neon_vget_lane_zext_internal) (neon_vget_lane_sext_internal) (neon_vget_lane_zext_internal) (neon_vget_lane) (neon_vdup_n) (neon_vdup_ndi) There should be never a chance to generate conditional Neon instructions. I'd like to take this up further on gcc-patches for any further review / comments. Ramana ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: native gdb for Android
Barry Song <21cn...@gmail.com> wrote: > So my questions are: > > 1. Should I compile the native gdb using android toolchain and android > bionic/libthread libraries? > 2. Why can’t the current gdb capture multithreads for android > processes? This question is actually about the theory for gdb to know > multi-threads. In my opinion, both gnu and android use clone() to fork > threads and threads in one process have same tgid in kernel and all > threads return same getpid() value. Why not gdb just travel process > lists to find multi-threads? I'm not sure what exactly is going on on Android with bionic. However, GDB currently does require support from the thread library in order to debug multi-threaded applications. This is needed e.g. to properly handle thread-local storage variables. GDB will also use this support to detect threads of a running process it is attaching to. (It is true that GDB *could* e.g. look at /proc to find threads, instead of inspecting thread library data structures. However, since the link to those data structures is required anyway, e.g. for TLS, this has not been implemented so far ...) When using glibc's libpthread, the support routines gdb uses to inspect target thread library datastructures are provided in libthread_db.so.1 (which comes with glibc, and is linked into gdb). I do not know the details on whether/how bionic provides a corresponding service. However, from looking at the gdbserver sources provided with Android, it seems there are some differences; in particular, there's this patch: +/* Android doesn't have libthread_db.so.1, just libthread_db.so. */ +#ifdef __ANDROID__ +#define LIBTHREAD_DB_SO "libthread_db.so" +#endif + If libthread_db is named differently, this would explain why GDB is unable to find and use it. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: native gdb for Android
Hi Barry, On Thu, 2012-02-02 at 10:23 +0800, Barry Song wrote: > 2.Why can’t the current gdb capture multithreads for android > processes? This question is actually about the theory for gdb to know > multi-threads. In my opinion, both gnu and android use clone() to fork > threads and threads in one process have same tgid in kernel and all > threads return same getpid() value. Why not gdb just travel process > lists to find multi-threads? Would you mind opening a bug report at https://bugs.launchpad.net/gdb-linaro with this issue? If possible, with a small testcase to reproduce the problem, and the steps to build the testcase. To be honest I can only look into this issue late next week though... -- []'s Thiago Jung Bauermann Linaro Toolchain Working Group ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Benchmark investigation at Connect
Hi Michael, On 2 February 2012 02:44, Michael Hope wrote: > I've set up a new user on my laptop that we can use for experimenting > with benchmarks during Connect. Here's what we've got: > * A user called 'connect' > * Ramana, Ulrich, Åsa, and myself can log in via SSH works for me . > * bzr repo for trunk, 4.6, and gcc-linaro 4.6 Ack. > * Tarballs of all gcc-linaro 4.4, 4.5, and 4.6 releases > * Tarballs of the recent CSL, Google 4.6, and Android 4.4 compilers > * A sysroot in ~/sysroot > * Cross-binutils etch in ~/cross > * A shared ccache in ~/ccache primed with these > * A ~/env.sh that sets up the right paths etc > * A ~/builds/doconfigure.sh that configures for our standard ARMv7-A > C/C++/Fortran configuration I've put a copy of some of the directory names and info from this mail into a common top level file called README.where just as I was looking around. I've poked around a bit but not tried building anything serious as I wasn't sure if it would affect your laptop in any other way. > * EEMBC, DENBench, and SPEC 2000 under ~/benchmarks I haven't tried running any of these but I presume that should fine. > > The trees under build/ build into build/$ver/build and install into > build/$ver/install. > > The benchmarks are set up to cross build and cross run. I've pulled > ursa2 out of the farm and nuked it, so we can do something like: > make CROSS_COMPILE=arm-linux-gnueabi- RUN="$PWD/sshrun ursa2" Are you carrying ursa2 as well with you or are we running this remotely from connect ? cheers Ramana ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Benchmark investigation at Connect
I'm bringing ursa2. -- Michael On Fri, Feb 3, 2012 at 12:51 PM, Ramana Radhakrishnan wrote: > Hi Michael, > > On 2 February 2012 02:44, Michael Hope wrote: >> I've set up a new user on my laptop that we can use for experimenting >> with benchmarks during Connect. Here's what we've got: >> * A user called 'connect' >> * Ramana, Ulrich, Åsa, and myself can log in via SSH > > works for me . > >> * bzr repo for trunk, 4.6, and gcc-linaro 4.6 > > Ack. > >> * Tarballs of all gcc-linaro 4.4, 4.5, and 4.6 releases >> * Tarballs of the recent CSL, Google 4.6, and Android 4.4 compilers >> * A sysroot in ~/sysroot >> * Cross-binutils etch in ~/cross >> * A shared ccache in ~/ccache primed with these >> * A ~/env.sh that sets up the right paths etc >> * A ~/builds/doconfigure.sh that configures for our standard ARMv7-A >> C/C++/Fortran configuration > > I've put a copy of some of the directory names and info from this mail > into a common top level file called README.where just as I was looking > around. > > I've poked around a bit but not tried building anything serious as I > wasn't sure if it would affect your laptop in any other way. > >> * EEMBC, DENBench, and SPEC 2000 under ~/benchmarks > > I haven't tried running any of these but I presume that should fine. > >> >> The trees under build/ build into build/$ver/build and install into >> build/$ver/install. >> >> The benchmarks are set up to cross build and cross run. I've pulled >> ursa2 out of the farm and nuked it, so we can do something like: >> make CROSS_COMPILE=arm-linux-gnueabi- RUN="$PWD/sshrun ursa2" > > Are you carrying ursa2 as well with you or are we running this > remotely from connect ? > > cheers > Ramana ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: native gdb for Android
Hi Ulrich,
2012/2/3 Ulrich Weigand :
> Barry Song <21cn...@gmail.com> wrote:
>
>> So my questions are:
>>
>> 1. Should I compile the native gdb using android toolchain and android
>> bionic/libthread libraries?
>> 2. Why can’t the current gdb capture multithreads for android
>> processes? This question is actually about the theory for gdb to know
>> multi-threads. In my opinion, both gnu and android use clone() to fork
>> threads and threads in one process have same tgid in kernel and all
>> threads return same getpid() value. Why not gdb just travel process
>> lists to find multi-threads?
>
> I'm not sure what exactly is going on on Android with bionic. However,
> GDB currently does require support from the thread library in order to
> debug multi-threaded applications. This is needed e.g. to properly
> handle thread-local storage variables. GDB will also use this support
> to detect threads of a running process it is attaching to.
>
> (It is true that GDB *could* e.g. look at /proc to find threads, instead
> of inspecting thread library data structures. However, since the link
> to those data structures is required anyway, e.g. for TLS, this has not
> been implemented so far ...)
>
> When using glibc's libpthread, the support routines gdb uses to inspect
> target thread library datastructures are provided in libthread_db.so.1
> (which comes with glibc, and is linked into gdb). I do not know the
> details on whether/how bionic provides a corresponding service.
>
> However, from looking at the gdbserver sources provided with Android,
> it seems there are some differences; in particular, there's this patch:
>
> +/* Android doesn't have libthread_db.so.1, just libthread_db.so. */
> +#ifdef __ANDROID__
> +#define LIBTHREAD_DB_SO "libthread_db.so"
> +#endif
> +
>
> If libthread_db is named differently, this would explain why GDB is
> unable to find and use it.
there are two ways to handle this issue:
1. ln -s /system/lib/libthread_db.so /system/lib/libthread_db.so.1
2. patching gdb
i did have changed linaro-gdb 11.10 release by:
diff --git a/gdb/arm-linux-tdep.c b/gdb/arm-linux-tdep.c
index ca0bc30..486faf6 100644
--- a/gdb/arm-linux-tdep.c
+++ b/gdb/arm-linux-tdep.c
@@ -98,8 +98,8 @@ static const char arm_linux_thumb2_le_breakpoint[] =
{ 0xf0, 0xf7, 0x00, 0xa0 };
buffer. This is also true for the SoftFPA model. However, for the FPA
model the PC is at offset 21 in the buffer. */
#define ARM_LINUX_JB_ELEMENT_SIZE INT_REGISTER_SIZE
-#define ARM_LINUX_JB_PC_FPA21
-#define ARM_LINUX_JB_PC_EABI 9
+#define ARM_LINUX_JB_PC_FPA24/*21*/
+#define ARM_LINUX_JB_PC_EABI 24/*9*/
/*
Dynamic Linking on ARM GNU/Linux
diff --git a/gdb/gdb_thread_db.h b/gdb/gdb_thread_db.h
index 957ed2c..51ed4fa 100644
--- a/gdb/gdb_thread_db.h
+++ b/gdb/gdb_thread_db.h
@@ -2,7 +2,7 @@
#include
#ifndef LIBTHREAD_DB_SO
-#define LIBTHREAD_DB_SO "libthread_db.so.1"
+#define LIBTHREAD_DB_SO "libthread_db.so"
#endif
#ifndef LIBTHREAD_DB_SEARCH_PATH
But both 1 and 2 can't simply fix the problem. if we compile gdb
statically by "make LDFLAGS=-static", it will finally come into a
crash:
# gdb attach 643
GNU gdb (Linaro GDB) 7.3-2011.10
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
this is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-none-linux-gnueabi".
For bug reporting instructions, please see:
