can linaro toolchain compile ARM earlier than Cortex A8?

[Barry Song]

Hi All,
After downloading linaro toolchain by apt-get in ubuntu, I compiled
the uboot for ARM1136 SoC with -march=armv5 option. And it can compile
successfully. Then I let the uboot run on target boards and system
failed due to "undefined instructions". Checked linaro toolchain
options, it is:

#arm-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.5.2/lto-wrapper
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.5.2-5ubuntu2~ppa1'
--with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.5 --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.5.2
--libdir=/usr/lib --enable-nls --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin
--enable-gold --enable-ld=default --with-plugin-ld=ld.gold
--enable-objc-gc --disable-sjlj-exceptions --with-arch=armv7-a
--with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb
--disable-werror --enable-checking=release
--program-prefix=arm-linux-gnueabi-
--includedir=/usr/arm-linux-gnueabi/include --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=arm-linux-gnueabi
--with-headers=/usr/arm-linux-gnueabi/include
--with-libs=/usr/arm-linux-gnueabi/lib
Thread model: posix
gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-5ubuntu2~ppa1)

The imporant options are "--with-arch=armv7-a --with-float=softfp
--with-fpu=vfpv3-d16". I just want to ask whether these options stop
arm-linux-gnueabi-gcc to support old arch? If so, according to gcc
documents at http://gcc.gnu.org/install/configure.html,

"

--with-cpu=cpu
--with-cpu-32=cpu
--with-cpu-64=cpu
Specify which cpu variant the compiler should generate code for by
default. cpu will be used as the default value of the -mcpu= switch.
This option is only supported on some targets, including ARM, i386,
M68k, PowerPC, and SPARC. The --with-cpu-32 and --with-cpu-64 options
specify separate default CPUs for 32-bit and 64-bit modes; these
options are only supported for i386, x86-64 and PowerPC.
--with-schedule=cpu
--with-arch=cpu
--with-arch-32=cpu
--with-arch-64=cpu
--with-tune=cpu
--with-tune-32=cpu
--with-tune-64=cpu
--with-abi=abi
--with-fpu=type
--with-float=type
These configure options provide default values for the
-mschedule=, -march=, -mtune=, -mabi=, and -mfpu= options and for
-mhard-float or -msoft-float. As with --with-cpu, which switches will
be accepted and acceptable values of the arguments depend on the
target.
"

There are only default values for later compiling. Users should be
able to swith to other values by setting other options. But why did
arm-linux-gnueabi-gcc still build "undefined instructions" to arm1136
with "arch=armv5"?  In fact arm1136 is armv6.

Then i compiled a toolchain for linaro gcc-linaro-4.4-2011.02-0 codes
by myself, the options are simple:

#arm-none-linux-gnueabi-gcc -v
Using built-in specs.
Target: arm-none-linux-gnueabi
Configured with: ../gcc-linaro-4.4-2011.02-0/configure
--target=arm-none-linux-gnueabi
--prefix=/home/vmuser/development/toolchain/build-toolchain/tools
--enable-languages=c,c++ --disable-libgomp
Thread model: posix
gcc version 4.4.5 (Linaro GCC 4.4-2011.02-0)

Then I compiled uboot by this toolchain again, the uboot can work.
Then why can the toolchain compiled by myself support more arch? And
what performance is lost in my compiling?

Thanks
Barry

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: can linaro toolchain compile ARM earlier than Cortex A8?

[Barry Song]

2011/3/24 Andrew Stubbs 
>
> On 24/03/11 11:05, Imre Kaloz wrote:
>>
>> On Thu, 24 Mar 2011 11:36:17 +0100, Andrew Stubbs
>>  wrote:
>>>
>>> However, you can build your own compiler from the Linaro sources, and
>>> then build the libraries you need to match, and you can have v5 support.
>>> This is not a straightforward process. :(
>>
>> You can always use the OpenWrt buildroot to easily build a custom
>> Linaro-based crosscompiler, just make sure you select the right libc for
>> your needs (we use uClibc by default) and a target similar to yours.
>
> Or OpenEmbedded or CrossTool / CrossTool-NG.

Thank all of you! you really help me much!  You toolchain team is really great!

In fact, i knew how to compile a toolchain.  As i said, i have
compiled a toolchain by simple options:
Configured with: ../gcc-linaro-4.4-2011.02-0/
configure
--target=arm-none-linux-gnueabi
--prefix=/home/vmuser/development/toolchain/build-toolchain/tools
--enable-languages=c,c++ --disable-libgomp
Thread model: posix
gcc version 4.4.5 (Linaro GCC 4.4-2011.02-0)

it can make uboot work with arch=armv5.

i want to know whether any performance is lost by my simple configure
options if the toolchain is used to armv7 with vfpv3? GCC documents
show that those options we use to compile gcc will become the default
options of gcc runtime. But what is the real benefit toolchains can
get by configuring gcc with default arch and fpu since we can switch
arch options at runtime?

Is the key glibc? If compiling glibc by gcc with options for a special
ARM arch and float point unit, it will improve the performance of
glibc to the arch? And then the glibc will not support other arch or
SoCs without the specified float point unit?


>
> Andrew
>
> ___
> linaro-toolchain mailing list
> linaro-toolchain@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-toolchain

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: can linaro toolchain compile ARM earlier than Cortex A8?

[Barry Song]

2011/3/24 Michael Hope :
> On Fri, Mar 25, 2011 at 2:59 AM, Barry Song <21cn...@gmail.com> wrote:
>> 2011/3/24 Andrew Stubbs 
>>>
>>> On 24/03/11 11:05, Imre Kaloz wrote:
>>>>
>>>> On Thu, 24 Mar 2011 11:36:17 +0100, Andrew Stubbs
>>>>  wrote:
>>>>>
>>>>> However, you can build your own compiler from the Linaro sources, and
>>>>> then build the libraries you need to match, and you can have v5 support.
>>>>> This is not a straightforward process. :(
>>>>
>>>> You can always use the OpenWrt buildroot to easily build a custom
>>>> Linaro-based crosscompiler, just make sure you select the right libc for
>>>> your needs (we use uClibc by default) and a target similar to yours.
>>>
>>> Or OpenEmbedded or CrossTool / CrossTool-NG.
>>
>> Thank all of you! you really help me much!  You toolchain team is really 
>> great!
>>
>> In fact, i knew how to compile a toolchain.  As i said, i have
>> compiled a toolchain by simple options:
>> Configured with: ../gcc-linaro-4.4-2011.02-0/
>> configure
>> --target=arm-none-linux-gnueabi
>> --prefix=/home/vmuser/development/toolchain/build-toolchain/tools
>> --enable-languages=c,c++ --disable-libgomp
>> Thread model: posix
>> gcc version 4.4.5 (Linaro GCC 4.4-2011.02-0)
>>
>> it can make uboot work with arch=armv5.
>>
>> i want to know whether any performance is lost by my simple configure
>> options if the toolchain is used to armv7 with vfpv3? GCC documents
>> show that those options we use to compile gcc will become the default
>> options of gcc runtime. But what is the real benefit toolchains can
>> get by configuring gcc with default arch and fpu since we can switch
>> arch options at runtime?
>>
>> Is the key glibc? If compiling glibc by gcc with options for a special
>> ARM arch and float point unit, it will improve the performance of
>> glibc to the arch? And then the glibc will not support other arch or
>> SoCs without the specified float point unit?
>
> Hi Barry.  The short answer is 'it depends' :)
>
> GCC is more than a compiler and includes other things such as a
> runtime library (libgcc) and hooks into the libc for features like
> thread local storage.  These are built for the architecture and
> floating point unit options you pass to GCC's configure, so if you
> want one toolchain that runs everywhere then you need to configure it
> for the lowest common denominator (normally a ARMv5T in ARM mode with
> no FPU).  A similar argument applies to GLIBC.
>
> The next question is, does this matter for your application?  What
> workload will your product run and will it be meaningfully affected by
> this lowest common denominator build?
>  * If your application uses a lot of floating point, then the lack of
> FPU support in GLIBC matters

Completely right. I got a linaro 4.5 by:

sudo add-apt-repository ppa:linaro-maintainers/toolchain
sudo apt-get update
sudo apt-get install gcc-4.5-arm-linux-gnueabi

Then I did WHETSTONE benchmark on a low-frequency cortex A9 FPGA with vfpv3.

Result showed linaro by apt-get is using generic glibc in fact. its
gave only 3.3 WHETSTONE MIPS. Then i compiled a glibc with vfpv3
support  to replace the glibc by apt-get, the new toolchain gave 16.7
WHETSTONE MIPS, 400% improvement in WHETSTONE.

>  * If your product has limited memory, then the smaller code size of
> Thumb-2 is worthwhile
>  * If you need to squeeze out another 5 % in performance, then using
> ARMv7 instead of ARMv5 will help

Completely right. I did a edn benchmark from
http://www.mrtc.mdh.se/projects/wcet/wcet_bench/edn/edn.c.  EDN can
show memory and fixed-point performance. My testing result shows edn
has a 5-10% performance improvement by linaro 4.5 with armv7_a option.

>
> There are other technical solutions such as:
>  * Building libgcc and glibc for the different variants and picking
> the best at link time
>  * Building them and picking at dynamic link time using hwcaps or similar
>
> These make sense for a generic binary toolchain such as the
> CodeSourcery one Andrew mentioned, and for generic distributions such
> as Ubuntu but not for a focused end user product.

Then my conclusion is that the best choice  for cortex A9 with vfpv3 is
1. using linaro gcc 4.4/4.5 with ARMV7 optimization
2. using glibc compiled with vfpv3 supporting

A strange phenomenon i found was nbench would enter dead loop in
ASSIGNMENT case. It could finish ASSIGNMENT case forever. nbench can
be downloaded from
http://www.tux.org/~mayer/linux/nbench-byte-2.2.3.tar.gz. I haven't
time to figure out whether it is a linaro gcc bug. Then i just ignore
this case by writing NBENCH.CONF like the following:
CUSTOMRUN=T
DONUMSORT=T
DOLU=T
DOSTRINGSORT=T
DOBITFIELD=T
DOEMF=T
DOFOUR=T
DOASSIGN=F
ASSIGNMINSECONDS=1
DOHUFF=T
DOIDEA=T

If you have time, may you help to check the reason?
>
> -- Michael

Thanks
Barry

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: can linaro toolchain compile ARM earlier than Cortex A8?

[Barry Song]

2011/3/30 Michael Hope :
> On Tue, Mar 29, 2011 at 5:40 PM, Barry Song <21cn...@gmail.com> wrote:
>> 2011/3/24 Michael Hope :
>>> Hi Barry.  The short answer is 'it depends' :)
>>>
>>> GCC is more than a compiler and includes other things such as a
>>> runtime library (libgcc) and hooks into the libc for features like
>>> thread local storage.  These are built for the architecture and
>>> floating point unit options you pass to GCC's configure, so if you
>>> want one toolchain that runs everywhere then you need to configure it
>>> for the lowest common denominator (normally a ARMv5T in ARM mode with
>>> no FPU).  A similar argument applies to GLIBC.
>>>
>>> The next question is, does this matter for your application?  What
>>> workload will your product run and will it be meaningfully affected by
>>> this lowest common denominator build?
>>>  * If your application uses a lot of floating point, then the lack of
>>> FPU support in GLIBC matters
>>
>> Completely right. I got a linaro 4.5 by:
>>
>> sudo add-apt-repository ppa:linaro-maintainers/toolchain
>> sudo apt-get update
>> sudo apt-get install gcc-4.5-arm-linux-gnueabi
>>
>> Then I did WHETSTONE benchmark on a low-frequency cortex A9 FPGA with vfpv3.
>>
>> Result showed linaro by apt-get is using generic glibc in fact. its
>> gave only 3.3 WHETSTONE MIPS. Then i compiled a glibc with vfpv3
>> support  to replace the glibc by apt-get, the new toolchain gave 16.7
>> WHETSTONE MIPS, 400% improvement in WHETSTONE.
>
> Whetstone is a floating point benchmark, so I'd expect this type of 
> improvement.
>
>>
>>>  * If your product has limited memory, then the smaller code size of
>>> Thumb-2 is worthwhile
>>>  * If you need to squeeze out another 5 % in performance, then using
>>> ARMv7 instead of ARMv5 will help
>>
>> Completely right. I did a edn benchmark from
>> http://www.mrtc.mdh.se/projects/wcet/wcet_bench/edn/edn.c.  EDN can
>> show memory and fixed-point performance. My testing result shows edn
>> has a 5-10% performance improvement by linaro 4.5 with armv7_a option.
>
> Nice :)  This matches what I've seen.
>
>> Then my conclusion is that the best choice  for cortex A9 with vfpv3 is
>> 1. using linaro gcc 4.4/4.5 with ARMV7 optimization
>> 2. using glibc compiled with vfpv3 supporting
>>
>> A strange phenomenon i found was nbench would enter dead loop in
>> ASSIGNMENT case. It could finish ASSIGNMENT case forever. nbench can
>> be downloaded from
>> http://www.tux.org/~mayer/linux/nbench-byte-2.2.3.tar.gz. I haven't
>> time to figure out whether it is a linaro gcc bug. Then i just ignore
>> this case by writing NBENCH.CONF like the following:
>> CUSTOMRUN=T
>> DONUMSORT=T
>> DOLU=T
>> DOSTRINGSORT=T
>> DOBITFIELD=T
>> DOEMF=T
>> DOFOUR=T
>> DOASSIGN=F
>> ASSIGNMINSECONDS=1
>> DOHUFF=T
>> DOIDEA=T
>>
>> If you have time, may you help to check the reason?
>
> I couldn't reproduce this, sorry.  I built nbench using
> gcc-linaro-4.5-2011.03-0 using both -O3 -mtune=cortex-a9
> -mfpu=vfpv3-d16 and -O3 -mtune=cortex-a9 -mfpu=neon and in both cases
> ASSIGNMENT completes.

