From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30237 invoked by alias); 9 Sep 2003 20:28:21 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 30215 invoked from network); 9 Sep 2003 20:28:20 -0000 Received: from unknown (HELO hawaii.kealia.com) (209.3.10.89) by sources.redhat.com with SMTP; 9 Sep 2003 20:28:20 -0000 Received: by hawaii.kealia.com (Postfix, from userid 2049) id 7D5C8CB14; Tue, 9 Sep 2003 13:28:19 -0700 (PDT) To: Elena Zannoni Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa] generate symbols associated to namespaces References: <20030622173547.GA22603@nevyn.them.org> <20030624185019.GA24662@nevyn.them.org> <16222.12105.616302.481564@localhost.redhat.com> From: David Carlton Date: Tue, 09 Sep 2003 20:28:00 -0000 In-Reply-To: <16222.12105.616302.481564@localhost.redhat.com> (Elena Zannoni's message of "Tue, 9 Sep 2003 15:51:37 -0400") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Rational FORTRAN, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-09/txt/msg00175.txt.bz2 On Tue, 9 Sep 2003 15:51:37 -0400, Elena Zannoni said: > David Carlton writes: > Ok, but, could you check in the algorithm change (the nested_level > stuff) for scan_partial_symbols w/o any namespace changes? So that > we can do a cvs -D if something goes wrong? I have decided that it > is best to have a change per 24hours period to a file, after > spending a couple of days tracking down some other breakage in > symfiles, a few weeks back. Then the rest of the changes. That should be fine. >> + psym = add_psymbol_to_list (pdi->name, strlen (pdi->name), >> + VAR_DOMAIN, LOC_STATIC, >> + &objfile->static_psymbols, >> + 0, addr + baseaddr, >> + cu_language, objfile); > I don't like this too much. I.e. changing add_psymbol_to_list to > return a value so you can get a hold of the psym. After all, > add_psymbol_to_list doesn't change any of the fields of the psymbol, > and cp_check_possible_namespace_symbols uses 2 fields that you > already have around. No, add_psymbol_to_list does change the fields: it calls SYMBOL_SET_NAMES to set the demangled name, which I need in cp_check_possible_namespace_symbols. So having add_psymbol_to_list return the psymbol seems the best solution; I suppose I could break out the demangled-name-caching code that SYMBOL_SET_NAMES uses into a separate function, but it doesn't seem worth it here. >> +static char * >> +add_partial_enumeration (struct partial_die_info *enum_pdi, char *info_ptr, >> + struct objfile *objfile, >> + const struct comp_unit_head *cu_header, >> + const char *namespace) >> +{ >> + bfd *abfd = objfile->obfd; >> + struct partial_die_info pdi; >> + >> + if (enum_pdi->name != NULL) >> + add_partial_symbol (enum_pdi, objfile, cu_header, namespace); >> + >> + while (1) >> + { >> + info_ptr = read_partial_die (&pdi, abfd, info_ptr, cu_header); >> + if (pdi.tag == 0) >> + break; >> + if (pdi.tag != DW_TAG_enumerator || pdi.name == NULL) >> + complaint (&symfile_complaints, "malformed enumerator DIE ignored"); >> + else >> + add_partial_symbol (&pdi, objfile, cu_header, namespace); >> + } >> + >> + return info_ptr; >> +} >> + > Any enumeration related tests that fail before and pass after this > change? Nope. I don't think it should change GDB's behavior on well-formed debug info. >> + /* Add a symbol associated to this if we haven't seen the namespace >> + before. */ >> + >> + if (dwarf2_extension (die) == NULL) > Could you use this function in the check before this, in > read_namespace (not in this patch, but already in the file)? I think so; I don't see why the using directive bit couldn't be moved into this block. > I think it would make sense, in a next pass, to have all the creation > of blocks go through the new function. That would be my instinct as well. I can't remember why I didn't do that in this patch, but I don't think I had a good reason for why it wouldn't work. David Carlton carlton@kealia.com