1

The way I understand it, segmented stacks are built with compiler support so that whenever a function running on the segmented stack calls another function, if first checks whether the stack has enough space for the stack frame for that new function. And if it doesn't another segmented stack is attached and code branches to that function.

But does this work if say for example I have a fiber running and I call another function from another shared (or compiled into non shared object file) library that was not compiled with the -fsplit-stack option? How do the functions in that library know that they would have to check to see if the segmented stack has enough space in the segmented stack to continue?

Only interested in clang and gcc implementations (and in particular with boost context), thanks!

Curious
  • 20,870
  • 8
  • 61
  • 146
  • It seems to me this question has been addressed [several times before](https://stackoverflow.com/search?tab=relevance&q=segmented%20stack). I can see you would like some _more_ confirmation, but honestly, I don't see why you expect anyone to be able to provide it, this time, when it didn't happen the other times – sehe Nov 19 '17 at 16:22
  • @sehe those questions were different. Which one in specific are you referring to? – Curious Nov 19 '17 at 16:23
  • 1
    I don't readily spot that now, but I've highlighted the sections I remember that I think answer your current question. Perhaps I misremember some of the things I privately read as part of the discussions that took place at the time. – sehe Nov 19 '17 at 16:31

1 Answers1

1

I'm going to grab back at a piece of documentation that I remember seeing at an earlier question about this subject:

Backward compatibility

We want to be able to use split stack programs on systems with prebuilt libraries compiled without split stacks. This means that we need to ensure that there is sufficient stack space before calling any such function.

Each object file compiled in split stack mode will be annotated to indicate that the functions use split stacks. This should probably be annotated with a note but there is no general support for creating arbitrary notes in GNU as. Therefore, each object file compiled in split stack mode will have an empty section with a special name: .note.GNU-split-stack. If an object file compiled in split stack mode includes some functions with the no_split_stack attribute, then the object file will also have a .note.GNU-no-split-stack section. This will tell the linker that some functions may not have the expected split stack prologue.

[...]

For calls from split-stack code to non-split-stack code, the linker will change the initial instructions in the split-stack (caller) function. This means that the linker will have to have special knowledge of the instructions that the compiler emits. The effect of the changes will be to increase the required framesize by a number large enough to reasonably work for a non-split-stack. This will be a target dependent number; the default will be something like 64K. Note that this large stack will be released when the split-stack function returns. Note that I'm disregarding the case of split-stack code in a shared library calling non-split-stack code in the main executable; that seems like an unlikely problem.

I specifically remember the list (italicized) caveat - I don't remember it was me who highlighted it or someone else. The keyword in that discussion was about "callbacks".

Community
  • 1
  • 1
sehe
  • 374,641
  • 47
  • 450
  • 633
  • So then do you think its bad to have a segmented stack function call another one in another shared library? Since it sort of involves guessing? – Curious Nov 19 '17 at 16:32
  • It doesn't involve guessing. The linker knows and emits enough code so it shouldn't break. However, it will be suboptimal (it could really hurt a lot for repeatedly called functions). The part where it will go wrong (again, NOT a guess, just deterministically wrong) is when you pass an external split-stack library a callback into your main program that is not split-stack. This will NOT be detected by the linker. – sehe Nov 19 '17 at 17:06
  • Mmm. I should probably not say "callback" (as it might imply function pointers, which is a separate issue, mentioned directly below in the docs). In fact they probably calling back into your non-splitstack code via dynamic linkage (exported symbols imported from the split-stack library via `-rdynamic`) – sehe Nov 19 '17 at 17:09
  • "When you pass an external split-stack library a callback into your main program that is not split stack" how is this case different from a split stack function calling another non split-stack function? That was the case I originally meant to ask about. Don't think i understand :( – Curious Nov 19 '17 at 17:12
  • It's backwards compatibility, not forward compatibility. Split-stack **knows** about splitstacks, so it can adjust when calling non-splitstack. Vice versa is not the case (the non-split stack code might have been compiled by a compiler that isn't aware of split stack code at all) – sehe Nov 19 '17 at 17:20
  • Oh got it, but then what if the function you are calling from the split stack code takes up more than 64KB on the stack? – Curious Nov 19 '17 at 18:39
  • 1
    Then you get a stack overflow as anywhere (iirc a default pthreads stack size is ~8kb) – sehe Nov 19 '17 at 18:41