StackThreads/MP: version 0.77 User's Guide

10.6: Big arguments

This problem rarely occurs. When a procedure calls another procedure with extremely large arguments. In practice the problem only occurs when you have a structure that embeds a large array and passes an instance of the structure by value. Here is an example that may cause the problem.

@        typedef struct bigstr
@        {
@          a[1000];
@        } bigstr;
@        void bigstr_eather(bigstr bs) { ... }
@
@        void caller()
@        {
@          bigstr b;
@          bigstr_eater(b);
@        }

stgcc command invokes gcc and examines the assembly code generated by gcc. It collects information about stack frame formats of compiled procedures. Collected information includes, among other things, the size of the SP-relative region (the region accessed via stack pointer) of each stack frame. The size of SP-relative regions are determined by gcc depending on the size of out-going parameters. stgcc must know the size of the region to do stack management. It computes the size by scanning the assembly instruction sequence and finding instructions that store something using stack pointer as the base register. For all such instructions, we check the offset + the operand size, and computes the maximum of these values. This is the size of the SP-relative region for that procedure.

In programs like this, the compiler may obscure such SP-relative stores. For example, if the location to be written cannot be reached by a store instruction using stack pointer as the base, the location may be computed to a general purpose register and then written using that register as the base. Even worse, arguments are written by calling functions like memcpy. Thus, stgcc may not be able to SP-relative regions accurately for such programs and as a consequence, stack management scheme may be broken.

I have never encountered this problem. You will not often encounter this problem either, because C/C++ programmers know that passing large structures are expensive in C/C++ and normally pass such structures by pointers.

There are some ways to make this problem even unlikely to occur, but I do not think of a perfect idea right now. To guarantee 100% safety, I guess we must eventually hack the compiler. We simply want to know gcc's idea about the size of SP-relative regions in a form of a comment or a directive in generated assembly instructions. Such information should be readily available inside a compiler and gcc seems to generate such information on some CPUs. Let's make it available all machines!