Date: Sun, 20 Jul 2014 21:59:59 +0200 From: Andreas Tobler <andreast-list@fgznet.ch> To: Ian Lepore <ian@FreeBSD.org> Cc: freebsd-arm@FreeBSD.org Subject: Re: [Bug 175605] devel/binutils: please fix build binutils-2.23.1 in raspberry pi Message-ID: <53CC1FBF.5010401@fgznet.ch> In-Reply-To: <1405814269.85788.48.camel@revolution.hippie.lan> 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> <1405814269.85788.48.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On 20.07.14 01:57, Ian Lepore wrote:
> On Tue, 2014-07-15 at 22:14 +0200, Andreas Tobler wrote:
>> 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 <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 => /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.
>>
>
> Using OABI on 9 is correct, I don't think the EABI support will ever be
> MFC'd to 9.
ok.
>> 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 think you've got it right... arm and armeb use EABI without VFP, and
> armv6 and armv6hf are EABI with VFP.
ok.
> 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.
I'll go ahead by the end of the coming week, after my vacation.
Thanks again and also thanks for the exidx stuff. Works fine here.
Andreas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53CC1FBF.5010401>