Date: Sat, 19 Jul 2014 17:57:49 -0600 From: Ian Lepore <ian@FreeBSD.org> To: Andreas Tobler <andreast-list@fgznet.ch> Cc: freebsd-arm@freebsd.org Subject: Re: [Bug 175605] devel/binutils: please fix build binutils-2.23.1 in raspberry pi Message-ID: <1405814269.85788.48.camel@revolution.hippie.lan> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <ian@FreeBSD.org> 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 <stdio.h>
> >>>>>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1405814269.85788.48.camel>