I think this looks fine of course since it is what I suggested (:-P), but would prefer to have someone else from transport sign off on it as well.

I think this is ok as far as I can tell.

My usage of MIPS is confined to qemu for CHERI stuff. CheriBSD has various pmap changes for MIPS though none that fix the issue kib@ noted. In particular CheriBSD has a new map for mips64 that is derived from the amd64 pmap and supports superpages. It also supports using large pages for the kstack which is really needed for newer compilers which bloat kstack usage. (Though one thing that isn't clear to me is why we don't just contigalloc kstacks for mips and then use kseg0 addresses rather than relying on pinned TLB entries for the kstack?)

Update: I've done a buildworld (though newer gcc is pickier about some things that I need to post some src patches for review) and have built base/binutils and base/gcc using this as a CROSS_TOOLCHAIN.

• Rework to explicitly remove this header so that this is check-plist friendly.
• Bump portrevision.

Normally @pizzamig is quite responsive on reviews for devel/gdb, so I wonder if he might be on vacation or some such?

You can put 'Approved by: jhb' and I'll take any fallout. Ed is on vacation this week AFAIK.

• Don't enable init_array/fini_array for arm-none-eabi-gcc and aarch64-none-elf-gcc.

I think this one can be abandoned now?

Don't forget to update the date (Dd) in the manpage before committing. I would probably not include the sample output in the commit message but instead send a reply e-mail to the commit mail that includes the sample output. For future reference, jkim@ is probably a good person to add on any ACPI-related reviews.

Oof, I failed to realize that some of these errors are not startup related, so maybe just '4 exited due to an error' in the manpage. I do think the earlier changes to use err() were also good changes, I would just stick with '4' for the exit value. However, if you want to commit this as-is for now and adopt err() in place of fprintf/perror + exit as a later change that is ok with me as well. This is fine with me with the manpage tweak (or some similar tweak).

err(errno) is probably not going to work well. For example ENOENT is 2 which maps to "2 halted" in the manpage.

Ping

Can this be committed already? :)

Have verified via ptrace_test on arm64 as well now, so both arm and arm64 have been runtime tested.

I think this page might have referred to some of these folks in the past, but those individuals have been purged by now (at least the ones mentioned explicitly in the text). Do we have any other references to things like re@ owning release branches (and other branches during freezes?) or secteam@ owning certain parts of the tree?

I would also add a bullet in the commit log to say "Remove comments specific to CVS". Taking files off of the vendor branch and some of the other language was CVS specific and it's good that you are removing it.

I've reworked this change to just remove ACFLAGS instead. No other platforms set anything in ACFLAGS in bsd.cpu.mk so I think this is more consistent. We could perhaps set AFLAGS, but I don't think anything uses AFLAGS in the tree, so I'd rather wait to add that until a real need arises.

• Drop ACFLAGS entirely.

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).

• Update pkg-plist to fix orphans

• Updated to use 'udf' on 32-bit arm and tested on 32-bit arm.
• Still need to verify arm64.

• Make init/fini conditional on OSVERSION for base/gcc.
• Add PORTREVISION bumps.

Remove pkg-descr and distinfo.

Actually, I wonder if ACFLAGS shouldn't be removed from bsd.cpu.mk instead. ACFLAGS is always included in addition CFLAGS, so the settings in ACFLAGS are redundant with CFLAGS in bsd.cpu.mk. (There is a separate AFLAGS for flags passed to a standalone assembler. Perhaps the ACFLAGS in bsd.cpu.mk was supposed to be AFLAGS instead?)

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

The build failure is fixed by D16054.

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.

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

Details on the error I get from the kernel build:

While my tinderbox is still running, the riscv64 buildworld is now compiling things with the right compiler (previously it died trying to compile the very first thing in libcompiler_rt and it's beyond that stage now)

In D16027#339568, @kib wrote:

Where the overflow occurs ? In this line ?

		phys_avail[3] = 0x90000000 + (ememsize - memsize);

Yes, they probably will need those. I wanted to get feedback for the idea of how these are enabled (if we wanted to do something with OSVERSION, etc.) first and then add the bumps to the final candidate patch.