Matt Thomas | 1 Sep 09:54 2009

RFC: setjmp/longjmp (and friends) for a new port


In adding support for MIPS64 environments to NetBSD, a lot of the work  
is just adapting the existing to nuances of new MIPS ABIs.  Trying to  
make minimal changes when possible is usually the best way to go.  But  
sometimes, a radical may be in order.

MIPS under NetBSD has always a jmp_buf that was a struct sigcontext.   
Changing that for the existing code is almost impossible since you  
have to live with the size limits of a jmp_buf.  But a new port  
doesn't have to worry about that, since there is no existing code to  
be compatible with.

So I'm thinking that in MIPS64, setjmp/longjmp can just be versions of  
getcontext/setcontext.
longjmp need to be able to set the return value, but that's a minor  
variation.

Can anyone think of valid reasons not do that?

Joerg Sonnenberger | 1 Sep 14:53 2009
Picon

Re: RFC: setjmp/longjmp (and friends) for a new port

On Tue, Sep 01, 2009 at 12:54:14AM -0700, Matt Thomas wrote:
> So I'm thinking that in MIPS64, setjmp/longjmp can just be versions of  
> getcontext/setcontext.
> longjmp need to be able to set the return value, but that's a minor  
> variation.
>
> Can anyone think of valid reasons not do that?

getcontext/setcontext modify the signal mask, setjmp/longjmp don't.

Joerg

Joerg Sonnenberger | 1 Sep 15:05 2009
Picon

Re: RFC: setjmp/longjmp (and friends) for a new port

On Tue, Sep 01, 2009 at 02:53:36PM +0200, Joerg Sonnenberger wrote:
> On Tue, Sep 01, 2009 at 12:54:14AM -0700, Matt Thomas wrote:
> > So I'm thinking that in MIPS64, setjmp/longjmp can just be versions of  
> > getcontext/setcontext.
> > longjmp need to be able to set the return value, but that's a minor  
> > variation.
> >
> > Can anyone think of valid reasons not do that?
> 
> getcontext/setcontext modify the signal mask, setjmp/longjmp don't.

OK, let me partially take that back. setjmp/longjmp may restore the
signal mask, SUS leaves that as undefined behavior. As such it is valid
to use getcontext/setcontext for that. Depending on the ABI patching the
output of getcontext should be good enough for longjmp, e.g. set the IP
to a ret and the return value register to the expected data.

Joerg

Matthew Mondor | 1 Sep 20:41 2009
Picon

Re: RFC: setjmp/longjmp (and friends) for a new port

On Tue, 1 Sep 2009 15:05:45 +0200
Joerg Sonnenberger <joerg <at> britannica.bec.de> wrote:

> > getcontext/setcontext modify the signal mask, setjmp/longjmp don't.
> 
> OK, let me partially take that back. setjmp/longjmp may restore the
> signal mask, SUS leaves that as undefined behavior. As such it is valid
> to use getcontext/setcontext for that. Depending on the ABI patching the
> output of getcontext should be good enough for longjmp, e.g. set the IP
> to a ret and the return value register to the expected data.

Indeed, on NetBSD setjmp/longjmp seem to also save/restore the signal
mask, while sig* variants do it conditionally and _* variants only
save/restore registers, at least according to setjmp(3)...
--

-- 
Matt

Christos Zoulas | 1 Sep 22:11 2009

Re: RFC: setjmp/longjmp (and friends) for a new port

In article <20090901130545.GC3447 <at> britannica.bec.de>,
Joerg Sonnenberger  <joerg <at> britannica.bec.de> wrote:
>On Tue, Sep 01, 2009 at 02:53:36PM +0200, Joerg Sonnenberger wrote:
>> On Tue, Sep 01, 2009 at 12:54:14AM -0700, Matt Thomas wrote:
>> > So I'm thinking that in MIPS64, setjmp/longjmp can just be versions of  
>> > getcontext/setcontext.
>> > longjmp need to be able to set the return value, but that's a minor  
>> > variation.
>> >
>> > Can anyone think of valid reasons not do that?
>> 
>> getcontext/setcontext modify the signal mask, setjmp/longjmp don't.
>
>OK, let me partially take that back. setjmp/longjmp may restore the
>signal mask, SUS leaves that as undefined behavior. As such it is valid
>to use getcontext/setcontext for that. Depending on the ABI patching the
>output of getcontext should be good enough for longjmp, e.g. set the IP
>to a ret and the return value register to the expected data.

Well, you could clear the uc_flags for signal mask and fpu before calling
setcontext to implement this, no?

christos

Matt Thomas | 1 Sep 23:40 2009

Re: RFC: setjmp/longjmp (and friends) for a new port


On Sep 1, 2009, at 1:11 PM, Christos Zoulas wrote:

