From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9572 invoked by alias); 3 Nov 2009 17:55:02 -0000 Received: (qmail 9526 invoked by uid 22791); 3 Nov 2009 17:55:01 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-vw0-f182.google.com (HELO mail-vw0-f182.google.com) (209.85.212.182) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 Nov 2009 17:54:56 +0000 Received: by vws12 with SMTP id 12so1830412vws.12 for ; Tue, 03 Nov 2009 09:54:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.124.226 with SMTP id v34mr403278vcr.8.1257270894840; Tue, 03 Nov 2009 09:54:54 -0800 (PST) In-Reply-To: <8ac60eac0911030938y2fba14a3na8446d61c7d497f5@mail.gmail.com> References: <4AEF6834.1080208@caviumnetworks.com> <8ac60eac0911030938y2fba14a3na8446d61c7d497f5@mail.gmail.com> Date: Tue, 03 Nov 2009 17:55:00 -0000 Message-ID: Subject: Re: GDB interactions with GCC From: Jean Christophe Beyler To: Paul Pluzhnikov Cc: David Daney , gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 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/msg00026.txt.bz2 On Tue, Nov 3, 2009 at 12:38 PM, Paul Pluzhnikov wrote: > 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. Yes that I was aware of. > 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. Also, I know that, though I don't yet know how much GCC generates automatically and how much work I must do in my port (but that's a GCC issue). > 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. My issue is this : > so once you get to (say) frame #5, GDB knows the values registers had in that frame How does it know if for example I do : int foo (int a) { return bar (a + 1); } On my architecture, I can have the code for foo reduced to : add FirstInputRegister, FirstInputRegister, 1 call bar branch return. Therefore, once I'm in bar, the input register that foo had has been lost since it's been incremented. The original value of a has been lost since it is not in a particular register, was not spilled. In this case, how does GDB handle it ? Is it still something that is generated by DWARF ? Or is it now lost and if I want to support this for my architecture, I must update the ABI to at least spill that input register? > I think you should give http://dwarfstd.org/Dwarf3Std.php (and in particular > 2.6: Location Descriptions) at least a quick read. I was reading this version http://www.eagercon.com/dwarf/dwarf-2.0.0.pdf since I saw in GCC the support of DWARF 2 :-). I'll read the section you speak of. Thanks for your help, Jc