Thanks. i will check whether it is our chip issue.

here one question: how much arm-linux-gnueabi-gcc depends on glibc version?

i run apt-get linaro 4.4, then got linaro 4.5 too. i found 4.5 was
using glibc 2.12, but old 4.4 was using 2.11. apt-get 4.5 modified
glibc from 2.11 to 2.12.  But 4.4 could still use new glibc to compile
and we haven't had any problem by now.  I even recompiled a glibc 2.13
to replace current 2.12, but i didn't recompile gcc based on the
glibc, the toolchain 4.4 and 4.5 can still work.

As i know, we compile arm-linux-gnueabi-gcc by following steps:
1. compile gcc 1, bootstrap in fact
2. compile glibc by gcc1
3. compile gcc2 based on glibc from step 2.

why can toolchain still work well by the steps?
1. keep arm-linux-gnueabi-gcc unchanged
2. replace glibc
So i am not sure whether any hidden problem exist by replacing glibc simply.

one more question, my ubuntu 10.10 always said "/lib/libc.so.6: file
not recognized: File format not recognized" if i enabled c++ language
when compiling linaro gcc 4.4 and 4.5. Then i can't install
libstdc++-v3 with errors like:
/bin/sh: line 3: cd: arm-none-linux-gnueabi/libstdc++-v3: No such file
or directory
make[1]: *** [install-target-libstdc++-v3] Error 1

In fact, my version matches:

$ /lib/libc.so.6
GNU C Library (Ubuntu EGLIBC 2.12.1-0ubuntu10.2) stable release
version 2.12.1, by Roland McGrath e

__aeabi_uldivmod undefined for sound/soc/codecs/snd-soc-wm8974.ko, snd-soc-wm8940.ko and snd-soc-wm8510.ko

[Barry Song]

Hi All,
I am using 2011.3 4.5 linaro GCC(armv7-a vfpv3d16) to compile kernel
and modules. I select to compile all codecs as modules:
"config SND_SOC_ALL_CODECS
  tristate "Build all ASoC CODEC drivers"
"
as M and I2C/SPI too.

Then in the kernel dir, run "make" to get both vmlinux and modules, I
found snd-soc-wm8974.ko, snd-soc-wm8940.ko and snd-soc-wm8510.ko will
fail due to "__aeabi_uldivmod undefined".

If i comment do_div() in these codec drivers, this issue will
disappear. But it is strange there are many codecs which use do_div()
too, for example:
sound/soc/codecs/max98088.c 
sound/soc/codecs/max9850.c  
sound/soc/codecs/wm8350.c   
sound/soc/codecs/wm8400.c   
sound/soc/codecs/wm8510.c   
sound/soc/codecs/wm8580.c   
sound/soc/codecs/wm8753.c   
sound/soc/codecs/wm8804.c   
sound/soc/codecs/wm8900.c   
sound/soc/codecs/wm8904.c   
sound/soc/codecs/wm8940.c   
sound/soc/codecs/wm8955.c   
sound/soc/codecs/wm8960.c   
sound/soc/codecs/wm8974.c   
sound/soc/codecs/wm8978.c   
sound/soc/codecs/wm8985.c   
sound/soc/codecs/wm8990.c   
sound/soc/codecs/wm8991.c   
sound/soc/codecs/wm8993.c   
sound/soc/codecs/wm8994.c   
sound/soc/codecs/wm8995.c   
sound/soc/codecs/wm9081.c   

but others can pass the compiling except those 3 modules. Is it due to
a wrong optimization by gcc?

Other information:
1. old tool-chains we are using can pass the compiling of the 3 modules.
2. If i built all codecs into kernel image, these 3 drivers don't
report error while compiling.

Thanks
Barry

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: __aeabi_uldivmod undefined for sound/soc/codecs/snd-soc-wm8974.ko, snd-soc-wm8940.ko and snd-soc-wm8510.ko

[Barry Song]

Hi Michael,

2011/4/26 Michael Hope :
> Hi Barry.  I think the toolchain is operating correctly here.  The
> current version recognises a divide followed by a modulo and optimises
> this into a call to the standard EABI function __aeabi__uldivmod().
> Note the code:
>
>        do_div(Kpart, source);
>
>        K = Kpart & 0x;
>
>        /* Check if we need to round */
>        if ((K % 10) >= 5)
>                K += 5;
>
> This function is provided by libgcc for normal applications. The
> kernel provides it's own versions in arch/arm/lib/lib1funcs.s but is
> missing __aeabi_uldivmod (note the 'l' for 64 bit).
In fact the problem happen ealier:

  if (Ndiv < 6) {
   source /= 2;
pll_div->pre_div = 1;
Ndiv = target / source;
} else
pll_div->pre_div = 0;

if ((Ndiv < 6) || (Ndiv > 12))
printk(KERN_WARNING
"WM8974 N value %u outwith recommended range!\n",
Ndiv);

pll_div->n = Ndiv;
Nmod = target % source;
Kpart = FIXED_PLL_SIZE * (long long)Nmod;

do_div(Kpart, source);

If commenting "source /= 2", the problem disappear.


