> Frank Hofmann - Solaris Sustaining writes: > > > > Let me guess: You've compiled this driver with gcc, and did not > > specify the "-mno-red-zone" compiler option ? > > Correct. My gcc flags for amd64 are "-m64 -mcmodel=kernel" > I got those flags from from http://iforce.sun.com/protected/solaris10/adoptionkit/x86/techinfo.html
ARGH ! Why do we not talk to each other internally ... > > Is -mno-red-zone a requirement for compiling drivers? Is it > scribbling over the stack without it? -mno-red-zone is required when compiling kernel code for AMD64. On all operating systems. For an explanation, read the PDF file I sent, or else check out for example: http://www.amd.com/us-en/assets/content_type/DownloadableAssets/Porting_x86_Linu x_device_drivers_to_AMD64_Technology.htm http://lists.suse.com/archive/suse-amd64/2003-Nov/0019.html http://lists.suse.com/archive/suse-amd64/2004-Jan/0034.html http://www.x86-64.org/lists/discuss/msg00734.html People trip over this all the time. Everywhere ... gcc 3.4.4 (we currently ship 3.4.3 with Solaris 10) AFAIK has the default option behaviour changed so that "-mcmodel=kernel" implies "-mno-red-zone". But it took the gcc people three years to make that change, and it came a few weeks too late for us to include gcc 3.4.4 ... -mno-red-zone disables gcc's use of unallocated stackspace. Without it, gcc generates code of the sort: movq %rbx, -0x20(%rsp) movq %r12, -0x18(%rsp) movq %r13, -0x10(%rsp) pushq %rbp movq %rsp, %rbp subq $0x20, %rsp ... I.e. it saves the nonvolatile registers into the stack before allocating the stackspace for them. Which works in userland, because the AMD64 ABI specifies "the memory (%rsp) ... -0xff(%rsp) will not be overwritten by interrupts/signals and may be used". It's supposed to be an optimization, save two instructions for allocating/freeing stackspace in leaf functions. Unfortunately, this can't work in any kernel, by virtue of how x86 CPUs dispatch interrupts/traps. It's just impossible. A kernel cannot be made compatible with this so-called "red zone". Best regards, FrankH.
