search for: prologue_end

Hi, I found that prologue_end markers where badly placed in my test, and applied https://reviews.llvm.org/D41762 in the hope that it would fix it (I'm on 4.0.1). However, this fix doesn't work for VLIW architectures. At this point we're iterating over bundles, not MachineInstructions, and the FrameSetup flag is...

...length: 0x00000000 Address Line Column File ISA Discriminator Flags ------------------ ------ ------ ------ --- ------------- ------------- 0x0000000000000000 12 0 1 0 0 is_stmt 0x0000000000000008 13 1 1 0 0 is_stmt prologue_end 0x0000000000000010 16 0 1 0 0 is_stmt 0x0000000000000018 17 1 1 0 0 is_stmt prologue_end 0x0000000000000020 20 0 1 0 0 is_stmt 0x0000000000000028 21 9 1 0 0 is_stmt prologue_end 0x000...

...length: 0x00000000 Address Line Column File ISA Discriminator Flags ------------------ ------ ------ ------ --- ------------- ------------- 0x0000000000000000 12 0 1 0 0 is_stmt 0x0000000000000008 13 1 1 0 0 is_stmt prologue_end 0x0000000000000010 16 0 1 0 0 is_stmt 0x0000000000000018 17 1 1 0 0 is_stmt prologue_end 0x0000000000000020 20 0 1 0 0 is_stmt 0x0000000000000028 21 9 1 0 0 is_stmt prologue_end 0x000...

...Round Table yet so here goes! Please let me know if you are interested by emailing me at: orlando.hyams at sony.com Below is a non-exhaustive list of possible topics. Feel free to include any preferences and suggestions in your response. a. Line tables: 1. Can we fix is_stmt? 2. Is prologue_end reliable? 3. General stepping behaviour/quality. b. Variable locations: 1. The state of DW_OP_entry_values in llvm. 2. The state of the instruction-referencing DBG_VALUE work. 3. The state of multi-register DWARF expressions in llvm. 4. The possibility of salvaging out-of-liv...

...he debugger do a better job of mapping the executing program to the original source, because the data it works with is more accurate/complete. * This is basically about IR/Metadata handling and representation, although it might leak into things like the “is_stmt” flag, and doing better with “prologue_end,” which are currently handled by AsmPrinter. * Better handling of induction variables, entry-values, variables with multiple locations, etc. 2. Changes to optimization passes/pipelines and codegen, to avoid borking the source-location and value/variable tracking; again this should improve...

...attributes #2 = { "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" } Yet when compiling it generates: https://gist.github.com/carlokok/7c3c98d2fd8c966671f40a5ad94f19d3 (Note how it checks fFinalizer before setting up ebp). It also has a: .loc 36 195 7 prologue_end before this happens How can I get llvm to do the frame setup before prologue init (so debuggers know what is going on)? And if not, how can a debugger know where the frame is? IR: https://gist.github.com/carlokok/2ba7da8a3f6ed9ae41e0c84d77b528d6 -- Carlo Kok RemObjects Software

...# ../lib/CodeGen/DeadMachineInstructionElim.cpp:126:0 .cfi_startproc # BB#0: # %entry #DEBUG_VALUE: xfuncx:MO <- %RDI #DEBUG_VALUE: xfuncx:TRI <- %RSI #DEBUG_VALUE: xfuncx:LivePhysRegs <- %RDX #DEBUG_VALUE: isReg:this <- %RDI .loc 2 127 18 prologue_end # ../lib/CodeGen/DeadMachineInstructionElim.cpp:127:18 movl $16777471, %eax # imm = 0x10000FF andl (%rdi), %eax .Ltmp128: #DEBUG_VALUE: isReg:this <- %RDI cmpl $16777216, %eax # imm = 0x1000000 jne .LBB4_2 # BB#1: # %if.then #DEBUG_VALUE:...

