>No, there is no option for that. (In C++, you can have objects that >manage data on the heap so that the object itself is local on the stack >but the bulk of the storage is on the heap.) >There are some warning options that could help you spot problem >functions, like -Wlarger-than and -Wstack-usage. You can also generate >stack usage information with -fstack-usage. >Also note that if the objects are not VLAs and you are not using >recursion, you can usually use "static" on the local variables to give >them fixed static addresses (in the data/bss section, rather than the >heap or stack) and thus move them off the stack. >Finally, are you sure the stack usage is actually a problem? Thanks a lot David :) Since I want to migrate many synchronous codes (currently) into asynchronous implementation by hooking the blocking syscalls for concurrency and performance by using C coroutine (copy stack). The split-stack is fine but it is not mature in GCC (from aspects of performance and customizability). And the standalone stack for each coroutine would also cost too much. (The -Wlarger-than, -Wstack-usage and -fstack-usage is very great and I'm using it.) (Sorry for reposting) On Wed, May 30, 2018 at 8:31 AM, Remus Clearwater < remus.clearwater@xxxxxxxxx> wrote: > >No, there is no option for that. (In C++, you can have objects that > >manage data on the heap so that the object itself is local on the stack > >but the bulk of the storage is on the heap.) > > >There are some warning options that could help you spot problem > >functions, like -Wlarger-than and -Wstack-usage. You can also generate > >stack usage information with -fstack-usage. > > >Also note that if the objects are not VLAs and you are not using > >recursion, you can usually use "static" on the local variables to give > >them fixed static addresses (in the data/bss section, rather than the > >heap or stack) and thus move them off the stack. > > >Finally, are you sure the stack usage is actually a problem? > > Thanks a lot David :) > > Since I want to migrate many synchronous codes (currently) into > asynchronous implementation by hooking the blocking syscalls for > concurrency and performance by using C coroutine (copy stack). The > split-stack is fine but it is not mature in GCC (from aspects of > performance and customizability). And the standalone stack for each > coroutine would also cost too much. > > (The -Wlarger-than, -Wstack-usage and -fstack-usage is very great and I'm > using it.) > > On Tue, May 29, 2018 at 2:36 PM, David Brown <david@xxxxxxxxxxxxxxx> > wrote: > >> On 29/05/18 03:27, Remus Clearwater wrote: >> > Hi, for some reason, I want to keep the stack frame usage of some >> functions >> > as smaller as possible, but rewrite them by hands is such a pain and >> very >> > stupid since they are using many and big local variables currently. And >> in >> > these functions they doesn't do anything like longjmp. >> > >> > So, is there a option to tell gcc to allocate local variable on the heap >> > not the default stack (auto free them before return)? >> > >> >> No, there is no option for that. (In C++, you can have objects that >> manage data on the heap so that the object itself is local on the stack >> but the bulk of the storage is on the heap.) >> >> There are some warning options that could help you spot problem >> functions, like -Wlarger-than and -Wstack-usage. You can also generate >> stack usage information with -fstack-usage. >> >> Also note that if the objects are not VLAs and you are not using >> recursion, you can usually use "static" on the local variables to give >> them fixed static addresses (in the data/bss section, rather than the >> heap or stack) and thus move them off the stack. >> >> Finally, are you sure the stack usage is actually a problem? >> >> >
