Page MenuHomeFreeBSD

Make devel/riscv64-binutils a slave of devel/binutils.
ClosedPublic

Authored by jhb on Jun 28 2018, 7:09 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Apr 27, 8:41 AM
Unknown Object (File)
Sat, Apr 27, 8:41 AM
Unknown Object (File)
Sat, Apr 27, 8:41 AM
Unknown Object (File)
Sat, Apr 27, 8:41 AM
Unknown Object (File)
Sat, Apr 27, 7:44 AM
Unknown Object (File)
Sat, Apr 27, 7:23 AM
Unknown Object (File)
Fri, Apr 19, 3:53 PM
Unknown Object (File)
Mar 17 2024, 2:43 PM
Subscribers

Details

Summary

Since the riscv support was merged into the upstream binutils repository
prior to the 2.30 release, switch the riscv64-binutils port over to the
standard binutils port rather than building from an alternate branch of
binutils 2.29.

Test Plan
  • riscv64 world built ok in tinderbox, but GENERIC kernel failed to build dtrace.ko due to a mismatch in float ABIs. Will follow up with details.
  • have not booted anything, just compile tested

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Details on the error I get from the kernel build:

/usr/local/riscv64-unknown-freebsd12.0/bin/ld -m elf64lriscv -d -warn-common --build-id=sha1 -r -d -o dtrace.kld dtrace.o dtrace_xoroshiro128_plus.o dtrace_asm.o dtrace_subr.o opensolaris_taskq.o
/usr/local/riscv64-unknown-freebsd12.0/bin/ld: dtrace_asm.o: can't link hard-float modules with soft-float modules
/usr/local/riscv64-unknown-freebsd12.0/bin/ld: failed to merge target specific data of file dtrace_asm.o

# riscv64-unknown-freebsd12.0-readelf -Ah /usr/obj/zoo/jhb/git/freebsd/riscv.riscv64/sys/GENERIC/modules/zoo/jhb/git/freebsd/sys/modules/dtrace/dtrace/dtrace.o
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           RISC-V
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          4326416 (bytes into file)
  Flags:                             0x1, RVC, soft-float ABI
  Size of this header:               64 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           64 (bytes)
  Number of section headers:         41
  Section header string table index: 40
# riscv64-unknown-freebsd12.0-readelf -Ah /usr/obj/zoo/jhb/git/freebsd/riscv.riscv64/sys/GENERIC/modules/zoo/jhb/git/freebsd/sys/modules/dtrace/dtrace/dtrace_asm.o 
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           RISC-V
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          6456 (bytes into file)
  Flags:                             0x5, RVC, double-float ABI
  Size of this header:               64 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           64 (bytes)
  Number of section headers:         16
  Section header string table index: 15

I'm not sure why dtrace_asm.o is marked as hard-float. There's nothing I can see in CFLAGS that forces either -mhard-float or -msoft-float AFAICT.

So comparing the compile output lines, dtrace.o uses '-mabi=lp64' from CFLAGS. dtrace_asm.o includes a second set of -march/-mabi (presumably from AFLAGS) that uses -mabi=lp64d

So it seems that .S files built as part of the kernel use a special rule from config(8) that doesn't include ACFLAGS, but .S files built as part of a kernel module do honor ACFLAGS. I'm testing a fix to sys/conf/kern.mk to append the same soft-float march/mabi lines to ACFLAGS that we currently append to CFLAGS.gcc. Not sure why the old binutils didn't flag this, maybe it was just less picky about the ABIs matching and this is fixed in the newer binutils.

Thanks for doing this. I will test it in Spike and QEMU, and will approve after success.

If you do that before me, please let me know and I will be happy to approve this.

lwhsu requested changes to this revision.Jun 29 2018, 9:48 AM

You may want to remove pkg-descr & distinfo, and update pkg-plist.

This revision now requires changes to proceed.Jun 29 2018, 9:48 AM

I believe the pkg-plist is still correct? All the other devel/<foo>-binutils ports use their own pkg-plist as well.

Remove pkg-descr and distinfo.

In D16053#340348, @jhb wrote:

I believe the pkg-plist is still correct? All the other devel/<foo>-binutils ports use their own pkg-plist as well.

Yes pkg-plist is still needed, but it needs updating for 2.29 -> 2.30.
You can remove it first, and do a "make check-orphans" to see what will be installed, then convert it into pkg-plist.
I have already done this so I can update this port after it gets tested in emulator, or you are also welcomed to do so.

I believe @bapt should be fine with this update. :-)

This is my WIP repository: https://github.com/lwhsu/freebsd-ports-riscv/tree/master/devel/riscv64-binutils .

I'm not very sure if we want STATIC option on, it was copied from aarch64-binutils but it's not in other *-binutils.

  • Update pkg-plist to fix orphans

I don't think we need the STATIC thing, and it's not really clear to me why aarch64 needs it either (supposedly something to do with cross-building under poudriere who I heard from someone (but I can't remember who) and the reasoning seemed a bit dubious).

LGTM, I'll do more tests in emulators and report back. Hope I can find time later this week or next.

This revision is now accepted and ready to land.Jul 3 2018, 4:54 PM
This revision was automatically updated to reflect the committed changes.