From owner-freebsd-arm@FreeBSD.ORG Fri Jul 18 07:08:38 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 2D1A66F7 for ; Fri, 18 Jul 2014 07:08:38 +0000 (UTC) Received: from o1.newsletters.flashissue.com (o1.newsletters.flashissue.com [50.31.39.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CB3E52083 for ; Fri, 18 Jul 2014 07:08:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=email1.flashissue.com; h=from:to:subject:mime-version:content-type:sender; s=smtpapi; bh=5VNgUNEr0w9/gtJ9bQV+ClXoDn8=; b=xCjWYrFFW5/K6ZsnTVwE+T58/6qbb 4e5TZBySOPlFRLeMsFg2jQzkj+9+idX+F0/zbtIirQsqEOEE5TBARpGuwhYW3x8Y a4wL5j9wqd3wkt7PJNQFetuL9oBvD2/tV1ClmcIdJ+KKR38bq/s9OUcsofpSE7tc gmbQs7AigUegVk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=email1.flashissue.com; h=from:to:subject:mime-version:content-type:sender; q=dns; s=smtpapi; b=ABTEgPVvbq6LypbJbrUNywYM9kQtM+iclyIfai1HlgCMHAGElcI G12iJuCRCUSDPmg4xv6ykK4dxwiUvQcNXFN5g32M8fiRgBcIscw2IWxKwPwX5t87 pKwBn2q/PjBVDumPIkeUeQ+nst+o13ar76R4R0vjILFfoJf84clUHmgA= Received: by mf191.sendgrid.net with SMTP id mf191.29952.53C8C7F438 2014-07-18 07:08:36.834743332 +0000 UTC Received: from ip-10-191-123-72.ec2.internal (ec2-23-21-128-144.compute-1.amazonaws.com [23.21.128.144]) by ismtpd-026.iad1.sendgrid.net (SG) with ESMTP id 147484cbfcb.2d7b.eb004 for ; Fri, 18 Jul 2014 07:08:15 +0000 (GMT) From: "Abiconol Cosm." To: Message-ID: <706736628.25964.1405667295186.JavaMail.root@ip-10-191-123-72> Subject: The best wart remover MIME-Version: 1.0 Date: Fri, 18 Jul 2014 07:08:36 +0000 (UTC) X-SG-EID: t2fXfoZHCw6vGsGKHqKxJ/rV5oGMz4+ZVTdCT99I5wWmNIyIODtY/ms0t7y5x64apCbX4i9t2QzGnJPg6OBoyJ4eoIsKtVWwSYLUTLjYvwt4D8DmySKCK/6+qxzb/a/6lpHBqQng9NhzCOMZQasKLIYpTWl5jFd1jmZhhOL5JyY= X-SG-ID: abJri/z89ozyEJuJkS5UoDaB/x8mT16BRdU6pWHt6OxYThwsJ3IEaTZ5jsgbHZWCh0Z7W3vPiAsxgrZzV8GQrEG4n8K4J+z2/b36tjBTZ9blrYS4At++3TxifsGvvHdCG4g7K6RNnyUF4uTnboWFu+tEtg03k0uQhGUW5wIm/H5mZoHWtVZNwdVpt2mDJPN3KYT//b7E8tAb3mf4//eEFBOaM3qmO1aiDHESkbsfe+voadX43PiTHTjLZDfjS9/npxSpxTO7GaSvftMxQoXvtntVL47WD4H6q7B9XdfHAU6XegW+NZH0f7qcgLyb5qaZWvUkjcrF9wSuEBP7AsFxoqfziAsaoAwAcDXFTBuVTCU= Sender: Abiconol Cosm. Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 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: Fri, 18 Jul 2014 07:08:38 -0000 - =C2=A0 =C2=A0 View in web browser =C2=A0 =C2=A0 ABICONOL Up to one in 10 = people will have a wart at some point in their life, most commonly in child= hood or adolescence. Warts and verrucas are usually harmless and go away by= themselves, with up to nine in 10 disappearing within two years in childre= n but often taking longer in adults. =C2=A0 =C2=A0 [continue...] =C2=A0 =C2= =A0 =C2=A0 =C2=A0 What is a wart ? Definition Warts are small, benign growt= hs caused by a viral infection of the skin or mucous membrane. The virus in= fects the surface layer. The viruses that cause warts are members of the hu= man papilloma virus (HPV) family. Warts are not cancerous but some strains = of HPV, usually not associated with warts, have been linked with... =C2=A0 = =C2=A0 [continue...] =C2=A0 =C2=A0 =C2=A0 Mailing address: Abiconol Cosm, A= ustralia, Sydney, 234 McConnel str., office 231, Sydney, Sydney, 2000, Aust= ralia Unsubscribe from future emails.= From owner-freebsd-arm@FreeBSD.ORG Sat Jul 19 22:35:22 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 0A6F19E8 for ; Sat, 19 Jul 2014 22:35:22 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (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 BEBF92568 for ; Sat, 19 Jul 2014 22:35:21 +0000 (UTC) Received: from c-50-155-136-3.hsd1.co.comcast.net ([50.155.136.3] helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1X8dDs-0008Ae-0v; Sat, 19 Jul 2014 22:35:20 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s6JMZJrq028118; Sat, 19 Jul 2014 16:35:19 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 50.155.136.3 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/afZLfDZPcYRtE0ohyoiBO X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: C++ exceptions in freebsd-arm doesn't seem to work From: Ian Lepore To: Olavi Kumpulainen In-Reply-To: References: Content-Type: text/plain; charset="iso-8859-13" Date: Sat, 19 Jul 2014 16:35:18 -0600 Message-ID: <1405809318.85788.35.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id s6JMZJrq028118 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: Sat, 19 Jul 2014 22:35:22 -0000 On Sat, 2014-06-07 at 14:12 +0200, Olavi Kumpulainen wrote: > Hi there, >=20 > If this question has been discussed before, sorry. I couldn=FFt find an= ything when scanning through the archives though. >=20 > So, I=FFm running FreeBSD-10/stable on a RPI version B as you can see h= ere; >=20 >=20 > Copyright (c) 1992-2014 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 199= 4 > The Regents of the University of California. All rights reserve= d. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 10.0-STABLE #0 r266807: Thu May 29 07:07:08 UTC 2014 > root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 2014051= 2 >=20 >=20 > I have this little program; >=20 > $ cat t.cc >=20 > #include > #include >=20 > void func()=20 > { > throw std::exception(); > } >=20 >=20 > int main() > { > std::cout << "Starting throw-test" << std::endl; >=20 > try > { > func(); > } > catch(std::exception){ > std::cout << =B4In my exception handler" << std::endl; > } > catch(...) { > std::cout << "In catch-all handler" << std::endl; > } >=20 > return 0; > } >=20 > With this Makefile; >=20 > $ cat Makefile >=20 > all : t >=20 > t : t.cc > c++ -o t -fexceptions t.cc >=20 >=20 > Running the above produces the following result; >=20 > $ ./t > Starting throw-test > Fatal error during phase 1 unwinding > Abort (core dumped) >=20 > Which indeed is not what I expected. >=20 > I=FFve tried debugging this for a couple of days and have concluded tha= t my throw clause ends up in contrib/gcc/config/arm/unwind-arm.c. The ass= ociated code in unwind-arm.c is; >=20 > static _Unwind_Reason_Code > get_eit_entry (_Unwind_Control_Block *ucbp, _uw return_address) > { > const __EIT_entry * eitp; > int nrec; > =20 > /* The return address is the address of the instruction following the > call instruction (plus one in thumb mode). If this was the last > instruction in the function the address will lie in the following > function. Subtract 2 from the address so that it points within th= e call > instruction itself. */ > return_address -=3D 2; >=20 > if (__gnu_Unwind_Find_exidx) > { > eitp =3D (const __EIT_entry *) __gnu_Unwind_Find_exidx (return_ad= dress, > &nrec); > if (!eitp) > { > UCB_PR_ADDR (ucbp) =3D 0; > return _URC_FAILURE; > } > } > else > { > eitp =3D &__exidx_start; > nrec =3D &__exidx_end - &__exidx_start; > } >=20 >=20 > Since __gnu_Unwind_Find_exidx =3D=3D NULL, the EIT is located in an arr= ay located between __exidx_start and __exidx_end. >=20 > However, __exidx_end =3D=3D __exidx_start! So the EIT has a length of z= ero, nrec will be 0. libgcc will fail the lookup and return _URC_FAILURE = to libcxxrt.cc, which in turn will produce the fprintf(stderr, "Fatal err= or during phase 1 unwinding\n"); >=20 > # readelf -s t | grep exidx > 36: 0000a267 0 NOTYPE GLOBAL DEFAULT ABS __exidx_start > 47: 0000a267 0 NOTYPE GLOBAL DEFAULT ABS __exidx_end > 115: 0000a267 0 NOTYPE GLOBAL DEFAULT ABS __exidx_end > 150: 0000a267 0 NOTYPE GLOBAL DEFAULT ABS __exidx_start >=20 > So exception throwing in clang++ doesn=FFt seem to work. >=20 > Can any of you guys shed some light on this? >=20 > Cheers, >=20 > /Olavi I checked in a partial fix for c++ exception handling in r268893. It fixes the specific problem you detailed above, which was essentially that the __gnu_Unwind_Find_exidx() function was not available in any shared library, making the unwinder fall back to using the __exidx_start and end symbols, which are only valid in a statically-linked app. With the new function in place, exceptions are closer to working with gcc 4.2.1, but still don't work with clang. With gcc, some things work and some things don't. For example if you throw an exception and in the same function have a catch with the right specific type it segfaults, but a catch(...) will catch it without problems. But you can catch an exception by type if the catch is in a function higher up the call chain from the place it was thrown. We're continuing to debug this at $work, and welcome any input if anyone else makes progress with it. Right now we still don't know whether the segfaults are because of bad unwinder library code or bad unwind data emitted by gcc. (I sure hope it's the library, because that's easier to fix.) On the clang front, it has been said that c++ exceptions work in clang 3.5, so we tried the clang-devel port, and it didn't just work. But it turns out that port hasn't been updated for quite a while, so we may not have tested the code that's supposed to work right. While trying that I discovered that clang 3.5 isn't scheduled for release for about another year, so that really isn't a viable solution for anyone with near-term needs, unless the required changes can be cherry-picked and brought into our version of 3.4. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Jul 19 22:54:09 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED7E2D58; Sat, 19 Jul 2014 22:54:09 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (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 C245626A8; Sat, 19 Jul 2014 22:54:09 +0000 (UTC) Received: from c-50-155-136-3.hsd1.co.comcast.net ([50.155.136.3] helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1X8dW4-000Htg-E7; Sat, 19 Jul 2014 22:54:08 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s6JMs7Se028188; Sat, 19 Jul 2014 16:54:07 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 50.155.136.3 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/DPNkPQySmnBhcLyB6LM6O X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: [CFR] mge driver / elf reloc From: Ian Lepore To: Fabien Thomas In-Reply-To: <14D22EA6-B73C-47BA-9A86-A957D24F23B8@freebsd.org> References: <14D22EA6-B73C-47BA-9A86-A957D24F23B8@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Sat, 19 Jul 2014 16:54:07 -0600 Message-ID: <1405810447.85788.41.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit 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: Sat, 19 Jul 2014 22:54:10 -0000 On Wed, 2014-06-18 at 11:47 +0200, Fabien Thomas wrote: > Hello, > > I've some pending patches to review before commit. > > Fix reloc alignment in ELF: > http://people.freebsd.org/~fabient/ARM/patch-arm_elf_alignfix > > Add missing stat counter: > http://people.freebsd.org/~fabient/ARM/patch-mge_ipackets > > Add missing rcvif: > http://people.freebsd.org/~fabient/ARM/patch-mge_rcvif > > Fix deadlock on transmit in error case: > http://people.freebsd.org/~fabient/ARM/patch-mge_tx_deadlock > > Avoid packet copy on transmit: > http://people.freebsd.org/~fabient/ARM/patch-mge_tx_optim > > Any comment ? > > Fabien Sorry to take so long to reply to this, I'm trying to get caught up. I see you've already committed the mge fixes. I think the ELF alignment fix looks good and should also be committed. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Jul 19 23:57:52 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CFE96E3B for ; Sat, 19 Jul 2014 23:57:52 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (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 8DC9B2B0E for ; Sat, 19 Jul 2014 23:57:52 +0000 (UTC) Received: from c-50-155-136-3.hsd1.co.comcast.net ([50.155.136.3] helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1X8eVj-000FPU-6a; Sat, 19 Jul 2014 23:57:51 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s6JNvnaf028268; Sat, 19 Jul 2014 17:57:49 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 50.155.136.3 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+4x3ccJ9tOsG0jpCU4aqH4 X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: [Bug 175605] devel/binutils: please fix build binutils-2.23.1 in raspberry pi From: Ian Lepore To: Andreas Tobler In-Reply-To: <53C58BAA.5040701@fgznet.ch> 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> <53C58BAA.5040701@fgznet.ch> Content-Type: text/plain; charset="iso-8859-13" Date: Sat, 19 Jul 2014 17:57:49 -0600 Message-ID: <1405814269.85788.48.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id s6JNvnaf028268 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: Sat, 19 Jul 2014 23:57:52 -0000 On Tue, 2014-07-15 at 22:14 +0200, Andreas Tobler wrote: > Hi all, >=20 > thanks for the feedback! >=20 > 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 =3D> /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 =3D> /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 ru= n > >>>>> "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=3Dboth --enable-new-dtags -o z /usr/lib/crt1.o > >>>>> /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /tmp/z-9530c3.o -l= gcc > >>>>> --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 wor= ks. > >>> 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 bloc= ks 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 netb= sd'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 hav= e > >>> 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 day= s. > >> 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 us= ers. > >> 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 maili= ng > >> lists. > > > > I have a 9.x arm-based (atmel) dhcpd and other network services serve= r that > > I run since I couldn=FFt 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=FFve worked > > around them, but most of the issues have since been fixed in -current= and 10. >=20 > My issue is here: >=20 > +++ gas/configure.tgt 1970-01-01 00:16:31.000000000 +0000 > @@ -136,6 +136,9 @@ > arm-*-symbianelf*) fmt=3Delf em=3Dsymbian ;; > arm-*-kaos*) fmt=3Delf ;; > arm-*-conix*) fmt=3Delf ;; > + arm-*-freebsd9* | armeb-*-freebsd9*) fmt=3Delf em=3Dfreebsd ;; > + arm-*-freebsd* | armeb-*-freebsd*) fmt=3Delf em=3Darmfbsdeabi ;; > + arm*-*-freebsd*) fmt=3Delf em=3Darmfbsdvfp ;; >=20 > fyi: > -> armfbsdeabi sets EABI_DEFAULT EF_ARM_EABI_VER5 > and > -> armfbsdvfp sets the same as armfbsdeabi plus FPU_DEFAULT FPU_ARCH_VF= P >=20 > On freebsd9 I leave the 'old' abi and I'm not sure if I should do so. A= s=20 > I understand you both, 9.x is not something official working. It works=20 > if one puts his hands on it and does the mods needed. >=20 Using OABI on 9 is correct, I don't think the EABI support will ever be MFC'd to 9. > On 10.x and up we have the eabi and everthing is nearly fine. Except th= e=20 > vfp support which is only for armv6* and up. Here I'm not so sure if I=20 > do the right thing. > The test cases look right, around 4 fails of 500 tests on my arm- and m= y=20 > armv6 board. >=20 I think you've got it right... arm and armeb use EABI without VFP, and armv6 and armv6hf are EABI with VFP. In theory we can do OABI without VFP on armv6, but I haven't tested that for more than a year. OABI with VFP isn't an option. -- Ian