similar to: [LLVMdev] How to get an LLVM-compiled executable which could be debugged using gdb

I am sorry for my poor statement of my problem. Yes, ��f�� is right. I want to know whether llvm could emit debugging information which GDB could use directly. Ex, how does the executable file generated from llc could be debug using gdb? A simple demonstration is greatly appreciated. 2011/6/14 ��f�� <chenwj at iis.sinica.edu.tw> > > Debug information can be placed in the assembler

Hi, On Tue, Jun 14, 2011 at 10:55 AM, Qingan Li wrote: > Hi, ... > Since the information from LLVM into gnu as and gnu ld is limited by the > assemble file, I am confusing with how to transfer the debug information to > gnu as and gnu ld. > Could any one help me? Debug information can be placed in the assembler source. This is what GCC does; you can see for yourself if you run

> Debug information can be placed in the assembler source. This is what > GCC does; you can see for yourself if you run > gcc -g -save-temps filename.c I guess he want to ask if llc can emit debugging information which GDB can use. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667

---------- Forwarded message ---------- From: Qingan Li <ww345ww at gmail.com> Date: 2011/5/30 Subject: To: llvmdev at cs.uiuc.edu Hi, I wrote an analysis pass, myPass, inherited from both ModulePass and ProfileInfo, and this pass requires the CallGraph, i.e., * class myPass : public ModulePass, public ProfileInfo { ...};* * void myPass::getAnalysisUsage(AnalysisUsage &AU) const

Hal's advice helps me a lot to understand the implementation much better. Thanks so much! So, now I am able to state my problem more clearly: 1) There are two kinds of locals, i.e., the local variables originated from the source code (like C/C++), and the compilation generated temporaries. After instruction selection phase, the former is seen as frame indexes, while the latter is seen as

On Sat, Oct 22, 2011 at 12:24 AM, James Molloy wrote: > Hi Paul, > > That should be easy enough, because the LLVM build has no warnings in it! > > Some of us build with -Werror, and even with those of us that don't warnings are not tolerated. You're already seeing all the warnings that are coming out of the build :) So, all the "variable might be used

Good evening, Csaba! I think rather, Cygwin does not need to know what PATHEXT would be. A patch(0001) is attached. Another patch is for unittests. Lit does not find *Tests.exe in unittests on ToT. 2010/12/24 Csaba Raduly <rcsaba at gmail.com>: > P.S. > With the above change, "make check-all" starts to run. Estimated run > time: 40 hours on my 1.8GHz single-core

Hi, For a couple of days now, one of the tests fails: FAIL: LLVM :: MC/R600/sopp.s (16225 of 19902) ******************** TEST 'LLVM :: MC/R600/sopp.s' FAILED ******************** Script: -- /home/csabaraduly/workspace/LLVM/build/Release+Asserts/bin/llvm-mc -arch=r600 -mcpu=SI -show-encoding /home/csabaraduly/workspace/LLVM/llvm/test/MC/R600/sopp.s |

Hi all, LLVM+clang builds fine under Cygwin 1.7, but "make check-all" fails to run because lit doesn't find the freshly built clang. The reason is as follows: in llvm/utils/lit/lit/Util.py, in the "which" method, there's 66: # Get suffixes to search. 67: pathext = os.environ.get('PATHEXT', '').split(os.pathsep) The problem is, PATHEXT is imported

When I searched for branch frequency profiling on the internet, I got this link by a casual chance: http://homepages.dcc.ufmg.br/~rimsa/tools/stprof-llvm.patch. It seems it was written by Andrei Rimsa. So I downloaded and integrate these files into the llvm-2.8 building. After the building, I tried "opt -static-profile bitcnt_1.bc", and an segment fault error occured. I debugged it

I compiled a program and standard library using clang/LLVM and found the results interesting: text data bss dec hex filename 141312 4076 16668 162056 27908 bzip2.arm 131764 4076 16668 152508 253bc bzip2.armv7 134748 4048 16624 155420 25f1c bzip2.i386 259112 4028 16732 279872 44540 bzip2.microblaze 168044 4040 16816 188900 2e1e4

> So... Are 40 and 41 the only legal behaviors or are there more? Since the program invokes undefined behavior, anything goes. The compiler is perfectly within its rights to send a rude email to your department chair if you compile that code. John

lit.py: ~/workspace/LLVM/llvm/tools/clang/test/lit.cfg:200: note: using clang: '~/workspace/LLVM/ninjacmake/./bin/clang' -- Testing: 37268 tests, 8 threads -- Testing: 0 .. FAIL: Builtins-i386-linux :: divsc3_test.c (4326 of 37268) ******************** TEST 'Builtins-i386-linux :: divsc3_test.c' FAILED ******************** Script: -- ~/workspace/LLVM/ninjacmake/./bin/clang

Yes, ARM normally runs as a little-endian and it is a 32-bit CPU. It CAN be configured to be a big-endian system, but that requires hardware support as far as I know. I do have an old, slow Mac Mini G4 PowerPC (big-endian) that I could hook up as a builder too. I was thinking of it the moment you mentioned big endian. I actually bought it for testing C++ code on because big-endian machines are

The latest in my problems building clang-only: llvm[4]: Linking Debug+Asserts executable clang /llvm/build/Debug+Asserts/lib/libclangLex.a: could not read symbols: File format not recognized collect2: ld returned 1 exit status Any suggestions appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL:

I installed LLVM3.7.0 according to the LLVM document. I can use "clang","LLVM-dis"commands ,and so on. but when I execute commad "make" at llvm/lib/Transform/Hello directory, the error is : ../../../Makefile.common:60:../../../Makefile.config:don't have that file or directory ../../../Makefile.common:68:../../../Makefile.rules:don't have that file or

Hi, Two days ago, the test suite started failing. Initially there were hundreds of failing tests; now only seven remain. They appear to be related to SystemZ. Here's the last failed test: ******************** FAIL: LLVM :: MC/Disassembler/SystemZ/unmapped.txt (11484 of 14435) ******************** TEST 'LLVM :: MC/Disassembler/SystemZ/unmapped.txt' FAILED ******************** Script:

On Wed, Feb 9, 2011 at 9:40 AM, NAKAMURA Takumi <geek4civic at gmail.com>wrote: > Anand, > > > I have not tried building llvm-gcc, though, ... > > Please show me "/path/to/config.status --version". > [Anand] Here is the config.status output taken from '/cygdrive/c/llvm-2.8': ./config.status --version llvm config.status 2.8 configured by

On Thursday, December 08, 2011 02:46:39 AM Csaba Raduly wrote: > On Wed, Dec 7, 2011 at 9:43 PM, Richard Pennington wrote: > > I compiled a program and standard library using clang/LLVM and found the > > results interesting: > > > > text data bss dec hex filename > > 141312 4076 16668 162056 27908 bzip2.arm > > 131764 4076

Hi, Can anyone help me with the stack slot coloring optimization? This corresponding file is /lib/codegen/stackslotcoloring.cpp. It is said this optimization was for stack slot overlay for frame size reduction, after register allocation phase. And this transformation pass relies on the LiveStack analysis pass. How, when checking the source code, it seems the LiveStack analysis has not been