NetBSD Problem Report #58225
From mlelstv@tazz.1st.de Sun May 5 07:57:41 2024
Return-Path: <mlelstv@tazz.1st.de>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.3 with cipher TLS_AES_256_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 EF1A61A9238
for <gnats-bugs@gnats.NetBSD.org>; Sun, 5 May 2024 07:57:40 +0000 (UTC)
Message-Id: <20240505063503.8B722CCAE5@tazz.1st.de>
Date: Sun, 5 May 2024 08:35:03 +0200 (CEST)
From: mlelstv@netbsd.org
Reply-To: mlelstv@netbsd.org
To: gnats-bugs@NetBSD.org
Subject: netbsd9/amd64 requires COMPAT_16 for 32bit support
X-Send-Pr-Version: 3.95
>Number: 58225
>Category: kern
>Synopsis: netbsd9/amd64 requires COMPAT_16 for 32bit support
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: pgoyette
>State: feedback
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun May 05 08:00:00 +0000 2024
>Closed-Date:
>Last-Modified: Thu Sep 05 08:35:01 +0000 2024
>Originator: Michael van Elst
>Release: NetBSD 10.99.10
>Organization:
--
Michael van Elst
Internet: mlelstv@serpens.de
"A potential Snark may lurk in every tree."
>Environment:
System: NetBSD tazz 10.99.10 NetBSD 10.99.10 (TAZZ) #401: Sun May 5 05:55:10 UTC 2024 mlelstv@slowpoke:/scratch2/obj.amd64/scratch/netbsd-current/src/sys/arch/amd64/compile/TAZZ amd64
Architecture: x86_64
Machine: amd64
>Description:
You can run 32bit NetBSD binaries on amd64 by using a kernel that is built
with COMPAT_NETBSD32 (like GENERIC). But for binaries from netbsd-9 or older,
this relies on the compat_netbsd32_16 module to be present to handle the
old signal context.
When you run a kernel without the older COMPAT options, you don't expect older
compat modules to be loaded. If you use a !INSECURE kernel, autoloading the
modules will also fail, leading to strange failures (e.g. python3.1.2 failing
to build).
Modules loaded because of compat_netbsd32_16 requirement.
compat_100 exec filesys a 2 - -
compat_16 exec filesys a 1 - compat_20
compat_20 exec filesys a 2 - compat_30
compat_30 exec filesys a 2 - compat_util,compat_40
compat_40 exec filesys a 2 - compat_50
compat_50 exec filesys a 2 - compat_60
compat_60 exec filesys a 2 - compat_70
compat_70 exec filesys a 1 - compat_80
compat_80 exec filesys a 2 - compat_90
compat_90 exec filesys a 2 - compat_100
compat_netbsd32 exec builtin - 7 - ksem,compat_util,exec_elf32
compat_netbsd32_100 exec filesys a 1 - compat_netbsd32,compat_100
compat_netbsd32_16 exec filesys - 0 - compat_netbsd32_20,compat_16
compat_netbsd32_20 exec filesys a 1 - compat_netbsd32_30,compat_20
compat_netbsd32_30 exec filesys a 1 - compat_netbsd32_40,compat_30
compat_netbsd32_40 exec filesys a 1 - compat_netbsd32_50,compat_40
compat_netbsd32_50 exec filesys a 1 - compat_netbsd32_60,compat_50
compat_netbsd32_60 exec filesys a 1 - compat_netbsd32_80,compat_60
compat_netbsd32_80 exec filesys a 1 - compat_netbsd32_90,compat_80
compat_netbsd32_90 exec filesys a 1 - compat_netbsd32_100,compat_90
Modules built in because of COMPAT_NETBSD32:
compat_netbsd32_coredump misc builtin - 0 - compat_netbsd32,compat_netbsd32_ptrace,coredump
compat_netbsd32_mqueue exec builtin - 0 - mqueue,compat_netbsd32
compat_netbsd32_nfssrv exec builtin - 0 - nfsserver,compat_netbsd32
compat_netbsd32_ptrace exec builtin - 1 - compat_netbsd32,ptrace_common
compat_netbsd32_quota exec builtin - 0 - compat_netbsd32
compat_netbsd32_sysvipc exec builtin - 0 - compat_netbsd32,sysv_ipc
compat_util misc builtin - 2 - -
Option COMPAT_90 should be sufficient to build a kernel that supports netbsd-9
binaries, including 32bit ones. It shouldn't silently include alsmost all
old compat code.
>How-To-Repeat:
Run netbsd-9/i386 binaries on a amd64 system (-10 or -current) without COMPAT_16.
>Fix:
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: kern-bug-people->pgoyette
Responsible-Changed-By: pgoyette@NetBSD.org
Responsible-Changed-When: Mon, 06 May 2024 06:43:27 +0000
Responsible-Changed-Why:
take
State-Changed-From-To: open->analyzed
State-Changed-By: pgoyette@NetBSD.org
State-Changed-When: Wed, 21 Aug 2024 01:12:27 +0000
State-Changed-Why:
problem understood
From: Paul Goyette <paul@whooppee.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/58225 - netbsd9/amd64 requires COMPAT_16 for 32bit support
Date: Tue, 20 Aug 2024 18:10:54 -0700 (PDT)
OK, I think I've got this understood now...
The changes that were made in compat_netbsd32_signal.c rev 1.53 and 1.54
are just plain wrong. These changes cause every netbsd32 image to load
all of the compat code all the way back to _16. This is a "backwards
dependency" where -current depends on older code; a correct ordering
would be having the older code depend on the newer (as can be seen in
all the MODULE(compat_netbsd32_*) modules' required-lists.
IMHO the right thing to do would be to move the relevant code out of
src/sys/compat/netbsd32/netbsd32_compat_16.c and into
src/sys/compat/netbsd32/netbsd32_signal.c That would leave only
the machdep code for sigreturn14. (The module init/fini changes in
rev 1.5 should remain, too.)
As a result, signal code will have everything it needs without using
a reverse-dependency. It also simplifies things by removing the need
to keep track of the *_valid stuff. (It also removes the need to
prevent any unload of the compat_netbsd32_16 module - the stuff using
``p->p_lflag & PL_SIGCOMPAT''.)
A reproducer for the problem should be simple. First you modload
the compat_netbsd32 module. Then run an image that uses the module
(preferably a 32-bit netbsd-9 or earlier). Observe with modstat(8)
that all compat_xx and compat_netbsd32_xx modules have been loaded.
+---------------------+--------------------------+----------------------+
| Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | 1B11 1849 721C 56C8 F63A | paul@whooppee.com |
| Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoyette@netbsd.org |
| & Network Engineer | | pgoyette99@gmail.com |
+---------------------+--------------------------+----------------------+
From: Paul Goyette <paul@whooppee.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/58225 - netbsd9/amd64 requires COMPAT_16 for 32bit support
(fwd)
Date: Fri, 23 Aug 2024 18:45:03 -0700 (PDT)
Logging feedback to the PR audit trail
+---------------------+--------------------------+----------------------+
| Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | 1B11 1849 721C 56C8 F63A | paul@whooppee.com |
| Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoyette@netbsd.org |
| & Network Engineer | | pgoyette99@gmail.com |
+---------------------+--------------------------+----------------------+
---------- Forwarded message ----------
Date: Thu, 22 Aug 2024 19:09:31 -0700 (PDT)
From: Paul Goyette <paul@whooppee.com>
To: thorpej@netbsd.org
Subject: Re: kern/58225 - netbsd9/amd64 requires COMPAT_16 for 32bit support
(fwd)
Can you look into this please?
From what I can see (*) you've handled the (COMPAT_NETBSD32 & COMPAT_16)
situation, but at the expense of mishandling (COMPAT_NETBSD32 & ! COMPAT_16)
situation. You really should not be auto-loading a module
that isn't desired. As you can see, that brings in a whole lot of other
cruft for COMPAT_* and COMPAT_NETBSD323_*.
What happens if we simply don't autoload compat_netbsd32_16 module? If
it is loaded through other means (modload(8) maybe) then we get the
behaviour that you already implemented; if the module isn't loaded, we
should reurn EINVAL.
Is there some way to "ask" an executable if it needs the module, and
then _selectively_ autoload it? Today the autoload is rather heavy
handed and happerns for way too many executables (ie, any 32-bit
executable from NetBSD-9, according to PR submitter).
I'd also like to rethink the lock-the-module stuff but that can maybe
wait a bit.
Thanks.
[*] "see" is difficult for me these days, having suffered almost daily
from insomnia for the past year. There may well be details and nuances
that my sleepdeprived gray cells have missed. Feel free to point them
out!
+---------------------+--------------------------+----------------------+
| Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | 1B11 1849 721C 56C8 F63A | paul@whooppee.com |
| Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoyette@netbsd.org |
| & Network Engineer | | pgoyette99@gmail.com |
+---------------------+--------------------------+----------------------+
---------- Forwarded message ----------
Date: Tue, 20 Aug 2024 18:10:54 -0700 (PDT)
From: Paul Goyette <paul@whooppee.com>
To: gnats-bugs@netbsd.org
Subject: Re: kern/58225 - netbsd9/amd64 requires COMPAT_16 for 32bit support
OK, I think I've got this understood now...
The changes that were made in compat_netbsd32_signal.c rev 1.53 and 1.54
are just plain wrong. These changes cause every netbsd32 image to load
all of the compat code all the way back to _16. This is a "backwards
dependency" where -current depends on older code; a correct ordering
would be having the older code depend on the newer (as can be seen in
all the MODULE(compat_netbsd32_*) modules' required-lists.
IMHO the right thing to do would be to move the relevant code out of
src/sys/compat/netbsd32/netbsd32_compat_16.c and into
src/sys/compat/netbsd32/netbsd32_signal.c That would leave only
the machdep code for sigreturn14. (The module init/fini changes in
rev 1.5 should remain, too.)
As a result, signal code will have everything it needs without using
a reverse-dependency. It also simplifies things by removing the need
to keep track of the *_valid stuff. (It also removes the need to
prevent any unload of the compat_netbsd32_16 module - the stuff using
``p->p_lflag & PL_SIGCOMPAT''.)
A reproducer for the problem should be simple. First you modload
the compat_netbsd32 module. Then run an image that uses the module
(preferably a 32-bit netbsd-9 or earlier). Observe with modstat(8)
that all compat_xx and compat_netbsd32_xx modules have been loaded.
+---------------------+--------------------------+----------------------+
| Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | 1B11 1849 721C 56C8 F63A | paul@whooppee.com |
| Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoyette@netbsd.org |
| & Network Engineer | | pgoyette99@gmail.com |
+---------------------+--------------------------+----------------------+
State-Changed-From-To: analyzed->feedback
State-Changed-By: pgoyette@NetBSD.org
State-Changed-When: Sat, 24 Aug 2024 01:51:56 +0000
State-Changed-Why:
feedback requested from original committer
From: Jason Thorpe <thorpej@me.com>
To: gnats-bugs@netbsd.org
Cc: pgoyette@netbsd.org,
gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org,
mlelstv@netbsd.org
Subject: Re: kern/58225 - netbsd9/amd64 requires COMPAT_16 for 32bit support
(fwd)
Date: Sat, 24 Aug 2024 06:39:54 -0700
> =46rom what I can see (*) you've handled the (COMPAT_NETBSD32 & =
COMPAT_16)
> situation, but at the expense of mishandling (COMPAT_NETBSD32 & ! =
COMPAT_16)=20
> situation. You really should not be auto-loading a module
> that isn't desired. As you can see, that brings in a whole lot of =
other
> cruft for COMPAT_* and COMPAT_NETBSD323_*.
>=20
> What happens if we simply don't autoload compat_netbsd32_16 module? =
If
> it is loaded through other means (modload(8) maybe) then we get the
> behaviour that you already implemented; if the module isn't loaded, we
> should reurn EINVAL.
Note the only reason I made the changes in the first place is because =
COMPAT_NETBSD32 signal delivery was already a complicated broken mess =
(and the changes addressed a reported bug). Sure, more modules might =
get loaded now, but at least signal delivery works.
TBH, I don=E2=80=99t get what the big deal is here. The NETBSD32 =
version is doing basically what the non-NETBSD32 version is doing: that =
is, if the process says is uses the old =E2=80=9Csigcontext=E2=80=9D =
type of trampoline, it auto-loads the compat_16 module. And it=E2=80=99s =
been doing that ever since 2019 when *you* made that change.
-- thorpej
From: Paul Goyette <paul@whooppee.com>
To: Jason Thorpe <thorpej@me.com>
Cc: Jason Thorpe <thorpej@netbsd.org>, mlelstv@netbsd.org, martin@netsd.org,
gnats-bugs@netbsd.org
Subject: Re: kern/58225 - netbsd9/amd64 requires COMPAT_16 for 32bit support
(fwd)
Date: Sat, 24 Aug 2024 08:15:24 -0700 (PDT)
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--0-395485268-1724512332=:29473
Content-Type: TEXT/PLAIN; CHARSET=X-UNKNOWN; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <Pine.NEB.4.64.2408240812521.29473@speedy.whooppee.com>
On Sat, 24 Aug 2024, Jason Thorpe wrote:
>
>
>> On Aug 22, 2024, at 7:09=E2=80=AFPM, Paul Goyette <paul@whooppee.com> wr=
ote:
>>
>> Can you look into this please?
>
> Looking. Note the only reason I made the changes in the first place=20
> is because COMPAT_NETBSD32 signal delivery was already a complicated=20
> broken mess (and the changes addressed a reported bug). Sure, more=20
> modules might get loaded now, but at least signal delivery works.
>
> TBH, I don't get what the big deal is here. The NETBSD32 version is=20
> doing basically what the non-NETBSD32 version is doing: that is, if=20
> the process says is uses the old "sigcontext" type of trampoline,=20
> it auto-loads the compat_16 module. And it's been doing that ever=20
> since 2019 when *you* made that change.
Hmmm, so it is. Boy, the signal delivery stuff is such a mess. :-)
Perhaps mlelstv@ or martin@ have further suggestions?
+---------------------+--------------------------+----------------------+
| Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | 1B11 1849 721C 56C8 F63A | paul@whooppee.com |
| Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoyette@netbsd.org |
| & Network Engineer | | pgoyette99@gmail.com |
+---------------------+--------------------------+----------------------+
--0-395485268-1724512332=:29473--
From: Martin Husemann <martin@duskware.de>
To: Paul Goyette <paul@whooppee.com>
Cc: Jason Thorpe <thorpej@me.com>, Jason Thorpe <thorpej@netbsd.org>,
mlelstv@netbsd.org, martin@netsd.org, gnats-bugs@netbsd.org
Subject: Re: kern/58225 - netbsd9/amd64 requires COMPAT_16 for 32bit support
(fwd)
Date: Sat, 24 Aug 2024 17:39:33 +0200
On Sat, Aug 24, 2024 at 08:15:24AM -0700, Paul Goyette wrote:
> Perhaps mlelstv@ or martin@ have further suggestions?
I got lost in all the dependencies. The original trigger of the PR
was a i386 tcsh binary build for 9.99.81 in march 2021 (with an up-to-date
libc.so).
The question why this came up now is whether we should pull up the
current fix to -10 or clean it up somehow first.
Martin
From: Jason Thorpe <thorpej@me.com>
To: Martin Husemann <martin@duskware.de>
Cc: Paul Goyette <paul@whooppee.com>,
Jason Thorpe <thorpej@netbsd.org>,
mlelstv@netbsd.org,
martin@netsd.org,
gnats-bugs@netbsd.org
Subject: Re: kern/58225 - netbsd9/amd64 requires COMPAT_16 for 32bit support
(fwd)
Date: Sat, 24 Aug 2024 08:42:30 -0700
> On Aug 24, 2024, at 8:39=E2=80=AFAM, Martin Husemann =
<martin@duskware.de> wrote:
>=20
> On Sat, Aug 24, 2024 at 08:15:24AM -0700, Paul Goyette wrote:
>> Perhaps mlelstv@ or martin@ have further suggestions?
>=20
> I got lost in all the dependencies. The original trigger of the PR
> was a i386 tcsh binary build for 9.99.81 in march 2021 (with an =
up-to-date
> libc.so).
I guess the **real** question is =E2=80=9Cwhy is a i386 tcsh binary for =
netbsd9 saying it wants the old sigcontext-style signal trampoline?=E2=80=9D=
-- thorpej
From: Martin Husemann <martin@duskware.de>
To: Jason Thorpe <thorpej@me.com>
Cc: Paul Goyette <paul@whooppee.com>, Jason Thorpe <thorpej@netbsd.org>,
mlelstv@netbsd.org, martin@NetBSD.org, gnats-bugs@netbsd.org
Subject: Re: kern/58225 - netbsd9/amd64 requires COMPAT_16 for 32bit support
(fwd)
Date: Sat, 24 Aug 2024 17:54:09 +0200
On Sat, Aug 24, 2024 at 08:42:30AM -0700, Jason Thorpe wrote:
> I guess the **real** question is ?why is a i386 tcsh binary for netbsd9 saying it wants the old sigcontext-style signal trampoline??
I am not sure in what way it is saying that, but the original binary
should still be here: https://www.netbsd.org/~martin/tcsh.gz
Martin
From: Jason Thorpe <thorpej@me.com>
To: Martin Husemann <martin@duskware.de>
Cc: Paul Goyette <paul@whooppee.com>,
Jason Thorpe <thorpej@netbsd.org>,
mlelstv@netbsd.org,
"martin@netbsd.org" <martin@NetBSD.org>,
gnats-bugs@netbsd.org
Subject: Re: kern/58225 - netbsd9/amd64 requires COMPAT_16 for 32bit support
(fwd)
Date: Sat, 24 Aug 2024 08:57:20 -0700
> On Aug 24, 2024, at 8:54=E2=80=AFAM, Martin Husemann =
<martin@duskware.de> wrote:
>=20
> On Sat, Aug 24, 2024 at 08:42:30AM -0700, Jason Thorpe wrote:
>> I guess the **real** question is ?why is a i386 tcsh binary for =
netbsd9 saying it wants the old sigcontext-style signal trampoline??
>=20
> I am not sure in what way it is saying that, but the original binary
> should still be here: https://www.netbsd.org/~martin/tcsh.gz
It=E2=80=99s a parameter (vers) passed to the __sigaction_sigtramp() =
system call.
-- thorpej
From: Martin Husemann <martin@duskware.de>
To: Jason Thorpe <thorpej@me.com>
Cc: Paul Goyette <paul@whooppee.com>, Jason Thorpe <thorpej@netbsd.org>,
mlelstv@netbsd.org, Martin Husemann <martin@NetBSD.org>,
gnats-bugs@netbsd.org
Subject: Re: kern/58225 - netbsd9/amd64 requires COMPAT_16 for 32bit support
(fwd)
Date: Sat, 24 Aug 2024 18:05:25 +0200
On Sat, Aug 24, 2024 at 08:57:20AM -0700, Jason Thorpe wrote:
>
>
> > On Aug 24, 2024, at 8:54?AM, Martin Husemann <martin@duskware.de> wrote:
> >
> > On Sat, Aug 24, 2024 at 08:42:30AM -0700, Jason Thorpe wrote:
> >> I guess the **real** question is ?why is a i386 tcsh binary for netbsd9 saying it wants the old sigcontext-style signal trampoline??
> >
> > I am not sure in what way it is saying that, but the original binary
> > should still be here: https://www.netbsd.org/~martin/tcsh.gz
>
> It?s a parameter (vers) passed to the __sigaction_sigtramp() system call.
(gdb) run
Starting program: /tmp/tcsh
Breakpoint 1.1, 0xfaa6c9e0 in __sigaction_sigtramp ()
from /usr/lib/i386/libc.so.12
(gdb) bt
#0 0xfaa6c9e0 in __sigaction_sigtramp () from /usr/lib/i386/libc.so.12
#1 0xfa94a9f2 in __libc_sigaction14 (sig=14, act=0xfffef2c8, oact=0x0)
at /usr/src/lib/libc/compat/sys/compat___sigaction14_sigtramp.c:68
#if defined(__HAVE_STRUCT_SIGCONTEXT) && defined(__LIBC12_SOURCE__)
/*
* We select the non-SA_SIGINFO trampoline if SA_SIGINFO is not
* set in the sigaction.
*/
if ((act->sa_flags & SA_SIGINFO) == 0) {
int sav = errno;
int rv = __sigaction_sigtramp(sig, act, oact,
__SIGTRAMP_SIGCONTEXT, __SIGTRAMP_SIGCONTEXT_VERSION);
if (rv >= 0 || errno != EINVAL)
return rv;
errno = sav;
}
#endif
Martin
From: Jason Thorpe <thorpej@me.com>
To: Martin Husemann <martin@duskware.de>
Cc: Paul Goyette <paul@whooppee.com>,
Jason Thorpe <thorpej@netbsd.org>,
mlelstv@netbsd.org,
martin@netsd.org,
gnats-bugs@netbsd.org
Subject: Re: kern/58225 - netbsd9/amd64 requires COMPAT_16 for 32bit support
(fwd)
Date: Sat, 24 Aug 2024 08:43:53 -0700
> On Aug 24, 2024, at 8:42=E2=80=AFAM, Jason Thorpe <thorpej@me.com> =
wrote:
>=20
> I guess the **real** question is =E2=80=9Cwhy is a i386 tcsh binary =
for netbsd9 saying it wants the old sigcontext-style signal =
trampoline?=E2=80=9D
(And regardless of what the answer to that question is, a real bug was =
demonstrated, so the fix is still relevant.)
-- thorpej
From: Jason Thorpe <thorpej@me.com>
To: Martin Husemann <martin@duskware.de>
Cc: Paul Goyette <paul@whooppee.com>,
Jason Thorpe <thorpej@netbsd.org>,
mlelstv@netbsd.org,
Martin Husemann <martin@NetBSD.org>,
gnats-bugs@netbsd.org
Subject: Re: kern/58225 - netbsd9/amd64 requires COMPAT_16 for 32bit support
(fwd)
Date: Sat, 24 Aug 2024 10:32:49 -0700
> On Aug 24, 2024, at 9:05=E2=80=AFAM, Martin Husemann =
<martin@duskware.de> wrote:
>=20
> (gdb) run
> Starting program: /tmp/tcsh=20
>=20
> Breakpoint 1.1, 0xfaa6c9e0 in __sigaction_sigtramp ()
> from /usr/lib/i386/libc.so.12
> (gdb) bt
> #0 0xfaa6c9e0 in __sigaction_sigtramp () from =
/usr/lib/i386/libc.so.12
> #1 0xfa94a9f2 in __libc_sigaction14 (sig=3D14, act=3D0xfffef2c8, =
oact=3D0x0)
> at /usr/src/lib/libc/compat/sys/compat___sigaction14_sigtramp.c:68
>=20
>=20
> #if defined(__HAVE_STRUCT_SIGCONTEXT) && defined(__LIBC12_SOURCE__)
> /*
> * We select the non-SA_SIGINFO trampoline if SA_SIGINFO is not =
=20
> * set in the sigaction.
> */
Ah, right, this is just a straight-up binary compatibility issue for =
platforms that historically supported sigcontext. This is probably =
going to same some doing to tidy up properly.
> if ((act->sa_flags & SA_SIGINFO) =3D=3D 0) {
> int sav =3D errno;
> int rv =3D __sigaction_sigtramp(sig, act, oact,
> __SIGTRAMP_SIGCONTEXT, =
__SIGTRAMP_SIGCONTEXT_VERSION);
> if (rv >=3D 0 || errno !=3D EINVAL)
> return rv;
> errno =3D sav;
> }
> #endif
>=20
> Martin
-- thorpej
From: Jason Thorpe <thorpej@me.com>
To: Martin Husemann <martin@duskware.de>
Cc: Paul Goyette <paul@whooppee.com>,
Jason Thorpe <thorpej@netbsd.org>,
mlelstv@netbsd.org,
Martin Husemann <martin@NetBSD.org>,
gnats-bugs@netbsd.org
Subject: Re: kern/58225 - netbsd9/amd64 requires COMPAT_16 for 32bit support
(fwd)
Date: Sat, 24 Aug 2024 10:32:49 -0700
> On Aug 24, 2024, at 9:05=E2=80=AFAM, Martin Husemann =
<martin@duskware.de> wrote:
>=20
> (gdb) run
> Starting program: /tmp/tcsh=20
>=20
> Breakpoint 1.1, 0xfaa6c9e0 in __sigaction_sigtramp ()
> from /usr/lib/i386/libc.so.12
> (gdb) bt
> #0 0xfaa6c9e0 in __sigaction_sigtramp () from =
/usr/lib/i386/libc.so.12
> #1 0xfa94a9f2 in __libc_sigaction14 (sig=3D14, act=3D0xfffef2c8, =
oact=3D0x0)
> at /usr/src/lib/libc/compat/sys/compat___sigaction14_sigtramp.c:68
>=20
>=20
> #if defined(__HAVE_STRUCT_SIGCONTEXT) && defined(__LIBC12_SOURCE__)
> /*
> * We select the non-SA_SIGINFO trampoline if SA_SIGINFO is not =
=20
> * set in the sigaction.
> */
Ah, right, this is just a straight-up binary compatibility issue for =
platforms that historically supported sigcontext. This is probably =
going to same some doing to tidy up properly.
> if ((act->sa_flags & SA_SIGINFO) =3D=3D 0) {
> int sav =3D errno;
> int rv =3D __sigaction_sigtramp(sig, act, oact,
> __SIGTRAMP_SIGCONTEXT, =
__SIGTRAMP_SIGCONTEXT_VERSION);
> if (rv >=3D 0 || errno !=3D EINVAL)
> return rv;
> errno =3D sav;
> }
> #endif
>=20
> Martin
-- thorpej
From: Paul Goyette <paul@whooppee.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/58225 - netbsd9/amd64 requires COMPAT_16 for 32bit support
Date: Thu, 5 Sep 2024 01:10:57 -0700 (PDT)
Getting back to an earlier comment (from Jason, I think)
> I guess the **real** question is ``why is a i386 tcsh binary
> for netbsd9 saying it wants the old sigcontext-style signal
> trampoline?''
Any thoughts on this?
+---------------------+--------------------------+----------------------+
| Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | 1B11 1849 721C 56C8 F63A | paul@whooppee.com |
| Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoyette@netbsd.org |
| & Network Engineer | | pgoyette99@gmail.com |
+---------------------+--------------------------+----------------------+
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/58225 - netbsd9/amd64 requires COMPAT_16 for 32bit support
Date: Thu, 5 Sep 2024 10:30:48 +0200
On Thu, Sep 05, 2024 at 08:15:02AM +0000, Paul Goyette via gnats wrote:
> > I guess the **real** question is ``why is a i386 tcsh binary
> > for netbsd9 saying it wants the old sigcontext-style signal
> > trampoline?''
>
> Any thoughts on this?
One of the backtraces I copied does answer this:
src/lib/libc/compat/sys/compat___sigaction14_sigtramp.c:68
/*
* We select the non-SA_SIGINFO trampoline if SA_SIGINFO is not
* set in the sigaction.
*/
and tcsh does:
struct sigaction act;
act.sa_handler = fn;
sigemptyset(&act.sa_mask);
act.sa_flags = 0;
if (sigaction(sig, &act, NULL) == 0) {
Martin
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.47 2022/09/11 19:34:41 kim Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2024
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home