All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Hirst <rhirst@linuxcare.com>
To: parisc-linux@thepuffingroup.com
Subject: [parisc-linux] signal handling problems (32 bit kernel)
Date: Mon, 20 Nov 2000 17:58:38 +0000	[thread overview]
Message-ID: <20001120175838.Q32715@linuxcare.com> (raw)

Hi,
  Following on from my problems with SEGV last week, I've come up with
a few signal handling issues:

=============================================================

parisc:signal.c

        /* Possibly bogus. */
#warning XXX FIXME probably bogus -PB
        /* I think this is bogus -- it'll cause the first instn of the
         * signal handler to be executed twice!  Better might be to
         * set iaoq[0] to one of the NOPs in the trampoline. -PB
         */
        regs->iaoq[0] = (unsigned long) haddr | 3;
        regs->iaoq[1] = (unsigned long) haddr | 3;

This causes real problems if the signal handler is a dynamic object
which has not yet been resolved; in that case the signal handler
points at the b,l instr in the following at the end of the .plt:

    2700:       0e 80 10 96     ldw  0(sr0,r20),r22
    2704:       ea c0 c0 00     bv r0(r22)
    2708:       0e 88 10 95     ldw  4(sr0,r20),r21
    270c:       ea 9f 1f dd     b,l 2700 <__DTOR_END__+0x54>,r20
    2710:       d6 80 1c 1e     depwi 0,31,2,r20

typically that results in a misalligned access on the first ldw
as r20 is screwed.

I've fixed that by setting iaoq[1] = iaoq[0]+4.  Is that OK, or
should we use the NOP approach in the comment above?

=============================================================

If a program gets a SEGV, fixes the cause of it in its signal
handler, and returns, then the faulting instruction is not rerun.
I think that's wrong (differs from m68k anyway).

=============================================================

Set the following program running:

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <signal.h>

int v[8];

void (* fp)(int);

void sig_handler(int sig)
{
}

void poke(int i)
{
        v[0] = i; v[1] = i; v[2] = i; v[3] = i;
        v[4] = i; v[5] = i; v[6] = i; v[7] = i;
}

int main()
{
        int j, i = 0;
        struct sigaction act;

        memset(&act, 0, sizeof(act));
        act.sa_handler = sig_handler;
        sigaction(SIGUSR1, &act, NULL);

        fp = sig_handler;
        fp(0);
        printf("I am %d\n", getpid());
        while (1) {
                poke (++i);
                j = v[7];
                if (j != i)
                        printf("Wah!\n");
        }
}


and then in another terminal do 'kill -USR1 <pid>'.  The program
either goes 'Wah!', gives a SEGV, or works.  That seems to be because
%r1 is corrupted while processing the signal.  The signal handler ends
with a syscall (rt_sigreturn_wrapper), and %r1, at least, is not saved
and restored over the syscall.  %r31 also appears to get corrupted, as
it is used in the final branch of the syscall return.

Richard

             reply	other threads:[~2000-11-20 17:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-11-20 17:58 Richard Hirst [this message]
2000-11-21  7:05 ` [parisc-linux] signal handling problems (32 bit kernel) Alan Modra
2000-11-21  9:34   ` Richard Hirst
2000-11-21 11:26     ` Alan Modra
2000-11-21 16:54   ` Richard Hirst

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20001120175838.Q32715@linuxcare.com \
    --to=rhirst@linuxcare.com \
    --cc=parisc-linux@thepuffingroup.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.