Re: Libc support for old BSD-style "sigcontext" signal handlers is broken, let's just kill it.
In article <141d1bec-0f6d-4bb8-8b44-aba98806c...@me.com>, Jason Thorpe wrote: > >> On Oct 26, 2021, at 6:56 AM, Jason Thorpe wrote: >> >> Obviously, the practical impact of this is nil, since no one apparently >noticed (and I guess we didnât break any programs that people were >using). We havenât documented that style of handler for a VERY long time >but presumably the intent was for it to continue to work because the code >remained and was modified several times over the years. (it was certainly >my original intent when I first added support for multiple signal >trampolines in a single process ~20 years ago, and it did in fact work for >the first few years that code existed). > >Oh, I suppose I should also point out that kernel support for the older >trampoline is in the COMPAT_16 module (the new âsiginfoâ stuff was >added in NetBSD 2.0). I think we should do the minimal change and merge all the __sigaction14_sigcontext.c files, as well as enable the ifdef'ed out code to restore compatibility and add unit tests if we are going to keep the code in the kernel so that we can test it. christos
Re: Libc support for old BSD-style "sigcontext" signal handlers is broken, let's just kill it.
Date:Tue, 26 Oct 2021 11:13:00 -0700 From:Jason Thorpe Message-ID: <474c830e-74d0-4234-b186-fe92ff97b...@me.com> | I mean, I could certainly fix it I think Christos already did. kre
Re: Libc support for old BSD-style "sigcontext" signal handlers is broken, let's just kill it.
> On Oct 26, 2021, at 11:07 AM, Robert Elz wrote: > >Date:Tue, 26 Oct 2021 18:27:20 +0300 >From:Valery Ushakov >Message-ID: > > | OTOH the old > | *binaries* (using old dynamic libc, or linked with old static libc) > | still need the kernel support. > > I think the point is that the "old dynamic libc" is the current libc, > unless an old binary is so old that it linked against libc.11 or earlier > (which means way back into the last millenium sometime). > > So not only is kernel support needed, libc (12) support is as well. Once > the fabled libc version bump happens this will all change. I mean, I could certainly fix it (and rev the symbol), just don’t know if it’s worth the bother since it’s been broken for so long. -- thorpej
Re: Libc support for old BSD-style "sigcontext" signal handlers is broken, let's just kill it.
Date:Tue, 26 Oct 2021 18:27:20 +0300 From:Valery Ushakov Message-ID: | OTOH the old | *binaries* (using old dynamic libc, or linked with old static libc) | still need the kernel support. I think the point is that the "old dynamic libc" is the current libc, unless an old binary is so old that it linked against libc.11 or earlier (which means way back into the last millenium sometime). So not only is kernel support needed, libc (12) support is as well. Once the fabled libc version bump happens this will all change. kre
Re: Libc support for old BSD-style "sigcontext" signal handlers is broken, let's just kill it.
> On Oct 26, 2021, at 8:27 AM, Valery Ushakov wrote: > > I'm not sure why we left the sigcontext version in the tree. I would > guess for reference only, so it doesn't really need any fixing, as far > as I understand. Presumably it was to keep old binaries that used the sigcontext style would keep working. If it was for reference only, one would think it would have been commented as such and the binary objects not actually built. The commit that broke it had the log message “make these consistent”, which doesn’t really convey to me that it was intended to disable them. -- thorpej
Re: Libc support for old BSD-style "sigcontext" signal handlers is broken, let's just kill it.
On Tue, Oct 26, 2021 at 06:56:54 -0700, Jason Thorpe wrote: > However, as I was adding an #ifdef conditional to the sigcontext > handling in the new unified __sigaction14_sigtramp.c (because new > architectures added after ?siginfo? support was added never really > needed it, and didn?t define a ?struct sigcontext?), I realized that > in 2006, support for sigcontext handling was broken on platforms > that previously supported it (each copy gained a __LIBC12_SOURCE__ > conditional around the sigcontext support, but nothing ever defined > __LIBC12_SOURCE__ for those files). [...] > Since Feb 2006 (with one minor exception; don?t worry, it was broken > a few months later), the ?siginfo? trampoline has always been > chosen, meaning that any old program dynamically linked against libc > that uses style ?2? above would get garbage in the ?code? and ?scp? > arguments. I'm replying from (fading) memory here, so apologies in advance if I'm confused about it... Isn't the above intended? We don't compile the source for the old trampoline b/c we now always use the sigingo one and we don't need the old trampoline in the new library. OTOH the old *binaries* (using old dynamic libc, or linked with old static libc) still need the kernel support. I'm not sure why we left the sigcontext version in the tree. I would guess for reference only, so it doesn't really need any fixing, as far as I understand. -uwe
Re: Libc support for old BSD-style "sigcontext" signal handlers is broken, let's just kill it.
> On Oct 26, 2021, at 6:56 AM, Jason Thorpe wrote: > > Obviously, the practical impact of this is nil, since no one apparently > noticed (and I guess we didn’t break any programs that people were using). We > haven’t documented that style of handler for a VERY long time but presumably > the intent was for it to continue to work because the code remained and was > modified several times over the years. (it was certainly my original intent > when I first added support for multiple signal trampolines in a single > process ~20 years ago, and it did in fact work for the first few years that > code existed). Oh, I suppose I should also point out that kernel support for the older trampoline is in the COMPAT_16 module (the new “siginfo” stuff was added in NetBSD 2.0). -- thorpej
