Gcc 4.2.1 to be removed before FreeBSD 13, a firm timeline

[Mark Millard]

[Turns out that 32-bit powerpc can not complete
a kyua run and I'd forgotten that the debug
kernel is catching something, stopping normal
boots.]

On 2020-Jan-6, at 10:52, Mark Millard <marklmi at yahoo.com> wrote:

> Warner Losh imp at bsdimp.com wrote on
> Mon Jan 6 06:56:06 UTC 2020 :
> 
>> . . .
>> Second, all other platforms still have the original deadlines to sort out
>> the last lingering issues with the external toolchain and/or clang. mips is
>> a bit up in the air right now since both the external toolchain and clang
>> have issues (though different issues). powerpc 32-bit is sorting out issues
>> as well. arm 32-bit still needs libunwind from gcc. An end of May deadline
>> is ample time for works in progress to get to the point where everything
>> boots and runs sufficiently well to show the platforms are still viable.
>> . . .
> 
> The reference to 32-bit powerpc surprised me,
> unless it is really powerpcspe specific.
> 
> 32-bit FreeBSD is booting the 32-bit powerpc's
> that I have access to, all the way to multi-user:
> Old 32-bit PowerMacs (from 2 socket G4's to an
> old iMac G3.) It is still based on the old ld.
> [All at head -r356187 currently.]
> 
> (I do not have access to a powerpcspe context.)
> 
> True that using 32-bit FreeBSD to boot 64-bit
> PowerPCs that have bridge mode is not working,
> but I'd have expected that to be more of a
> nice-to-have instead of a tier 2 vs. tier 4
> issue. Power-ISA-3/Power9 removed bridge mode,
> if I understand right. So progress on the
> "Can you buy a new one?" scale has started for
> bridge mode.
> 
> May be there is some significant bridge mode
> booting use that I'm not imagining but that
> exists? (I've used it some but would not
> call it required.)
> 
> I am able to put a 32-bit world in a 64-bit G5
> directory tree and use it via poudriere to build
> 32-bit ports under 64-bit FreeBSD. And lib32 is
> working so I can also directly execute the 32-bit
> code under the 64-bit FreeBSD . (I've not tried
> any kyua passes yet, 64-bit or 32-bit.)
> 
> Other things I've seen from Ed Maste left the
> impression that the old ld would not be a
> cause-tier-4 issue if lld does not make it in
> time for some reason. (Nice to delete old ld for
> 13, not required to?)
> 
> Of course, it might be that 32-bit powerpc
> (non-spe) just fails the "Can you buy a new
> one?" test. But, if applied, that would mean
> that sorting anything out might still leave it
> tier 4.
> 
> Are there could-cause-tier-4 types of problems
> that I'm not aware of for 32-bit powerpc
> (non-spe)?
> 
> For me, tier-4 for the old 32-bit PowerMac's
> would just mean that I no longer use them,
> even when I could have access. My use is not
> something that would drive FreeBSD choices.
> But I'm still interested in what the choices
> will end up being and so am tracking.

I have run into something that is broken
for both non-debug and debug kernels for
32-bit powerpc, at least for the old
PowerMac contexts that I have access to.

The kyua test:

sys/vm/mlock_test:mlock__copy_on_write_vnode

never completes, using a cpu nearly full time.
The stuck process can not be killed. (This
blocks making a complete kyua test set run.)

It appears to be stuck during the test's

       ATF_REQUIRE(ptrace(PT_WRITE_D, pid, addr, val) == 0);

I've other details that I've sent out notes
on in other messages.

It has been a long time since I've run kyua
on 32-bit powerpc. I've no clue if this is
fairly new or not.

I do not know if being able to run a kyua
test pass to completion (or even stricter
kyua criteria) are considered or not.


I had also forgotten that the debug kernel
stops a normal boot, complaining of memory
that is modified after being freed. (In my
contexts, boot -v has side stepped the
issue. boot -s has in some contexts, but
not in others.) I do not know how new this
issue is. (I rarely use a debug kernel.)



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)