Re: symtab.h: 2000-10-12 SYMBOL_INIT_DEMANGLED_NAME change, why ?

Re: symtab.h: 2000-10-12 SYMBOL_INIT_DEMANGLED_NAME change, why ?

[Peter.Schauer]

> There is no noticeable speed decrease due to this change.
> I originally thought the  actual likely culprit is somewhere in the stabsreader, the
> SYMBOL_LANGUAGE not getting set in all cases.
> But it turned out the current file's language was language_unknown for
> some reason, at the point it wanted to set the symbol language.
> However, I couldn't follow all the codepaths to track this down, due
> to the gotos.
> I didn't feel like wasting any more time on it, so i just fixed the
> symptom, as you said.

I would be volunteering to `waste' more time on it, if you can provide
an example, as I'd rather like to fix the cause.

-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de
From kevinb@cygnus.com Sat Oct 28 14:34:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: Elena Zannoni <ezannoni@redhat.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: [PATCH RFA] dwarf2read.c: symbol relocation in new_symbol()
Date: Sat, 28 Oct 2000 14:34:00 -0000
Message-id: <1001028213434.ZM3907@ocotillo.lan>
X-SW-Source: 2000-10/msg00260.html
Content-length: 1725

AIX5/IA-64 relocates read-only and read/write sections by different
amounts.  The patch below fixes dwarf2read.c to account for this
scenario.

I was tempted to try to fix the other occurrences of baseaddr in
this file, but decided to leave that for one our symtabs/dwarf2
experts.

I've tested this patch on linux/x86 w/ -gdwarf-2 and saw no
regressions.  (I've also done some limited testing on AIX5 and it does
indeed fix the problems that I was seeing.)

Okay to commit?

	* dwarf2read.c (new_symbol): Relocate address of symbol by the
	base address of the section it is in rather than always using
	the base address of the .text section.

Index: dwarf2read.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2read.c,v
retrieving revision 1.16
diff -u -p -r1.16 dwarf2read.c
--- dwarf2read.c	2000/08/04 16:51:47	1.16
+++ dwarf2read.c	2000/10/28 20:59:09
@@ -4185,7 +4185,10 @@ new_symbol (struct die_info *die, struct
 		     the variable is referenced.  */
 		  if (SYMBOL_VALUE_ADDRESS (sym))
 		    {
-		      SYMBOL_VALUE_ADDRESS (sym) += baseaddr;
+		      fixup_symbol_section (sym, objfile);
+		      SYMBOL_VALUE_ADDRESS (sym) +=
+			ANOFFSET (objfile->section_offsets,
+			          SYMBOL_SECTION (sym));
 		      SYMBOL_CLASS (sym) = LOC_STATIC;
 		    }
 		  else
@@ -4215,8 +4218,11 @@ new_symbol (struct die_info *die, struct
 		    }
 		  else
 		    {
+		      fixup_symbol_section (sym, objfile);
 		      SYMBOL_CLASS (sym) = LOC_STATIC;
-		      SYMBOL_VALUE_ADDRESS (sym) = addr + baseaddr;
+		      SYMBOL_VALUE_ADDRESS (sym) =
+		        addr + ANOFFSET (objfile->section_offsets,
+			                 SYMBOL_SECTION (sym));
 		    }
 		}
 	    }

Re: symtab.h: 2000-10-12 SYMBOL_INIT_DEMANGLED_NAME change, why ?

[Daniel Berlin]

"Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de> writes:

> > There is no noticeable speed decrease due to this change.
> > I originally thought the  actual likely culprit is somewhere in the stabsreader, the
> > SYMBOL_LANGUAGE not getting set in all cases.
> > But it turned out the current file's language was language_unknown for
> > some reason, at the point it wanted to set the symbol language.
> > However, I couldn't follow all the codepaths to track this down, due
> > to the gotos.
> > I didn't feel like wasting any more time on it, so i just fixed the
> > symptom, as you said.
> 
> I would be volunteering to `waste' more time on it, if you can provide
> an example, as I'd rather like to fix the cause.

Okeydokey, i'll send you one.

You'll likely find it's bad debug info being produced by GCC 2.95.2 in
stabs mode, in which case, we can't get it fixed (unless it's still
broken in 2.97, which i doubt).
--Dan

Re: symtab.h: 2000-10-12 SYMBOL_INIT_DEMANGLED_NAME change, why ?

[Daniel Berlin]

"Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de> writes:

> I do not understand the need for the following change:
> 
> 2000-10-12  Elena Zannoni  <ezannoni@kwikemart.cygnus.com>
> 
> 	From Daniel Berlin <dberlin@redhat.com> :
> 
> 	* symtab.h (SYMBOL_INIT_DEMANGLED_NAME): Initialize the symbol
>  	language to auto instead of unknown, so it will try to demangle
>  	the symbol.
> 
> Dan, could you provide an example why this is needed ?

Yup.
Well, I can explain *why* it is needed.
> 
> Minimal symbols are always demangled with language_auto.
> Symbol readers make sure that the proper language is used for
> SYMBOL_INIT_DEMANGLED_NAME, either via cu_language or via
> deduce_language_from_filename.

This is not true anymore.
We run into quite a few cases where the language is unknown when
symbol_init_demangled_name gets called the first time.

The problem then becomes that when, in the future, the language gets
set properly, and symbol_init_demangled_name gets called again, it
won't set the demangled name, ever, because we already tried once.


In other words, whether our demangled name gets initialized properly
or not should not depend on when we initialize it.

Before it did.
I can't see this as a valid optimization.
> 
> So language_unknown should not happen normally, it looks to me like this
> change is trying to cure a symptom rather than a cause.

I spent weeks trying to track down the cause, and it appears to only
happen in certain versions of gcc. 2.95.2 comes to mind.
However, since there will be no 2.95.3, and people still need to be
debugging C++ programs, the change is needed anyway.
> 
> And if we really should need this change, the comment for
> SYMBOL_INIT_DEMANGLED_NAME should be updated, currently it no longer reflects
> reality.
> 


> -- 
> Peter Schauer			pes@regent.e-technik.tu-muenchen.de