>
> -- Michael
>
> On Tue, Apr 26, 2011 at 12:45 AM, Barry Song <21cn...@gmail.com> wrote:
>> Hi All,
>> I am using 2011.3 4.5 linaro GCC(armv7-a vfpv3d16) to compile kernel
>> and modules. I select to compile all codecs as modules:
>> "config SND_SOC_ALL_CODECS
>>          tristate "Build all ASoC CODEC drivers"
>> "
>> as M and I2C/SPI too.
>>
>> Then in the kernel dir, run "make" to get both vmlinux and modules, I
>> found snd-soc-wm8974.ko, snd-soc-wm8940.ko and snd-soc-wm8510.ko will
>> fail due to "__aeabi_uldivmod undefined".
>>
>> If i comment do_div() in these codec drivers, this issue will
>> disappear. But it is strange there are many codecs which use do_div()
>> too, for example:
>> sound/soc/codecs/max98088.c
>> sound/soc/codecs/max9850.c
>> sound/soc/codecs/wm8350.c
>> sound/soc/codecs/wm8400.c
>> sound/soc/codecs/wm8510.c
>> sound/soc/codecs/wm8580.c
>> sound/soc/codecs/wm8753.c
>> sound/soc/codecs/wm8804.c
>> sound/soc/codecs/wm8900.c
>> sound/soc/codecs/wm8904.c
>> sound/soc/codecs/wm8940.c
>> sound/soc/codecs/wm8955.c
>> sound/soc/codecs/wm8960.c
>> sound/soc/codecs/wm8974.c
>> sound/soc/codecs/wm8978.c
>> sound/soc/codecs/wm8985.c
>> sound/soc/codecs/wm8990.c
>> sound/soc/codecs/wm8991.c
>> sound/soc/codecs/wm8993.c
>> sound/soc/codecs/wm8994.c
>> sound/soc/codecs/wm8995.c
>> sound/soc/codecs/wm9081.c
>>
>> but others can pass the compiling except those 3 modules. Is it due to
>> a wrong optimization by gcc?
>>
>> Other information:
>> 1. old tool-chains we are using can pass the compiling of the 3 modules.
>> 2. If i built all codecs into kernel image, these 3 drivers don't
>> report error while compiling.
>>
>> Thanks
>> Barry
>>
>> ___
>> linaro-toolchain mailing list
>> linaro-toolchain@lists.linaro.org
>> http://lists.linaro.org/mailman/listinfo/linaro-toolchain
>>
>

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: __aeabi_uldivmod undefined for sound/soc/codecs/snd-soc-wm8974.ko, snd-soc-wm8940.ko and snd-soc-wm8510.ko

[Barry Song]

2011/4/26 Barry Song <21cn...@gmail.com>:
> Hi Michael,
>
> 2011/4/26 Michael Hope :
>> Hi Barry.  I think the toolchain is operating correctly here.  The
>> current version recognises a divide followed by a modulo and optimises
>> this into a call to the standard EABI function __aeabi__uldivmod().
>> Note the code:
>>
>>        do_div(Kpart, source);
>>
>>        K = Kpart & 0x;
>>
>>        /* Check if we need to round */
>>        if ((K % 10) >= 5)
>>                K += 5;
>>
>> This function is provided by libgcc for normal applications. The
>> kernel provides it's own versions in arch/arm/lib/lib1funcs.s but is
>> missing __aeabi_uldivmod (note the 'l' for 64 bit).
> In fact the problem happen ealier:
>
>  if (Ndiv < 6) {
>               source /= 2;
>                pll_div->pre_div = 1;
>                Ndiv = target / source;
>        } else
>                pll_div->pre_div = 0;
>
>        if ((Ndiv < 6) || (Ndiv > 12))
>                printk(KERN_WARNING
>                        "WM8974 N value %u outwith recommended range!\n",
>                        Ndiv);
>
>        pll_div->n = Ndiv;
>        Nmod = target % source;
>        Kpart = FIXED_PLL_SIZE * (long long)Nmod;
>
>        do_div(Kpart, source);
>
> If commenting "source /= 2", the problem disappear.
>
>
Or if adding one line before do_div, all will be ok.
asm("" : "+r"(source));
do_div(Kpart, source);

>>
>> -- Michael
>>
>> On Tue, Apr 26, 2011 at 12:45 AM, Barry Song <21cn...@gmail.com> wrote:
>>> Hi All,
>>> I am using 2011.3 4.5 linaro GCC(armv7-a vfpv3d16) to compile kernel
>>> and modules. I select to compile all codecs as modules:
>>> "config SND_SOC_ALL_CODECS
>>>          tristate "Build all ASoC CODEC drivers"
>>> "
>>> as M and I2C/SPI too.
>>>
>>> Then in the kernel dir, run "make" to get both vmlinux and modules, I
>>> found snd-soc-wm8974.ko, snd-soc-wm8940.ko and snd-soc-wm8510.ko will
>>> fail due to "__aeabi_uldivmod undefined".
>>>
>>> If i comment do_div() in these codec drivers, this issue will
>>> disappear. But it is strange there are many codecs which use do_div()
>>> too, for example:
>>> sound/soc/codecs/max98088.c
>>> sound/soc/codecs/max9850.c
>>> sound/soc/codecs/wm8350.c
>>> sound/soc/codecs/wm8400.c
>>> sound/soc/codecs/wm8510.c
>>> sound/soc/codecs/wm8580.c
>>> sound/soc/codecs/wm8753.c
>>> sound/soc/codecs/wm8804.c
>>> sound/soc/codecs/wm8900.c
>>> sound/soc/codecs/wm8904.c
>>> sound/soc/codecs/wm8940.c
>>> sound/soc/codecs/wm8955.c
>>> sound/soc/codecs/wm8960.c
>>> sound/soc/codecs/wm8974.c
>>> sound/soc/codecs/wm8978.c
>>> sound/soc/codecs/wm8985.c
>>> sound/soc/codecs/wm8990.c
>>> sound/soc/codecs/wm8991.c
>>> sound/soc/codecs/wm8993.c
>>> sound/soc/codecs/wm8994.c
>>> sound/soc/codecs/wm8995.c
>>> sound/soc/codecs/wm9081.c
>>>
>>> but others can pass the compiling except those 3 modules. Is it due to
>>> a wrong optimization by gcc?
>>>
>>> Other information:
>>> 1. old tool-chains we are using can pass the compiling of the 3 modules.
>>> 2. If i built all codecs into kernel image, these 3 drivers don't
>>> report error while compiling.
>>>
>>> Thanks
>>> Barry
>>>
>>> ___
>>> linaro-toolchain mailing list
>>> linaro-toolchain@lists.linaro.org
>>> http://lists.linaro.org/mailman/listinfo/linaro-toolchain
>>>
>>

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: __aeabi_uldivmod undefined for sound/soc/codecs/snd-soc-wm8974.ko, snd-soc-wm8940.ko and snd-soc-wm8510.ko

[Barry Song]

2011/4/26 Nicolas Pitre :
> On Tue, 26 Apr 2011, Michael Hope wrote:
>
>> Yip, so the compiler spots these two lines:
>>          Ndiv = target / source;
>>          Nmod = target % source;
>>
>> and turns them into
>>   Ndiv, Nmod = __aeabi_uldivmod(target, source)
>
> Why would gcc do that?  All four variables involved here are of type
> unsigned int, no unsigned long long.  Seems to me that __aeabi_uidivmod
> should have been used here instead.

I think we should dig into do_div, as i have reported,  add a line
"asm("" : "+r"(source));" before "do_div(Kpart, source);" can also
avoid this optimization.
So the __aeabi_uldivmod should be in do_div.

>
>
> Nicolas
>

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: __aeabi_uldivmod undefined for sound/soc/codecs/snd-soc-wm8974.ko, snd-soc-wm8940.ko and snd-soc-wm8510.ko

[Barry Song]

2011/4/27 Michael Hope :
> On Tue, Apr 26, 2011 at 1:48 PM, Barry Song <21cn...@gmail.com> wrote:
>> 2011/4/26 Barry Song <21cn...@gmail.com>:
>>> Hi Michael,
>>>
>>> 2011/4/26 Michael Hope :
>>>> Hi Barry.  I think the toolchain is operating correctly here.  The
>>>> current version recognises a divide followed by a modulo and optimises
>>>> this into a call to the standard EABI function __aeabi__uldivmod().
>>>> Note the code:
>>>>
>>>>        do_div(Kpart, source);
>>>>
>>>>        K = Kpart & 0x;
>>>>
>>>>        /* Check if we need to round */
>>>>        if ((K % 10) >= 5)
>>>>                K += 5;
>>>>
>>>> This function is provided by libgcc for normal applications. The
>>>> kernel provides it's own versions in arch/arm/lib/lib1funcs.s but is
>>>> missing __aeabi_uldivmod (note the 'l' for 64 bit).
>>> In fact the problem happen ealier:
>>>
>>>  if (Ndiv < 6) {
>>>               source /= 2;
>>>                pll_div->pre_div = 1;
>>>                Ndiv = target / source;
>>>        } else
>>>                pll_div->pre_div = 0;
>>>
>>>        if ((Ndiv < 6) || (Ndiv > 12))
>>>                printk(KERN_WARNING
>>>                        "WM8974 N value %u outwith recommended range!\n",
>>>                        Ndiv);
>>>
>>>        pll_div->n = Ndiv;
>>>        Nmod = target % source;
>>>        Kpart = FIXED_PLL_SIZE * (long long)Nmod;
>>>
>>>        do_div(Kpart, source);
>>>
>>> If commenting "source /= 2", the problem disappear.
>>>
>>>
>> Or if adding one line before do_div, all will be ok.
>>        asm("" : "+r"(source));
>>        do_div(Kpart, source);
>
> Hi Barry.  I can reproduce the problem in Linaro GCC 4.5-2011.04 and
> GCC 4.5.2.  It does not exist in GCC 4.6.0.  wm8974_set_dai_pll()
> inlines the call to pll_factors() and leaves a .globl reference to
> __aeabi_uldivmod in the code.  This function is never called.
>
> Marking pll_factors() as __attribute__((noinline)) also works around
> the problem.
>
> I've logged http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48783 upstream
> and recorded this as LP: #771551.

