[Bug 175605] devel/binutils: please fix build binutils-2.23.1 in raspberry pi

[Warner Losh]

On Jul 14, 2014, at 2:41 PM, Ian Lepore <ian at 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 at 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.

Warner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20140714/2fff0078/attachment.sig>