NetBSD Problem Report #54233

From www@netbsd.org  Sun May 26 12:58:02 2019
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id CEE147A159
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 26 May 2019 12:58:01 +0000 (UTC)
Message-Id: <20190526125801.0045A7A1E0@mollari.NetBSD.org>
Date: Sun, 26 May 2019 12:58:00 +0000 (UTC)
From: coypu@sdf.org
Reply-To: coypu@sdf.org
To: gnats-bugs@NetBSD.org
Subject: 32bit compat gdb works poorly
X-Send-Pr-Version: www-1.0

>Number:         54233
>Category:       toolchain
>Synopsis:       32bit compat gdb works poorly
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    mgorny
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun May 26 13:00:00 +0000 2019
>Last-Modified:  Sat Jun 22 14:00:02 +0000 2019
>Originator:     coypu
>Release:        NetBSD 8.99.41
>Organization:
>Environment:
NetBSD plu 8.99.41 NetBSD 8.99.41 (GENERIC) #0: Thu May 23 18:48:19 IDT 2019  fly@plu:/home/fly/obj/sys/arch/amd64/compile/GENERIC amd64

>Description:
Either pkgsrc or base gdb is not very good.
It doesn't have the ability even to disassemble where it is.

> cat test8.c
#include <stdio.h>
int main() {
	printf("Hello world\n");
	return 0;
}
> gcc test8.c -m32
> gdb -q ./a.out
Reading symbols from ./a.out...(no debugging symbols found)...done.
(gdb) b main
Breakpoint 1 at 0x804887a
(gdb) r
Starting program: /home/fly/a.out 
warning: `/usr/libexec/ld.elf_so': Shared library architecture i386:x86-64 is not compatible with target architecture i386.
warning: `/usr/libexec/ld.elf_so': Shared library architecture i386:x86-64 is not compatible with target architecture i386.
Couldn't read debug registers: No such file or directory.
(gdb) disas
No function contains program counter for selected frame.
(gdb) x/i $pc
=> 0x45e187:	Cannot access memory at address 0x45e187
(gdb) c
Continuing.
Couldn't read debug registers: No such file or directory.
(gdb) c
Continuing.
Couldn't read debug registers: No such file or directory.
(gdb) c
Continuing.

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.

>How-To-Repeat:

>Fix:

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: toolchain-manager->mgorny
Responsible-Changed-By: mgorny@NetBSD.org
Responsible-Changed-When: Sun, 26 May 2019 20:08:14 +0000
Responsible-Changed-Why:
I will attempt to fix missing compat32 code.


From: Christos Zoulas <christos@zoulas.com>
To: gnats-bugs@netbsd.org
Cc: =?utf-8?B?TWljaGHFgiBHw7Nybnk=?= <mgorny@netbsd.org>,
 toolchain-manager@netbsd.org,
 netbsd-bugs@netbsd.org,
 gnats-admin@netbsd.org,
 coypu@sdf.org
Subject: Re: toolchain/54233 (32bit compat gdb works poorly)
Date: Sun, 26 May 2019 16:11:10 -0400

 I think that the problem is partially within gdb...

 christos

 > On May 26, 2019, at 4:08 PM, mgorny@netbsd.org <mgorny@NetBSD.org> wrote:
 > 
 > Synopsis: 32bit compat gdb works poorly
 > 
 > Responsible-Changed-From-To: toolchain-manager->mgorny
 > Responsible-Changed-By: mgorny@NetBSD.org
 > Responsible-Changed-When: Sun, 26 May 2019 20:08:14 +0000
 > Responsible-Changed-Why:
 > I will attempt to fix missing compat32 code.
 > 
 > 

From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= <mgorny@gentoo.org>
To: Christos Zoulas <christos@zoulas.com>, gnats-bugs@netbsd.org
Cc: toolchain-manager@netbsd.org, netbsd-bugs@netbsd.org, 
	gnats-admin@netbsd.org, coypu@sdf.org
Subject: Re: toolchain/54233 (32bit compat gdb works poorly)
Date: Sun, 26 May 2019 22:20:40 +0200

 --=-qdsQUkJSppjCW2YioBhz
 Content-Type: text/plain; charset="UTF-8"
 Content-Transfer-Encoding: quoted-printable

 On Sun, 2019-05-26 at 16:11 -0400, Christos Zoulas wrote:
 > I think that the problem is partially within gdb...
 >=20

 It's possible.  However, I certainly do see that dbreg operations are
 commented out in compat32, so I'll try to fix at least that.

 --=20
 Best regards,
 Micha=C5=82 G=C3=B3rny


 --=-qdsQUkJSppjCW2YioBhz
 Content-Type: application/pgp-signature; name="signature.asc"
 Content-Description: This is a digitally signed message part
 Content-Transfer-Encoding: 7bit

 -----BEGIN PGP SIGNATURE-----

 iQGTBAABCgB9FiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAlzq9RhfFIAAAAAALgAo
 aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEM3
 NkE4NDUwOTQwOThEMjhDQzhCMjZDNTYzOUFEQUUyMzI5RTI0MEUACgkQY5ra4jKe
 JA6OrggAqlmcPeGN6usea9awNCoTrFCVHSPHVO6yGttorM9Gf7a0wY8xXt5qPv3X
 jbH/rr+4A/SXi4pOh6xH0fwcUFNUEGN+QmjKO5pn1vsiPNmKt69lwML3DDlfOaxw
 Vr4poLVO85TugkmDN3GRXJASX+FA3R3ERBqIsJNmWvOcPLiKafphEPruerUFAbR5
 +3ZxkIQ5mTqhYk0DM1T/TpadlzXAy9LNOTjTga5N5Z/zCGBiMTfboC5MR2qwJ2fN
 uOvWl34kOvWrPQY6XAfnGpUdEUJQRtYUA9hKHSPuv4PC04K6BQc8wbztaAgvMJ6v
 jDLvdj11SCOlPcJxjgweQx9FRweF/Q==
 =HV6k
 -----END PGP SIGNATURE-----

 --=-qdsQUkJSppjCW2YioBhz--

From: coypu@sdf.org
To: gnats-bugs@netbsd.org
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>
 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>
 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>
 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>
 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.

>Unformatted:

Home	PR Database Search