search for: esp

These crashes only happen at night/during the evening, way after maximum load: Jan 27 21:19:57 postamt kernel: [1490698.849461] imap[15089]: segfault at 00000008 eip 080b779b esp bfbe20a0 error 4 Jan 27 21:20:50 postamt kernel: [1490752.022142] imap[15251]: segfault at 00000008 eip 080b779b esp bfd241e0 error 4 Jan 27 21:21:53 postamt kernel: [1490814.348208] imap[15482]: segfault at 00000008 eip 080b779b esp bfeca390 error 4 Jan 27 21:22:26 postamt kernel: [1490846.872861]...

...ll 76719BA1 >> >> I am assuming this is the sqrt function as this is the only >> function called in the LLVM IR. >> >> The code at 76719BA1 is: >> >> 76719BA1 push ebp >> 76719BA2 mov ebp,esp >> 76719BA4 sub esp,20h >> 76719BA7 and esp,0FFFFFFF0h >> 76719BAA fld st(0) >> 76719BAC fst dword ptr [esp+18h] >> 76719BB0 fistp qword ptr [esp+10h] >> 76719BB4 fild...

...(~a & b) | a);* } int main(){ int a, b; scanf("%d %d", &a, &b); return cal(a,b); } *X86 .s file with clang at O2 for above program :* suyog at suyog-Inspiron-N5010:~$ Open/rbuild/bin/clang -S -O2 1.c main: # @main # BB#0: subl $28, %esp leal 20(%esp), %eax movl %eax, 8(%esp) leal 24(%esp), %eax movl %eax, 4(%esp) movl $.L.str, (%esp) calll __isoc99_scanf movl 20(%esp), %eax * orl 24(%esp), %eax* addl $28, %esp retl As seen, optimization happened at IR level itself...

...%in1, i32 %in2) { entry: %q = call fastcc i32 @tailcaller(i32 %in2, i32 %in1) %ww = sub i32 %q, 6 ret i32 %ww } Built with (ToT LLVM): llc < ~/temp/z.ll -march=x86 -tailcallopt -O3 The produced code is (cleaned up a bit) tailcallee: # @tailcallee movl 4(%esp), %eax ret $12 tailcaller: # @tailcaller subl $12, %esp movl %edx, 20(%esp) movl %ecx, 16(%esp) addl $12, %esp jmp tailcallee # TAILCALL foo: # @foo subl $12, %esp movl 20(%esp), %ecx movl 16(%e...

...ing llvm-dis command, but what I got is like the following. So how could I get the assemble code like objdump? I mean the memory address for each instruction. Thanks Qiuyu llvm-dis: .text .align 16 .globl adpcm_coder .type adpcm_coder, @function adpcm_coder: .LBBadpcm_coder_0: # entry sub %ESP, 116 mov DWORD PTR [%ESP + 12], %ESI mov %EAX, DWORD PTR [%ESP + 120] mov %ECX, DWORD PTR [%ESP + 124] mov %EDX, DWORD PTR [%ESP + 128] mov %ESI, DWORD PTR [%ESP + 132] mov DWORD PTR [%ESP], 0 mov DWORD PTR [%ESP + 44], %EAX mov DWORD PTR [%ESP + 40], %ECX objdump : 08048720 <adpcm_cod...

Hello all, In r223757 I've committed a patch that performs, for the 32-bit x86 calling convention, the transformation of MOV instructions that push function arguments onto the stack into actual PUSH instructions. For example, it will transform this: subl $16, %esp movl $4, 12(%esp) movl $3, 8(%esp) movl $2, 4(%esp) movl $1, (%esp) calll _func addl $16, %esp Into this: pushl $4 pushl $3 pushl $2 pushl $1 calll _func addl $16, %esp The main motivation for this is code size (a "pushl $4" is 2 bytes, a...

