Adding the index and the range will increase the size of the binary, as we will then have to add code to pass the index and size to the runtime for every bounds check.

@randall77, instead of passing the index and size and bloating the code, could the panicindex function walk up the stack and know which registers/offsets to pull those two numbers from?

@bradfitz Maybe. It would require a custom calling convention.

We typically do:

CMP index, bound
JAE fail

fail:
CALL panicindex

So inside panicindex the stack doesn't tell you what registers the index and bound are in. Or even if they are in registers; one of them may be a constant or be in memory.
If we forced both index and bounds to be in registers, maybe we could add functions like panicindex_rax_rcx - they could save the named registers somewhere before using standard Go to construct the panic message.

It's certainly a whole lot easier to just do:

fail:
MOV index, 0(SP)
MOV bound, 8(SP)
CALL panicindex

Just a question of whether that extra code is worth it.

Could panicindex use arch-specific code to decode the CMP (find it by looking up the stack one frame) in order to find the index? This could be incrementally implemented: for architectures not yet decoding the CMP instruction, continue to not report the index.

Linux on MIPS is able to fixup unaligned accesses by decoding the offending instruction and emulating it in software (https://www.linux-mips.org/wiki/Alignment#Transparent_fixing_by_the_kernel). This would be the same idea: in the normal case (index in bounds) the code is unchanged from the optimal code, and in the failure case extra effort is expended to go figure out what went wrong.

Personally I say bloat the code as much as you want if it leads to more helpful error's.

@jeffallen It isn't easy to find the CMP. The panicindex is out of line and there is no record of where the branch to it came from.
In my example above there could be multiple JAE fail instructions - how do you know which one went to the panicindex?
We could solve this by not combining panicindex calls. That wouldn't be too bad, they only get combined within a source line anyway. Also, we could put the panicindex inline so we wouldn't have to scan the whole function to find it.
Still, this is tricky to get right. Walking backwards in an x86 instruction stream is hard. There may be no CMP (the compiler may have proved it will always fail. It may use a SUB to get the same result (#17638), ...).

As a representative example, there are 4747 calls to panicslice/panicindex in cmd/go. Two extra "MOV reg1, (SP); MOV reg2, 8(SP)" instructions on amd64 would cost about 9 bytes. So that's about 43k extra bytes of program overhead so that errors (or at least back traces) can include index/length information.

cmd/go is about 10.7MB large, so that would amount to an executable file size increase of 0.4%.

One more use case for this would be: having details on SIGBUS received when accessing mmaped file if actual IO caused by access ended with error. Specifically the details would allow to turn SIGBUS into EIO error with information about problematic offset in the file.

More context: https://groups.google.com/d/msg/golang-nuts/11rdExWP6ac/226CPanVBAAJ