address reviewer comments

addresses commiter's suggestions

Hi! Any comments/remarks to the updated version?

In D27666#734447, @lattera-gmail.com wrote:

In D27666#734443, @mw wrote:

Hi,

I'm refreshing the discussion. The current status is following:

3. Fixes for the outstanding bugs ntpd (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253208) and Firefox/Thunderbird (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239873) landed on Friday. Hopefully this will cover all cases that might have remained unknown until now.

It seems like a problem with the underlying AS{L}R implementation. HardenedBSD has not needed to make any changes to any application since it completed its PaX-inspired ASLR implementation in 2015. If applications experience issues with FreeBSD's AS{L}R implementation, it'd be safe to assume a problem with the AS{L}R implementation, not the application.

In D27666#734443, @mw wrote:

Hi,

I'm refreshing the discussion. The current status is following:

3. Fixes for the outstanding bugs ntpd (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253208) and Firefox/Thunderbird (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239873) landed on Friday. Hopefully this will cover all cases that might have remained unknown until now.

I'm refreshing the discussion. The current status is following:

1. PIE enabled by default in 64-builds.
2. Ports' exp-run issues are fixed (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214864)
3. Fixes for the outstanding bugs ntpd (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253208) and Firefox/Thunderbird (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239873) landed on Friday. Hopefully this will cover all cases that might have remained unknown until now.

Initialize RGB offsets along with palette.

Address reviewer's comments

I tested this patch with D31232 few weeks ago on the Blackbird and it looks good to me once it's approved.

• Address reviewer's comments

In D31804#717525, @dim wrote:

Let's do this for now to get the PowerPC builds working again. But also be aware that the bisected upstream commit is only exposing an underlying issue: most likely the root cause is in the PowerPC backend.

Let's do this for now to get the PowerPC builds working again. But also be aware that the bisected upstream commit is only exposing an underlying issue: most likely the root cause is in the PowerPC backend.

In D31698#715220, @fbsd-phab_maskray.me wrote:

This is not suitable for the upstream. The root cause behind dso_local needs to be found and fixed.

Glad to see you solve the last piece of this puzzle!

This is not suitable for the upstream. The root cause behind dso_local needs to be found and fixed.

I wouldn't say "reverts LLVM commit 2518433f861fcb877d0a7bdd9aec1aec1f77505a", but something like "amends LLVM commit 2518433f861fcb877d0a7bdd9aec1aec1f77505a", as we're adding code here. But otherwise, LGTM!

Abandoned in favor of D31698

In D31646#713731, @emaste wrote:

Move logic to BROKEN_OPTIONS as suggested by @jhibbits

This will work for src itself, but I think it won't work with ports that use /usr/share/mk?

Move logic to BROKEN_OPTIONS as suggested by @jhibbits

In D31646#713717, @emaste wrote:

is there a PR to reference here?

Move logic to BROKEN_OPTIONS as suggested by @jhibbits

is there a PR to reference here?

Great job luporl!

I no longer have access to any operational old-PowerMacs. (And never had access to any other example types of PowerPC/Power hardware.) As such, I'll no longer be involved in powerpc64 or 32-bit powerpc activities.

This approach of auto detecting the correct frame buffer physical address based on Vendor ID looks good.
It would help to make FreeBSD graphics work out of the box for Blackbird and Talos II machines, instead of forcing the user to figure out the physical address of its VGA adapter and pass it to the kernel manually, or else the system just hangs.
Ideally, Petitboot should fix it on their side, but I don't know if it will happen anytime soon, since Linux isn't affected, because it just talks directly to ASPEED video device, instead of relying on the framebuffer info exposed in the device tree.

D31232 fixes OFWFB with radix. After it lands it should be safe to make radix default.

After discussion with @imp , we decided to try the "reroot" approach instead. It appears to be generic solution for other modules as well, and can be used on other platforms.
A new review entry will be created when it's ready for review.

For some reason this breaks the boot with VGA console on Blackbird.
I'm using D30626 locally, but reverted it as well. With D30626 reverted and adding kernel parameter 'hw.ofwfb.physaddr=0x000600c280000000' the kernel hangs as well with no output.

Looks fine to me.

In D30793#692367, @imp wrote:

That is, I'd rather see ZFS64

include GENERIC64
options ZFS

etc

That is, I'd rather see ZFS64

include GENERIC64
options ZFS

etc

I'd really rather we didn't do this... I don't think it's a good idea....

It ended up being not entirely necessary due to the linker behavior of forcing required sections into whatever segment is a natural fit for them, unless we explicitly break it with /DISCARD/.

Is this still needed? We've had ifuncs for a year now, with no problems.

Seems to work fine on my G4.

Rebase against latest code.

Updating comments

Break instead of return, keeping it consistent with previous code

Update with reviewer comments
retested

This is superseded by D29136.

Address jhibbits' comments

I created D29550, D29551, D29552 and D29553, which allow us to disable stack gap for ntpd during build.

Thanks for re-testing. I had tested it on my blackbird but it has only one socket populated.

BTW I got a second PS3 in the mail today so I now have the ability to test both a modern OtherOS++ (Rebug 4.86.1) setup and a classic OtherOS on OFW 2.80 setup.

I haven't had any luck doing raw kernel loads on mine. Are you trying with ELFv1 or ELFv2 kernels? I can't get either 12.2 or -current kernels to load properly, is there some special petitboot version you are using with yours?

• Fix bug in host_open error path
• Fix linker script problems

I did a full test run with the updated version of this patch in (among others) and it worked fine.