Move current stack frame in C

Question

I was wondering if there would be a convenient way to copy the current stack frame, move it somewhere else, and then 'return' from the function, from the new location?

I have been playing around with setjmp and longjmp while allocating large arrays on the stack to force the stack pointer away. I am familiar with the calling conventions and where arguments to functions end up etc, but I am not extremely experienced with pointer arithmetic.

To describe the end goal in general terms; The ambition is to be able to allocate stack frames and to jump to another stack frame when I call a function (we can call this function switch). Before I jump to the new stack frame, however, I'd like to be able to grab the return address from switch so when I've (presumably) longjmpd to the new frame, I'd be able to return to the position that initiated the context switch.

I've already gotten some inspiration of how to imitate coroutines using longjmp an setjmp from this post.

If this is possible, it would be a component of my current research, where I am trying to implement a (very rough) proof of concept extension in a compiler. I'd appreciate answers and comments that address the question posed in my first paragraph, only.

Update

To try and make my intention clearer, I wrote up this example in C. It needs to be compiled with -fno-stack-protector. What i want is for the local variables a and b in main to not be next to each other on the stack (1), but rather be separated by a distance specified by the buffer in call. Furthermore, currently this code will return to main twice, while I only want it to do so once (2). I suggest you read the procedures in this order: main, call and change.

If anyone could answer any of the two question posed in the paragraph above, I would be immensely grateful. It does not have to be pretty or portable.

Again, I'd prefer answers to my questions rather than suggestions of better ways to go about things.

#include <stdio.h>
#include <stdlib.h>
#include <setjmp.h>

jmp_buf* buf;
long* retaddr;

int change(void) {
  // local variable to use when computing offsets
  long a[0];

  for(int i = 0; i < 5; i++) a[i]; // same as below, not sure why I need to read this

  // save this context
  if(setjmp(*buf) == 0) {
    return 1;
  }
  // the following code runs when longjmp was called with *buf

  // overwrite this contexts return address with the one used by call
  a[2] = *retaddr;

  // return, hopefully now to main
  return 1;
}

static void* retain;

int call() {
  buf     = (jmp_buf*)malloc(sizeof(jmp_buf));
  retaddr = (long*)   malloc(sizeof(long));
  long a[0];
  for(int i = 0; i < 5; i++) a[i]; // not sure why I need to do this. a[2] reads (nil) otherwise

  // store return address
  *retaddr = a[2];

  // allocate local variables to move the stackpointer
  char n[1024];
  retain = n; // maybe cheat the optimiser?

  // get a jmp_buf from another context
  change();

  // jump there
  longjmp(*buf, 1);
}


// It returns to main twice, I am not sure why
int main(void) {
  char a;
  call(); // this function should move stackpointer (in this case, 1024 bytes)
  char b;
  printf("address of a: %p\n", &a);
  printf("address of b: %p\n", &b);
  return 1;
}

Answer 1

This is possible, it is what multi-tasking schedulers do, e.g. in embedded environments.
It is however extremely environment-specific and would have to dig into the the specifics of the processor it is running on.

Basically, the possible steps are:

• Determine the registers which contain the needed information. Pick them by what you need, they are probably different from what the compiler uses on the stack for implementing function calls.
• Find out how their content can be stored (most likely specific assembler instructions for each register).
• Use them to store all contents contiguosly.
• The place to do so is probably allocated already, inside the object describing and administrating the current task.
• Consider not using a return address. Instead, when done with the "inserted" task, decide among the multiple task datasets which describe potential tasks to return to. That is the core of scheduling. If the return address is known in advance, then it is very similar to normal function calling. I.e. the idea is to potentially return to a different task than the last one left. That is also the reason why tasks need their own stack in many cases.

By the way, I don't think that pointer arithmetic is the most relevant tool here.
The content of the registers which make the stack frame are in registers, not anywhere in memory which a pointer can point to. (At least in most current systems, C64 staying out of this....).

Answer 2

tl;dr - no.

(On every compiler worth considering): The compiler knows the address of local variables by their offset from either the sp, or a designated saved stack pointer, the frame or base pointer. a might have an address of (sp+1), and b might have an address of (sp+0). If you manage to successfully return to main with the stack pointer lowered by 1024; these will still be known as (sp+1), (sp+0); although they are technically now (sp+1-1024), (sp+0-1024), which means they are no longer a & b.

You could design a language which fixed the local allocation in the way you consider, and that might have some interesting expressiveness, but it isn't C. I doubt any existing compiler could come up with a consistent handling of this. To do so, when it encountered:

char a;

it would have to make an alias of this address at the point it encountered it; say:

add %sp, $0, %r1
sub %sp, $1, %sp

and when it encountered

char b;
add %sp, $0, %r2
sub %sp, $1, %sp

and so on, but one it runs out of free registers, it needs to spill them on the stack; and because it considers the stack to change without notice, it would have to allocate a pointer to this spill area, and keep that stored in a register.

Btw, this is not far removed from the concept of a splayed stack (golang uses these), but generally the granularity is at a function or method boundary, not between two variable definitions.

Interesting idea though.