code review 11223043: cmd/5g, cmd/6g, cmd/8g: fix line number of caller of de...

cmd/5g, cmd/6g, cmd/8g: fix line number of caller of deferred func

Deferred functions are not run by a call instruction. They are run by
the runtime editing registers to make the call start with a caller PC
returning to a
        CALL deferreturn
instruction.

That instruction has always had the line number of the function's
closing brace, but that instruction's line number is irrelevant.
Stack traces show the line number of the instruction before the
return PC, because normally that's what started the call. Not so here.
The instruction before the CALL deferreturn could be almost anywhere
in the function; it's unrelated and its line number is incorrect to show.

Fix the line number by inserting a true hardware no-op with the right
line number before the returned-to CALL instruction. That is, the deferred
calls now appear to start with a caller PC returning to the second instruction
in this sequence:
        NOP
        CALL deferreturn

The traceback will show the line number of the NOP, which we've set
to be the line number of the function's closing brace.

The NOP here is not the usual pseudo-instruction, which would be
elided by the linker. Instead it is the real hardware instruction:
XCHG AX, AX on 386 and amd64, and AND.EQ R0, R0, R0 on ARM.

Fixes issue 5856.

[rsc, 2013-07-12 17:47:52]

Hello ken2, ken@golang.org (cc: golang-dev@googlegroups.com),

I'd like you to review this change to
https://code.google.com/p/go/

[rsc, 2013-07-12 17:47:59]

*** Submitted as https://code.google.com/p/go/source/detail?r=14ded0061c96 ***

cmd/5g, cmd/6g, cmd/8g: fix line number of caller of deferred func

Deferred functions are not run by a call instruction. They are run by
the runtime editing registers to make the call start with a caller PC
returning to a
        CALL deferreturn
instruction.

That instruction has always had the line number of the function's
closing brace, but that instruction's line number is irrelevant.
Stack traces show the line number of the instruction before the
return PC, because normally that's what started the call. Not so here.
The instruction before the CALL deferreturn could be almost anywhere
in the function; it's unrelated and its line number is incorrect to show.

Fix the line number by inserting a true hardware no-op with the right
line number before the returned-to CALL instruction. That is, the deferred
calls now appear to start with a caller PC returning to the second instruction
in this sequence:
        NOP
        CALL deferreturn

The traceback will show the line number of the NOP, which we've set
to be the line number of the function's closing brace.

The NOP here is not the usual pseudo-instruction, which would be
elided by the linker. Instead it is the real hardware instruction:
XCHG AX, AX on 386 and amd64, and AND.EQ R0, R0, R0 on ARM.

Fixes issue 5856.

R=ken2, ken
CC=golang-dev
https://codereview.appspot.com/11223043

[khr1, 2013-07-12 21:13:37]

This looks like it generates the two-byte nop "87 c0" (xchg %eax,%eax).
 Why not the one-byte "90" nop?  Did you just not want to add a new
AREALNOP instruction?


On Fri, Jul 12, 2013 at 10:47 AM, <rsc@golang.org> wrote:

> *** Submitted as
>
https://code.google.com/p/go/**source/detail?r=14ded0061c96<https://code.goog...
>
>
> cmd/5g, cmd/6g, cmd/8g: fix line number of caller of deferred func
>
> Deferred functions are not run by a call instruction. They are run by
> the runtime editing registers to make the call start with a caller PC
> returning to a
>         CALL deferreturn
> instruction.
>
> That instruction has always had the line number of the function's
> closing brace, but that instruction's line number is irrelevant.
> Stack traces show the line number of the instruction before the
> return PC, because normally that's what started the call. Not so here.
> The instruction before the CALL deferreturn could be almost anywhere
> in the function; it's unrelated and its line number is incorrect to
> show.
>
> Fix the line number by inserting a true hardware no-op with the right
> line number before the returned-to CALL instruction. That is, the
> deferred
> calls now appear to start with a caller PC returning to the second
> instruction
> in this sequence:
>         NOP
>         CALL deferreturn
>
> The traceback will show the line number of the NOP, which we've set
> to be the line number of the function's closing brace.
>
> The NOP here is not the usual pseudo-instruction, which would be
> elided by the linker. Instead it is the real hardware instruction:
> XCHG AX, AX on 386 and amd64, and AND.EQ R0, R0, R0 on ARM.
>
> Fixes issue 5856.
>
> R=ken2, ken
> CC=golang-dev
>
https://codereview.appspot.**com/11223043<https://codereview.appspot.com/1122...
>
>
>
https://codereview.appspot.**com/11223043/<https://codereview.appspot.com/112...
>
>
> --
>
> ---You received this message because you are subscribed to the Google
> Groups "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to
golang-dev+unsubscribe@**googlegroups.com<golang-dev%2Bunsubscribe@googlegrou...
> .
> For more options, visit
https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/o...
> .
>
>
>

[rsc, 2013-07-13 00:58:53]

Wow, I'm amazed you found that.

6l and 8l did not know about the special case for XCHG AX, reg, so they
were using the general form.

We've gotten so far without any use cases for a REALNOP instruction that I
don't want to add one just yet. I updated 6l and 8l to use the one-byte
form for XCHG AX, reg (and vice versa).

Russ