> In article <20090901130545.GC3447 <at> britannica.bec.de>,
> Joerg Sonnenberger  <joerg <at> britannica.bec.de> wrote:
>> On Tue, Sep 01, 2009 at 02:53:36PM +0200, Joerg Sonnenberger wrote:
>>> On Tue, Sep 01, 2009 at 12:54:14AM -0700, Matt Thomas wrote:
>>>> So I'm thinking that in MIPS64, setjmp/longjmp can just be  
>>>> versions of
>>>> getcontext/setcontext.
>>>> longjmp need to be able to set the return value, but that's a minor
>>>> variation.
>>>>
>>>> Can anyone think of valid reasons not do that?
>>>
>>> getcontext/setcontext modify the signal mask, setjmp/longjmp don't.
>>
>> OK, let me partially take that back. setjmp/longjmp may restore the
>> signal mask, SUS leaves that as undefined behavior. As such it is  
>> valid
>> to use getcontext/setcontext for that. Depending on the ABI  
>> patching the
>> output of getcontext should be good enough for longjmp, e.g. set  
>> the IP
>> to a ret and the return value register to the expected data.
>
> Well, you could clear the uc_flags for signal mask and fpu before  
> calling
> setcontext to implement this, no?

(Continue reading)

Joerg Sonnenberger | 1 Sep 23:45 2009
Picon

Re: RFC: setjmp/longjmp (and friends) for a new port

On Tue, Sep 01, 2009 at 08:11:40PM +0000, Christos Zoulas wrote:
> Well, you could clear the uc_flags for signal mask and fpu before calling
> setcontext to implement this, no?

Actually, fpu needs to be part of setjmp/longjmp. Signal mask should be
optional depending on the function being called. Especially if the
setcontext implementation is pure userland.

Joerg

Thomas Klausner | 4 Sep 14:53 2009
Picon

Re: Simple unzip(1) replacement

On Mon, Aug 24, 2009 at 10:45:03AM +0200, Joerg Sonnenberger wrote:
> in src/usr.bin/unzip there is a simple libarchive frontend emulating
> most of the infozip command line. Some of the major obscure features are
> missing (-T, -z, -b, -s, -C, -K, -M, -V, -W, -X, -$, -/, -:, only
> positive option forms). It should be good enough for pkgsrc and everyday
> usage though.

Now that it's enabled by default (sorry for not testing earlier) I
tried it out. The first three commands I tried were completely
different in both...

For comparison, here are the same steps with NetBSD unzip and infozip
unzip:

NetBSD unzip
# unzip -v arnold.zip
 Length   Method    Size  Ratio   Date   Time  CRC-32    Name
--------  ------  ------- -----   ----   ----  ------    ----
 4194304  Stored  4194304   0%  06-20-09 13:07 00000000  arnold.txt
--------          ------- ---                            -------
 4194304          4194304   0%                                   1 file
# unzip arnold.zip
x arnold.txt
# unzip arnold.zip
unzip: not implemented

# /usr/pkg/bin/unzip -v arnold.zip
Archive:  arnold.zip
 Length   Method    Size  Ratio   Date   Time   CRC-32    Name
--------  ------  ------- -----   ----   ----   ------    ----
(Continue reading)

Aleksey Cheusov | 5 Sep 19:22 2009
Picon
Picon

regression/bug in /usr/bin/make


I think I've found a bug in make.

Makefile:
    var = head
    res = no

    .for i in head:tail
    .if !empty(var:M${i:C/:.*//})
        res=yes
    .endif
    .endfor

    all:
         <at> echo ${res}

shell session:
    0 ~>/usr/bin/make -f /home/cheusov/tmp/1.mk all 
    make: Bad modifier `:tail' for 
    no
    0 ~>

This is how NetBSD-5 make and current make work.

The problem here is that "head" and "tail" are separated by colon.
C/:.*// for unknown reason doesn't work.

Should I send PR?

P.S.
(Continue reading)

Alan Barrett | 5 Sep 19:35 2009

logging and silencing /etc/rc output

In order to address PR 41946, I would like to do the following:

  * expose the kernel's boothowto variable via "sysctl kern.boothowto";
  * add a new rc.conf cariable, $rc_silent, defaulting to true or false
    according to the value of the AB_SILENT bin in boothowto;
  * add a post-processor function inside /etc/rc, which will log
    almost all output to /var/run/rc.log, as well as displaying it on
    the console in the usual case; but if $rc_silent is true it will
    display a spinning "twiddle" on the console instead of the usual
    output;
  * allow rc.d scripts to be marked with "KEYWORD: interative" if they
    need user interaction (which implies that hiding their output
    would be bad).

A patch to do the above is available in
<ftp://ftp.netbsd.org/pub/NetBSD/misc/apb/rc.20090905.diff>.
The parts of the patch that affect /etc/rc and /etc/rc.subr
are hard to read, so patched versions of those files are
available from <ftp://ftp.netbsd.org/pub/NetBSD/misc/apb/rc> and
<ftp://ftp.netbsd.org/pub/NetBSD/misc/apb/rc.subr>.

I'd appreciate comments.

--apb (Alan Barrett)


Gmane