...bp, -8 movl %esp, %ebp .Ltmp6: .cfi_def_cfa_register %ebp pushl %ebx subl $20, %esp .Ltmp7: .cfi_offset %ebx, -12 calll .L0$pb .L0$pb: popl %eax .Ltmp8: addl $_GLOBAL_OFFSET_TABLE_+(.Ltmp8-.L0$pb), %eax movl 8(%ebp), %ecx leal .L.str at GOTOFF(%eax), %edx movl %ecx, -8(%ebp) .loc 1 13 2 prologue_end # a.c:13:2 .Ltmp9: movl -8(%ebp), %ecx movl %edx, (%esp) movl %ecx, 4(%esp) movl %eax, %ebx calll printf at PLT .loc 1 14 1 # a.c:14:1 movl %eax, -12(%ebp) # 4-byte Spill addl $20, %esp popl %ebx popl %ebp ret .Ltmp10: .Ltmp11: .size moo, .Ltmp11-moo .Lfunc_...

..., 4(%eax) .LBE2: .loc 1 14 0 *movl 8(%ebp), %eax* popl %ebp ret $4 clang assembly (snippet of sum function) _Z3sum2A1S_: .loc 1 8 0 pushl %edi pushl %esi leal 24(%esp), %eax leal 16(%esp), %ecx movl 12(%esp), %edx .loc 1 9 17 prologue_end movl $0, 4(%edx) movl $0, (%edx) .loc 1 10 2 movl (%ecx), %esi movl (%eax), %edi addl %edi, %esi movl %esi, (%edx) .loc 1 11 2 movl 4(%ecx), %ecx movl 4(%eax), %eax addl %eax, %ecx *movl %ecx, 4(%edx)* .loc 1...

...artproc >> # BB#0: # %entry >> #DEBUG_VALUE: xfuncx:MO <- %RDI >> #DEBUG_VALUE: xfuncx:TRI <- %RSI >> #DEBUG_VALUE: xfuncx:LivePhysRegs <- %RDX >> #DEBUG_VALUE: isReg:this <- %RDI >> .loc 2 127 18 prologue_end # >> ../lib/CodeGen/DeadMachineInstructionElim.cpp:127:18 >> movl $16777471, %eax # imm = 0x10000FF >> andl (%rdi), %eax >> .Ltmp128: >> #DEBUG_VALUE: isReg:this <- %RDI >> cmpl $16777216, %eax # imm = 0x1000000 >&...

For the given test: class A1 { int x; int y; public: A1(int a, int b) { x=a; y=b; } A1 operator+(const A1&); }; A1 A1::operator+(const A1& second) { A1 sum(0,0); sum.x = x + second.x; sum.y = y + second.y; return (sum); } int main (void) { A1 one(2,3); A1 two(4,5); return 0; } when the exectable of this code is debugged in gdb for i386, we dont get the

...t_begin: > .data > .file 1 "test.c" > .text > .global main > .type main, at function > main: # @main > Lfunc_begin0: > .loc 1 3 0 # test.c:3:0 > # BB#0: # %entry > .loc 1 2 0 prologue_end # test.c:2:0 > [SP + -4] = FP;; > [SP + -8] = J30;; > FP = SP;; > J31 = -40;; > SP = SP + J31;; > #DEBUG_VALUE: main:argc <- undef > #DEBUG_VALUE: main:argv <- undef > R2 = 0;; > R3 = 11;; > [FP + -12] = R2;; > [FP + -16] = R0;; > [FP + -20] = R1;;...

When compiling code with lld -O0 --lto-O0 --eh-frame-hdr I get strange interleaved line info all over the place: ... 0x00000000000595ac 22 11 1 0 0 is_stmt 0x00000000000595bc 25 7 1 0 0 is_stmt <<< 0x00000000000595c0 22 11 1 0 0 is_stmt 0x00000000000595c4 25 7 1 0 0 is_stmt <<< 0x00000000000595c8 26 7 1 0 0 is_stmt but the code only has 1 reference to line 25 and the

