From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10642 invoked by alias); 26 Nov 2014 21:11:36 -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 10588 invoked by uid 89); 26 Nov 2014 21:11:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 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-f169.google.com Received: from mail-vc0-f169.google.com (HELO mail-vc0-f169.google.com) (209.85.220.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 26 Nov 2014 21:11:34 +0000 Received: by mail-vc0-f169.google.com with SMTP id hy10so1691386vcb.14 for ; Wed, 26 Nov 2014 13:11:32 -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=qM1X5YMF9P590EluMIwXA+khH8USDePnbKQY/aY7lZ8=; b=PR79qyBLEqPBtWxb3tJxkreRios984kQVHEh9oXUWpD8gj831lmt/o0Kw2alkWdAIK R04lS63qmYKhHGuBJshJKrQJ1KFscSAQ4DrDoQIjA4fujH3Fg3GJ79p+co0g1f/cmSLM UgWl1zzL3tLfGU8ZQNU8bXOKQjVk6/fD4B7FRnpSnzBNY7IcO9S7lNotqj2FNMGxZtEb gCLlA8WHrBtBNtbhaxIIQfDXFwoS/k7qbsP8zcKH/fwVzfN07bqZMrm5BtFIFtQS8iCx RpzU8guMUfZyhbqNU1021+oU+edrLkH2scbDlWHetRn/0kCJel0QzxzThgAiY55euM+D lTXg== X-Gm-Message-State: ALoCoQlnaNcukZWmULx7YAawBjvTZi5l9bI40IY4rqszkdG98kx2KXPBQ+pQg9rdtCbYmQ5saQN+ MIME-Version: 1.0 X-Received: by 10.220.136.17 with SMTP id p17mr19113282vct.3.1417036291986; Wed, 26 Nov 2014 13:11:31 -0800 (PST) Received: by 10.52.114.101 with HTTP; Wed, 26 Nov 2014 13:11:31 -0800 (PST) In-Reply-To: References: Date: Wed, 26 Nov 2014 21:11:00 -0000 Message-ID: Subject: Re: [RFC] While processing a struct die, store the method's address in its fn_field From: Doug Evans To: Siva Chandra Cc: gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-11/txt/msg00671.txt.bz2 On Tue, Nov 25, 2014 at 11:31 PM, Siva Chandra wrote: > Phew... > > On Tue, Nov 25, 2014 at 7:22 PM, Doug Evans wrote: >> fwiw, GDB is bad enough that I often can't trust just reading the code. >> I often punt on that and actually single step through >> the relevant code to REALLY see what is happening. > > I single stepped through the code and now see everything that you said here! > > I believed this in gdbtypes.h: > > 889 /* * If is_stub is clear, this is the mangled name which > 890 we can look up to find the address of the method > 891 (FIXME: it would be cleaner to have a pointer to the > 892 struct symbol here instead). > 893 > 894 If is_stub is set, this is the portion of the mangled > 895 name which specifies the arguments. For example, "ii", > 896 if there are two int arguments, or "" if there are no > 897 arguments. See gdb_mangle_name for the conversion from > 898 this format to the one used if is_stub is clear. */ > 899 > 900 const char *physname; > > Rest of what I thought I understood fell out from this belief! And the > names look so enticing. > > Resetting my mind ... Zoinks! Yeah, that comment needs some TLC. [btw, the term "physname" is in a transition mode. In some places it means "mangled name". In other places it means "demangled name". It's not clear to me what we want to transition to though.]