Re: m68k, signals and single-stepping

Re: m68k, signals and single-stepping

[Geert Uytterhoeven]

Hi Al,

On Thu, Sep 30, 2010 at 07:58, Al Viro <viro@zeniv.linux.org.uk> wrote:
>        I've been trying to sort out what's going on with TIF_DELAYED_TRACE,
> but unfortunately neither User's Manual for 68040 nor Programmer's Reference
> Manual for 68k family cover tracing exceptions in enough details ;-/
>
>        a) regs.SR.T1 is cleared if you have created a sigframe; in
> addition, SIGTRAP is sent to yourself.
>        b) if you leave a syscall and see TIF_DELAYED_TRACE set, you
> do the same thing, signals or no signals.
>        c) if you leave an exception *and* no signal handlers are triggered,
> you leave T1 alone.
>        d) if you step into a tracing exception, you get SIGTRAP again,
> with si_code set to TRAP_TRACE (instead of SI_KERNEL); si_addr is set
> (unlike the previous cases).
>        e) TIF_DELAYED_TRACE is set when you ask for singlestepping;
> the same thing sets SR.T1.
>        f) PTRACE_POKEUSR can't change tracing bits in SR; neither can
> sigreturn.
>        g) if UM is clear on anything, it's that for TRAP the tracing
> exception is handled before entering the trap itself.
>
> So what's that SIGTRAP on exit from syscall in single-stepping mode for?
> I can understand doing that when we've set a signal handler up, but...
>
> There'd been some changes of behaviour in cset with rather uninformative
> commit message
>    [PATCH] M68k update (part 42)
>    M68k task and thread updates
> and AFAICS until that point we had the same "send SIGTRAP and clear T1" on
> ret_from_exception, no matter what had led there.  Was that a bugfix or
> just an unintended change?
>
> BTW, there's a bunch of signal races in m68k, mostly parallel to similar
> crap I'd been fixing lately on other targets; I have fixes, but I'd rather
> understand what's going on with tracing in there before touching the
> more subtle ones...

Sorry, I don't know. I try to stay away from the signal code as much
as possible.

Perhaps Andreas knows?

Anyway, thanks for looking into this!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: m68k, signals and single-stepping

[Andreas Schwab]

Geert Uytterhoeven <geert@linux-m68k.org> writes:

>> So what's that SIGTRAP on exit from syscall in single-stepping mode for?

The trace exception is low priority exception that is executed after all
other exceptions are processed.  So if the cpu single steps over a trap
insns, the trace exception processing is started when the trap exception
processing is complete, which is just before the cpu starts executing
the trap exception handler in the kernel.  You want the SIGTRAP to be
sent to the user process, so you have to delay sending it until the
kernel returns to user space.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: m68k, signals and single-stepping

[Al Viro]

On Thu, Sep 30, 2010 at 10:21:47AM +0200, Andreas Schwab wrote:
> Geert Uytterhoeven <geert@linux-m68k.org> writes:
> 
> >> So what's that SIGTRAP on exit from syscall in single-stepping mode for?
> 
> The trace exception is low priority exception that is executed after all
> other exceptions are processed.  So if the cpu single steps over a trap
> insns, the trace exception processing is started when the trap exception
> processing is complete, which is just before the cpu starts executing
> the trap exception handler in the kernel.  You want the SIGTRAP to be
> sent to the user process, so you have to delay sending it until the
> kernel returns to user space.

Um...  What's wrong with doing that from trap_c()?

Re: m68k, signals and single-stepping

[Andreas Schwab]

Al Viro <viro@ZenIV.linux.org.uk> writes:

> On Thu, Sep 30, 2010 at 10:21:47AM +0200, Andreas Schwab wrote:
>> Geert Uytterhoeven <geert@linux-m68k.org> writes:
>> 
>> >> So what's that SIGTRAP on exit from syscall in single-stepping mode for?
>> 
>> The trace exception is low priority exception that is executed after all
>> other exceptions are processed.  So if the cpu single steps over a trap
>> insns, the trace exception processing is started when the trap exception
>> processing is complete, which is just before the cpu starts executing
>> the trap exception handler in the kernel.  You want the SIGTRAP to be
>> sent to the user process, so you have to delay sending it until the
>> kernel returns to user space.
>
> Um...  What's wrong with doing that from trap_c()?

IIRC that was the only way to make gdb work correctly wrt. single
stepping over system calls and into signal handlers.  If anyone wants to
test it with today's kernel on real hardware, please go ahead.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: m68k, signals and single-stepping

[Al Viro]

On Thu, Sep 30, 2010 at 02:34:11PM +0200, Andreas Schwab wrote:

> > Um...  What's wrong with doing that from trap_c()?
> 
> IIRC that was the only way to make gdb work correctly wrt. single
> stepping over system calls and into signal handlers.  If anyone wants to
> test it with today's kernel on real hardware, please go ahead.

