red-zone

use of -mcmodel=kernel flag in x86 platform

≯℡__Kan透↙ 提交于 2019-12-24 07:39:42
问题 I am trying to cross compile a device driver built for x86 architecture to arm platform. It got compiled without any errors, but I dont think whole features are available. So I checked the makefile and found this particular part. ifeq ($(ARCH),x86_64) EXTRA_CFLAGS += -mcmodel=kernel -mno-red-zone This is the only part that depends on architecture it seems. After some time on google, I found that -mcmodel=kernel is for kernel code model and -mno-red-zone is to avoid using red zone in memory

Why is there no “sub rsp” instruction in this function prologue and why are function parameters stored at negative rbp offsets?

狂风中的少年 提交于 2019-12-17 17:04:17
问题 That's what I understood by reading some memory segmentation documents: when a function is called, there are a few instructions (called function prologue) that save the frame pointer on the stack, copy the value of the stack pointer into the base pointer and save some memory for local variables. Here's a trivial code I am trying to debug using GDB: void test_function(int a, int b, int c, int d) { int flag; char buffer[10]; flag = 31337; buffer[0] = 'A'; } int main() { test_function(1, 2, 3, 4

Why does GCC subtract the wrong value to the stack pointer when allocating a big array with no subsequent function calls?

浪子不回头ぞ 提交于 2019-12-05 14:03:21
问题 Really bizarre gcc quirk. Check this out: main() { int a[100]; a[0]=1; } produces this assembly: 0: 55 push %rbp 1: 48 89 e5 mov %rsp,%rbp 4: 48 81 ec 18 01 00 00 sub $0x118,%rsp b: c7 85 70 fe ff ff 01 movl $0x1,-0x190(%rbp) 12: 00 00 00 15: c9 leaveq 16: c3 retq The top of the stack is clearly 400, since its a 100 * 4 array. So when it writes to the first entry, it does rbp - 400 (line 'b'). Good. But why does it subtract 280 from the stack (line '4') pointer? Doesn't that point to the

Invalid access of stack red zone from Java VM

人走茶凉 提交于 2019-12-05 11:51:56
问题 I'm trying to figure out what can cause this error in Java: Invalid access of stack red zone 0x115ee0ed0 rip=0x114973900 Has anyone ever encountered this error message? It's literally killing the JVM and everything stops there. I'm currently using this version of Java:(on OS X 10.6) java version "1.6.0_15" Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02-90, mixed mode) All I'm looking for is some sort of explanation and tips on how to

Why does GCC subtract the wrong value to the stack pointer when allocating a big array with no subsequent function calls?

故事扮演 提交于 2019-12-04 00:41:16
Really bizarre gcc quirk. Check this out: main() { int a[100]; a[0]=1; } produces this assembly: 0: 55 push %rbp 1: 48 89 e5 mov %rsp,%rbp 4: 48 81 ec 18 01 00 00 sub $0x118,%rsp b: c7 85 70 fe ff ff 01 movl $0x1,-0x190(%rbp) 12: 00 00 00 15: c9 leaveq 16: c3 retq The top of the stack is clearly 400, since its a 100 * 4 array. So when it writes to the first entry, it does rbp - 400 (line 'b'). Good. But why does it subtract 280 from the stack (line '4') pointer? Doesn't that point to the middle of the array? If we add a function call afterward, gcc does the right thing: b() {} main() { int a

Why do we need stack allocation when we have a red zone?

限于喜欢 提交于 2019-11-29 10:37:04
I have the following doubts: As we know System V x86-64 ABI gives us about a fixed-size area (128 bytes) in the stack frame, so called redzone. So, as a result we don't need to use, for example, sub rsp, 12 . Just make mov [rsp-12], X and that's all. But I cannot grasp idea of that. Why does it matter? Is it necessary to sub rsp, 12 without redzone? After all, stack size is limited at the beginning so why sub rsp, 12 is important? I know that it makes possible us to follow the top of the stack but let's ignore it at that moment. I know what some instructions use rsp value ( like ret ) but don

Why is there no “sub rsp” instruction in this function prologue and why are function parameters stored at negative rbp offsets?

穿精又带淫゛_ 提交于 2019-11-28 13:47:10
That's what I understood by reading some memory segmentation documents: when a function is called, there are a few instructions (called function prologue) that save the frame pointer on the stack, copy the value of the stack pointer into the base pointer and save some memory for local variables. Here's a trivial code I am trying to debug using GDB: void test_function(int a, int b, int c, int d) { int flag; char buffer[10]; flag = 31337; buffer[0] = 'A'; } int main() { test_function(1, 2, 3, 4); } The purpose of debugging this code was to understand what happens in the stack when a function is

Why does the compiler reserve a little stack space but not the whole array size?

拈花ヽ惹草 提交于 2019-11-28 13:11:10
The following code int main() { int arr[120]; return arr[0]; } Compiles into this: sub rsp, 360 mov eax, DWORD PTR [rsp-480] add rsp, 360 ret Knowing the ints are 4 bytes and the array is size 120, the array should take 480 bytes, but only 360 bytes are subtracted from ESP... Why is this? Below the stack area used by a function, there is a 128-byte red zone that is reserved for program use. Since main calls no other function, it has no need to move the stack pointer by more than it needs, though it doesn't matter in this case. I only subtracts enough from rsp to ensure that the array is