search for: leaveq

...-0x8(%rbp),%rax 23: 89 10 mov %edx,(%rax) 25: b8 00 00 00 00 mov $0x0,%eax 2a: 90 nop 2b: 90 nop 2c: 90 nop 2d: 90 nop 2e: 90 nop 2f: c9 leaveq 30: c3 retq instead of: 0000000000000000 <foo>: 0: 55 push %rbp 1: 48 89 e5 mov %rsp,%rbp 4: 48 83 ec 10 sub $0x10,%rsp 8: 48 89 7d f8 mov %rdi,-0x8(%rbp) c: b8 00 00 00 00 mov $0x0,...

...0x2b7184072042: retq (gdb) x/10i nfoo_addr 0x40603a <nativefoo>: push %rbp 0x40603b <nativefoo+1>: mov %rsp,%rbp 0x40603e <nativefoo+4>: mov $0x1e,%edi 0x406043 <nativefoo+9>: callq 0x406018 <addOne> <--- ok 0x406048 <nativefoo+14>: leaveq 0x406049 <nativefoo+15>: retq OS X 64-bit: (gdb) print addone_addr $1 = (void *) 0x100000d56 (gdb) x/10i foo_addr x/10i foo_addr 0x102080030: sub $0x8,%rsp 0x102080034: mov $0x14,%edi 0x102080039: callq 0x100000d56 <addOne> <--- ok 0x10208003e: add $0x8,%rsp...

...<+45>: push %rbp 0xffffffff8102ca8e <+46>: mov $0x40000020,%edi 0xffffffff8102ca93 <+51>: mov %rsp,%rbp 0xffffffff8102ca96 <+54>: and $0xfffffffffffffff0,%rsp 0xffffffff8102ca9a <+58>: callq *0xffffffff81c36330 0xffffffff8102caa1 <+65>: leaveq 0xffffffff8102caa2 <+66>: retq 0xffffffff8102caa3 <+67>: shl $0x20,%rdx 0xffffffff8102caa7 <+71>: or %rdx,%rax 0xffffffff8102caaa <+74>: mul %r9 0xffffffff8102caad <+77>: mov %rdx,%rax 0xffffffff8102cab0 <+80>: add %r8,%rax...

...<+45>: push %rbp 0xffffffff8102ca8e <+46>: mov $0x40000020,%edi 0xffffffff8102ca93 <+51>: mov %rsp,%rbp 0xffffffff8102ca96 <+54>: and $0xfffffffffffffff0,%rsp 0xffffffff8102ca9a <+58>: callq *0xffffffff81c36330 0xffffffff8102caa1 <+65>: leaveq 0xffffffff8102caa2 <+66>: retq 0xffffffff8102caa3 <+67>: shl $0x20,%rdx 0xffffffff8102caa7 <+71>: or %rdx,%rax 0xffffffff8102caaa <+74>: mul %r9 0xffffffff8102caad <+77>: mov %rdx,%rax 0xffffffff8102cab0 <+80>: add %r8,%rax...

...18 > <PropertyReader::PropertyReader()+0x18> > 14: R_X86_64_PLT32 > std::vector<PropertyReader::record, > std::allocator<PropertyReader::record> > >::vector()-0x4 > 18: 90 nop > 19: c9 leaveq > 1a: c3 retq > ... > > But linking such an object file with lld does not produce the original > error so something else is going on. > > > Let me know if more is needed. > >> > >> I recall that this object file is created in a bit...

...;foo+9>: mov %eax,-0x10(%rbp) 0x00000001000010b8 <foo+12>: mov $0x420c0000,%eax 0x00000001000010bd <foo+17>: mov %eax,-0xc(%rbp) 0x00000001000010c0 <foo+20>: mov -0x10(%rbp),%rax 0x00000001000010c4 <foo+24>: movd %rax,%xmm0 0x00000001000010c9 <foo+29>: leaveq 0x00000001000010ca <foo+30>: retq Here the two values are returned 'packed' in xmm0, while LLVM returns them separately in xmm0 and xmm1. This is causing problems when calling the function generated by LLVM from C (or my real use case, via libFFI). What happens is that I get t...

...fff8102ca8e <+46>: mov $0x40000020,%edi > 0xffffffff8102ca93 <+51>: mov %rsp,%rbp > 0xffffffff8102ca96 <+54>: and $0xfffffffffffffff0,%rsp > 0xffffffff8102ca9a <+58>: callq *0xffffffff81c36330 > 0xffffffff8102caa1 <+65>: leaveq > 0xffffffff8102caa2 <+66>: retq > 0xffffffff8102caa3 <+67>: shl $0x20,%rdx > 0xffffffff8102caa7 <+71>: or %rdx,%rax > 0xffffffff8102caaa <+74>: mul %r9 > 0xffffffff8102caad <+77>: mov %rdx,%rax > 0xffffff...

On Wed, Mar 15, 2017 at 2:22 PM, Martin Richtarsky <s at martinien.de> wrote: > Here is the relevant output: > > 0000000000013832 <func()>: > 13832: 55 push %rbp > 13833: 48 89 e5 mov %rsp,%rbp > 13836: 53 push %rbx > 13837: 48 83 ec 18 sub $0x18,%rsp

