From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20792 invoked by alias); 20 May 2012 12:34:46 -0000 Received: (qmail 20452 invoked by uid 22791); 20 May 2012 12:34:45 -0000 X-SWARE-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 20 May 2012 12:34:25 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SW5L2-0008Q1-QY for gdb-patches@sources.redhat.com; Sun, 20 May 2012 14:34:20 +0200 Received: from ppp121-45-145-2.lns10.adl6.internode.on.net ([121.45.145.2]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 20 May 2012 14:34:20 +0200 Received: from toojays by ppp121-45-145-2.lns10.adl6.internode.on.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 20 May 2012 14:34:20 +0200 To: gdb-patches@sources.redhat.com From: John Steele Scott Subject: Re: [patch] PR symtab/13277: Resolving opaque structures in ICC generated binaries. Date: Sun, 20 May 2012 12:34:00 -0000 Message-ID: <4FB8E4BD.6000501@toojays.net> References: <4E9A6F3C.6010400@toojays.net> <20111019084011.GA9326@host1.jankratochvil.net> <4EA3E995.8040206@toojays.net> <20111026221057.GA24628@host1.jankratochvil.net> <4EBFB451.8030503@toojays.net> <4FA4912E.9050709@toojays.net> <20120512183722.GA20606@host2.jankratochvil.net> <4FB10DD8.7040501@toojays.net> <20120518144642.GA19690@host2.jankratochvil.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Tom Tromey User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 In-Reply-To: <20120518144642.GA19690@host2.jankratochvil.net> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-05/txt/msg00736.txt.bz2 Jan, Thank you for continuing to work with me on this. On 19/05/12 00:16, Jan Kratochvil wrote: > Hi John, > > On Mon, 14 May 2012 15:51:20 +0200, John Steele Scott wrote: >> Are the existing tests already known to work with ICC? > I do not remember trying it. I assume many tests will FAIL. But we do not > want to diff gcc results vs. icc results but only icc results before the patch > vs. icc results after the patch. I bit the bullet and installed icc on my local machine. It's quite painful due to (I think) a round-trip to the licensing server for each compilation unit. Anyway, I was able to run the testsuite. I run "make check" with RUNTESTFLAGS="CC_FOR_TARGET=icc CFLAGS_FOR_TARGET='-debug extended' CXX_FOR_TARGET=icpc CXXFLAGS_FOR_TARGET='-debug extended'". I saw later your wiki page at http://sourceware.org/gdb/wiki/Running%20the%20test%20suite%20with%20a%20non-GCC%20compiler. It seems icc does now understand --print-multi-lib. > With my icc test there is difference between the types for v and w: > struct s; > extern struct s v; > struct w {} w; > > DW_AT_producer : Intel(R) C Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 12.1.4.319 Build 20120410 Fixes SameLinkageName MemberPointers > > <1>: Abbrev Number: 4 (DW_TAG_variable) > DW_AT_name : v > DW_AT_type : <0xfa> > [shortened] > <1>: Abbrev Number: 5 (DW_TAG_structure_type) > DW_AT_decl_line : 1 > DW_AT_decl_column : 8 > DW_AT_decl_file : 1 > DW_AT_accessibility: 1 (public) > DW_AT_byte_size : 0 > <100> DW_AT_name : s > <1><102>: Abbrev Number: 6 (DW_TAG_variable) > <107> DW_AT_name : w > <109> DW_AT_type : <0x118> > [shortened] > <1><118>: Abbrev Number: 5 (DW_TAG_structure_type) > <119> DW_AT_decl_line : 4 > <11a> DW_AT_decl_column : 8 > <11b> DW_AT_decl_file : 1 > <11c> DW_AT_accessibility: 1 (public) > <11d> DW_AT_byte_size : 0 > <11e> DW_AT_name : w > > This means icc does must not use TYPE_STUB_SUPPORTED. Just one needs to fix > producer_is_icc so that it gets processed only once and cached via > 'checked_producer' as otherwise it may needlessly slow down reading DWARF. If I understand you correctly, the problem with my previous approach is that it essentially ignores empty structs. And indeed now that I run the testsuite with ICC, it shows failures in gdb.base/nofield.exp. The approach you suggested passes that test. However, this brings us back to the problem I wrote about last October (see http://article.gmane.org/gmane.comp.gdb.patches/69651): the zero-size structures are cluttering up the psymbols and basic_lookup_transparent_type will only do one psymbol->symbol expansion per call. For a frequently referenced opaque type in a non-trivial program, initially "ptype" will show it as "no data fields". But if I repeatedly invoke ptype, eventually it resolves the type correctly. Of course this does not happen with my trivial testcase, and I'm unsure how I would expand that to expose this issue. Can you suggest a way to fix this, without ignoring zero-size structs? If I have to chose between showing empty structs, and correctly resolving non-empty structs, I would prefer to resolve the non-empty ones, they are much more interesting. :) On the question of caching the producer info in the dwarf2_cu; I propose to extract out the second half of producer_is_gxx_lt_4_6 into a new check_producer function which will set cu->producer_is_gxx_lt_4_6 and cu->producer_is_icc as appropriate (and then set cu->checked_producer). producer_is_gxx_lt_4_6 and producer_is_icc will call check_producer if cu->checked_producer is not set. Sound okay? Thanks, John