From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23886 invoked by alias); 4 Jan 2015 08:54:37 -0000 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 Received: (qmail 23866 invoked by uid 89); 4 Jan 2015 08:54:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f53.google.com Received: from mail-pa0-f53.google.com (HELO mail-pa0-f53.google.com) (209.85.220.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sun, 04 Jan 2015 08:54:33 +0000 Received: by mail-pa0-f53.google.com with SMTP id kq14so26706013pab.40 for ; Sun, 04 Jan 2015 00:54:31 -0800 (PST) X-Received: by 10.70.43.209 with SMTP id y17mr135140122pdl.2.1420361671517; Sun, 04 Jan 2015 00:54:31 -0800 (PST) Received: from sspiff.org (173-13-178-53-sfba.hfc.comcastbusiness.net. [173.13.178.53]) by mx.google.com with ESMTPSA id hx9sm51513187pad.38.2015.01.04.00.54.29 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Jan 2015 00:54:30 -0800 (PST) Received: by sspiff.org (sSMTP sendmail emulation); Sun, 04 Jan 2015 00:53:40 -0800 From: Doug Evans To: gdb-patches@sourceware.org Subject: [RFC] Empty result of "info types inner": Is this a bug? Date: Sun, 04 Jan 2015 08:54:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg00032.txt.bz2 Hi. Consider this example (source appended at the end). bash$ gdb info-types (gdb) info types inner All types matching regular expression "inner": (gdb) start ... (gdb) step ... (gdb) info types inner All types matching regular expression "inner": File info-types-2.cc: c::inner; (gdb) Technically, it's a bug that the first "info types inner" didn't print anything, but is this a bug we're willing to accept for performance reasons? I want to make the case that the answer is "No." "info types" shouldn't have a different answer depending on what symtabs have been expanded. However, it currently does because of the shortcut we take building the partial symtab: When reading classes we don't traverse into inner classes (as well as taking other shortcuts). [That and the fact that we don't make up for these shortcuts in search_symbols() - kinda hard without expanding every symtab or adding more specialized debug info reading code.] We take shortcuts when building partial syms in order to speed up startup. However, it would be nice to collect some new data on what we're saving relative to what we're spending. If it's not much, it'd be worth it IMO to spend it given the simplification it would allow. I'm not suggesting we couldn't build psymtabs even faster, e.g., being even lazier than what we are now. But (depending on what we're being lazy with) this increases the complexity of symbol lookup, and we have .gdb_index now: if we slow down building psymtabs by 10% (I just picked that number out of the air, as I say I need to collect some data) we don't slow down startup with .gdb_index at all. We have an index we generate to make gdb faster, here's another way it can help: put every symbol from GLOBAL/STATIC_BLOCKs in it. [We still have to support older indices, but we can phase them out, we've done it before.] As part of my cleaning up of symbol handling, I've been wanting to simplify things (as well as speed things up), and one thing that will help is if *every* symbol that appears in GLOBAL/STATIC_BLOCK of expanded symtabs already appears in partial symtabs/.gdb_index. I think this would result in a massive simplfication: The subtleties that we currently have could disappear. Plus it would simplify the last step I want to take for now in symbol lookup: search psymtabs/index first (not last) and only search psymtabs/index (and never loop over GLOBAL/STATIC_BLOCK). I have a version of this patch that works with psymtabs/index as they exist today, and I'm mostly happy with it, but if I can I'd like to simplify it, and I'm using the above example as motivation for thinking about the problem some more: It doesn't fix the above bug, and we don't want IMO to fix it by expanding every symtab ... If you think about it, it's odd that we loop over GLOBAL/STATIC_BLOCK. I kinda wonder how that ever got started. If I'm missing something please let me know! Setting aside the fact that we always expand the symtab with main() at startup, there are no expanded symtabs at startup. So if we want gdb to work as well at startup as it does later during the debugging session, symbol lookup has to work with no expanded symtabs! There's kinda no point in looping over something that isn't there. :-) So why can't we just search psymtab/index and leave it at that? The answer, or at least part of the answer, is that psymtabs/index doesn't contain everything that exists in GLOBAL/STATIC_BLOCK, and we rely on progressive lookup to expand symtabs as we go along so that when we get to looking up "c" in "a::b::c" its symtab as already been expanded (because we're not going to find it in psymtabs/index). Still, why do we have to loop over all GLOBAL/STATIC_BLOCKs to find "c"? I don't actually know, I think it's just convervatism, but if there is a real reason it'd be great to add some clarity here. If we know where we found "b", I think(!) we could just look there, and if that fails look in psymtabs/index (e.g., static members can get put in psymtabs even though their containing class isn't in psymtabs). Would gcc emit a c++ class with two typedefs, with one typedef in one compilation unit and the other typedef in another compilation unit? Maybe we can't assume it won't happen, sigh, in which case all the more reason to have psymtabs/index include every static/global symbol. Plus if gcc could do that, "ptype foo::second_typedef" cannot otherwise work, unless the (potentially only) compilation unit with that typedef happens to get expanded via other means. Or we change lookup to loop over all compilation units that define foo until we find second_typedef, except that psymtabs/index only contain one entry for foo, so we'd have to change that too. [There is still one reason to support looping over all expanded symtabs: if there's a bug psymtabs/index. GDB is just a tool and users would rather it still work, even with its bugs. But that doesn't have to be the default behaviour.] ---snip--- info-types.cc extern void foo (); int main () { foo (); return 0; } ---snip--- info-types-2.cc class foo_class { public: foo_class () { } typedef int foo_typedef; class inner { public: static foo_typedef y; }; }; foo_class::foo_typedef foo_class::inner::y = 23; int xyz; void foo () { xyz = foo_class::inner::y; } ---snip--- bash$ g++ -g info-types.c info-types-2.cc -o info-types