similar to: [LLVMdev] an annoying runtime bug of lldb on redhat enterprise linux 6.3 with gcc 4.8.2

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

Sorry, this is the attachment. 2014-02-19 15:08 GMT+08:00 杨勇勇 <triple.yang at gmail.com>: > Thank you. > > Here is an example and the attchment contains extra files including object > file and executable file. > I want to print for example the value of "a", but lldb command "frame > variable a" displays "0" and so does "b", and

Sergei, Thank you for your attention. My target is a custom VLIW DSP. I am not sure dependency dag is correct when it gets scheduled and packetized. Months ago, I submitted a bug at http://llvm.org/bugs/show_bug.cgi?id=17894 which explained more details. I am not sure my understanding of this bug is proper, but modified my local codes this way and it works for my target when scheduling and

2013/6/23 David Chisnall <David.Chisnall at cl.cam.ac.uk> > Hi, > > In our version of LLVM, we've added different-sized iPTR* types, so we > have an iPTR256 for our fat pointers. This causes some problems with > constraints, because the way that TableGen resolves constraints is not > expected to handle multiple pointer types. We've added a flag that can be >

Hi, In our version of LLVM, we've added different-sized iPTR* types, so we have an iPTR256 for our fat pointers. This causes some problems with constraints, because the way that TableGen resolves constraints is not expected to handle multiple pointer types. We've added a flag that can be set on a per-backend basis to turn this off. Our problem is perhaps a bit different form yours,

David, thanks for your immediate response. Since iPTR is a reserved type for tablegen internal use, can you make a further explanation? On the other hand, it can be simply treated as a register class assignment problem during register allocation. Assume both pointer and integet have a 32 bit width. backend handles it just as to i32. When it performs register allocation, it can retrieve from

llvm code generator lowers both integer and pointer types into ixx(say, i16, i32, i64, ...). This make senses for some optimizations. However, integer registers and pointer registers is expilicitly distinguished from each other for some architectures, like TriCore, Blackfin, and our lab prototype dsp, which accelerates address computation and memory access. I have already read this mail thread:

We also have this problem, and have added iPTR types to the back end. Our pointers are actually fat pointers, so this also requires tweaking some optimisations (for example, things like to turn GEPs with 64-bit offsets into pointer-sized offsets, but our pointers are larger than any integer type that we support...). Most of the changes are a bit ugly, and I'm loath to upstream them without

On Sun, Jun 23, 2013 at 04:57:44PM +0100, David Chisnall wrote: > Hi, > > In our version of LLVM, we've added different-sized iPTR* types, so we have an iPTR256 for our fat pointers. This causes some problems with constraints, because the way that TableGen resolves constraints is not expected to handle multiple pointer types. We've added a flag that can be set on a per-backend

Hi, LLVMer. I use pseudo-instructions ADJCALLSTACK(DOWN | UP) to adjust call stacks, and it works well with "-O0" option. However, ADJCALLSTACK(DOWN | UP) are removed during codegen DCE pass under "-O2". What have I ignored? Thanks. -- 杨勇勇 (Yang Yong-Yong) -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, all, When I schedule machine instructions in a VLIW way and packetize them, a problem is encountered, and I will show it use a simplified case as follows. ############ original instruction sequence ... insn1 ... jump LBB0_xx ... LBB0_xx: ... ############ expected instruction sequence after scheduling and packetizing insn1; jump LBB0_xx ... LBB0_xx: ... ############ generated instruction

Hi, I write a backend and come cross an abnormal problem. Here I give a example to describe it: /////////////////////////////////////////////////////////////////////////////////////////// // A simple C function int foo() { return 1234; } ///////////////////////////////////////////////////////////////////////////////////////// When compiling foo() into my target ISA, I would expect codes

Hi, developers, I notice following asm symbol definitions are eveluated improperly: A = 9 B = 3*A - 2 * A + 1 the value of B should be 10 instead of 8. It seems asm parser treat "B = 3*A - 2 * A + 1" as "B = 3*A - (2 * A + 1)" because the second "*" has higher precedence than "-", and evaluation just performs simple recursion within

Thank you, Clayton. This is very helpful. We use the LLDB specific GDB remote extensions, and our debugger server supports "qRegisterInfo" package. "reg 0x3c" is the frame pointer. In the example mentioned above, we have SP = FP - 40 for current call frame. And variable "a" is stored at address (FP + -24) from asm instruction [FP + -24] = R3;; Thus we can conclude

Hi, guys, I compiled a subroutine with -O2, and llvm backend produced codes like: ################################################################## LBB0_32: ... R31 = -1 R20 = R31 * R20; .... bnz R2, LBB0_34 LBB0_31: ... b LBB0_34 LBB0_33: # weird basic block? R20 = R5 LBB0_34: ....

http://llvm.org/docs/CommandGuide/FileCheck.html says FileCheck ignores white spaces/tabs by default unless you use "--strict-whitespace" option. 2013/3/15 Shawn <shaolin.xie at ia.ac.cn>: > Hi all: > I'm writing testcase for the MC layer regression in llvm, the > disassembled string is a bit complicate, for example: > "IALU.T0 (I0) = BIU0.DM ; REPEAT

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

On 2019/10/24 ??11:26, Liu, Yong wrote: > >> -----Original Message----- >> From: Jason Wang [mailto:jasowang at redhat.com] >> Sent: Tuesday, October 22, 2019 9:06 PM >> To: Liu, Yong <yong.liu at intel.com>; mst at redhat.com; Bie, Tiwei >> <tiwei.bie at intel.com> >> Cc: virtualization at lists.linux-foundation.org >> Subject: Re: [PATCH]

Hi all: I'm writing testcase for the MC layer regression in llvm, the disassembled string is a bit complicate, for example: "IALU.T0 (I0) = BIU0.DM ; REPEAT AT ( 2 ) ;;" The spaces in the disassembled string is error-prone. Is there any option to tell the FileCheck utility to ignore the spaces ? Kind Regards. Shawn.

Yes, I did an offline upgrade. 1. Stop all clients using gluster servers. 2. Stop glusterfsd and glusterd on both servers. 3. Backed up /var/lib/gluster* in all servers just to be safe. 4. Upgraded all servers from 3.6.x to 3.10.x (I did not have quotas or anything that required special steps) 5. Started gluster daemons again and confirmed everything was fine prior to letting clients connect. 5.