From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29358 invoked by alias); 26 Nov 2012 18:36:48 -0000 Received: (qmail 29256 invoked by uid 22791); 26 Nov 2012 18:36:47 -0000 X-SWARE-Spam-Status: No, hits=-5.9 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_BJ X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 26 Nov 2012 18:36:43 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qAQIabGj013067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Nov 2012 13:36:37 -0500 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qAQIaZFV019111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 26 Nov 2012 13:36:36 -0500 From: Tom Tromey To: Joel Brobecker Cc: Pierre Muller , "'Pedro Alves'" , "'Eli Zaretskii'" , gdb-patches@sourceware.org Subject: Re: [RFC-v4] Fix .text section offset for windows DLL (was Calling __stdcall functions in the inferior) References: <83y5jb7rfe.fsf@gnu.org> <006001cdaada$00c81f00$02585d00$@muller@ics-cnrs.unistra.fr> <20121024194517.GK3555@adacore.com> <011901cdb2ab$48076b90$d81642b0$@muller@ics-cnrs.unistra.fr> <20121105171121.GA2972@adacore.com> <50991f5f.8382440a.1100.ffff82abSMTPIN_ADDED@mx.google.com> <509ABA17.30507@redhat.com> <000301cdbd96$f5cd9f10$e168dd30$@muller@ics-cnrs.unistra.fr> <20121122173019.GF9964@adacore.com> <009801cdcb5f$38ecd830$aac68890$@muller@ics-cnrs.unistra.fr> <20121126172227.GB3089@adacore.com> Date: Mon, 26 Nov 2012 18:36:00 -0000 In-Reply-To: <20121126172227.GB3089@adacore.com> (Joel Brobecker's message of "Mon, 26 Nov 2012 18:22:27 +0100") Message-ID: <87ip8sgqj0.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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-11/txt/msg00680.txt.bz2 >>>>> "Joel" == Joel Brobecker writes: Joel> prim_record_minimal_symbol Joel> -> prim_record_minimal_symbol_full with copy_name=1 Joel> -> SYMBOL_SET_NAMES (msymbol, name, name_len, copy_name, objfile); Joel> | else Joel> | { Joel> | lookup_len = len; Joel> | lookup_name = linkage_name; Joel> | linkage_name_copy = linkage_name; Joel> | } Joel> | Joel> | entry.mangled = (char *) lookup_name; Joel> | slot = ((struct demangled_name_entry **) Joel> | htab_find_slot (objfile->demangled_names_hash, Joel> | &entry, INSERT)); Joel> Does it looks like a reference to the string might actually Joel> get inserted in the htab if not found, thus defeating the Joel> mechanism above? Tom might be better suited to answer that Joel> question more authoritatively. Here, 'entry' is used to look in the hash table, but it is not entered into the hash table itself. For that you have to go into the subsequent "*slot == NULL" code; and there it allocates a new entry on the objfile's obstack. There are two cases, but e.g.: *slot = obstack_alloc (&objfile->objfile_obstack, offsetof (struct demangled_name_entry, demangled) + demangled_len + 1); Joel> In the meantime, one approach that might be equally suitable, but Joel> without the bug, is if allocate the name on the objfile obstack, Joel> and then call prim_record_minimal_symbol_full directly I think there's no need; this is what the 'copy_name=1' case is for. Tom