similar to: Insight/gdb users?

On Jul 17, 2008, at 7:51 PM, Richard Pennington wrote: > Hi, > > As part of my work with Elsa/LLVM I've been trying to wean myself from > gcc, I'm using my own preprocessor now (to eliminate gcc -E) and have > been calling ld and as directly. You should consider using the clang preprocessor :) > My question is: What assembler does the LLVM PIC target use? I'd

Hi, As part of my work with Elsa/LLVM I've been trying to wean myself from gcc, I'm using my own preprocessor now (to eliminate gcc -E) and have been calling ld and as directly. To do this, I've set up a version of bunutils (based on 2.18.50) and gdb/insight (based on 6.8) to handle all the LLVM targets (except PIC, see below). The nice thing about gdb 6.8 is that one binary can

Hi paulr: Thanks for your kindly response. Maybe I don't describe my question cleanly, let me show more information. From my side, I notice that whether we are in the continue keyword mode or we are in the right brace mode, the target of br instruction is the same, i.e. for loop Continue Keyword Mode: ; <label>:6: ; preds = %3 br label

I'm adding the gdb list because it appears there's currently no way to tell gdb about newly-JITted code. That is, it's not an LLVM-specific problem. There appear to be two techniques in common use to debug dynamically-generated code despite this. First, as Evan suggests below, we can have the JIT print the address range that it's written a function into, have gdb disassemble that,

Hi, I have some problem with setting breakpoints with gdb in order to debug some shared library for R. Classical use of gdb work well gcc -g -o footest.o footest.c gdb footest.o b 2 run ... but as i tried to use it with R : $ R -d gdb GNU gdb 5.2.1 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it

Hi Roland, Is Foo.cpp a Clang source file? If so, make sure you run the compiler itself with "clang -cc1", not the compiler *driver* with bare "clang". See here ( http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-March/020275.html ) for a similar question. -Matt On 04/13/2012 04:19 PM, Roland Leißa wrote: > Hi all, > > I currently have a problem setting up gdb

On Apr 13, 2012, at 2:19 PM, Roland Leißa <leissa at cs.uni-saarland.de> wrote: > Hi all, > > I currently have a problem setting up gdb with clang/llvm. > > I configured llvm/clang (trunk) with: > ../llvm/configure --prefix=PROJECT_DIR/install_debug --enable-expensive-checks --enable-targets=host --enable-debug-runtime --enable-shared > > Now, when I invoke gdb

Hi Eric, I'm using gcc. My make command is make -j9 as mentioned earlier, the -cc1 switch did the trick for me. Thanks for helping out. -- Roland ----- Original Message ----- > From: "Eric Christopher" <echristo at apple.com> > To: "Roland Leißa" <leissa at cs.uni-saarland.de> > Cc: LLVMdev at cs.uiuc.edu > Sent: Freitag, 13. April 2012 14:39:53

Hi all, I currently have a problem setting up gdb with clang/llvm. I configured llvm/clang (trunk) with: ../llvm/configure --prefix=PROJECT_DIR/install_debug --enable-expensive-checks --enable-targets=host --enable-debug-runtime --enable-shared Now, when I invoke gdb with the freshly built clang it basically works. I can look at backtraces, set breakpoints and so on but breakpoints are never

Let me show you the following simple C code: int main() { int i; for (i = 0; i < 256; i++) { i++; } } In this simple C code, if we use Clang to compile it and debug it: We will get something like this: (gdb) b main Breakpoint 1 at 0x100000f7b: file a.c, line 5. (gdb) r Starting program: a.out [New Thread 0x1403 of process 23435] warning: unhandled dyld version (15) Thread 2

Hello. Building R-patched from source on Win64 using current Rtools 3.5.0.4, I?m getting the following notes indicating an extra left brace somewhere; or is the problem on my end? My installed Perl is Strawberry 5.28.0.1-64 bit. Thank you, Avi (Sent from an iPhone, so my apologies if HTML also comes through) ------ Making HTML documentation ------ creating doc/manual/version.texi creating

Hey guys, I can't seem to figure out how to debug a COM32 app with GDB under qemu. I start "qemu -s" and then "gdb hello.elf ; target remote:1234" but can't set any breakpoints that work. I"m using syslinux4 (pathbased from the repo). Can anyone verify that they can use qemu+com32+gdb with something as simple as com32/samples/hello.c32 ? Also, is it

On Apr 20, 2009, at 5:06 PMPDT, Ken McMillan wrote: > > Well... > > $ ~/software/llvm-gcc4.2-2.5-x86-linux-RHEL4/bin/llvm-gcc -g gdb1.c - > o gdb1 > /tmp/ccbAj8x9.s: Assembler messages: > /tmp/ccbAj8x9.s:35: Error: suffix or operands invalid for `push' > /tmp/ccbAj8x9.s:44: Error: suffix or operands invalid for `pop' > /tmp/ccbAj8x9.s:56: Error: suffix or

On 06/21/2010 14:14, Reid Kleckner wrote: > Since FreeBSD is an ELF target, this should work fine. I've also > tested that this works in 32-bit by building gdb and llvm in 32-bit > mode and testing this stuff while running on a 64-bit OS. > > I would try setting a breakpoint in gdb on > 'llvm::JITDebugRegisterer::RegisterFunction' to see that it is being > called,

Hey guys, I've searched the archives but couldn't find any instructions on setting breakpoints in com32 apps. I'm trying to debug my app under Qemu. BTW, is there any limits on the amount of malloc space you can do? I'm trying to track down a reboot after a lot of mallocs. Thanks a lot.

I'm quite new to wine development but I have used winedbg and gdb a couple of times (in console). Now Im trying to setup wine as an Eclipse project and so far everything works except debugging. I am using Eclipse 3.6 on ubuntu and have set up a debug configuration where I changed the following (rest is default): - C app: loader/wine - gdb debugger: winedbg --gdb When I try launching the debug

Hi everyone. I'm trying to learn my way around the R internals. I've gone pretty much as far as I can go with the information given in Writing R Extensions and R Internals, but I still have a lot of questions, too many in fact to post them to the r-devel list. But I think I could answer many of these if I could just step through R's execution during some basic operations. What

My test environment: 1. Installed mingw/MSYS from sourceforge.net/projects/mingw using the "Automated MinGW Installer" mingw-get-inst-20110802.exe (installed everything except Fortran). 2. Installed Python 2.7 from www.python.org/download using python-2.7.2.msi 3. MSYS bash path set to /c/MinGW/bin:/bin:/c/Python27:/c/WINDOWS/ system32:/c/WINDOWS:/c/WINDOWS/system32/wbem 4. Built

Well... $ ~/software/llvm-gcc4.2-2.5-x86-linux-RHEL4/bin/llvm-gcc -g gdb1.c -o gdb1 /tmp/ccbAj8x9.s: Assembler messages: /tmp/ccbAj8x9.s:35: Error: suffix or operands invalid for `push' /tmp/ccbAj8x9.s:44: Error: suffix or operands invalid for `pop' /tmp/ccbAj8x9.s:56: Error: suffix or operands invalid for `push' /tmp/ccbAj8x9.s:65: Error: suffix or operands invalid for `pop'

I have implemented this exact behavior in an out of tree LLVM fork I maintain, where one of my users needed this behavior, and it seems to work well. What we have done is extend the definition of DISubprogram to contain a new field "endLine" which holds the line number of the closing brace. A pass late in our backend uses this information to set the DebugLoc of return instructions in our