From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22416 invoked by alias); 13 May 2008 21:12:46 -0000 Received: (qmail 22407 invoked by uid 22791); 13 May 2008 21:12:45 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate5.de.ibm.com (HELO mtagate5.de.ibm.com) (195.212.29.154) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 13 May 2008 21:12:24 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.8/8.13.8) with ESMTP id m4DLCK4e496732 for ; Tue, 13 May 2008 21:12:20 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m4DLCKCr3715196 for ; Tue, 13 May 2008 23:12:20 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m4DLCKK4018493 for ; Tue, 13 May 2008 23:12:20 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id m4DLCKfr018490; Tue, 13 May 2008 23:12:20 +0200 Message-Id: <200805132112.m4DLCKfr018490@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Tue, 13 May 2008 23:12:20 +0200 Subject: Re: Overlay support broken (Re: [patch] [2/2] Discontiguous PSYMTABs (psymtabs->symtabs by addrmap)) To: pedro@codesourcery.com Date: Wed, 14 May 2008 01:11:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, jan.kratochvil@redhat.com, drow@false.org X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: 2008-05/txt/msg00416.txt.bz2 Pedro Alves wrote: > Please also make sure that you're setting SYMBOL_CLASS > before calling fixup_*symbol_section everywhere. This will break > dwarf2read.c, for example: Ah, thanks for pointing that out! > + struct minimal_symbol *msym = NULL; > + if (addr != ~(CORE_ADDR) 0) > + /* If we have an address to lookup, use it. */ > + msym = lookup_minimal_symbol_by_pc (addr); > + > + if (!msym > + || addr != SYMBOL_VALUE_ADDRESS (msym) > + || strcmp (DEPRECATED_SYMBOL_NAME (msym), ginfo->name) != 0) > + /* Try by looking up by name. Not perfect, since it can match the > + wrong symbol. */ > + msym = lookup_minimal_symbol (ginfo->name, NULL, objfile); Hmm, I guess there is the possibility that even though there is a msymbol at ADDR with name NAME, both lookup_minimal_symbol_by_pc (ADDR) and lookup_minimal_symbol (NAME) might fail to find it ... E.g. if there are minimal symbols ADDR' NAME ADDR NAME' ADDR NAME lookup by pc might find NAME', but lookup by name might find ADDR'. Maybe we need a lookup_minimal_symbol_by_pc_name or so? > + /* We either have an OBJFILE, or we can get at it from the sym's > + symtab. Anything else is a bug. */ > + gdb_assert (objfile || (sym->symtab && sym->symtab->objfile)); > + > + if (objfile == NULL) > + objfile = sym->symtab->objfile; Huh. If that's true, why does fixup_symbol_section even have an OBJFILE argument? Is there ever a situation where we cannot use sym->symtab->objfile? > + switch (SYMBOL_CLASS (sym)) > + { > + case LOC_UNRESOLVED: > + addr = ~(CORE_ADDR) 0; > + break; Why do we need to fixup the section for an LOC_UNRESOLVED symbol? I understand that every time we want to use the address of a LOC_UNRESOLVED, the user needs to look up the msymbol anyway. They should then use the section from the msymbol too, right? > + switch (SYMBOL_CLASS (psym)) > + { > + case LOC_STATIC: > + case LOC_BLOCK: > + addr = SYMBOL_VALUE_ADDRESS (psym); > + break; > + default: > + /* Nothing else will be listed in the minsyms -- no use looking > + it up. */ > + return psym; > + } Any reason for not supporting LOC_LABEL or LOC_INDIRECT for psymbols? (Well, except from the fact that apparently none of the symbol readers left in GDB will ever generate LOC_INDIRECT ... But at least mdebugread.c will generate LOC_LABEL psymbols, it seems.) Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com