Re: toolchain/54233: 32bit compat gdb works poorly

[coypu%sdf.org@localhost]

The following reply was made to PR toolchain/54233; it has been noted by GNATS.

From: coypu%sdf.org@localhost
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: toolchain/54233: 32bit compat gdb works poorly
Date: Sat, 22 Jun 2019 13:57:36 +0000

 I have to roll back to a 2017 kernel to have this working again.
 
 Some bad commits I identified that let me go all the way to Dec 2017:
 
 commit 80d084c7ddc1104b2bf191ccaa8a5347e71253ef
 Author: maxv <maxv%NetBSD.org@localhost>
 Date:   Fri Dec 1 21:22:45 2017 +0000
 
     Don't even bother with the trap frame, and force the default values.
 
 
 commit 4cab1e757c7197a01b6dc268c0104fa43ab7f0aa
 Author: maxv <maxv%NetBSD.org@localhost>
 Date:   Thu Oct 19 09:32:01 2017 +0000
 
     Make sure we don't go farther with 32bit LWPs. There appears to be some
     confusion in the code - in part introduced by myself -, and clearly this
     place is not supposed to handle 32bit LWPs.
     
     Right now we're returning EINVAL, but verily we would need to redirect
     these calls to their netbsd32 counterparts.
 
 One of these, I didn't bother checking separately:
 
 commit 5542798943417f4d1bdb61d0a49a9f8c1c37445c
 Author: maxv <maxv%NetBSD.org@localhost>
 Date:   Tue Jul 25 18:03:56 2017 +0000
 
     This branch must be static, otherwise there is a condition under which
     the KASSERT in startlwp32 would be triggered.
 
 commit ef20f297e5f1527c1b54d4b2de8280a6cca21c71
 Author: maxv <maxv%NetBSD.org@localhost>
 Date:   Tue Jul 25 17:43:44 2017 +0000
 
     Must not be from n32.
 
 
 
 With these reverted I can see a backtrace with an unmodified -current
 userland in Dec 2017.
 
 Still working on bisecting the rest of the commits.