From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31376 invoked by alias); 8 Dec 2014 19:47: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 31361 invoked by uid 89); 8 Dec 2014 19:47:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.0 required=5.0 tests=AWL,BAYES_00,NO_DNS_FOR_FROM,TBC,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mailuogwhop.emc.com Received: from mailuogwhop.emc.com (HELO mailuogwhop.emc.com) (168.159.213.141) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 08 Dec 2014 19:47:45 +0000 Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sB8Jlfxr010385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2014 14:47:42 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com sB8Jlfxr010385 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com sB8Jlfxr010385 Received: from mailsyshubprd07.lss.emc.com (mailhub.lss.emc.com [10.253.24.63]) by maildlpprd01.lss.emc.com (RSA Interceptor); Mon, 8 Dec 2014 14:47:13 -0500 Received: from usendtaylorx2l.lss.emc.com (usendtaylorx2l.lss.emc.com [10.243.10.188]) by mailsyshubprd07.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sB8JlIQ6007378; Mon, 8 Dec 2014 14:47:18 -0500 Received: by usendtaylorx2l.lss.emc.com (Postfix, from userid 26043) id CE5B35DC03A; Mon, 8 Dec 2014 14:47:16 -0500 (EST) Received: from usendtaylorx2l (localhost [127.0.0.1]) by usendtaylorx2l.lss.emc.com (Postfix) with ESMTP id 3ED025DAF57; Mon, 8 Dec 2014 14:47:16 -0500 (EST) To: Doug Evans cc: gdb Subject: Re: gdb -- symbols read in? or not read in? In-reply-to: References: <28470.1418061861@usendtaylorx2l> Comments: In-reply-to Doug Evans message dated "Mon, 08 Dec 2014 14:03:42 -0500." Date: Mon, 08 Dec 2014 19:47:00 -0000 Message-ID: <29511.1418068036@usendtaylorx2l> From: David Taylor X-RSA-Classifications: public X-Sentrion-Hostname: mailuogwprd02.lss.emc.com X-SW-Source: 2014-12/txt/msg00012.txt.bz2 Doug Evans wrote: > On Mon, Dec 8, 2014 at 10:04 AM, David Taylor wrote: [...] > > and in both cases GDB responded with > > > > type = struct { > > > > } > > Ugh. Got repro? While I can reproduce it at will, I do not yet have a test file that I can share. [...] > > 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). I didn't check. Checking just now I see that it is header files that are duplicated. No *.c files and no assbembly files are in both lists. Why would you expect headers to be in both lists? Of course, this might just be a weirdness unrelated to my real problem of member fields not showing up. > > Is this a known problem? I didn't see anything in the bug database > > about it. > > > News to me. Got repro? Not yet. I'll look into how hard it is to create one. Current reproduction involves way too many files. I expect that reducing it down will take some time. I was hoping that either it was reported and I missed it in my searches or that someone had seen it, but didn't report it, and knew more about it. > Repros for all problems found will help. Understood. As a developer I fully understand that it is very hard to debug problems that are not reliably reproducible. And even harder to verify the fix. > We definitely want to help you get past this, stabs needs to die. > (light pun on dwarf intended :-)). What? You mean that you want to stab STABS? ;) We record macro information in the debug information. [Aside: the GCC and GDB changes for doing this with STABS were posted *years* ago but never merged.] Until GCC 4.7.x which extended DWARF to put all the macro strings together, using DWARF caused our files to swell to 10+ times the size with STABS and was therefore a non starter for us. I'll look into reproduction with a smaller set of files. If I'm unable to it'll probably be next year before I can debug it myself (due to the company's use-it-or-lose-it vacation policy I'll be gone the last couple of weeks of this month).