From owner-freebsd-arm@FreeBSD.ORG Tue Jul 15 20:14:51 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A98E52D9; Tue, 15 Jul 2014 20:14:51 +0000 (UTC) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 397E42FEF; Tue, 15 Jul 2014 20:14:50 +0000 (UTC) Received: from [192.168.225.11] (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id s6FKEYUS097206; Tue, 15 Jul 2014 22:14:40 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <53C58BAA.5040701@fgznet.ch> Date: Tue, 15 Jul 2014 22:14:34 +0200 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Warner Losh , Ian Lepore Subject: Re: [Bug 175605] devel/binutils: please fix build binutils-2.23.1 in raspberry pi References: <201407121943.s6CJhT2p097909@mech-cluster241.men.bris.ac.uk> <53C19400.6050404@fgznet.ch> <1405370509.1312.11.camel@revolution.hippie.lan> <9C3614F7-C311-453F-B0E7-BE0312766640@bsdimp.com> In-Reply-To: <9C3614F7-C311-453F-B0E7-BE0312766640@bsdimp.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 20:14:51 -0000 Hi all, thanks for the feedback! On 14.07.14 22:45, Warner Losh wrote: > > On Jul 14, 2014, at 2:41 PM, Ian Lepore wrote: > >> On Sat, 2014-07-12 at 22:01 +0200, Andreas Tobler wrote: >>> On 12.07.14 21:43, Anton Shterenlikht wrote: >>>>>> --- Comment #6 from mexas@bris.ac.uk --- >>>>>> Forgot to say that this was with Andreas Tobler's patchset. >>>>>> Also, it segfaults with the OS default ld too: >>>>>> >>>>>> $ cat z.c >>>>>> #include >>>>>> int main(int argc, char **argv) >>>>>> { >>>>>> printf("mumu\n"); >>>>>> return 0; >>>>>> } >>>>>> $ cc -c z.c -Wall >>>>>> $ /usr/local/bin/ld -o z /usr/lib/crt1.o /usr/lib/crti.o z.o -lc >>>>>> $ ldd z >>>>>> z: >>>>>> libc.so.7 => /lib/libc.so.7 (0x2003c000) >>>>>> $ file z >>>>>> z: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses >>>>>> shared libs), for FreBSD 10.0 (1000710), not stripped >>>>>> $ ./z >>>>>> Segmentation fault (core dumped) >>>>>> $ /usr/bin/ld -o z /usr/lib/crt1.o /usr/lib/crti.o z.o -lc >>>>>> $ ldd z >>>>>> z: >>>>>> libc.so.7 => /lib/libc.so.7 (0x2003c000) >>>>>> $ file z >>>>>> z: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses >>>>>> shared libs), for FreBSD 10.0 (1000710), not stripped >>>>>> $ ./z >>>>>> Segmentation fault (core dumped) >>>>>> $ >>>>>> >>>>> Why are you using this strange invocation of the linker? If I run >>>>> "cc -v -o z z.c", here is how it invokes ld: >>>>> >>>>> "/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 >>>>> --hash-style=both --enable-new-dtags -o z /usr/lib/crt1.o >>>>> /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /tmp/z-9530c3.o -lgcc >>>>> --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s >>>>> --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o >>>>> >>>>> The resulting program runs without difficulty. -- George >>>> >>>> well, I copied my invocation from: >>>> http://people.freebsd.org/~rene/patches/binutils-rpi-bug.txt >>>> >>>> but you are right. I have now did just the same >>>> using /usr/local/bin/ld, and the executable worked. >>>> >>>> So probably Andreas Tobler's patchset should >>>> be committed? >>>> >>>> I'm building lang/gcc right now, will see how it goes. >>> >>> You can save the time for gcc. Nothing else than the system gcc works. >>> I do some work on gcc-4.10 and it is hairy. >>> I can bootstrap gcc-4.10 but I have some issues with tls which blocks me >>> to come out with my patch set. The overall view is good. >> >> >>> I even have C++ exceptions working with EABI. >> >> We are actively working on this at $work (using clang, not gcc) and I'd >> love to see whatever patches you've got. I was about to import netbsd's >> find_exidx.c for ld-elf.so, but if you've already done it I won't >> bother. There are other aspects of it still not working for us, so >> maybe you've solved things we're still working on. >> >>> >>> Also, the binutils patch set is not satisfying for me. I do not have >>> feedback for arm*b nor for arm* < FreeBSD 10.0. >>> >> >> I doubt you'll ever get feedback for either of these. We only have 2 or >> 3 users who have hardware and are even trying to use armeb these days. >> The hardware is old and rare. -current only became usable again on >> armeb in the past week or two. >> >> As for arm on < 10, there's not much support. and not many active users. >> It's not an official project policy or anything, but in effect we've >> abandoned active support on anything older than 10 due to lack of >> resources. We use 8.2 with arm at work, and all the patches we've >> generated there over the years have been merged to 8, 10, and 11. >> >> 9.x on arm has always been a nonexistant thing for me. I don't know of >> anybody even trying to use it, based on the traffic on irc and mailing >> lists. > > I have a 9.x arm-based (atmel) dhcpd and other network services server that > I run since I couldn’t get the 10.x MCI driver on atmel to work on the newer SAM9 > SoCs. All the optimizations for it work great on the AT91RM9200, but break newer > ones. > > That said, there are a number of bumps in the 9.x support in arm. :( I’ve worked > around them, but most of the issues have since been fixed in -current and 10. My issue is here: +++ gas/configure.tgt 1970-01-01 00:16:31.000000000 +0000 @@ -136,6 +136,9 @@ arm-*-symbianelf*) fmt=elf em=symbian ;; arm-*-kaos*) fmt=elf ;; arm-*-conix*) fmt=elf ;; + arm-*-freebsd9* | armeb-*-freebsd9*) fmt=elf em=freebsd ;; + arm-*-freebsd* | armeb-*-freebsd*) fmt=elf em=armfbsdeabi ;; + arm*-*-freebsd*) fmt=elf em=armfbsdvfp ;; fyi: -> armfbsdeabi sets EABI_DEFAULT EF_ARM_EABI_VER5 and -> armfbsdvfp sets the same as armfbsdeabi plus FPU_DEFAULT FPU_ARCH_VFP On freebsd9 I leave the 'old' abi and I'm not sure if I should do so. As I understand you both, 9.x is not something official working. It works if one puts his hands on it and does the mods needed. On 10.x and up we have the eabi and everthing is nearly fine. Except the vfp support which is only for armv6* and up. Here I'm not so sure if I do the right thing. The test cases look right, around 4 fails of 500 tests on my arm- and my armv6 board. I hope I could show my issues. Thanks again. Andreas