From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23684 invoked by alias); 17 May 2012 20:38:46 -0000 Received: (qmail 23674 invoked by uid 22791); 17 May 2012 20:38:45 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 17 May 2012 20:38:27 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q4HKcQlv017168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 May 2012 16:38:26 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q4HKcOBr007278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 17 May 2012 16:38:25 -0400 From: Tom Tromey To: chansarav Cc: gdb@sourceware.org Subject: Re: problem while probing the local variables References: Date: Thu, 17 May 2012 20:38:00 -0000 In-Reply-To: (chansarav@gmail.com's message of "Thu, 17 May 2012 14:11:40 +0530") Message-ID: <87r4uik0fz.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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: 2012-05/txt/msg00080.txt.bz2 >>>>> ">" == chansarav writes: >> 1. Currently the compiler tool chain generates the ELF files only with >> allocable sections (data and code). The non-allocable sections are not >> included in the ELF file generated. Hence the symbol table information >> is missing. Will this hinder the debugging by gdb? I don't really know the answer to this one, sorry. I suspect it will hurt. >> 2. On debugging for the message "Symbol i is Unexpected opcode after >> DW_OP_breg0 for symbol "i".", I found that in function >> locexpr_describe_location_piece () of dwarf2loc.c, the frame_offset >> for symbol 'i' is being read correctly. But problem comes out in the >> following piece of code: >> From this I get the understanding of that there could be problem with >> the dwarf information generated. I should check the dwarf information >> generated regarding this issue. Is my understanding correct? Yes, check the DWARF. >> 3. On debugging for the message "No symbol "result" in current >> context.", I found that in function parse_exp_in_context () of file >> parse.c the exception is thrown by 'lang->la_parser ()'. I couldn't >> understand what goes wrong here. Could anyone direct me on this? This is a complicated area. I would say that for a missing symbol your best bet is to start by debugging the DWARF reading. This is most likely where things go wrong. But, there are many possible ways it could fail. For example, I've been debugging problems like this recently, where the problem was that gdb ended up choosing the wrong block to search. Tom