Compile the following functions with "-O3 -target i386-win32" (see <https://godbolt.org/z/exmjWY>): __int64 __fastcall div(__int64 foo, __int64 bar) { return foo / bar; } On the left the generated code; on the right the expected, properly optimised code: push dword ptr [esp + 16] | push dword ptr [esp + 16] | push dword ptr [esp + 16] | push dword ptr [esp + 16] | call __alldiv | jmp __alldiv ret 16 | __int64 __fastcall mod(__int64 foo, __int64 bar) { return fo...

...'m seeing three cases of >> call 76719BA1 >> >> I am assuming this is the sqrt function as this is the only function >> called in the LLVM IR. >> >> The code at 76719BA1 is: >> >> 76719BA1 push ebp >> 76719BA2 mov ebp,esp >> 76719BA4 sub esp,20h >> 76719BA7 and esp,0FFFFFFF0h >> 76719BAA fld st(0) >> 76719BAC fst dword ptr [esp+18h] >> 76719BB0 fistp qword ptr [esp+10h] >> 76719BB4 fild qword ptr [esp+10h] >> 76719BB8 mov...

Hello again. I still think that you are wrong. Realignement with and esp,-16 not always changes stack poiner. If esp is already aligned to 16 byte boundary, it will not change! Take a look at following example. Assume esp has value 0x000001000 at start of X86CompilationCallback function. Then execution of it will yield following esp values: 0x000000FFC - after push ebp...

...ilcaller(i32 %in2, i32 %in1) > %ww = sub i32 %q, 6 > ret i32 %ww > } > > Built with (ToT LLVM): > llc < ~/temp/z.ll -march=x86 -tailcallopt -O3 > > The produced code is (cleaned up a bit) > > tailcallee: # @tailcallee > movl 4(%esp), %eax > ret $12 > > tailcaller: # @tailcaller > subl $12, %esp > movl %edx, 20(%esp) > movl %ecx, 16(%esp) > addl $12, %esp > jmp tailcallee # TAILCALL > > foo: # @foo >...

...xxxx } return s; } ====== Output A ====== ====================== foo: # @foo .Ltmp12: .cfi_startproc # BB#0: pushl %ebx .Ltmp13: .cfi_def_cfa_offset 8 pushl %edi .Ltmp14: .cfi_def_cfa_offset 12 pushl %esi .Ltmp15: .cfi_def_cfa_offset 16 subl $88, %esp .Ltmp16: .cfi_def_cfa_offset 104 .Ltmp17: .cfi_offset %esi, -16 .Ltmp18: .cfi_offset %edi, -12 .Ltmp19: .cfi_offset %ebx, -8 pxor %xmm0, %xmm0 movl 112(%esp), %eax testl %eax, %eax je .LBB1_3 # BB#1: xorl %ebx, %ebx movl 108(%esp), %ecx movl 104(%esp), %edx xorl %esi, %esi .align 16, 0...

...tput from --print-after-all for the function. The bizarre thing is that even this looks correct: the debugInt is called first with @foo, then @foo+4, and the stores seem to be going to the right addresses as well: @foo and @foo+4! BB#0: derived from LLVM BB %entry PUSHi32 <ga:@foo>, %ESP<imp-def>, %ESP<imp-use> CFI_INSTRUCTION <call frame instruction> CALLpcrel32 <ga:@debugPointer>, <regmask %BH %BL %BP %BPL %BX %DI %DIL %EBP %EBX %EDI %ESI %SI %SIL>, %ESP<imp-use>, %ESP<imp-def>, %EAX<imp-def,dead>, %EDX<imp-def,de...

...t;> *X86 .s file with clang at O2 for above program :* >>>> >>>> suyog at suyog-Inspiron-N5010:~$ Open/rbuild/bin/clang -S -O2 1.c >>>> >>>> main: # @main >>>> # BB#0: >>>> subl $28, %esp >>>> leal 20(%esp), %eax >>>> movl %eax, 8(%esp) >>>> leal 24(%esp), %eax >>>> movl %eax, 4(%esp) >>>> movl $.L.str, (%esp) >>>> calll __isoc99_scanf >>>> movl 20(%es...

...arre thing is that even >> this looks correct: the debugInt is called first with @foo, then @foo+4, >> and the stores seem to be going to the right addresses as well: @foo and >> @foo+4! >> >> BB#0: derived from LLVM BB %entry >> PUSHi32 <ga:@foo>, %ESP<imp-def>, %ESP<imp-use> >> CFI_INSTRUCTION <call frame instruction> >> CALLpcrel32 <ga:@debugPointer>, <regmask %BH %BL %BP %BPL %BX >> %DI %DIL %EBP %EBX %EDI %ESI %SI %SIL>, %ESP<imp-use>, %ESP<imp-def>, >> %EAX<...