Ouch...  Resurrecting that 840av box will be interesting - most likely
a dead battery, but... ;-/  And yes, I certainly understand why qemu
testing is not sufficient for that kind of stuff - subtle enough to
make the odds of stepping on qemu bugs...

Oh, well.  Anyway, the obvious ones I've got are:
	* setup_frame/setup_rt_frame should report failure, so that
handle_signal() wouldn't block signals in that case (losing the original
mask, since it's not stored anywhere in that case)
	* notify_resume isn't handled at all
	* sigsuspend would be better off with ERESTARTNOHAND scheme.

FWIW, I wonder if it would be better to have handle_signal() call
send_sig() and clear regs.SR.T1 and forget about checking return
value of do_signal(); do_delayed_trace is still needed, since currently
there are two places that can reach it, but it'd make the code around
calling do_signal() simpler while preserving the current behaviour...

Re: m68k, signals and single-stepping

[Finn Thain]

On Thu, 30 Sep 2010, Al Viro wrote:

> On Thu, Sep 30, 2010 at 02:34:11PM +0200, Andreas Schwab wrote:
> 
> > > Um...  What's wrong with doing that from trap_c()?
> > 
> > IIRC that was the only way to make gdb work correctly wrt. single 
> > stepping over system calls and into signal handlers.  If anyone wants 
> > to test it with today's kernel on real hardware, please go ahead.
> 
> Ouch...  Resurrecting that 840av box will be interesting - most likely a 
> dead battery, but... ;-/

My 840av has a weird issue where it powers up and lights the front LED but 
doesn't POST, chime, etc. Eventually (after waiting 2 minutes? 15 
minutes... it varies) I can then reset it with ctrl-apple-power key and it 
comes good. New battery didn't affect this. I've been considering swapping 
in a PSU from a pmac 8500 but maybe it just needs some new capacitors.

> And yes, I certainly understand why qemu testing is not sufficient for 
> that kind of stuff - subtle enough to make the odds of stepping on qemu 
> bugs...

I can test patches for you on a quadra 700 (MC68040) that I have set up at 
the moment. My time is in demand at present, but if you've tested them on 
aranym, and you can tell me what to look for, it shouldn't take too long.

What are the userland pre-requisites for this kind of testing? I have 
etch-m68k handy, but it is getting long in the tooth (that is, it 
pre-dates the siginfo patches that Maxim wrote, all of the ptrace work 
that Andreas has done recently, and probably a bunch of other related 
stuff that I didn't notice).

Finn

> 
> Oh, well.  Anyway, the obvious ones I've got are:
> 	* setup_frame/setup_rt_frame should report failure, so that
> handle_signal() wouldn't block signals in that case (losing the original
> mask, since it's not stored anywhere in that case)
> 	* notify_resume isn't handled at all
> 	* sigsuspend would be better off with ERESTARTNOHAND scheme.
> 
> FWIW, I wonder if it would be better to have handle_signal() call
> send_sig() and clear regs.SR.T1 and forget about checking return
> value of do_signal(); do_delayed_trace is still needed, since currently
> there are two places that can reach it, but it'd make the code around
> calling do_signal() simpler while preserving the current behaviour...
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: m68k, signals and single-stepping

[Andreas Schwab]

Finn Thain <fthain@telegraphics.com.au> writes:

> What are the userland pre-requisites for this kind of testing?

The best way to test it is to run the gdb testsuite and look for
regressions.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: m68k, signals and single-stepping

[Finn Thain]

On Sat, 2 Oct 2010, Andreas Schwab wrote:

> Finn Thain <fthain@telegraphics.com.au> writes:
> 
> > What are the userland pre-requisites for this kind of testing?
> 
> The best way to test it is to run the gdb testsuite and look for 
> regressions.

That sounds convenient enough. What test failures might one expect for 
recent kernel, tools and libc? (Other than failures due to race conditions 
Al mentioned.)

Finn

> 
> Andreas.
> 
> 

Re: m68k, signals and single-stepping

[Andreas Schwab]

Finn Thain <fthain@telegraphics.com.au> writes:

> That sounds convenient enough. What test failures might one expect for 
> recent kernel, tools and libc?

You'll need to compare the runs before and after any patching.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: m68k, signals and single-stepping

[Andreas Schwab]

Geert Uytterhoeven <geert@linux-m68k.org> writes:

> Hi Al,
>
> On Thu, Sep 30, 2010 at 07:58, Al Viro <viro@zeniv.linux.org.uk> wrote:
>>        I've been trying to sort out what's going on with TIF_DELAYED_TRACE,
>> but unfortunately neither User's Manual for 68040 nor Programmer's Reference
>> Manual for 68k family cover tracing exceptions in enough details ;-/

See 8.3 (Exception Priorities) in the MC68040UM, or 8.1.12 (Multiple
Exceptions) in the MC68030UM.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."