From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7704 invoked by alias); 19 Jul 2006 11:33:09 -0000 Received: (qmail 7681 invoked by uid 22791); 19 Jul 2006 11:33:07 -0000 X-Spam-Check-By: sourceware.org Received: from mx.transitive.com (HELO pennyblack.transitives.com) (217.207.128.220) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 19 Jul 2006 11:33:03 +0000 Received: from internal.transitives.com ([172.16.0.1] helo=okra.transitives.com) by pennyblack.transitives.com with esmtp (Exim 4.50) id 1G3A9O-0006pB-PD for gdb@sources.redhat.com; Wed, 19 Jul 2006 12:23:36 +0100 Subject: Gcc options for improving debugging? From: Alex Bennee Reply-To: kernel-hacker@bennee.com To: gdb@sources.redhat.com Content-Type: text/plain Date: Wed, 19 Jul 2006 13:05:00 -0000 Message-Id: <1153308778.9831.49.camel@okra.transitives.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.0 Content-Transfer-Encoding: 7bit X-Spam-Score: -5.8 (-----) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-07/txt/msg00135.txt.bz2 Hi, By default we build our software with -O3 which brings in a host of optimisations which make following code in GDB a pain. Artifacts I have to deal with include: * this=Variable "this" is not available and friends * funky execution order when tracing * Compressed backtraces due to inlineing Now I have tackled this one way by introducing a -O0 variant of our build for debugging. However it's becoming more tricky to compile with low optimisation levels when we have some quite complex inline assembler that needs a certain level of optimisation to be able to derive constants from C++ functions. An alternate approach is to compile with -O3 but turn off specific optimisations which make life tricky for gdb. So far I have: * -ggdb3 (obviously) * -fno-omit-frame-pointer (seems to help with finding some variables) What else would you suggest? Would this be worth adding to section 4.1 of the manual "Compiling for debugging". -- Alex, homepage: http://www.bennee.com/~alex/ Hardware, n.: The parts of a computer system that can be kicked.