similar to: [LLVMdev] Debugging with llvm-gcc/mingw doesn't seem to work

Hello, Argiris > Can you please try out the steps I mentioned before with the linux > binaries ? I just want to make sure that there's not something wrong > with my setup. Here they are: $ cat dbg.c int main() { return 0; } $ gdb a.out GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later

Hello, Argiris > Any ideas? 1. Make sure, that you don't mix dwarf and stabs debug information. AFAIR, this can really mess the things 2. It can be, that debug information emitted is not correct. This is known open problem. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Hi, Here are the steps to reproduce the debugging issue: -create test.c: int main() { return 0; } -llvm-gcc -g test.c -o test.exe -gdb test.exe -(gdb) break test.c:3 >> No line 3 in file "test.c". This is with the llvm-2.3-x86-mingw32 binaries and gdb-6.8-mingw-3. Any ideas? -Argiris

I see. Here's another interesting issue: (gdb) b gdb1.c:4 No line 4 in file "gdb1.c". (gdb) step foo () at /home/mcmillan/projects/impact2/test//gdb1.c:4 4 x++; (gdb) You can see that I can step to line 4, but I can't set a breakpoint there. (I used -disable-fp-elim in the compilation). Have you seen this before? Thanks -- Ken Dale Johannesen wrote: > > > On

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'

Ken McMillan wrote: > I see. Here's another interesting issue: > > (gdb) b gdb1.c:4 > No line 4 in file "gdb1.c". > (gdb) step > foo () at /home/mcmillan/projects/impact2/test//gdb1.c:4 > 4 x++; > (gdb) > > You can see that I can step to line 4, but I can't set a breakpoint there. > Works fine here (llvm 2.5, 32 bit, gdb 6.8) Try llc

Fair enough, you win this round. ;P (Which actually makes me happy as that makes things a lot more consistent and sensible.) -J -------------------------------------------------- From: "Argiris Kirtzidis" <akyrtzi at gmail.com> Sent: Thursday, October 02, 2008 12:32 PM To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Subject: Re: [LLVMdev] MS C++ gives

Argiris Kirtzidis wrote: > > ... > > Try > llc -disable-fp-elim gdb1.bc > > Thanks, I would never have guessed that :-). Are there any other optimizations that are harmful to debug info that I should know about? Thanks -- Ken -- View this message in context: http://www.nabble.com/problems-with-dwarf-gdb-tp23033690p23049871.html Sent from the LLVM - Dev mailing list

Those rules only apply to if and switch statements. (Yes, this is insane, but true.) The entire section you are quoting from, 6.4, is titled "Selection statements [stmt.select]", which specifically covers these two cases. A for is an iteration statement, not a selection statement. So, if you read 6.5.3p1 (which is actually about for statements) it states that a for loop is rewritten

On Apr 14, 2009, at 4:19 PMPDT, Ken McMillan wrote: > > > > Argiris Kirtzidis wrote: >> >> ... >> >> Try >> llc -disable-fp-elim gdb1.bc >> >> > > Thanks, I would never have guessed that :-). > > Are there any other optimizations that are harmful to > debug info that I should know about? Lots of them. Partly this is because

Jay Freeman (saurik) wrote: > Those rules only apply to if and switch statements. (Yes, this is insane, > but true.) The entire section you are quoting from, 6.4, is titled > "Selection statements [stmt.select]", which specifically covers these two > cases. A for is an iteration statement, not a selection statement. > See 6.4p2: "The rules for conditions apply

Jay Freeman (saurik) wrote: > gcc is correct. According to the ISO specification, the for-init-statement > is supposed to inject any variable names into the same declarative scope as > the condition of an equivalent restructuring of the loop in the form of a > while statement, which in turn fronts the declaration to an extra scope that > surrounds the /entire/ loop construct.

Hi Argiris, It was for example the project TableGen, llvm-dis... I saw it under Properties/Linker/Command Line And the output is also: Linking... Starting pass 1 LINK : fatal error LNK1181: cannot open input file '..\configure\configure\configure.lib' Build log was saved at "file://d:\Studium\Diplom\Download\llvm-2.3\win32\TableGen\Win32\Release\Bui ldLog.htm" TableGen - 1

Óscar Fuentes wrote: > Argiris Kirtzidis <akyrtzi at gmail.com> writes: > > >> I gave it a try and unfortunately it doesn't seem practical to use >> CMake-produced VC++ projects. Every time you run CMake so that the VC++ >> projects include new files, the entire solution gets rebuilt. >> > > I recall some discussion about the behavior you

Óscar Fuentes wrote: > Argiris Kirtzidis <akyrtzi at gmail.com> writes: > > >> How does updating the CMake produced VC++ project files work ? >> I mean: >> >> -I have CMake produce VC++ project files >> -Compile the solution >> -Do a svn update and pick up a couple of files >> -Have CMake produce new project files >> -Now, do I have

I'm having trouble debugging x86 code generated by LLVM. GDB does work with the code, but not correctly, for example, the "next" command does not skip over a function call. Here's an example. Source program gdb1.c: int x; void foo(){ x++; } void bar(){ x--; } int main(){ foo(); bar(); return 0; } commands: $ llvm-gcc -g -emit-llvm -c gdb1.c -o gdb1.bc $ llc

Argiris Kirtzidis <akyrtzi at gmail.com> writes: > I gave it a try and unfortunately it doesn't seem practical to use > CMake-produced VC++ projects. Every time you run CMake so that the VC++ > projects include new files, the entire solution gets rebuilt. I recall some discussion about the behavior you describe on the cmake ml, but can't find it right now. IIRC, once

Le Anh Quang wrote: > Hi, > but on some other project, they require "configure.lib". What is this one ? > Thanks Hi Le Anh, What project are you talking about, and how did you determine that it requires "configure.lib" ? AFAIK, all LLVM projects have dependency on the configure project but this is only so that some include files are created, no

If I use the jump threading pass on the attached IR: $ opt before.ll -jump-threading -o - | llvm-dis -o after.ll a big chunk gets removed, a chunk that is actually necessary. ('before.ll' passes the test in webkit, while 'after.ll' fails) Can someone take a look ? -Argiris -------------- next part -------------- A non-text attachment was scrubbed... Name: before.ll Type:

Argiris Kirtzidis <akyrtzi at gmail.com> writes: > How does updating the CMake produced VC++ project files work ? > I mean: > > -I have CMake produce VC++ project files > -Compile the solution > -Do a svn update and pick up a couple of files > -Have CMake produce new project files > -Now, do I have to rebuild the entire solution again ? AFAIK, it should do the right