From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jim Blandy <jimb@redhat.com>
To: Kevin Buettner <kevinb@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] symtab.c: Search section table when fixing up a symbol's section
Date: Tue, 18 May 2004 17:00:00 -0000
Message-id: <vt2zn8565ey.fsf@zenia.home>
References: <20040517120219.5fad9bc0@saguaro> <vt2n04693gv.fsf@zenia.home> <20040517142316.3b0f4320@saguaro>
X-SW-Source: 2004-05/msg00527.html

Just to make this explicit: if there are no further comments on this
by the end of Friday, feel free to commit this.

Kevin Buettner <kevinb@redhat.com> writes:
> Thanks for looking it over.
> 
> 	* symtab.c (fixup_section): Search section table when lookup by
> 	name fails.
> 
> Index: symtab.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/symtab.c,v
> retrieving revision 1.129
> diff -u -p -r1.129 symtab.c
> --- symtab.c	8 Apr 2004 21:18:13 -0000	1.129
> +++ symtab.c	17 May 2004 21:13:13 -0000
> @@ -868,6 +868,62 @@ fixup_section (struct general_symbol_inf
>        ginfo->bfd_section = SYMBOL_BFD_SECTION (msym);
>        ginfo->section = SYMBOL_SECTION (msym);
>      }
> +  else if (objfile)
> +    {
> +      /* Static, function-local variables do appear in the linker
> +	 (minimal) symbols, but are frequently given names that won't
> +	 be found via lookup_minimal_symbol().  E.g., it has been
> +	 observed in frv-uclinux (ELF) executables that a static,
> +	 function-local variable named "foo" might appear in the
> +	 linker symbols as "foo.6" or "foo.3".  Thus, there is no
> +	 point in attempting to extend the lookup-by-name mechanism to
> +	 handle this case due to the fact that there can be multiple
> +	 names.
> +	 
> +	 So, instead, search the section table when lookup by name has
> +	 failed.  The ``addr'' and ``endaddr'' fields may have already
> +	 been relocated.  If so, the relocation offset (i.e. the
> +	 ANOFFSET value) needs to be subtracted from these values when
> +	 performing the comparison.  We unconditionally subtract it,
> +	 because, when no relocation has been performed, the ANOFFSET
> +	 value will simply be zero.
> +	 
> +	 The address of the symbol whose section we're fixing up HAS
> +	 NOT BEEN adjusted (relocated) yet.  It can't have been since
> +	 the section isn't yet known and knowing the section is
> +	 necessary in order to add the correct relocation value.  In
> +	 other words, we wouldn't even be in this function (attempting
> +	 to compute the section) if it were already known.
> +
> +	 Note that it is possible to search the minimal symbols
> +	 (subtracting the relocation value if necessary) to find the
> +	 matching minimal symbol, but this is overkill and much less
> +	 efficient.  It is not necessary to find the matching minimal
> +	 symbol, only its section.  
> +	 
> +	 Note that this technique (of doing a section table search)
> +	 can fail when unrelocated section addresses overlap.  For
> +	 this reason, we still attempt a lookup by name prior to doing
> +	 a search of the section table.  */
> +	 
> +      CORE_ADDR addr;
> +      struct obj_section *s;
> +
> +      addr = ginfo->value.address;
> +
> +      ALL_OBJFILE_OSECTIONS (objfile, s)
> +	{
> +	  int idx = s->the_bfd_section->index;
> +	  CORE_ADDR offset = ANOFFSET (objfile->section_offsets, idx);
> +
> +	  if (s->addr - offset <= addr && addr < s->endaddr - offset)
> +	    {
> +	      ginfo->bfd_section = s->the_bfd_section;
> +	      ginfo->section = idx;
> +	      return;
> +	    }
> +	}
> +    }
>  }
>  
>  struct symbol *