From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14370 invoked by alias); 17 Sep 2008 06:34:19 -0000 Received: (qmail 14362 invoked by uid 22791); 17 Sep 2008 06:34:18 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 17 Sep 2008 06:33:44 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id m8H6WpiL006570; Wed, 17 Sep 2008 02:33:12 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m8H6WesC009635; Wed, 17 Sep 2008 02:32:40 -0400 Received: from lindt.uglyboxes.com (sebastian-int.corp.redhat.com [172.16.52.221]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id m8H6WYXi000593; Wed, 17 Sep 2008 02:32:38 -0400 Message-ID: <48D0A482.8060000@redhat.com> Date: Thu, 18 Sep 2008 21:19:00 -0000 From: Keith Seitz User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: John Fine CC: insight@sourceware.org Subject: Re: Can't debug x86_64 C++ programs. References: <48D024D1.3000107@verizon.net> In-Reply-To: <48D024D1.3000107@verizon.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact insight-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: insight-owner@sourceware.org X-SW-Source: 2008-q3/txt/msg00062.txt.bz2 John Fine wrote: > When I try to use it, Insight has so many bugs, I couldn't begin to list > them here and other bugs interfere with any attempt to understand or > work around any specific bug. Unfortunately, insight is quickly approaching EOL. I have been about the only person to keep it hobbling along for quite some years, and I am just about ready to spend my copious free time on some other project. As you've discovered, there are a ton of problems. Unfortunately, it takes an experienced eye to recognize the difference between a problem with the GUI and gdb. Gdb is pretty much the worst debugger on the planet when it comes to C++. Sad but true. Red Hat and other companies (and interested parties) are attempting to make gdb a better C++ debugger. You might want to keep an eye on the archer project at sourceware.org. It's probably quite a while out, though, before anything substantially useable is ready. > If there is any chance of getting any support, I'd be glad to do > specific tests or give much more detail of the failures. Isolated test cases are very useful. I don't often use x86_64, but I do now have access to such a box. For right now, all my comments below apply to running insight on x86. I will try to verify all of your issues on x86_64 by the end of the week. > If you know of a GUI debugger that works, please tell me. You might try the CDT project in Eclipse or even some of the debuggers mentioned off of the insight homepage hosted on sourceware.org. I have no experience with those unfortunately, and they are all based on gdb, so it is unlikely that C++ debugging is going to be any better than what you are experiencing now. > The step over buttons (both "Next" and "Next Asm") usually do a step > into. They sometimes step over, so they must be connected to the right > thing, but usually they step into. That is very odd. I certainly have never experienced this, and I have actually been using insight almost daily now for several weeks. Can you give me a test case? By the way, what version of insight are you attempting to use? [insight -v or "show version" in a console window] What compiler? > The Finish button usually does nothing, sometimes does the step out of > operation that I want and sometimes causes the program being debugged to > seg fault. If I restart the program and set a breakpoint where a > correct step out of would reach and get into the same place as before > and just continue, the breakpoint will be hit, but even with the > breakpoint there a Finish will make the program seg fault. I am sorry, but I also have not encountered these problems, and believe me when I say I've been using "finish" a awful lot of late, debugging gdb's symbol code with C++. Can you provide me with a test case? > If I try to view the registers window anytime after pressing Run, the > whole debugger crashes. If I view the register window first, it > appears, then when I press run it populates, then a moment later the > whole debugger crashes. Once again, I am sorry, but I cannot reproduce this (on x86). > I normally want to work in SRC+ASM mode. The compiler has often put asm > instructions in a strange order relative to source lines and I'm used to > that and (in Windows debuggers) know how to work around it with the dual > view. Insight keeps changing its mind about which view is on top (opens > with source on top, then changes back and forth for reasons I can't > begin to guess). That is very distracting. Holy moly! Do they really do that? I admit that I seldom use SRC+ASM, but the way that code is arranged in insight, I would have thought that it was impossible for the SRC and ASM panes to swap back and forth. I would definitely like to see a test case for this. > If I set a breakpoint on a source line, it shows on an asm line that is > probably a plausible choice given the debug info the compiler generated > (but often isn't a usable choice for actual debugging). If I set a > breakpoint on an asm line, it only sometimes gets marked on the correct > source line. But I've used objdump to verify that the debug info > generated by the compiler is correct enough that the asm line in > question can be traced to the correct source line. When it goes to a > wrong source line, I'm pretty sure that wrong line is in a totally wrong > file, not just the wrong line of the current file. Insight does not do anything with breakpoints other than display them. This is almost certainly a gdb problem. Nonetheless, given that I've been working on gdb and C++, I would appreciate it if you could send me a test case for this so that I can integrate it into the test suite. > I expect someone will tell me I should have completely unoptimized code > when debugging. That usually isn't practical. I know how to deal with > all the strange sequence and inlining effects using dual view in a > working GUI debugger. The failures I've described above happen even in > functions where the optimization did nothing strange. It is not possible for me to say whether anything is misbehaving. If you are correct, it certainly sounds like there is a problem with gdb/insight. Optimization is a strange beast, but it sounds like you already are well-aware of the pitfalls of debugging optimized code. Once again, I must apologize and ask for a test case. I simply have not seen the issues you are reporting _on x86_. I will attempt to double-check your findings against x86_64 this week, but if you have test cases for any of these, it would certainly make things a whole lot easier. Keith