...ssentially redundant with preempt_count it is a little cheaper to use a separate counter in the PDA @@ -525,7 +535,7 @@ ENTRY(common_interrupt) interrupt do_IRQ /* 0(%rsp): oldrsp-ARGOFFSET */ ret_from_intr: - cli + DISABLE_INTERRUPTS(CLBR_NONE) TRACE_IRQS_OFF decl %gs:pda_irqcount leaveq @@ -552,13 +562,13 @@ retint_swapgs: /* * The iretq could re-enable interrupts: */ - cli + DISABLE_INTERRUPTS(CLBR_NONE) TRACE_IRQS_IRETQ - swapgs + SWAPGS jmp restore_args retint_restore_args: - cli + DISABLE_INTERRUPTS(CLBR_NONE) /* * The iretq could re-enable interrup...

...ssentially redundant with preempt_count it is a little cheaper to use a separate counter in the PDA @@ -525,7 +535,7 @@ ENTRY(common_interrupt) interrupt do_IRQ /* 0(%rsp): oldrsp-ARGOFFSET */ ret_from_intr: - cli + DISABLE_INTERRUPTS(CLBR_NONE) TRACE_IRQS_OFF decl %gs:pda_irqcount leaveq @@ -552,13 +562,13 @@ retint_swapgs: /* * The iretq could re-enable interrupts: */ - cli + DISABLE_INTERRUPTS(CLBR_NONE) TRACE_IRQS_IRETQ - swapgs + SWAPGS jmp restore_args retint_restore_args: - cli + DISABLE_INTERRUPTS(CLBR_NONE) /* * The iretq could re-enable interrup...

...; > >> 14: R_X86_64_PLT32 > >> std::vector<PropertyReader::record, > >> std::allocator<PropertyReader::record> > >> >::vector()-0x4 > >> 18: 90 nop > >> 19: c9 leaveq > >> 1a: c3 retq > >> ... > >> > >> But linking such an object file with lld does not produce the original > >> error so something else is going on. > >> > >> > Let me know if more is needed. > >> &g...

Hi All, I''m getting the attached panic in the hypervisor on a Sun 6270 running xen-testing.hg changeset 19913:6063c16aeeaa. I can run xen-3.3.1 from the standard SLES 11 distribution (which says that it''s changeset 18546 but it has many patches). Any ideas? thanks, dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

Hi, while we're still waiting for a definitive ACK from Microsoft that the algorithm is good for SMP case (as we can't prevent the code in vdso from migrating between CPUs) I'd like to send v2 with some modifications to keep the discussion going. Changes since v1: - Document the TSC page reading protocol [Thomas Gleixner]. - Separate the TSC page reading code from

Hi, while we're still waiting for a definitive ACK from Microsoft that the algorithm is good for SMP case (as we can't prevent the code in vdso from migrating between CPUs) I'd like to send v2 with some modifications to keep the discussion going. Changes since v1: - Document the TSC page reading protocol [Thomas Gleixner]. - Separate the TSC page reading code from

...RESTORE_REST - cli + DISABLE_INTERRUPTS(CLBR_NONE) TRACE_IRQS_OFF jmp int_with_check CFI_ENDPROC @@ -525,7 +533,7 @@ ENTRY(common_interrupt) interrupt do_IRQ /* 0(%rsp): oldrsp-ARGOFFSET */ ret_from_intr: - cli + DISABLE_INTERRUPTS(CLBR_NONE) TRACE_IRQS_OFF decl %gs:pda_irqcount leaveq @@ -552,13 +560,13 @@ retint_swapgs: /* * The iretq could re-enable interrupts: */ - cli + DISABLE_INTERRUPTS(CLBR_NONE) TRACE_IRQS_IRETQ swapgs jmp restore_args retint_restore_args: - cli + DISABLE_INTERRUPTS(CLBR_NONE) /* * The iretq could re-enable interrupts: */...

...RESTORE_REST - cli + DISABLE_INTERRUPTS(CLBR_NONE) TRACE_IRQS_OFF jmp int_with_check CFI_ENDPROC @@ -525,7 +533,7 @@ ENTRY(common_interrupt) interrupt do_IRQ /* 0(%rsp): oldrsp-ARGOFFSET */ ret_from_intr: - cli + DISABLE_INTERRUPTS(CLBR_NONE) TRACE_IRQS_OFF decl %gs:pda_irqcount leaveq @@ -552,13 +560,13 @@ retint_swapgs: /* * The iretq could re-enable interrupts: */ - cli + DISABLE_INTERRUPTS(CLBR_NONE) TRACE_IRQS_IRETQ swapgs jmp restore_args retint_restore_args: - cli + DISABLE_INTERRUPTS(CLBR_NONE) /* * The iretq could re-enable interrupts: */...

We''ve been hitting the following issue on a variety of hosts and recent Xen/dom0 version combinations. Here''s an excerpt from our latest: Xen: 4.1.4 (xenbits @ 23432) Dom0: 3.7.1-x86_64 BUG: unable to handle kernel NULL pointer dereference at 000000000000001c IP: [<ffffffff8141a301>] evtchn_from_irq+0x11/0x40 PGD 0 Oops: 0000 [#1] SMP Modules linked in: ebt_comment