Thanks. I am totally thinking it is a gcc bug not an optimization
feature. in fact, __aeabi_uldivmod is never called as seen by objdump.
It only exists in symbol reference list.

>
> -- Michael
>

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

-O2 cause optimization issues while va parameters functions

[Barry Song]

Hi All,

As i have frequently said, we are using 2011.3 4.5 linaro gcc. For the
following codes, if we compile it by -O2, it will crash with "segment
fault", if we just comment " if(unifi_debug >= level) {", all will be
ok.
If we don't compile it by -O2, all will be ok too.

#include 
#include 
#include 

#define DEBUG_BUFFER_SIZE 80
int unifi_debug = 5;

void
unifi_trace(void* ospriv, int level, const char *fmt, ...)
{
static char s[DEBUG_BUFFER_SIZE];
va_list args;
unsigned int len;

if(unifi_debug >= level) {
va_start(args, fmt);
len = vsnprintf(&(s)[0],
(DEBUG_BUFFER_SIZE),
 fmt, args);

va_end(args);
if (len >= DEBUG_BUFFER_SIZE) {
(s)[DEBUG_BUFFER_SIZE - 2] = '\n';
(s)[DEBUG_BUFFER_SIZE - 1] = 0;
}

printf("%s", s);
}
}

int main(void)
{
char *prog = "/usr/sbin/unififw";
unifi_trace(NULL, 1, "start %s\n", prog);
return 0;
}

Thanks
Barry


with-o2.asm
Description: Binary data


without-o2.asm
Description: Binary data
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: __aeabi_uldivmod undefined for sound/soc/codecs/snd-soc-wm8974.ko, snd-soc-wm8940.ko and snd-soc-wm8510.ko

[Barry Song]

2011/4/27 Andrew Stubbs :
> On 27/04/11 09:44, Barry Song wrote:
>>
>> Thanks. I am totally thinking it is a gcc bug not an optimization
>> feature. in fact, __aeabi_uldivmod is never called as seen by objdump.
>> It only exists in symbol reference list.
>
> Your code contains "Nmod = target % source" so the only reason divmod
> wouldn't get called is if it got optimized away somehow.
>
> If that were the case then it would be a compiler bug somehow, but when I
> build the test case in Michael's bug report it looks like __aeabi_uidivmod
> does get called, AFAICT.
>
> I don't see any reference to __aeabi_uldivmod so you must have different
> compiler or testcase?

__aeabi_u*i*divmod does get called in asm codes. I mean
__aeabi_u*l*divmod has never existed in asm codes after objdump the
target ko.
__aeabi_u*l*divmod only exists in refrence list. the list means what
symbols are depent by this module. So we got a link error. but in
fact, the module doesn't need link this symbol since it never call
__aeabi_u*l*divmod in asm level.

>
> Andrew
>

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: -O2 cause optimization issues while va parameters functions

[Barry Song]

2011/4/27 Andrew Stubbs :
> On 27/04/11 10:08, Barry Song wrote:
>>
>> Hi All,
>>
>> As i have frequently said, we are using 2011.3 4.5 linaro gcc. For the
>> following codes, if we compile it by -O2, it will crash with "segment
>> fault", if we just comment " if(unifi_debug>= level) {", all will be
>> ok.
>> If we don't compile it by -O2, all will be ok too.
>
> Sorry, are you saying that the compiler crashes, or are you saying that the
> output binary crashes at runtime?

the target binary got crash while running on armv7 board, not gcc :-)

>
> Andrew
>

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: -O2 cause optimization issues while va parameters functions

[Barry Song]

2011/4/27 Andrew Stubbs :
> On 27/04/11 10:23, Barry Song wrote:
>>
>> the target binary got crash while running on armv7 board, not gcc :-)
>
> I suspect I know what the problem is here.
>
> Can you try again with -fno-shrink-wrap, please?
i guess it is related with this bug:

https://bugs.launchpad.net/gcc-linaro/+bug/771675
>
> Andrew
>

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: [alsa-devel] [PATCH] ASoC: prevent compilers from optimising pll calculation into __aeabi__uldivmod

[Barry Song]

2011/4/27 Mark Brown 
>
> On Wed, Apr 27, 2011 at 04:50:12PM +0800, Barry Song wrote:
>
> > Marking pll_factors() as noinline or putting asm("" : "+r"(source)); before 
> > the
> > call to do_div() works around the problem.
>
> If we do have to do something in the callers rather than in do_div() the
> annotation seems substantially more taseful than inserting a random asm
> into the code.
I agree. for this patch which will not be applied, people can just get
information about how to workaround the gcc issue while they have the
same problem. google can find there are other people who failed to
compile wm8974 module too. eg.
http://irclogs.ubuntu.com/2010/03/30/%23ubuntu-arm.txt

Andrew Stubbs, Michael Hope in Linaro's toolchain team are working
hard on this gcc issue. there have been many update today:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48783

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: [alsa-devel] [PATCH] ASoC: prevent compilers from optimising pll calculation into __aeabi__uldivmod

[Barry Song]

2011/4/27 Mark Brown :
> On Wed, Apr 27, 2011 at 11:00:18PM +0800, Barry Song wrote:
>> 2011/4/27 Mark Brown 
>
>> > If we do have to do something in the callers rather than in do_div() the
>> > annotation seems substantially more taseful than inserting a random asm
>> > into the code.
>
>> I agree. for this patch which will not be applied, people can just get
>> information about how to workaround the gcc issue while they have the
>> same problem. google can find there are other people who failed to
>> compile wm8974 module too. eg.
>> http://irclogs.ubuntu.com/2010/03/30/%23ubuntu-arm.txt
>
>> Andrew Stubbs, Michael Hope in Linaro's toolchain team are working
>> hard on this gcc issue. there have been many update today:
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48783
>
> Is this just some Linaro toolchain that has the issue rather than a
> vanilla GCC release?  If so and they fix the compiler bug it doesn't
> seem terribly useful to bodge it in mainline.
>

i am guessing it is a generic gcc issue since Michael posted it at
http://gcc.gnu.org/bugzilla not Linaro's Launchpad. not sure :-)

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: [alsa-devel] [PATCH] ASoC: prevent compilers from optimising pll calculation into __aeabi__uldivmod

[Barry Song]

2011/4/27 Barry Song <21cn...@gmail.com>:
> 2011/4/27 Mark Brown :
>> On Wed, Apr 27, 2011 at 11:00:18PM +0800, Barry Song wrote:
>>> 2011/4/27 Mark Brown 
>>
>>> > If we do have to do something in the callers rather than in do_div() the
>>> > annotation seems substantially more taseful than inserting a random asm
>>> > into the code.
>>
>>> I agree. for this patch which will not be applied, people can just get
>>> information about how to workaround the gcc issue while they have the
>>> same problem. google can find there are other people who failed to
>>> compile wm8974 module too. eg.
>>> http://irclogs.ubuntu.com/2010/03/30/%23ubuntu-arm.txt
>>
>>> Andrew Stubbs, Michael Hope in Linaro's toolchain team are working
>>> hard on this gcc issue. there have been many update today:
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48783
>>
>> Is this just some Linaro toolchain that has the issue rather than a
>> vanilla GCC release?  If so and they fix the compiler bug it doesn't
>> seem terribly useful to bodge it in mainline.
>>
>
> i am guessing it is a generic gcc issue since Michael posted it at
> http://gcc.gnu.org/bugzilla not Linaro's Launchpad. not sure :-)

Linaro doesn't exist yet when the discussion happened at
http://irclogs.ubuntu.com/2010/03/30/%23ubuntu-arm.txt discussion:

" [19:03]  I got this while compiling: "ERROR:
"__aeabi_uldivmod" [sound/soc/codecs/snd-soc-wm8974.ko] undefined!"
[19:04]  Now, I can disable the driver alltogether, but is
this related to the CSL cross compiler?
[19:04]  nosse1: google should give answer - common problem it was
[19:04]  hehe - sorry, you're right
"

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

"BFD_ASSERT (out_attr[Tag_ABI_HardFP_use].i == 0) " assert

[Barry Song]

