From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19092 invoked by alias); 26 Nov 2012 20:58:39 -0000 Received: (qmail 18964 invoked by uid 22791); 26 Nov 2012 20:58:38 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_NO X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 26 Nov 2012 20:58:31 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 0B54D2E17B; Mon, 26 Nov 2012 15:58:31 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YqCGif9N+Uwr; Mon, 26 Nov 2012 15:58:30 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id AB5F92E17A; Mon, 26 Nov 2012 15:58:30 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 6EDF6C270B; Mon, 26 Nov 2012 21:58:28 +0100 (CET) Date: Mon, 26 Nov 2012 20:58:00 -0000 From: Joel Brobecker To: Tom Tromey 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) Message-ID: <20121126205828.GF3089@adacore.com> References: <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> <87ip8sgqj0.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ip8sgqj0.fsf@fleche.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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/msg00692.txt.bz2 > 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); Ah, I got tricked by the INSERT, but looking at the htab_find_slot documentation, indeed, it clearly explains that the data still needs to be set. I wasn't able to to determine from just reading the code where we might be creating a dangling pointer. > I think there's no need; this is what the 'copy_name=1' case is for. Right. We just need to dig deeper to figure out what it's not working for Pierre... I don't think we want to check in his patch where the xmalloc'ed name does not have a corresponding xfree... Thanks, Tom. -- Joel