Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
More about multi-stack allocator.Serge Orlov (sorlovCON.MCST.RU)
Wed, 28 Oct 1998 16:12:30 +0300
- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Patrick Oonk: "FW: Security Bulletins Digest"
- Previous message: Kragen: "Re: Netscape "What's Related""
Hi, I received some questions about multi-stack allocator, here is the answers: > how about performance compare with "canary" and "stack guard"? Author of StackGuard wrote to me about multi-stack: > Way cool... > ... > Your performance figures are very impressive. StackGuard puts "canaries" into every function (at least in the current version). In contrast multi-stack allocator is used only for local arrays and does not affect functions without local arrays. So if a program spends most of time in functions without arrays, it is even hard to measure slowdown. If a program uses arrays, then the slowdown is about 1%. That is lower than with StackGuard. The main difference is memory. StackGuard almost does not increase memory consumption, while multi-stacked program can use a lot of additional memory. Reread my first post for figures. Fortunately, memory is cheap nowadays. > So how compatible is it? Can it inter-operate with standard shared > libraries? Do you just have to re-compile the shared libraries? You can mix multi-stacked programs and shared libraries in all possible ways. Well, at least on elf-i386-linux, other platforms may need some porting and checking. Shared libraries are also easy to recompile. Just add -fmulti-stack option. Crispin Cowan also noted that the C standard states that automatic variables are to be laid out in sequential memory, although some padding is allowed. OK, I'll add this to "Limitations" paragraph, but I have not seen any programs that depend on layout of automatic variables. Serge Orlov <sorlovcon.mcst.ru>.