PR23425, unresolved symbol diagnostic

  dwarf2.c code reasonably assumes that debug info is local to a file,
an assumption now violated by gcc, resulting in "DWARF error: invalid
abstract instance DIE ref" or wrong details when attempting to print
linker error messages with file, function and line reported.

This is because find_abstract_instance is only prepared to handle
DW_FORM_ref_addr when the .debug_info section referenced is in the
current file.  When that isn't the case, relocations to access another
file's .debug_info will typically be against a symbol defined at the
start of that .debug_info section, plus an addend.  Since the dwarf2.c
code only considers the current file's debug info, that symbol will be
undefined, resolving to zero.  In effect the ref_addr will wrongly
resolve to the current file's .debug_info.

This patch avoids the problem by treating relocations in debug
sections against undefined symbols in a similar manner to the way
relocations against symbols defined in discarded sections are
resolved.  They result in a zero value (except in .debug_ranges)
regardless of the addend.

I think this should be OK for all the gdb uses of
bfd_simple_get_relocated_section_contents or similar code in
compile-object-load.c, but I won't commit this immediately to give gdb
folk time to comment.

	PR 23425
	* reloc.c (bfd_generic_get_relocated_section_contents): Zero reloc
	fields in debug sections when reloc is against an undefined symbol
	and called from bfd_simple_get_relocated_section_contents or
	similar.
	* dwarf2.c (find_abstract_instance): Return true for zero offset
	DW_FORM_ref_addr without returning values.
  

>>>>> "Alan" == Alan Modra <amodra@gmail.com> writes:

Alan> I think this should be OK for all the gdb uses of
Alan> bfd_simple_get_relocated_section_contents or similar code in
Alan> compile-object-load.c, but I won't commit this immediately to give gdb
Alan> folk time to comment.

There should be gdb test cases covering the relocation cases.

For the compile feature you'll need to make sure your gcc is
compile-capable and that the needed library and plugin are installed.

However, I believe relocation isn't only used for the compile feature.
There's this in dwarf2read.c:

  /* When debugging .o files, we may need to apply relocations; see
     http://sourceware.org/ml/gdb-patches/2002-04/msg00136.html .
     We never compress sections in .o files, so we only need to
     try this when the section is not compressed.  */
  retbuf = symfile_relocate_debug_section (objfile, sectp, buf);

I don't know if there is a test case for this or not -- I'd hope so.

Tom
  

On 09/11/2018 05:04 PM, Tom Tromey wrote:
>>>>>> "Alan" == Alan Modra <amodra@gmail.com> writes:
> 
> Alan> I think this should be OK for all the gdb uses of
> Alan> bfd_simple_get_relocated_section_contents or similar code in
> Alan> compile-object-load.c, but I won't commit this immediately to give gdb
> Alan> folk time to comment.
> 
> There should be gdb test cases covering the relocation cases.

Yeah, you can debug an unrelocated .o file directly,
like "file foo.o".  The canonical testcase for that, I think is
gdb.base/relocate.exp.

> 
> For the compile feature you'll need to make sure your gcc is
> compile-capable and that the needed library and plugin are installed.
> 
> However, I believe relocation isn't only used for the compile feature.
> There's this in dwarf2read.c:
> 
>   /* When debugging .o files, we may need to apply relocations; see
>      http://sourceware.org/ml/gdb-patches/2002-04/msg00136.html .
>      We never compress sections in .o files, so we only need to
>      try this when the section is not compressed.  */
>   retbuf = symfile_relocate_debug_section (objfile, sectp, buf);
> 
> I don't know if there is a test case for this or not -- I'd hope so.

gdb.base/relocate.exp likely covers this.

Thanks,
Pedro Alves