<p dir="ltr"><br>
On Jul 15, 2014 11:30 AM, "Martin Jansa" <<a href="mailto:martin.jansa@gmail.com">martin.jansa@gmail.com</a>> wrote:<br>
><br>
> * triggers some issue in gcc-4.9, this call:<br>
> arm-oe-linux-gnueabi-gcc -march=armv5te -mthumb -mthumb-interwork -mtune=xscale<br>
> --sysroot=/OE/build/shr-core/tmp-eglibc/sysroots/spitz -O2 -pipe -g<br>
> -feliminate-unused-debug-types -I.<br>
> -I/OE/build/shr-core/tmp-eglibc/work/xscalete-oe-linux-gnueabi/gdb/7.7-r0/gdb-7.7/gdb<br>
> -I/OE/build/shr-core/tmp-eglibc/work/xscalete-oe-linux-gnueabi/gdb/7.7-r0/gdb-7.7/gdb/common<br>
> -I/OE/build/shr-core/tmp-eglibc/work/xscalete-oe-linux-gnueabi/gdb/7.7-r0/gdb-7.7/gdb/config<br>
> -DLOCALEDIR="\"/usr/share/locale\"" -DHAVE_CONFIG_H<br>
> -I/OE/build/shr-core/tmp-eglibc/work/xscalete-oe-linux-gnueabi/gdb/7.7-r0/gdb-7.7/gdb/../include/opcode<br>
> -I/OE/build/shr-core/tmp-eglibc/work/xscalete-oe-linux-gnueabi/gdb/7.7-r0/gdb-7.7/gdb/../opcodes/..<br>
> -I../bfd<br>
> -I/OE/build/shr-core/tmp-eglibc/work/xscalete-oe-linux-gnueabi/gdb/7.7-r0/gdb-7.7/gdb/../bfd<br>
> -I/OE/build/shr-core/tmp-eglibc/work/xscalete-oe-linux-gnueabi/gdb/7.7-r0/gdb-7.7/gdb/../include<br>
> -I../libdecnumber<br>
> -I/OE/build/shr-core/tmp-eglibc/work/xscalete-oe-linux-gnueabi/gdb/7.7-r0/gdb-7.7/gdb/../libdecnumber<br>
> -I/OE/build/shr-core/tmp-eglibc/work/xscalete-oe-linux-gnueabi/gdb/7.7-r0/gdb-7.7/gdb/gnulib/import<br>
> -Ibuild-gnulib/import -Wall -Wdeclaration-after-statement<br>
> -Wpointer-arith -Wpointer-sign -Wno-unused -Wunused-value<br>
> -Wunused-function -Wno-switch -Wno-char-subscripts -Wmissing-prototypes<br>
> -Wdeclaration-after-statement -Wempty-body -Wmissing-parameter-type<br>
> -Wold-style-declaration -Wold-style-definition -Wformat-nonliteral -c<br>
> -o eval.o -MT eval.o -MMD -MP -MF .deps/eval.Tpo<br>
> /OE/build/shr-core/tmp-eglibc/work/xscalete-oe-linux-gnueabi/gdb/7.7-r0/gdb-7.7/gdb/eval.c<br>
><br>
> just hangs (strace shows occasional call to mmap, brk, munmap) and eats all available memory<br>
> (in my case 20GB), I've waited for 2,5 hours and it didn't finish,<br>
> after removing -mthumb it builds in second.<br>
><br>
> Signed-off-by: Martin Jansa <<a href="mailto:Martin.Jansa@gmail.com">Martin.Jansa@gmail.com</a>><br>
> ---<br>
> meta/recipes-devtools/gdb/<a href="http://gdb_7.7.bb">gdb_7.7.bb</a> | 3 +++<br>
> 1 file changed, 3 insertions(+)<br>
><br>
> diff --git a/meta/recipes-devtools/gdb/<a href="http://gdb_7.7.bb">gdb_7.7.bb</a> b/meta/recipes-devtools/gdb/<a href="http://gdb_7.7.bb">gdb_7.7.bb</a><br>
> index 1abc9d8..bc042ec 100644<br>
> --- a/meta/recipes-devtools/gdb/<a href="http://gdb_7.7.bb">gdb_7.7.bb</a><br>
> +++ b/meta/recipes-devtools/gdb/<a href="http://gdb_7.7.bb">gdb_7.7.bb</a><br>
> @@ -7,6 +7,9 @@ PACKAGECONFIG ??= ""<br>
> PACKAGECONFIG[python] = "--with-python=${WORKDIR}/python,--without-python,python"<br>
> PACKAGECONFIG[babeltrace] = "--with-babeltrace,--without-babeltrace,babeltrace"<br>
><br>
> +# cc1 (4.9) call with -mthumb gets stuck and eats all available memory (over 20GB in my case)<br>
> +ARM_INSTRUCTION_SET = "arm"</p>
<p dir="ltr">we dont want to turn thumb off unconditionally since thumb2 may be ok. </p>
<p dir="ltr">> +<br>
> do_configure_prepend() {<br>
> if [ -n "${@bb.utils.contains('PACKAGECONFIG', 'python', 'python', '', d)}" ]; then<br>
> cat > ${WORKDIR}/python << EOF<br>
> --<br>
> 2.0.0<br>
><br>
> --<br>
> _______________________________________________<br>
> Openembedded-core mailing list<br>
> <a href="mailto:Openembedded-core@lists.openembedded.org">Openembedded-core@lists.openembedded.org</a><br>
> <a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
</p>