From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32716 invoked by alias); 3 Nov 2009 17:38:18 -0000 Received: (qmail 32707 invoked by uid 22791); 3 Nov 2009 17:38:18 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 Nov 2009 17:38:13 +0000 Received: from spaceape24.eur.corp.google.com (spaceape24.eur.corp.google.com [172.28.16.76]) by smtp-out.google.com with ESMTP id nA3HcBs2022230 for ; Tue, 3 Nov 2009 17:38:11 GMT Received: from pzk37 (pzk37.prod.google.com [10.243.19.165]) by spaceape24.eur.corp.google.com with ESMTP id nA3Hc0p2018352 for ; Tue, 3 Nov 2009 09:38:09 -0800 Received: by pzk37 with SMTP id 37so4124620pzk.10 for ; Tue, 03 Nov 2009 09:38:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.237.31 with SMTP id k31mr265688wah.183.1257269888132; Tue, 03 Nov 2009 09:38:08 -0800 (PST) In-Reply-To: References: <4AEF6834.1080208@caviumnetworks.com> Date: Tue, 03 Nov 2009 17:38:00 -0000 Message-ID: <8ac60eac0911030938y2fba14a3na8446d61c7d497f5@mail.gmail.com> Subject: Re: GDB interactions with GCC From: Paul Pluzhnikov To: Jean Christophe Beyler Cc: David Daney , gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-11/txt/msg00025.txt.bz2 On Tue, Nov 3, 2009 at 9:22 AM, Jean Christophe Beyler wrote: > If so, doesn't that mean that if we want GDB on an architecture that > does not require any stack copies, we still have to generate those > uselessly (except for GDB ;-)) ? You appear to be under mistaken assumption that GDB can only access stack in the inferior process. GDB can access *any* memory in the inferior, as well as registers. DWARF debug info (which GCC generates) tells GDB where to find any variable. The location (described by DWARF) could be "in register", "in memory at address NNNN", or a complicated expression involving possibly multiple registers, offsets and memory. DWARF also describes how the register set changes when you step to previous frame, so once you get to (say) frame #5, GDB knows the values registers had in that frame, and can again (using DWARF debug info) tell you values of parameters, locals, etc. I think you should give http://dwarfstd.org/Dwarf3Std.php (and in particular 2.6: Location Descriptions) at least a quick read. Cheers, -- Paul Pluzhnikov