From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3563 invoked by alias); 8 Dec 2014 19:03:47 -0000 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 Received: (qmail 3543 invoked by uid 89); 8 Dec 2014 19:03:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-vc0-f173.google.com Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com) (209.85.220.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 08 Dec 2014 19:03:44 +0000 Received: by mail-vc0-f173.google.com with SMTP id im17so2404389vcb.32 for ; Mon, 08 Dec 2014 11:03:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YH3a811FARAg79MmQSul/h+Voq65RSvRYfQUpjB+Nc4=; b=kubvNen+5Z+vsyS/BkIB9/ILNKV5QXXw/0EUQrcrXNBWpmmPkRgauMXCYICMKAER2N RFLN3Zq5zWaFpInLpeDWLCGhoQhqIsfbUrj3LI+63Xv3wA8qRqiVrR1Te2Symd1yFejl 2F4yS3XcrKjQNIyBIB6AG10jmvL5TCq5QbNYta4xyl0T6eM3xbo693KXBEiwQb+LeEgA DBg2iX7K0CV5sYLvrIBJKRV4cC0YtehW/HOhrnNZiHBqoprIu1xCyOYCMXWlM9IVIWN0 IB3S37Mdw3lIksefXwdBFYPcC6caToUF+opNnRoC1fTQOVuMtD/6pZQrLRyeM7dq4VL6 te4Q== X-Gm-Message-State: ALoCoQlqJFTLUGPT3cxPU8DGsciUVHLc4DGm/gLaP30JCCcVIHKLk4UAANuPcF81ECLEe7QhVW1m MIME-Version: 1.0 X-Received: by 10.220.102.20 with SMTP id e20mr26598105vco.12.1418065422287; Mon, 08 Dec 2014 11:03:42 -0800 (PST) Received: by 10.52.114.101 with HTTP; Mon, 8 Dec 2014 11:03:42 -0800 (PST) In-Reply-To: <28470.1418061861@usendtaylorx2l> References: <28470.1418061861@usendtaylorx2l> Date: Mon, 08 Dec 2014 19:03:00 -0000 Message-ID: Subject: Re: gdb -- symbols read in? or not read in? From: Doug Evans To: David Taylor Cc: gdb Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-12/txt/msg00010.txt.bz2 On Mon, Dec 8, 2014 at 10:04 AM, David Taylor wrote: > > We have recently switched from STABS to DWARF for our product. And are > having some issues with DWARF that we never had with STABS. > > The first was that with DWARF, GDB seems to not know about the existence > of most of the header files. > > Someone would want to look at something in a header file and would say > something like "list foo.h". GDB would respond that it didn't know > anything about the header. If you did "info sources", all the *.c and > assembly files would be listed, but only a small fraction of the header > files. > > I've mostly taught them to first do a list of a function in a file (or > even just the first few lines of the file) that includes the header > before trying to do something with the header. > > I've gotten push back -- people wanting us to switch back to STABS -- > but I've been able to resist it so far. > > But, now I've encountered a new problem with DWARF. I tried > > print . > > where is an instance of a struct and is a element of > that struct. > > I tried > > ptype > and > ptype > > and in both cases GDB responded with > > type = struct { > > } Ugh. Got repro? > I tried listing a function within the file that defines the global > veriable and then trying again. No improvement. > > Then I did "info sources" and was rather surprised at the output. There > were 3379 files mentioned. > > There were 680 files in the "Source files for which symbols > have been read in:" list. > > And 2699 files in the "Source files for which symbols will be read in on > demand:" list. > > All files listed were shown with full paths. But, the surprising part > was that 598 of the files listed in the first list were also listed in > the second list! > > So, were the symbols read in? Or not read in? No file should be in > both lists. Were .c/.cc files in both lists, or just headers? It would not be unexpected to find headers in both lists, but finding .c/.cc files in both lists would be a bug (assuming things like the .c not being used as a "header", and all files came from the same objfile). > > > Is this a known problem? I didn't see anything in the bug database > about it. News to me. Got repro? > > > Anyone know of any workarounds other than possibly adding -readnow to > the GDB startup command line which is unacceptable as it adds MINUTES to > the startup time (and haven't tried it so I don't know if it helps or > not). > > If variable.member does not consistently work, I might not be able to > resist the push back to switch back to STABS. > > This is with GDB 7.8 on an x86-64 GNU/Linux system. Repros for all problems found will help. We definitely want to help you get past this, stabs needs to die. (light pun on dwarf intended :-)).