Hi All,
I found Jie has committed a patch
"http://sourceware.org/ml/binutils/2010-05/msg00083.html";.
I am using the newest binary utils(2.21) and encounted the following ASSERT in
arm_elf32.c:
+ if (out_attr[i].i == 0)
+   {
+ BFD_ASSERT (out_attr[Tag_ABI_HardFP_use].i == 0);

My compiling options are as below,
ASM_FLAGS  :=
\
-gdwarf-2 \
-mfpu=vfp \
-mfloat-abi=softfp\
-mthumb-interwork

C_FLAGS:=
\
$(ASM_FLAGS)  \
-O3 -Wno-all  \
-fno-optimize-sibling-calls   \
-mlong-calls  \
-ffunction-sections   \



CPP_FLAGS :=
\
-fno-rtti \
-fno-exceptions   \


LINK_FLAGS:=
\
 --gc-sections -nostdlib  \
 -L ../stdlib \
 -Wl,--as-needed  \
 -Wl,-no-enum-size-warning\
 --cref   \

ARFLAGS:=
\
 rcs

Can anyone give me any tip about why the assert is triggered?

I have reported a bug here:
http://sourceware.org/bugzilla/show_bug.cgi?id=12700

But not sure whether it is a bug.

-barry

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: "BFD_ASSERT (out_attr[Tag_ABI_HardFP_use].i == 0) " assert

[Barry Song]

In the Tag_FP_arch case (i=Tag_FP_arch) of
elf32_arm_merge_eabi_attributes (bfd *ibfd, bfd *obfd) function, when
this ASSERT happen, i got some log:

in_attr[i].i = 2 in_attr[Tag_ABI_HardFP_use].i = 3
out_attr[i].i = 0   out_attr[Tag_ABI_HardFP_use].i = 3,

For in_attr[i].i = 2,  it means "Use of the v2 FP ISA was permitted
(implies use of the v1 FP ISA) "
For in_attr[Tag_ABI_HardFP_use].i = 3, it means "The user permitted
this entity to use both SP and DP VFP instructions (Note: This is
effectively an explicit version of the default encoded by 0)"
For out_attr[i].i = 0, it means "The user did not permit this entity
to use instructions requiring FP hardware".

According to Jie's patch, when out_attr[i].i = 0,
out_attr[Tag_ABI_HardFP_use].i should be 0 too. But what i saw is
out_attr[Tag_ABI_HardFP_use].i is also 3, same with
in_attr[Tag_ABI_HardFP_use].i .

Which compiling option changes out_attr[Tag_ABI_HardFP_use].i to 3?
And which compiling options set out_attr[i].i to 0?

Thanks
Barry

2011/4/28 Barry Song <21cn...@gmail.com>:
> Hi All,
> I found Jie has committed a patch
> "http://sourceware.org/ml/binutils/2010-05/msg00083.html";.
> I am using the newest binary utils(2.21) and encounted the following ASSERT in
> arm_elf32.c:
> +             if (out_attr[i].i == 0)
> +               {
> +                 BFD_ASSERT (out_attr[Tag_ABI_HardFP_use].i == 0);
>
> My compiling options are as below,
> ASM_FLAGS              :=
> \
>                        -gdwarf-2                                             \
>                        -mfpu=vfp                                             \
>                        -mfloat-abi=softfp                                    \
>                        -mthumb-interwork
>
> C_FLAGS                :=
> \
>                        $(ASM_FLAGS)                                          \
>                        -O3     -Wno-all                                      \
>                        -fno-optimize-sibling-calls                           \
>                        -mlong-calls                                          \
>                        -ffunction-sections                                   \
>
>
>
> CPP_FLAGS             :=
> \
>                        -fno-rtti                                             \
>                        -fno-exceptions                                       \
>
>
> LINK_FLAGS            :=
> \
>                         --gc-sections -nostdlib                              \
>                         -L ../stdlib                                         \
>                         -Wl,--as-needed                                      \
>                         -Wl,-no-enum-size-warning                            \
>                         --cref                                               \
>
> ARFLAGS                :=
>        \
>                             rcs
>
> Can anyone give me any tip about why the assert is triggered?
>
> I have reported a bug here:
> http://sourceware.org/bugzilla/show_bug.cgi?id=12700
>
> But not sure whether it is a bug.
>
> -barry
>
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: "BFD_ASSERT (out_attr[Tag_ABI_HardFP_use].i == 0) " assert

[Barry Song]

After checking much,  I find the problem is caused by "-nostdlib"
given to g++, if we set this option to g++ for linking, it will change
the out_attr[Tag_FP_arch] to 0, which is generically be 4 for linaro
new toolchain.

A right process without -nostdlib doesn't cause ASSERT:

#arm-none-linux-gnueabi-g++ main.cpp -mfloat-abi=softfp -mfpu=vfp
-march=armv6  -mcpu=arm1136jf-s

out_attr[i].i:4, out_attr[Tag_ABI_HardFP_use].i:0, in_attr[i].i:0,
in_attr[Tag_ABI_HardFP_use].i:0
ibfd: 
/home/vmuser/development/toolchain/build-toolchain/tools-64/bin/../lib/gcc/arm-none-linux-gnueabi/4.5.3/../../../../arm-none-linux-gnueabi/lib/crti.o
obfd: a.out

out_attr[i].i:4, out_attr[Tag_ABI_HardFP_use].i:0, in_attr[i].i:4,
in_attr[Tag_ABI_HardFP_use].i:3
ibfd: 
/home/vmuser/development/toolchain/build-toolchain/tools-64/bin/../lib/gcc/arm-none-linux-gnueabi/4.5.3/crtbegin.o
obfd: a.out

out_attr[i].i:4, out_attr[Tag_ABI_HardFP_use].i:3, in_attr[i].i:2,
in_attr[Tag_ABI_HardFP_use].i:3
/tmp/cc7Krzo3.o a.out

out_attr[i].i:4, out_attr[Tag_ABI_HardFP_use].i:3, in_attr[i].i:0,
in_attr[Tag_ABI_HardFP_use].i:0
ibfd: elf-init.oS
obfd: a.out

out_attr[i].i:4, out_attr[Tag_ABI_HardFP_use].i:3, in_attr[i].i:4,
in_attr[Tag_ABI_HardFP_use].i:3
ibfd: 
/home/vmuser/development/toolchain/build-toolchain/tools-64/bin/../lib/gcc/arm-none-linux-gnueabi/4.5.3/crtend.o
obfd: a.out

out_attr[i].i:4, out_attr[Tag_ABI_HardFP_use].i:3, in_attr[i].i:0,
in_attr[Tag_ABI_HardFP_use].i:0
ibfd: 
/home/vmuser/development/toolchain/build-toolchain/tools-64/bin/../lib/gcc/arm-none-linux-gnueabi/4.5.3/../../../../arm-none-linux-gnueabi/lib/crtn.o
obfd: a.out


with -nostdlib option, compiling a stand-alone program which doesn't
call any library, we will find the first out_attr[i].i becomes 0,
which caused ASSERT in the newest binutil with Jie's patch.


A wrong process using -nostdlib causes ASSERT:
...
out_attr[i].i:0, out_attr[Tag_ABI_HardFP_use].i:3, in_attr[i].i:2,
in_attr[Tag_ABI_HardFP_use].i:3
ibfd: 
/home/vmuser/development/svn/Current/Linux/Main/out/prima2cb/.obj/firmware/nanddisk/NANDDisk/soc/dir_soc.o
obfd: 
/home/vmuser/development/svn/Current/Linux/Main/out/prima2cb/.obj/firmware/nanddisk/NANDDisk.elf

/home/vmuser/development/toolchain/build-toolchain/tools-64/bin/../lib/gcc/arm-none-linux-gnueabi/4.5.3/../../../../arm-none-linux-gnueabi/bin/ld:
BFD (GNU Binutils) 2.21 assertion fail
/home/vmuser/development/toolchain/build-toolchain/binutils-2.21/bfd/elf32-arm.c:10172


i didn't verify whether gcc has this issue too.

Thanks
Barry

2011/4/27 Barry Song <21cn...@gmail.com>:
> In the Tag_FP_arch case (i=Tag_FP_arch) of
> elf32_arm_merge_eabi_attributes (bfd *ibfd, bfd *obfd) function, when
> this ASSERT happen, i got some log:
>
> in_attr[i].i = 2                 in_attr[Tag_ABI_HardFP_use].i = 3
> out_attr[i].i = 0               out_attr[Tag_ABI_HardFP_use].i = 3,
>
> For in_attr[i].i = 2,  it means "Use of the v2 FP ISA was permitted
> (implies use of the v1 FP ISA) "
> For in_attr[Tag_ABI_HardFP_use].i = 3, it means "The user permitted
> this entity to use both SP and DP VFP instructions (Note: This is
> effectively an explicit version of the default encoded by 0)"
> For out_attr[i].i = 0, it means "The user did not permit this entity
> to use instructions requiring FP hardware".
>
> According to Jie's patch, when out_attr[i].i = 0,
> out_attr[Tag_ABI_HardFP_use].i should be 0 too. But what i saw is
> out_attr[Tag_ABI_HardFP_use].i is also 3, same with
> in_attr[Tag_ABI_HardFP_use].i .
>
> Which compiling option changes out_attr[Tag_ABI_HardFP_use].i to 3?
> And which compiling options set out_attr[i].i to 0?
>
> Thanks
> Barry
>
> 2011/4/28 Barry Song <21cn...@gmail.com>:
>> Hi All,
>> I found Jie has committed a patch
>> "http://sourceware.org/ml/binutils/2010-05/msg00083.html";.
>> I am using the newest binary utils(2.21) and encounted the following ASSERT 
>> in
>> arm_elf32.c:
>> +             if (out_attr[i].i == 0)
>> +               {
>> +                 BFD_ASSERT (out_attr[Tag_ABI_HardFP_use].i == 0);
>>
>> My compiling options are as below,
>> ASM_FLAGS              :=
>> \
>>                        -gdwarf-2                                             
>> \
>>                        -mfpu=vfp                                             
>> \
>>                        -mfloat-abi=softfp                                    
>> \
>>                        -mthumb-interwork
>>
>> C_FLAGS                :=
>> \
>>                        $(ASM_FLAGS)                                          
>> \
>>                        -O3     -Wno-all                                      
>> \
>&

Re: "BFD_ASSERT (out_attr[Tag_ABI_HardFP_use].i == 0) " assert

[Barry Song]

2011/4/28 Andrew Stubbs :
> On 28/04/11 02:30, Barry Song wrote:
>>
>> I am using the newest binary utils(2.21) and encounted the following
>> ASSERT in
>> arm_elf32.c:
>> +             if (out_attr[i].i == 0)
>> +               {
>> +                 BFD_ASSERT (out_attr[Tag_ABI_HardFP_use].i == 0);
>
> [...]
>
>> But not sure whether it is a bug.
>
> I should say that it is a bug because asserts are there to catch bugs. If it
> were checking the input were valid then it would give a diagnostic message.
> That said, it may be that the bug *is* that a diagnostic should be used
> instead of an assert. :)
>
> In this case 'i' will be 'Tag_FP_arch', so the code is saying that if
> Tag_FP_arch is not set, then set that and set Tag_ABI_HardFP_use at the same
> time. Since this is the only place Tag_ABI_HardFP_use is ever set, it should
> not be possible to have it set without Tag_FP_arch also being set, so if the
> assert triggers then something is broken.
>
> So, the question is, what is setting the tags this way? Assuming the code is
> ok, the only other way it could happen is in a malformed input file.
>
> Now, the reason this is an assert, and not a diagnostic, is probably because
> the tags are not considered "user input". Yes, the user can set them via
> assembler directives, but the assembler is supposed to make sure they are
> valid before creating the object file.
>
> Could you please run the broken link again with "-Wl,-t" (trace) and record
> all the input files the linker uses, and check what attributes (tags) are
> set on those files using "readelf -A".

my other two mails explain what happened, in fact link input file is simple:
readelf -A .../dir_soc.o
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "ARM1136JF-S"
  Tag_CPU_arch: v6
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-1
  Tag_FP_arch: VFPv2
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_enum_size: int
  Tag_ABI_HardFP_use: SP and DP
  Tag_ABI_optimization_goals: Aggressive Speed
  Tag_DIV_use: Not allowed

ASSERT found just because we are using -nostdlib flag since we don't
call any library. This flag changed out_attr[Tag_FP_arch] to 0, which
is generically 4 for linaro new toolchain by watching a normal
compile/link process.

>
> I suspect that you may have a mal-formed binary on your system (possibly
> created by an older version of binutils).
>
> Andrew
>

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: "BFD_ASSERT (out_attr[Tag_ABI_HardFP_use].i == 0) " assert

[Barry Song]

Hi Loïc,

2011/4/28 Loïc Minier :
>        Hey
>
>  I've let this one through, but in the future would you please gzip your

thanks for your help.
>  attachments so that they are smaller than 100 KiB total, or host them
>  somewhere?

of course ok.

>
>    Thanks!
> --
> Loïc Minier

-barry

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: "BFD_ASSERT (out_attr[Tag_ABI_HardFP_use].i == 0) " assert

[Barry Song]

2011/4/28 Chung-Lin Tang :
> I think I've seen this assert fail myself before, a long time ago...
>
> While this is probably a BFD bug of some sort, do you happen to have
> assembly code source files among the .o objects? Could you try adding
> ".eabi_attribute 27, 3" to the asm files and see if it links?

Chung-Lin, thanks! i do have asm codes. after adding ".eabi_attribute
27, 3", nothing different. i am just a kernel engineer and an user to
toolchain, i don't know too much well about toolchain like you. but
i'll try to figure out more so that you can help. Anyway, thank you
guys very much.

>
>
> On 2011/4/28 06:06 PM, Barry Song wrote:
>> Hi Andrew,
>>
>> 2011/4/28 Andrew Stubbs > <mailto:andrew.stu...@linaro.org>>:
>>> On 28/04/11 09:59, Barry Song wrote:
>>>>
>>>> my other two mails explain what happened, in fact link input file is
>>>> simple:
>>>
>>> There must be more than one input file to the link, otherwise I
>> believe you
>>> wouldn't see this problem. We need to find out what the other ones are.
>>>
>>>> ASSERT found just because we are using -nostdlib flag since we don't
>>>> call any library. This flag changed out_attr[Tag_FP_arch] to 0, which
>>>> is generically 4 for linaro new toolchain by watching a normal
>>>> compile/link process.
>>>
>>> The -nostdlib flag only changes the list of libraries that will be linked.
>>> It shouldn't change any attributes directly.
>>>
>>> Here's how a link should work, if I understand it correctly:
>>>
>>> 1. The linker creates an empty output file (conceptually). This file will
>>> have all attributes set to default settings (i.e. zero).
>>>
>>> 2. Each input file is then merged into the output file in turn. New
>> sections
>>> are added, or existing ones appended to, and the symbol tables and
>> such are
>>> built incrementally. At each step, the attributes are merged from the
>> input
>>> file to the output file.
>>>
>>> For the first input file, the attribute merge is basically just a
>> copy. Both
>>> Tag_FP_arch and Tag_ABI_HardFP_use should be zero in the (empty) output
>>> file, so we should not be able to hit this condition.
>>>
>>> For the second input file, the attribute merge is more complicated.
>> For each
>>> attribute the result will be either be the union, or the intersection
>> of the
>>> two attributes, or else it will throw an error.
>>>
>>> So, it should be that this can't happen, but clearly it does, so something
>>> is broken, but I can't tell what without reproducing it, or at least
>> seeing
>>> what inputs you're dealing with.
>>>
>>> So, please help me figure out what the full set of input files are and
>> I see
>>> if I can work from there.
>>
>> Thanks very much. i can't send you all source codes, but i can send you
>> the related binaries causing ASSERT.  All link log is as below. Note the
>> red part is where ASSERT happen. Input is dir_soc.o, output is a elf
>> file. It is the first time the elf file begin to born.
>>
>> !-
>> out_attr[i].i:2, out_attr[Tag_ABI_HardFP_use].i:3, in_attr[i].i:2,
>> in_attr[Tag_ABI_HardFP_use].i:3
>> ibfd:
>> /home/vmuser/development/svn/Current/Linux/Main/out/prima2cb/.obj/firmware/nanddisk/NANDDisk/soc/prima2/chip/nand_controller/soc_nand/dir_soc_nand.o
>> obfd:
>> /home/vmuser/development/svn/Current/Linux/Main/out/prima2cb/.obj/firmware/nanddisk/NANDDisk/soc/prima2/chip/nand_controller/dir_nand_controller.o
>>
>> -!
>>
>> make[6]: Leaving directory
>> `/home/vmuser/development/svn/Current/Linux/Main/firmware/nanddisk/src/soc/prima2/chip/nand_controller'
>> make[6]: Entering directory
>> `/home/vmuser/development/svn/Current/Linux/Main/firmware/nanddisk/src/soc/prima2/chip/zone_mgr'
>> make[6]: Leaving directory
>> `/home/vmuser/development/svn/Current/Linux/Main/firmware/nanddisk/src/soc/prima2/chip/zone_mgr'
>>
>>
>> !-
>> out_attr[i].i:2, out_attr[Tag_ABI_HardFP_use].i:3, in_attr[i].i:2,
>> in_attr[Tag_ABI_HardFP_use].i:3
>> ibfd:
>> /home/vmuser/development/svn/Current/Linux/Main/out/prima2cb/.obj/firmware/nanddisk/NANDDisk/soc/prima2/chip/nand_controller/dir_nand_controller.o
>> obfd:
>> /home/vmuser/development/svn/Cur

Re: Linaro 11.05 released

[Barry Song]

2011/5/29 Fathi Boudra :
> Hi,
>
> The Linaro Team is pleased to announce the release of Linaro 11.05.
>
> 11.05 is the second public release that brings together the huge amount of
> engineering effort that has occurred within Linaro over the past 6 months.
>
> This is the first release delivering Android, Ubuntu and the Working Group
> components nicely bundled into one release. We will continue to pick up more
> Working Group and Landing Team outputs in the upcoming monthly releases.
>
> We encourage everybody to use the 11.05 release. The download links for all
> images and components are available on our release page:
>
>  http://wiki.linaro.org/Cycles/1105/Final
>
> Highlights of this release:
>
>  * Linaro GCC 4.5, GCC 4.6 and GDB 7.2 2011.05, recently released components

i have been wondering why always two versions are released at the same
time. what kind of users are expected to use 4.5, and what kind of
users are expected to use 4.6?

my another question is whether we have a policy to maintain old
realease. for example, in case1105 has some bugs, is it possible
linato toolchain team fix those bugs in the old version later. many
users are using old version with bugs, if they move to new version
directly, new feature maybe import new bugs. so people maybe want to
use old version with  bug fixes, but without new features.


>   created by the Toolchain Working Group.
>  * Linaro Kernel 2011.05-2.6.38, the first source tarball release of Linux
>   Linaro done by the Kernel Working Group.
>  * Linaro Evaluation Builds (LEBs) for Android and Ubuntu on PandaBoard with
>   3D graphics acceleration.
>  * Android cross toolchain based on latest gcc-linaro and gdb-linaro
>  * Host development tools (cross compiler, image builders) readily integrated
>   for the Ubuntu distribution users (Lucid, Maverick and Natty support).
>  * And many more...
>
> Using the Android-based images
> ==
>
> The Android-based images come in three parts: system, userdata and boot.
> These need to be combined to form a complete Android install. For an
> explanation of how to do this please see:
>
>  http://wiki.linaro.org/Platform/Android/ImageInstallation
>
> If you are interested in getting the source and building these images
> yourself please see the following pages:
>
>  http://wiki.linaro.org/Platform/Android/GetSource
>  http://wiki.linaro.org/Platform/Android/BuildSource
>
> Using the Ubuntu-based images
> =
>
> The Ubuntu-based images consist of two parts. The first part is a hardware
> pack, which can be found under the hwpacks directory and contains hardware
> specific packages (such as the kernel and bootloader). The second part is
> the rootfs, which is combined with the hardware pack to create a complete
> image. For more information on how to create an image please see:
>
>  http://wiki.linaro.org/Platform/DevPlatform/Ubuntu/ImageInstallation
>
> Getting involved
> 
>
> More information on Linaro can be found on our websites:
>
>  * Homepage: http://www.linaro.org
>  * Wiki: http://wiki.linaro.org
>
> Also subscribe to the important Linaro mailing lists and join our IRC
> channels to stay on top of Linaro developments:
>
>  * Announcements:
>   http://lists.linaro.org/mailman/listinfo/linaro-announce
>  * Development:
>   http://lists.linaro.org/mailman/listinfo/linaro-dev
>  * IRC:
>   #linaro on irc.linaro.org or irc.freenode.net
>   #linaro-android irc.linaro.org or irc.freenode.net
>
> Known issues with this release
> ==
>
> For any errata issues, please see:
>
>  http://wiki.linaro.org/Cycles/1105/Final#Known_Issues
>
> Bug reports for this release should be filed in Launchpad against the
> individual packages that are affected. If a suitable package cannot be
> identified, feel free to assign them to:
>
>  http://www.launchpad.net/linaro
>
> Cheers,
>
> Fathi Boudra
> --
> Linaro Release Manager   |   Platform Project Manager
>
> ___
> linaro-announce mailing list
> linaro-annou...@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-announce
>

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Linaro 11.05 released

[Barry Song]

2011/5/31 Michael Hope :
> On Tue, May 31, 2011 at 1:56 AM, Barry Song <21cn...@gmail.com> wrote:
>> 2011/5/29 Fathi Boudra :
>>> Hi,
>>>
>>> The Linaro Team is pleased to announce the release of Linaro 11.05.
>>>
>>> 11.05 is the second public release that brings together the huge amount of
>>> engineering effort that has occurred within Linaro over the past 6 months.
>>>
>>> This is the first release delivering Android, Ubuntu and the Working Group
>>> components nicely bundled into one release. We will continue to pick up more
>>> Working Group and Landing Team outputs in the upcoming monthly releases.
>>>
>>> We encourage everybody to use the 11.05 release. The download links for all
>>> images and components are available on our release page:
>>>
>>>  http://wiki.linaro.org/Cycles/1105/Final
>>>
>>> Highlights of this release:
>>>
>>>  * Linaro GCC 4.5, GCC 4.6 and GDB 7.2 2011.05, recently released components
>>
>> i have been wondering why always two versions are released at the same
>> time. what kind of users are expected to use 4.5, and what kind of
>> users are expected to use 4.6?
>>
>> my another question is whether we have a policy to maintain old
>> realease. for example, in case1105 has some bugs, is it possible
>> linato toolchain team fix those bugs in the old version later. many
>> users are using old version with bugs, if they move to new version
>> directly, new feature maybe import new bugs. so people maybe want to
>> use old version with  bug fixes, but without new features.
>
> Hi Barry.  Have a look at the toolchain flyer:
>  https://wiki.linaro.org/WorkingGroups/ToolChain/Flyer
>
> At any one time we run a development series and a maintenance series.
> At the moment these are 4.6 and 4.5 based respectively.  When the FSF
> GCC 4.7 comes out, development will stop on 4.5, 4.6 will go into
> maintenance, and we'll start up a new 4.7 branch.
>
> We currently only fix issues on tip and make them available in the
> next monthly release.  While we don't support older releases or older
> branches, the branches are never closed or deleted so you are welcome
> to submit patches or make your own branch and backport changes into
> that.
that problem is most users have no toolchain team and no enough
resources to work on backporting issues.
most people just want to use a "stable" toolchain. so hope the
consolidation of toolchain validation can help :-)

>
> We are considering a 'stable' branch that is released monthly,
> maintained for six months, and only has bug fixes but that hasn't been
> agreed to yet.
>
> Hope that helps,
>
> -- Michael
>

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Linaro 11.05 released

[Barry Song]

2011/6/1 Christian Robottom Reis :
> On Wed, Jun 01, 2011 at 11:18:04AM +0800, Barry Song wrote:
>> > Hi Barry.  Have a look at the toolchain flyer:
>> >  https://wiki.linaro.org/WorkingGroups/ToolChain/Flyer
>> >
>> > At any one time we run a development series and a maintenance series.
>> > At the moment these are 4.6 and 4.5 based respectively.  When the FSF
>> > GCC 4.7 comes out, development will stop on 4.5, 4.6 will go into
>> > maintenance, and we'll start up a new 4.7 branch.
>> >
>> > We currently only fix issues on tip and make them available in the
>> > next monthly release.  While we don't support older releases or older
>> > branches, the branches are never closed or deleted so you are welcome
>> > to submit patches or make your own branch and backport changes into
>> > that.
>> that problem is most users have no toolchain team and no enough
>> resources to work on backporting issues.
>> most people just want to use a "stable" toolchain. so hope the
>> consolidation of toolchain validation can help :-)
>
> I guess the short answer is that for somebody wanting a stable
> toolchain, picking a release from the 4.5 series is the safer bet, and
> if you do find bugs, well, report them to launchpad.net/gcc-linaro or to
> this mailing list.

sure:-) as linaro toolchain really shows strong performance, we did
have used it for several monthes, reported bugs and discussed with
linaro toolchain team. really thank the team very much for the help! i
asked this just because we really want to use it as a long term plan
in our all productions using linux. so the stability is what we really
care about. to users like us, if old release can get maintained, we
can pull the bug fixes from linaro and don't need to upgrade to new
frequently and monthly.
thanks very much for the great contribution of linaro toolchain team.

>
> PS: Michael, can you update the flyer to include the links I suggested
> we add to the release announcement?
> --
> Christian Robottom Reis   | [+55] 16 9112 6430 | http://launchpad.net/~kiko
> Linaro Engineering VP     | [ +1] 612 216 4935 | http://async.com.br/~kiko
>

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

native gdb for Android

[Barry Song]

Hi guys,
I compile a native gdb using linaro 2011.10 by “./configure
--host=arm-none-linux-gnueabi --target=arm-none-linux-gnueabi”, and
the gdb runs on arm target boards directly.
# gdb
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:
.
(gdb)

I can use it to debug native programs on target boards directly. For
example, attach process, set breakpoints, check registers and memory.
One issue is I can't see multi-threads, for example:

PID 646 is system_server by ps
"646 1000  159m Ssystem_server"

Then I use gdb to attach it:

# gdb attach 646
(gdb) info threads
  Id   Target Id Frame
* 1process 646 "system_server" __ioctl ()
at bionic/libc/arch-arm/syscalls/__ioctl.S:15

as you see, “info threads” only shows one thread but there are several
threads in system_server.

But if I compile a new program based on glibc and gnu libthread, I can
see multi-threads by the gdb.

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?

Thanks
Barry

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: native gdb for Android

[Barry Song]

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 <http://gnu.org/licenses/gpl.html>
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:
<http://bugs.launchpad.net/gdb-linaro/>...
attach: No such file or directory.
Attaching to process 643
Reading symbols from /system/bin/app_process...done.
BFD: /system/bin/linker: warning: sh_link not set for section `.ARM.exidx'

warning: Could not load shared library symbols for 6 libraries, e.g.
gralloc.default.so.
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?
Reading symbols from /system/bin/linker...(no debugging symbols found)...done.
Loaded symbols for /system/bin/linker
Reading symbols from /system/lib/libc.so...done.
Loaded symbols for /system/lib/libc.so
Reading symbols from /system/lib/libstdc++.so...(no debugging symbols
found)...done.
Loaded symbols for /system/lib/libstdc++.so
Reading symbols from /system/lib/libm.so...(no debugging symbols found)...done.
Loaded symbols for /system/lib/libm.so
...
__ioctl () at bionic/libc/arch-arm/syscalls/__ioctl.S:15
15  bionic/libc/arch-arm/syscalls/__ioctl.S: No such file or directory.
in bionic/libc/arch-a

Re: native gdb for Android

[Barry Song]

2012/2/3 Thiago Jung Bauermann :
> 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...

Thiago, yes. i will.
PS: now there is a platform/external/gdb.git tree in
http://android.git.linaro.org/gitweb. i would suggest linaro make the
gdb compilable with an Android.mk by arm-eabi-gcc just like other
external components something like:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)

LOCAL_MODULE_TAGS := eng

LOCAL_MODULE := gdb

LOCAL_SRC_FILES += \
   ... \

include $(BUILD_EXECUTABLE)

finally, i hope that will result in a native gdb running on boards and
supporting multithreads. that is actually very useful to many users.

> --
> []'s
> Thiago Jung Bauermann
> Linaro Toolchain Working Group

-barry

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: native gdb for Android

[Barry Song]

Ulrich,
thanks a lot!

2012/2/4 Ulrich Weigand :
> Barry Song <21cn...@gmail.com> wrote.
>> 2012/2/3 Ulrich Weigand :
>> > 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
>
> That would seem a good thing in any case.  (Is there any reason for
> Android to use nonstandard shared library naming conventions?)
>
>> this "fixed" Assertion `_rtld_global_ro._dl_pagesize != 0' , but it
>> still can't find multi-threads for android processes:
>> (gdb) info threads
>>   Id   Target Id         Frame
>> * 1    process 645 "system_server" __ioctl ()
>>     at bionic/libc/arch-arm/syscalls/__ioctl.S:15
>>
>> (gdb) info threads
>>   Id   Target Id         Frame
>> * 1    process 938 "mediaserver" __ioctl ()
>>     at bionic/libc/arch-arm/syscalls/__ioctl.S:15
>
> I had a quick look at the AOSP sources, and found that there actually
> is an implementation of libthread_db that is supposed to work with
> bionic.  Well, there seem to be multiple versions:
>
> ./bionic/libthread_db
> ./ndk/sources/android/libthread_db/gdb-6.6
> ./ndk/sources/android/libthread_db/gdb-7.1.x
>
> I'm not sure why there needs to be a different version for each
> GDB(server) release ...   Maybe there's something in there that
> also needs changing when it's being used by GDB directly instead
> of by gdbserver.
>
> I'll probably not be able to help you very much here; I'd suggest
> you 1) make sure your GDB actually uses the correct version of
> libthread_db (in particular, not one from glibc, but this one that
> handles bionic) and 2) if it still doesn't work, you'll have to
> debug what's going wrong.

for 1, i think gdb has loaded /system/lib/libthread_db.so of android
according to log info after patching gdb:
--- 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

for 2, the answer is it doesn't work yet.  i reported this issue at:
https://bugs.launchpad.net/gdb-linaro/+bug/926472
as Thiago pointed out. Thanks, Thiago!

>
> Note that from a quick look at the above libthread_db sources,
> those actually do not look into bionic data structures at all,
> but rather just traverse /proc to get a thread list.  While this
> is somewhat odd (if you want to do that, you could just do it in
> gdb/server itself -- the only reason why libthread_db is a separate
> project is its close integration with the thread library), it ought
> to make it easier to understand what's going on / wrong.
>
>
> Mit freundlichen Gruessen / Best Regards
>
> Ulrich Weigand
>
-barry

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: [ANNOUNCE] Linaro Toolchain Binaries 2013.07 released

[Barry Song]

2013-07-30 10:01 GMT+08:00 Zhenqiang Chen :
> The Linaro Toolchain and Platform Working Groups are pleased to
> announce the 2013.07 release of the Linaro Toolchain Binaries, a
> pre-built version of Linaro GCC and Linaro GDB that runs on generic
> Linux or Windows and targets the glibc Linaro Evaluation Build.
>
> Uses include:
>  * Cross compiling ARM applications from your laptop
>  * Remote debugging
>  * Build the Linux kernel for your board
>
> What's included:
>  * Linaro GCC 4.8 2013.07-1
>  * Linaro Newlib 2.0 2013.06
>  * Linaro Binutils 2.23 2013.06
>  * Linaro Eglibc 2.17-2013.07-2

So the libraries search path has been moved from /lib /usr/lib to
/lib/arm-linux-gnueabihf/ and /usr//lib/arm-linux-gnueabihf/? i want
to know the rule for that.
if people want to be compatible with old buildsystem, so we suppose we
use a LD_LIBRARY_PATH?

>  * Linaro GDB 7.6 2013.05
>  * A statically linked gdbserver
>  * A system root
>  * Manuals under share/doc/
>

-barry

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

why ld.so in arm-linux-gnueabihf- toolchains search so many paths ?

[Barry Song]

hi guys,
sorry maybe my question is stupid as i am not a toolchain guy.

i have no idea why ld.so search so many paths. for example, put
"-rpath" with /home/cnb1szh/test in a simple test program. then during
dynamic linking at runtime, we get the below linking debug
information:

30693: find library=libmytest.so [0]; searching

30693: search 
path=/home/cnb1szh/test/tls/v7l/neon/vfp:/home/cnb1szh/test/tls/v7l/neon:/home/cnb1szh/test/tls/v7l/vfp:/home/cnb1szh/test/tls/v7l:/home/cnb1szh/test/tls/neon/vfp:/home/cnb1szh/test/tls/neon:/home/cnb1szh/test/tls/vfp:/home/cnb1szh/test/tls:/home/cnb1szh/test/v7l/neon/vfp:/home/cnb1szh/test/v7l/neon:/home/cnb1szh/test/v7l/vfp:/home/cnb1szh/test/v7l:/home/cnb1szh/test/neon/vfp:/home/cnb1szh/test/neon:/home/cnb1szh/test/vfp:/home/cnb1szh/test
(RPATH from file ./hello)

30693: trying file=/home/cnb1szh/test/tls/v7l/neon/vfp/libmytest.so

30693: trying file=/home/cnb1szh/test/tls/v7l/neon/libmytest.so

30693: trying file=/home/cnb1szh/test/tls/v7l/vfp/libmytest.so

30693: trying file=/home/cnb1szh/test/tls/v7l/libmytest.so

30693: trying file=/home/cnb1szh/test/tls/neon/vfp/libmytest.so

30693: trying file=/home/cnb1szh/test/tls/neon/libmytest.so

30693: trying file=/home/cnb1szh/test/tls/vfp/libmytest.so

30693: trying file=/home/cnb1szh/test/tls/libmytest.so

30693: trying file=/home/cnb1szh/test/v7l/neon/vfp/libmytest.so

30693: trying file=/home/cnb1szh/test/v7l/neon/libmytest.so

30693: trying file=/home/cnb1szh/test/v7l/vfp/libmytest.so

30693: trying file=/home/cnb1szh/test/v7l/libmytest.so

30693: trying file=/home/cnb1szh/test/neon/vfp/libmytest.so

30693: trying file=/home/cnb1szh/test/neon/libmytest.so

30693: trying file=/home/cnb1szh/test/vfp/libmytest.so

30693: trying file=/home/cnb1szh/test/libmytest.so


but we don't have /home/cnb1szh/test/tls/, /home/cnb1szh/test/v7l/,
/home/cnb1szh/test/vfp/, /home/cnb1szh/test/neon/, why does the ld.so
search so many paths?


-barry
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: why ld.so in arm-linux-gnueabihf- toolchains search so many paths ?

[Barry Song]

2015-12-01 23:26 GMT+08:00 Ryan Arnold :
>
>
> On Tue, Dec 1, 2015 at 1:24 AM, Barry Song <21cn...@gmail.com> wrote:
>>
>> hi guys,
>> sorry maybe my question is stupid as i am not a toolchain guy.
>>
>> i have no idea why ld.so search so many paths. for example, put
>> "-rpath" with /home/cnb1szh/test in a simple test program. then during
>> dynamic linking at runtime, we get the below linking debug
>> information:
>>
>> 30693: find library=libmytest.so [0]; searching
>>
>> 30693: search
>> path=/home/cnb1szh/test/tls/v7l/neon/vfp:/home/cnb1szh/test/tls/v7l/neon:/home/cnb1szh/test/tls/v7l/vfp:/home/cnb1szh/test/tls/v7l:/home/cnb1szh/test/tls/neon/vfp:/home/cnb1szh/test/tls/neon:/home/cnb1szh/test/tls/vfp:/home/cnb1szh/test/tls:/home/cnb1szh/test/v7l/neon/vfp:/home/cnb1szh/test/v7l/neon:/home/cnb1szh/test/v7l/vfp:/home/cnb1szh/test/v7l:/home/cnb1szh/test/neon/vfp:/home/cnb1szh/test/neon:/home/cnb1szh/test/vfp:/home/cnb1szh/test
>> (RPATH from file ./hello)
>>
>> 30693: trying file=/home/cnb1szh/test/tls/v7l/neon/vfp/libmytest.so
>>
>> 30693: trying file=/home/cnb1szh/test/tls/v7l/neon/libmytest.so
>>
>> 30693: trying file=/home/cnb1szh/test/tls/v7l/vfp/libmytest.so
>>
>> 30693: trying file=/home/cnb1szh/test/tls/v7l/libmytest.so
>>
>> 30693: trying file=/home/cnb1szh/test/tls/neon/vfp/libmytest.so
>>
>> 30693: trying file=/home/cnb1szh/test/tls/neon/libmytest.so
>>
>> 30693: trying file=/home/cnb1szh/test/tls/vfp/libmytest.so
>>
>> 30693: trying file=/home/cnb1szh/test/tls/libmytest.so
>>
>> 30693: trying file=/home/cnb1szh/test/v7l/neon/vfp/libmytest.so
>>
>> 30693: trying file=/home/cnb1szh/test/v7l/neon/libmytest.so
>>
>> 30693: trying file=/home/cnb1szh/test/v7l/vfp/libmytest.so
>>
>> 30693: trying file=/home/cnb1szh/test/v7l/libmytest.so
>>
>> 30693: trying file=/home/cnb1szh/test/neon/vfp/libmytest.so
>>
>> 30693: trying file=/home/cnb1szh/test/neon/libmytest.so
>>
>> 30693: trying file=/home/cnb1szh/test/vfp/libmytest.so
>>
>> 30693: trying file=/home/cnb1szh/test/libmytest.so
>>
>>
>> but we don't have /home/cnb1szh/test/tls/, /home/cnb1szh/test/v7l/,
>> /home/cnb1szh/test/vfp/, /home/cnb1szh/test/neon/, why does the ld.so
>> search so many paths?
>>
>>
>> -barry
>> ___
>> linaro-toolchain mailing list
>> linaro-toolchain@lists.linaro.org
>> https://lists.linaro.org/mailman/listinfo/linaro-toolchain
>
>
>
> Hi Barry, this is a known, intentional behavior of the dynamic-linker.
>
> It defaults to searching for libraries in a tls directory (the glibc
> developers intend to remove this since linux-threads are now gone and nptl
> is the standard but no-one has stepped forward to do so), then directories
> based on the cpu, then directories that are based on the hardware
> capabilities for the platform (AT_HWCAP for 'arm') in various combinations.
> This is why you see it searching the different variations of directories.
>
> This is not a bug.
>
> What this does is allows the Linux distribution to provide optimized
> versions of the libraries in each of those directories.  The optimized
> versions of the library have the most efficient code-gen for the capability
> present.  For instance, in your own library, if you wanted to have a neon
> optimized version and a non-neon optimized version you'd put the neon one in
> test/neon/ and the non-optimized version in test/ directly.

Hi Ryan,
thanks a lot!
i am wondering whether ld.so will check the capbility of ARM to decide
which version should be used.
for example, suppose we have a platform like this:

1. there is no neon in ARM chips,
2. in the filesystem, there is a lib using neon and the other lib without neon

will ld.so use the 2nd lib automatically and ignore the 1st search
path with neon?

if there is no this capbility, it seems the feature is not making so
many senses?

>
> --
> Ryan S. Arnold
> Linaro Toolchain Working Group - Engineering Manager
> www.linaro.org

-barry
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain