Allowing signal handlers to modify SE and BE

Allowing signal handlers to modify SE and BE

[Corey Minyard]

I noticed the following in signal.c:

/*
 * These are the flags in the MSR that the user is allowed to change
 * by modifying the saved value of the MSR on the stack.  SE and BE
 * should not be in this list since gdb may want to change these.  I.e,
 * you should be able to step out of a signal handler to see what
 * instruction executes next after the signal handler completes.
 * Alternately, if you stepped into a signal handler, you should be
 * able to continue 'til the next breakpoint from within the signal
 * handler, even if the handler returns.
 */
#define MSR_USERCHANGE	(MSR_FE0 | MSR_FE1)


Is this really the case?  I noticed in the x86 version that setting
the equivalent of the SE bit is allowed, how does the x86 get away
with this while the PPC can't?  Also, gdb does not use the BE bit at
all (This is branch-trace enable, not breakpoint enable), so allowing
it would not hurt anything.  And gdb doesn't directly use the SE bit,
it uses it through ptrace, so it should be safe to allow the signal
handler to modify it since ptrace would override that.  If the signal
handler didn't modify the bits, it won't hurt anything.  If it
modifies these bits it will not be debugabble, sure, but there are
many ways to make your program not debuggable.

Why am I asking?  Because I'm working on two different programs that
need to be able to set these bits from a signal handler.  I would
rather have this as a standard part of the kernel than have to patch
it every release.

Thanks,

Corey

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Allowing signal handlers to modify SE and BE

[Dan Malek]

Corey Minyard wrote:

> Is this really the case?  I noticed in the x86 version that setting
> the equivalent of the SE bit is allowed, how does the x86 get away
> with this while the PPC can't?

These bits are optionally supported by processors.  As I recall,
the 601 doesn't but I don't know of any others.  You may find a
processor where they don't have any effect.  I can't think of any
other reason.


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Allowing signal handlers to modify SE and BE

[Gabriel Paubert]

On Tue, 17 Oct 2000, Dan Malek wrote:

> > Is this really the case?  I noticed in the x86 version that setting
> > the equivalent of the SE bit is allowed, how does the x86 get away
> > with this while the PPC can't?
>
> These bits are optionally supported by processors.  As I recall,
> the 601 doesn't but I don't know of any others.  You may find a
> processor where they don't have any effect.  I can't think of any
> other reason.

Slight correction: the 601 does have the SE bit but not the BE bit. The
other important difference of the 601 is that it handles debug exceptions
differently (different vector etc...).

So at least the SE bit is present on all processors.

	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Allowing signal handlers to modify SE and BE

[Corey Minyard]

Gabriel Paubert <paubert@iram.es> writes:

> On Tue, 17 Oct 2000, Dan Malek wrote:
>
> > > Is this really the case?  I noticed in the x86 version that setting
> > > the equivalent of the SE bit is allowed, how does the x86 get away
> > > with this while the PPC can't?
> >
> > These bits are optionally supported by processors.  As I recall,
> > the 601 doesn't but I don't know of any others.  You may find a
> > processor where they don't have any effect.  I can't think of any
> > other reason.
>
> Slight correction: the 601 does have the SE bit but not the BE bit. The
> other important difference of the 601 is that it handles debug exceptions
> differently (different vector etc...).
>
> So at least the SE bit is present on all processors.
>

Yes, I believe the SE bit is required, but I don't have my PPC manual
with me right now.  But that shouldn't hurt allowing the bits in.

I was actually kind of looking for the person that originally put the
comment in.  I was thinking that maybe I was missing something and
this would cause a problem.  I haven't seen any, but you never know.
If it caused problems for others, that would be a good reason to not
put it into the mainstream kernel code :-).

-Corey

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Allowing signal handlers to modify SE and BE

[Paul Mackerras]

Corey Minyard writes:

> I noticed the following in signal.c:
>
> /*
>  * These are the flags in the MSR that the user is allowed to change
>  * by modifying the saved value of the MSR on the stack.  SE and BE
>  * should not be in this list since gdb may want to change these.  I.e,
>  * you should be able to step out of a signal handler to see what
>  * instruction executes next after the signal handler completes.
>  * Alternately, if you stepped into a signal handler, you should be
>  * able to continue 'til the next breakpoint from within the signal
>  * handler, even if the handler returns.
>  */
> #define MSR_USERCHANGE	(MSR_FE0 | MSR_FE1)

This came from Kevin Buettner in July 1997 when he was hacking on gdb
to get it working properly under ppc/linux.  I don't know if Kevin is
still around or who the current maintainer of gdb on ppc/linux is.  We
can change this definition if you can get an ack from someone who
knows that it won't break gdb.

Paul.

--
Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
paulus@linuxcare.com.au, http://www.linuxcare.com.au/
Linuxcare.  Support for the revolution.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Allowing signal handlers to modify SE and BE

[Kevin Buettner]

On Oct 18, 11:01am, Paul Mackerras wrote:

> Corey Minyard writes:
>
> > I noticed the following in signal.c:
> >
> > /*
> >  * These are the flags in the MSR that the user is allowed to change
> >  * by modifying the saved value of the MSR on the stack.  SE and BE
> >  * should not be in this list since gdb may want to change these.  I.e,
> >  * you should be able to step out of a signal handler to see what
> >  * instruction executes next after the signal handler completes.
> >  * Alternately, if you stepped into a signal handler, you should be
> >  * able to continue 'til the next breakpoint from within the signal
> >  * handler, even if the handler returns.
> >  */
> > #define MSR_USERCHANGE	(MSR_FE0 | MSR_FE1)
>
> This came from Kevin Buettner in July 1997 when he was hacking on gdb
> to get it working properly under ppc/linux.  I don't know if Kevin is
> still around or who the current maintainer of gdb on ppc/linux is.  We
> can change this definition if you can get an ack from someone who
> knows that it won't break gdb.

I'm still around and I'm also the linux/ppc gdb maintainer.

I have not been paying close attention to changes in the kernel, so I
do not know for certain that adding MSR_SE (and MSR_BE) to the list of
bits that are restored from the signal frame would break gdb.

I suspect that it would, however.  Here's the scenario:  You're
debugging a program with gdb and you are stopped at the end of a
signal handler.  You then use si (as many times as necessary) to step
out of the signal handler and into the sigtramp code on the stack.  As
Corey mentioned in a previous message, gdb uses ptrace() to set the SE
bit to cause a single step to occur.  Eventually, you'll hit the ``sc''
instruction and this'll take you into one of sys_sigreturn() or
sys_rt_sigreturn().

When we get into sys_sigreturn() or sys_rt_sigreturn() in this
scenario, we want to make sure that SE stays set when we start
executing the user process again.  If we don't, gdb will not stop as
it should.  It seems to me that if we add MSR_SE to MSR_USERCHANGE,
we'll be taking the SE value off the user stack which will effectively
ignore the value set by ptrace().

I've just consulted my mail archives, and at the time that I sent Paul
the patch which removed MSR_SE and MSR_BE from MSR_USERCHANGE, I noted
that this patch fixed a gdb testsuite failure.  Here's what I said:

	* The SE and BE flags of the MSR are _not_ restored from the
	  signal frame.  This is so that gdb can step out of a signal
	  handler.  (See comment in the patch for more details.)  This
	  eliminated one of the unexpected failures in running the gdb
	  test suite.

If you really want to be able to allow these bits to be changed by
a signal handler, I suppose you could look at the value of

    current->ptrace & PT_PTRACED

and use this to conditionally allow them to be changed in the signal
return path.  (I.e, you'd permit them to be changed if the process in
question is not being ptrace'd.)  You'd even still be able to debug such
programs, but you'd experience a slight loss of functionality since
the program that you're debugging would control whether or not you're
single stepping in certain instances.

Kevin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Allowing signal handlers to modify SE and BE

[Frank Rowand]

Gabriel Paubert wrote:
>
> On Tue, 17 Oct 2000, Dan Malek wrote:
>
> > > Is this really the case?  I noticed in the x86 version that setting
> > > the equivalent of the SE bit is allowed, how does the x86 get away
> > > with this while the PPC can't?
> >
> > These bits are optionally supported by processors.  As I recall,
> > the 601 doesn't but I don't know of any others.  You may find a
> > processor where they don't have any effect.  I can't think of any
> > other reason.
>
> Slight correction: the 601 does have the SE bit but not the BE bit. The
> other important difference of the 601 is that it handles debug exceptions
> differently (different vector etc...).
>
> So at least the SE bit is present on all processors.
>
>         Gabriel.

The SE bit is not present on at least some of the IBM PPC 4xx processors.
It is not present on the 405 processors.  It is not present on the 403GCX.
(I did not check the other 403 variants.)

(This doesn't affect the discussion that led to the question about the SE
bit, but I thought I would let people know about the 4xx processors....)

-Frank
--
Frank Rowand <frank_rowand@mvista.com>
MontaVista Software, Inc

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/