...ne instrs printed I tested this code on x86 32bit machine. To verify above result, we can use gdb. You can get information to debug jitted codes from http://llvm.org/docs/DebuggingJITedCode.html. (gdb) disassem Dump of assembler code for function main: 0xb7c27060 <+0>: sub $0x1c,%esp 0xb7c27063 <+3>: movl $0x0,0x18(%esp) 0xb7c2706b <+11>: mov 0x20(%esp),%eax 0xb7c2706f <+15>: mov %eax,0x14(%esp) 0xb7c27073 <+19>: mov 0x24(%esp),%eax 0xb7c27077 <+23>: mov %eax,0x10(%esp) => 0xb7c2707b <+27>: c...

...ext: > .text: > 0: 00 00 addb %al, (%eax) > 00000000: IMAGE_REL_I386_DIR32 _XEP:setfoo > 2: 00 00 addb %al, (%eax) > > _setfoo: > 4: 56 pushl %esi > 5: 83 ec 40 subl $64, %esp > 8: 89 e0 movl %esp, %eax > a: c7 00 00 00 00 00 movl $0, (%eax) > 0000000c: IMAGE_REL_I386_DIR32 _foo > 10: e8 00 00 00 00 calll 0 <_setfoo+0x11> > 00000011: IMAGE_REL_I38...

...ne, I found that LLVM generates redundant code when calling functions with constant parameters, with optimizations disabled. Consider the following C code snippet: int foo(int x, int y); void bar() { foo(1, 2); foo(3, 4); } Clang/LLVM 6.0 generates the following assembly code: _bar: subl $32, %esp movl $1, %eax movl $2, %ecx movl $1, (%esp) movl $2, 4(%esp) movl %eax, 28(%esp) movl %ecx, 24(%esp) calll _foo movl $3, %ecx movl $4, %edx movl $3, (%esp) movl $4, 4(%esp) movl %eax, 20(%esp) movl %ecx, 16(%esp) movl %edx, 12(%esp) calll _foo movl %eax, 8(%esp) addl $32, %esp retl Note how the co...

...xxxx } return s; } ====== Output A ====== ====================== foo: # @foo .Ltmp12: .cfi_startproc # BB#0: pushl %ebx .Ltmp13: .cfi_def_cfa_offset 8 pushl %edi .Ltmp14: .cfi_def_cfa_offset 12 pushl %esi .Ltmp15: .cfi_def_cfa_offset 16 subl $88, %esp .Ltmp16: .cfi_def_cfa_offset 104 .Ltmp17: .cfi_offset %esi, -16 .Ltmp18: .cfi_offset %edi, -12 .Ltmp19: .cfi_offset %ebx, -8 pxor %xmm0, %xmm0 movl 112(%esp), %eax testl %eax, %eax je .LBB1_3 # BB#1: xorl %ebx, %ebx movl 108(%esp), %ecx movl 104(%esp), %edx xorl %esi, %esi .align 16, 0...

...stein, Michael M wrote: Hello all, In r223757 I've committed a patch that performs, for the 32-bit x86 calling convention, the transformation of MOV instructions that push function arguments onto the stack into actual PUSH instructions. For example, it will transform this: subl $16, %esp movl $4, 12(%esp) movl $3, 8(%esp) movl $2, 4(%esp) movl $1, (%esp) calll _func addl $16, %esp Into this: pushl $4 pushl $3 pushl $2 pushl $1 calll _func addl $16, %esp The main motivation for this is code size (a "pushl $4" is 2 bytes, a...

...# Intel. .text .text .align 16 .align 16 .globl main .globl main .type main, @function main: main: subl $12, %esp sub esp, 12 fnstcw 10(%esp) fnstcw word ptr [esp + 10] movb $2, 11(%esp) mov byte ptr [esp + 11], 2 fldcw 10(%esp) fldcw word ptr [esp + 10] movl 20(%esp), %eax mov eax, dword ptr [esp + 20]...