linux.git/arch/sh, branch v2.6.33

sh64: fix tracing of signals.

2010-02-15T05:17:45+00:00

This follows the parisc change to ensure that tracehook_signal_handler()
is aware of when we are single-stepping in order to ptrace_notify()
appropriately. While this was implemented for 32-bit SH, sh64 neglected
to make use of TIF_SINGLESTEP when it was folded in with the 32-bit code,
resulting in ptrace_notify() never being called.

As sh64 uses all of the other abstractions already, this simply plugs in
the thread flag in the appropriate enable/disable paths and fixes up the
tracehook notification accordingly. With this in place, sh64 is brought
in line with what 32-bit is already doing.

Reported-by: Mike Frysinger 
Signed-off-by: Paul Mundt

sh: Remove superfluous setup_frame_reg call

2010-02-08T01:47:11+00:00

There's no need to setup the frame pointer again in
call_handle_tlbmiss. The frame pointer will already have been setup in
handle_interrupt.

Signed-off-by: Matt Fleming 
Signed-off-by: Paul Mundt

sh: Don't continue unwinding across interrupts

2010-02-08T01:47:04+00:00

Unfortunately, due to poor DWARF info in current toolchains, unwinding
through interrutps cannot be done reliably. The problem is that the
DWARF info for function epilogues is wrong.

Take this standard epilogue sequence,

80003cc4:       e3 6f           mov     r14,r15
80003cc6:       26 4f           lds.l   @r15+,pr
80003cc8:       f6 6e           mov.l   @r15+,r14
						<---- interrupt here
80003cca:       f6 6b           mov.l   @r15+,r11
80003ccc:       f6 6a           mov.l   @r15+,r10
80003cce:       f6 69           mov.l   @r15+,r9
80003cd0:       0b 00           rts

If we take an interrupt at the highlighted point, the DWARF info will
bogusly claim that the return address can be found at some offset from
the frame pointer, even though the frame pointer was just restored. The
worst part is if the unwinder finds a text address at the bogus stack
address - unwinding will continue, for a bit, until it finally comes
across an unexpected address on the stack and blows up.

The only solution is to stop unwinding once we've calculated the
function that was executing when the interrupt occurred. This PC can be
easily calculated from pt_regs->pc.

Signed-off-by: Matt Fleming 
Signed-off-by: Paul Mundt

sh: Setup frame pointer in handle_exception path

2010-02-08T01:46:53+00:00

In order to allow the DWARF unwinder to unwind through exceptions we
need to setup the frame pointer register (r14).

Signed-off-by: Matt Fleming 
Signed-off-by: Paul Mundt

sh: Correct the offset of the return address in ret_from_exception

2010-02-08T01:46:46+00:00

The address that ret_from_exception and ret_from_irq will return to is
found in the stack slot for SPC, not PR. This error was causing the
DWARF unwinder to pick up the wrong return address on the stack and then
unwind using the unwind tables for the wrong function.

While I'm here I might as well add CFI annotations for the other
registers since they could be useful when unwinding.

Signed-off-by: Matt Fleming 
Signed-off-by: Paul Mundt

sh: Fix access to released memory in clk_debugfs_register_one()

2010-02-02T02:32:23+00:00

Signed-off-by: Marek Skuczynski 
Signed-off-by: Paul Mundt

sh: Fix access to released memory in dwarf_unwinder_cleanup()

2010-02-02T02:32:22+00:00

Signed-off-by: Marek Skuczynski 
Acked-by: Matt Fleming 
Signed-off-by: Paul Mundt

Split 'flush_old_exec' into two functions

2010-01-29T16:22:01+00:00

'flush_old_exec()' is the point of no return when doing an execve(), and
it is pretty badly misnamed.  It doesn't just flush the old executable
environment, it also starts up the new one.

Which is very inconvenient for things like setting up the new
personality, because we want the new personality to affect the starting
of the new environment, but at the same time we do _not_ want the new
personality to take effect if flushing the old one fails.

As a result, the x86-64 '32-bit' personality is actually done using this
insane "I'm going to change the ABI, but I haven't done it yet" bit
(TIF_ABI_PENDING), with SET_PERSONALITY() not actually setting the
personality, but just the "pending" bit, so that "flush_thread()" can do
the actual personality magic.

This patch in no way changes any of that insanity, but it does split the
'flush_old_exec()' function up into a preparatory part that can fail
(still called flush_old_exec()), and a new part that will actually set
up the new exec environment (setup_new_exec()).  All callers are changed
to trivially comply with the new world order.

Signed-off-by: H. Peter Anvin 
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds

sh64: wire up sys_accept4.

2010-01-19T08:00:31+00:00

sh64 on the other hand provides both direct broken out syscalls as well
as socketcall access. As there are binaries that use both socketcall has
to stay around. The current ABI prefers direct syscalls.

It was pointed out that when sys_recvmmsg was added in, sys_accept4 was
overlooked. This takes care of wiring it up.

Signed-off-by: Paul Mundt

sh: unwire sys_recvmmsg.

2010-01-19T08:00:06+00:00

sh32 at the moment only uses sys_socketcall to reach these, so unwire
recvmmsg for now. While we're at it, add it to the ignore list, as per
the s390 change.

Signed-off-by: Paul Mundt