...dx, 4(%eax) .LBE2: .loc 1 14 0 movl 8(%ebp), %eax popl %ebp ret $4 clang assembly (snippet of sum function) _Z3sum2A1S_: .loc 1 8 0 pushl %edi pushl %esi leal 24(%esp), %eax leal 16(%esp), %ecx movl 12(%esp), %edx .loc 1 9 17 prologue_end movl $0, 4(%edx) movl $0, (%edx) .loc 1 10 2 movl (%ecx), %esi movl (%eax), %edi addl %edi, %esi movl %esi, (%edx) .loc 1 11 2 movl 4(%ecx), %ecx movl 4(%eax), %eax addl %eax, %ecx movl %ecx, 4(%edx) .loc 1 1...

All of this information is contained in the DWARF debug info that you must generate. Are you generating DWARF? If not, you will need to. If so, please attach an example program that contains DWARF and specify which function you are having trouble getting variable information for. Greg Clayton On Feb 18, 2014, at 12:44 AM, 杨勇勇 <triple.yang at gmail.com> wrote: > Hi, all > > I

Hi, all I ported llvm backend and lldb recently. Both tools can basically work. lldb is able to debug programs in asm style and frame unwinding is OK. But "frame variable XX" does not work because lldb is not able to determine the address of XX from debug info. Can someone give any clue? Thanks in advance. -- 杨勇勇 (Yang Yong-Yong) -------------- next part -------------- An HTML

...11, sp >>> sub sp, sp, #8 >>> str r3, [r11, #20] >>> str r2, [r11, #16] >>> str r1, [r11, #12] >>> ldr r1, [r11, #76] >>> str r1, [sp, #4] >>> .loc 1 7 0 prologue_end >>> ldr r2, .LCPI0_0 >>> cmp r2, r1 >>> beq .LBB0_2 >>> b .LBB0_1 >>> --------------------------------------------------------------- >>> >>> From reg, stack dump: >>> -------...

...16 > push {r11, lr} > mov r11, sp > sub sp, sp, #8 > str r3, [r11, #20] > str r2, [r11, #16] > str r1, [r11, #12] > ldr r1, [r11, #76] > str r1, [sp, #4] > .loc 1 7 0 prologue_end > ldr r2, .LCPI0_0 > cmp r2, r1 > beq .LBB0_2 > b .LBB0_1 > --------------------------------------------------------------- > > From reg, stack dump: > -----------------------------------------------------------------------...

...x > popl %ebp > ret $4 > > clang assembly (snippet of sum function) > _Z3sum2A1S_: > .loc 1 8 0 > pushl %edi > pushl %esi > leal 24(%esp), %eax > leal 16(%esp), %ecx > movl 12(%esp), %edx > .loc 1 9 17 prologue_end > movl $0, 4(%edx) > movl $0, (%edx) > .loc 1 10 2 > movl (%ecx), %esi > movl (%eax), %edi > addl %edi, %esi > movl %esi, (%edx) > .loc 1 11 2 > movl 4(%ecx), %ecx > movl 4(%eax), %eax > addl...

...or Release builds. I haven't made such detailed comparisons for the Debug builds yet. Here is the Release assembly at -Os: .align 2 .code 16 .thumb_func "-[LifeGrid cycleContinuously]" "-[LifeGrid cycleContinuously]": Ltmp265: Lfunc_begin24: .loc 1 380 0 .loc 1 380 1 prologue_end push {r4, r5, r6, r7, lr} add r7, sp, #12 push.w {r8, r10, r11} vpush {d8} sub sp, #4 .loc 1 382 2 Ltmp266: movw r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_7-(LPC24_0+4)) Ltmp267: mov r4, r0 Ltmp268: movt r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_7-(LPC24_0+4)) movw r0, :lower16:(L_OBJC_CLAS...