From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24490 invoked by alias); 8 Dec 2014 18:04:40 -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 24475 invoked by uid 89); 8 Dec 2014 18:04:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,NO_DNS_FOR_FROM,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mailuogwdur.emc.com Received: from mailuogwdur.emc.com (HELO mailuogwdur.emc.com) (128.221.224.79) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 08 Dec 2014 18:04:38 +0000 Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sB8I4ZVe019480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 8 Dec 2014 13:04:36 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com sB8I4ZVe019480 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com sB8I4ZVe019480 Received: from mailsyshubprd08.lss.emc.com (mailhub.lss.emc.com [10.253.24.64]) by maildlpprd56.lss.emc.com (RSA Interceptor) for ; Mon, 8 Dec 2014 13:03:38 -0500 Received: from usendtaylorx2l.lss.emc.com (usendtaylorx2l.lss.emc.com [10.243.10.188]) by mailsyshubprd08.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sB8I4N6f003404 for ; Mon, 8 Dec 2014 13:04:24 -0500 Received: by usendtaylorx2l.lss.emc.com (Postfix, from userid 26043) id 8E2AA5DC051; Mon, 8 Dec 2014 13:04:21 -0500 (EST) Received: from usendtaylorx2l (localhost [127.0.0.1]) by usendtaylorx2l.lss.emc.com (Postfix) with ESMTP id 000795DAF57 for ; Mon, 8 Dec 2014 13:04:21 -0500 (EST) From: David Taylor To: gdb@sourceware.org Subject: gdb -- symbols read in? or not read in? Date: Mon, 08 Dec 2014 18:04:00 -0000 Message-ID: <28470.1418061861@usendtaylorx2l> X-RSA-Classifications: DLM_1, public X-Sentrion-Hostname: mailuogwprd52.lss.emc.com X-IsSubscribed: yes X-SW-Source: 2014-12/txt/msg00009.txt.bz2 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 { } 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. Is this a known problem? I didn't see anything in the bug database about it. 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.