Hello,
If you go into your LLVM IR dump and look at the place where the function
is defined, you'll see a reference to an attribute set, e.g.
define void @main.foo(i8* nest %nest.1) #0 !dbg !16 {
Here "#0" refers to this attribute set (appearing later in the dump):
attributes #0 = { "disable-tail-calls"="true" "frame-pointer"="none"
"null-pointer-is-valid"="true" "split-stack" "target-cpu"="x86-64"
"target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" }
One of these attributes is "split-stack". When this attribute is set, the
LLVM back end will emit a stack check in the prolog with a call to expand
the stack if needed.
You can find this code at
https://github.com/llvm/llvm-project/blob/25bb61649085c0a6e66630bbffe7faa54cd67829/llvm/lib/CodeGen/PrologEpilogInserter.cpp#L1128
Hope this helps.
Thanks, Than
On Wed, Jun 23, 2021 at 11:11 PM Kavindu Gimhan Zoysa <kavindu...@gmail.com>
wrote:
> Hi Kurtis,
>
> Thank you for your input.
>
> I am searching how do languages handle stack overflow. Languages like
> rust, handle this by catching SIGSEGV. In golang, as I found, it was
> handled by increasing the stack[1], [2] (Sorry if my terms are wrong). I
> have generated object dump(objdump -d) for go source code (just a function
> call) I can see that at the beginning of every function call it checks for
> the stack overflow and try to increase the stack(see //go:nosplit section
> of [2]). I am lloking how does gollvm handle this.
>
> *00000000004871a0 <main.foo>:*
> * 4871a0: 64 48 8b 0c 25 f8 ff mov %fs:0xfffffffffffffff8,%rcx*
> * 4871a7: ff ff *
> * 4871a9: 48 8d 44 24 f8 lea -0x8(%rsp),%rax*
> * 4871ae: 48 3b 41 10 cmp 0x10(%rcx),%rax*
> * 4871b2: 0f 86 e1 00 00 00 jbe 487299 <main.foo+0xf9>*
> * ........*
> * 487299: e8 62 80 fc ff callq 44f300
> <runtime.morestack_noctxt>*
> * 48729e: e9 fd fe ff ff jmpq 4871a0 <main.foo>*
>
> [1]:
> https://github.com/golang/go/blob/02ab8d1a1dc82ce019969221313bfa28911f54a1/src/runtime/stack.go#L28
> [2]: https://dave.cheney.net/2018/01/08/gos-hidden-pragmas
> On Thursday, 24 June 2021 at 08:17:33 UTC+5:30 Kurtis Rader wrote:
>
>> This might be an XY Problem <https://xyproblem.info/>, or your question
>> simply needs more context. Your sample program is an example of infinite
>> recursion. How that is detected is platform specific. It might be done via
>> a special signal. Or it might be done by a syscall to grow the stack
>> returning an error. So my question is, why are you asking how infinite
>> recursion is handled?
>>
>> On Wed, Jun 23, 2021 at 7:33 PM Kavindu Gimhan Zoysa <kavin...@gmail.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> *package main*
>>>
>>> *func main() {*
>>> * foo()*
>>> *}*
>>>
>>> *func foo() {*
>>> * a := 5*
>>> * _ = a*
>>> * foo()*
>>> *}*
>>>
>>> I have generated the below llvm ir using the command `./bin/llvm-goc -S
>>> test.go -dump-ir`. I expected there are some llvm intrinsics that have been
>>> used to handle stack overflow. But it is not there. How does gollvm handle
>>> stackoverflow?
>>>
>>> *define void @main.main(i8* nest %nest.0) #0 !dbg !14 {*
>>> *entry:*
>>> * call void @main.foo(i8* nest undef), !dbg !15*
>>> * ret void*
>>> *}*
>>>
>>> *define void @main.foo(i8* nest %nest.1) #0 !dbg !16 {*
>>> *entry:*
>>> * %a = alloca i64, align 8*
>>> * %0 = bitcast i64* %a to i8**
>>> * call void @llvm.lifetime.start.p0i8(i64 8, i8* %0)*
>>> * store i64 5, i64* %a, align 8*
>>> * call void @llvm.dbg.declare(metadata i64* %a, metadata !17, metadata
>>> !DIExpression()), !dbg !20*
>>> * %a.ld.0 = load i64, i64* %a, align 8, !dbg !21*
>>> * call void @main.foo(i8* nest undef), !dbg !22*
>>> * %1 = bitcast i64* %a to i8**
>>> * call void @llvm.lifetime.end.p0i8(i64 8, i8* %1)*
>>> * ret void*
>>> *}*
>>>
>>> --
>>> 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.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/0bbb1347-5ceb-4ed2-9622-cb695d29bc6dn%40googlegroups.com
>>> <https://groups.google.com/d/msgid/golang-nuts/0bbb1347-5ceb-4ed2-9622-cb695d29bc6dn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>>
>> --
>> Kurtis Rader
>> Caretaker of the exceptional canines Junior and Hank
>>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/53de3903-83a2-4b31-b73d-4d46504ca28cn%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/53de3903-83a2-4b31-b73d-4d46504ca28cn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CA%2BUr55FYWC3UcCLLzz3Rzyfi5GU6viyEEmo2%3DFiKWk5Y%3Dqtbmw%40mail.gmail.com.
