What does "128 bytes on entry" specify in the TEXT time·now function?
550 views
Skip to first unread message
Peng Gao
Feb 1, 2016, 10:31:28 PM2/1/16
to golang-nuts
I found this function in sys_linux_amd64.s, and it's definition.
// func now() (sec int64, nsec int32) TEXT time·now(SB),NOSPLIT,$16 // Be careful. We're calling a function with gcc calling convention here. // We're guaranteed 128 bytes on entry, and we've taken 16, and the // call uses another 8. // That leaves 104 for the gettime code to use. Hope that's enough! MOVQ runtime·__vdso_clock_gettime_sym(SB), AX CMPQ AX, $0 JEQ fallback MOVL $0, DI // CLOCK_REALTIME LEAQ 0(SP), SI CALL AX MOVQ 0(SP), AX // sec MOVQ 8(SP), DX // nsec MOVQ AX, sec+0(FP) MOVL DX, nsec+8(FP) RET fallback: LEAQ 0(SP), DI MOVQ $0, SI MOVQ runtime·__vdso_gettimeofday_sym(SB), AX CALL AX MOVQ 0(SP), AX // sec MOVL 8(SP), DX // usec IMULQ $1000, DX MOVQ AX, sec+0(FP) MOVL DX, nsec+8(FP) RET What does "128 bytes on entry" specify in the TEXT time·now function?
Brad Fitzpatrick
Feb 1, 2016, 11:11:58 PM2/1/16
to Peng Gao, golang-nuts
I think that's how much of Go's stack is guaranteed to still be valid. Go's stacks are small and grow as needed, unlike C, but this code is calling with gcc calling convention from Go code, and the gettime code isn't going to grow Go's stack for it... it'll just corrupt things and probably crash if there's not enough space.
I don't know where 128 comes from, though.
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Ian Lance Taylor
Feb 1, 2016, 11:35:53 PM2/1/16
to Brad Fitzpatrick, Peng Gao, golang-nuts
On Mon, Feb 1, 2016 at 8:11 PM, Brad Fitzpatrick <brad...@golang.org> wrote:
> I think that's how much of Go's stack is guaranteed to still be valid. Go's
> stacks are small and grow as needed, unlike C, but this code is calling with
> gcc calling convention from Go code, and the gettime code isn't going to
> grow Go's stack for it... it'll just corrupt things and probably crash if
> there's not enough space.
>
> I don't know where 128 comes from, though.
Every function is guaranteed to have at least 128 bytes on the stack
> I think that's how much of Go's stack is guaranteed to still be valid. Go's
> stacks are small and grow as needed, unlike C, but this code is calling with
> gcc calling convention from Go code, and the gettime code isn't going to
> grow Go's stack for it... it'll just corrupt things and probably crash if
> there's not enough space.
>
> I don't know where 128 comes from, though.
at function entry. This is used to simplify the stack overflow check
for functions with small stack frames. See _StackSmall in
runtime/stack.go.
Ian
Brad Fitzpatrick
Feb 2, 2016, 12:50:47 PM2/2/16
to Ian Lance Taylor, Peng Gao, golang-nuts
On Mon, Feb 1, 2016 at 8:35 PM, Ian Lance Taylor <ia...@golang.org> wrote:
On Mon, Feb 1, 2016 at 8:11 PM, Brad Fitzpatrick <brad...@golang.org> wrote:
> I think that's how much of Go's stack is guaranteed to still be valid. Go's
> stacks are small and grow as needed, unlike C, but this code is calling with
> gcc calling convention from Go code, and the gettime code isn't going to
> grow Go's stack for it... it'll just corrupt things and probably crash if
> there's not enough space.
>
> I don't know where 128 comes from, though.
Every function is guaranteed to have at least 128 bytes on the stack
at function entry. This is used to simplify the stack overflow check
for functions with small stack frames. See _StackSmall in
runtime/stack.go.
Is there anything special about or precedent for that value, though? Is it trying to match some ABI defined elsewhere, or did we just make it up?
Ian Lance Taylor
Feb 2, 2016, 1:23:20 PM2/2/16
to Brad Fitzpatrick, Peng Gao, golang-nuts
128 bytes. it's not identical, though, and of course we use it on all
processors, not just amd64. And it doesn't have to match the amd64
red zone size anyhow. So, as far as I know, we made it up.
Ian
Lars Seipel
Feb 2, 2016, 2:18:57 PM2/2/16
to Brad Fitzpatrick, Ian Lance Taylor, Peng Gao, golang-nuts
On Tue, Feb 02, 2016 at 09:50:09AM -0800, Brad Fitzpatrick wrote:
> Is there anything special about or precedent for that value, though? Is it
> trying to match some ABI defined elsewhere, or did we just make it up?
The x86-64 sysv ABI[1] also specifies a so-called "red zone" of 128
> Is there anything special about or precedent for that value, though? Is it
> trying to match some ABI defined elsewhere, or did we just make it up?
bytes, which can be used as scratch space.
[1] http://www.x86-64.org/documentation/abi.pdf
Reply all
Reply to author
Forward
0 new messages