Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Douglas RAILLARD <public.douglas.raillard@gmail.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/1] Fix elf2flt build
Date: Mon, 31 Aug 2015 14:08:16 +0200	[thread overview]
Message-ID: <55E443B0.4010503@gmail.com> (raw)
In-Reply-To: <20150831060501.GA9163@waldemar-brodkorb.de>

On 31/08/2015 08:05, Waldemar Brodkorb wrote:
> Hi,
> Douglas RAILLARD wrote,
> 
>> On 28/08/2015 15:01, Waldemar Brodkorb wrote:
>>> Please disable UCLIBC_HAS_CONTEXT_FUNCS, as the code is not thumb
>>> ready. I'll accept any patches for this 
>>
>> Works better without UCLIBC_HAS_CONTEXT_FUNCS
>>
>>> NPTL is not thumb ready, please use LINUXTHREADS.OLD for ARM no-MMU
>>> or send a fix :)
>>
>> Still fails with LINUXTHREADS_OLD:
>> /working_dir/buildroot/output/host/usr/bin/arm-buildroot-uclinux-uclibcgnueabi-gcc -c libpthread/linuxthreads.old/mutex.c -o libpthread/linuxthreads.old/mutex.os -Wall -Wstrict-prototypes -Wstrict-aliasing -funsigned-char -fno-builtin -fno-asm -fmerge-all-constants -msoft-float -std=gnu99 -mlittle-endian -fstack-protector -nostdinc -I./include -I./include -include libc-symbols.h -I./libc/sysdeps/linux/arm -I./libc/sysdeps/linux -I./ldso/ldso/arm -I./ldso/include -I. -DSTATIC -Os -fstrict-aliasing -I./libpthread/linuxthreads.old/sysdeps/unix/sysv/linux/arm -I./libpthread/linuxthreads.old/sysdeps/arm -I./libpthread/linuxthreads.old/sysdeps/unix/sysv/linux -I./libpthread/linuxthreads.old/sysdeps/pthread -I./libpthread/linuxthreads.old -I./libpthread -I./libc/sysdeps/linux/common -isystem /working_dir/buildroot/output/host/usr/lib/gcc/arm-buildroot-uclinux-uclibcgnueabi/4.9.3/include-fixed -isystem /working_dir/buildroot/output/host/usr/lib/gcc/arm-buildroot-uclinux-uclibcgnue
 abi/4.9.3
/in
>> clude -I/working_dir/buildroot/output/build/linux-headers-4.1.4/usr/include/ -DNDEBUG -DNOT_IN_libc -DIS_IN_libpthread -fstack-protector-all -DIN_LIB=libpthread -fPIC -MT libpthread/linuxthreads.old/mutex.os -MD -MP -MF libpthread/linuxthreads.old/.mutex.os.dep
>> /tmp/ccWVQC5r.s: Assembler messages:
>> /tmp/ccWVQC5r.s:34: Error: selected processor does not support ARM opcodes
>> /tmp/ccWVQC5r.s:35: Error: attempt to use an ARM instruction on a Thumb-only processor -- `swp r3,r3,[r0]'
>> /tmp/ccWVQC5r.s:36: Error: attempt to use an ARM instruction on a Thumb-only processor -- `orr r0,pc,#1'
>> /tmp/ccWVQC5r.s:37: Error: attempt to use an ARM instruction on a Thumb-only processor -- `bx r0'
>> /tmp/ccWVQC5r.s:151: Error: selected processor does not support ARM opcodes
>> /tmp/ccWVQC5r.s:152: Error: attempt to use an ARM instruction on a Thumb-only processor -- `swp r3,r3,[r0]'
>> /tmp/ccWVQC5r.s:153: Error: attempt to use an ARM instruction on a Thumb-only processor -- `orr r0,pc,#1'
>> /tmp/ccWVQC5r.s:154: Error: attempt to use an ARM instruction on a Thumb-only processor -- `bx r0'
>> Makerules:383: recipe for target 'libpthread/linuxthreads.old/mutex.os' failed
>> make[1]: *** [libpthread/linuxthreads.old/mutex.os] Error 1
>> make[1]: Leaving directory '/working_dir/buildroot/output/build/uclibc-1.0.5'
>> package/pkg-generic.mk:156: recipe for target '/working_dir/buildroot/output/build/uclibc-1.0.5/.stamp_built' failed
>> make: *** [/working_dir/buildroot/output/build/uclibc-1.0.5/.stamp_built] Error 2
>>
>> It seems that the problem stems from libpthread/linuxthreads.old/sysdeps/arm/pt-machine.h in testandset function:
>>      83         "\tswp %0, %2, [%3]\n"
>>      84         "\torr %1, pc, #1\n"
>>      85         "\tbx %1\n"
>>
>>
>> Is it still the good place to send such reports or should I post them somewhere else ? (or in a new thread)
> 
> Okay, for me.
> Please enable COMPILE_IN_THUMB_MODE in your uClibc config. It is
> missing in the generated config. Would be cool if you prepare a
> patch with the two fixes.

With COMPILE_IN_THUMB_MODE uClibc-ng now compiles cleanly, thanks for
your help :)
I will send a patch in the next few days for the config file of
uClibc-ng when compiling for Cortex M3.

BTW: Are there any benefits in using 2.24 (default) instead of 2.25.1
and also gcc 4.9.x (default) instead of gcc 5.x ?


Best regards,
Douglas


-- 

Douglas RAILLARD

  reply	other threads:[~2015-08-31 12:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-27 16:47 [Buildroot] [PATCH 1/1] Fix elf2flt build Douglas RAILLARD
2015-08-27 18:35 ` Thomas Petazzoni
2015-08-27 21:00   ` Douglas RAILLARD
     [not found]   ` <6966330.pLhB8QsgjT@raillard-dv6>
2015-08-28  8:09     ` Thomas Petazzoni
2015-08-28 10:17       ` Douglas RAILLARD
2015-08-28 11:20         ` Thomas Petazzoni
2015-08-28 13:01           ` Waldemar Brodkorb
2015-08-30 15:43             ` Douglas RAILLARD
2015-08-31  6:05               ` Waldemar Brodkorb
2015-08-31 12:08                 ` Douglas RAILLARD [this message]
2015-08-31 12:28                   ` Thomas Petazzoni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55E443B0.4010503@gmail.com \
    --to=public.douglas.raillard@gmail.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox