PR23425, unresolved symbol diagnostic

PR23425, unresolved symbol diagnostic

[Alan Modra]

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.

diff --git a/bfd/dwarf2.c b/bfd/dwarf2.c
index 8fadb5c4b6..3b2885599e 100644
--- a/bfd/dwarf2.c
+++ b/bfd/dwarf2.c
@@ -2837,7 +2837,9 @@ find_abstract_instance (struct comp_unit *   unit,
       info_ptr = unit->stash->info_ptr_memory;
       info_ptr_end = unit->stash->info_ptr_end;
       total = info_ptr_end - info_ptr;
-      if (!die_ref || die_ref >= total)
+      if (!die_ref)
+	return TRUE;
+      else if (die_ref >= total)
 	{
 	  _bfd_error_handler
 	    (_("DWARF error: invalid abstract instance DIE ref"));
diff --git a/bfd/reloc.c b/bfd/reloc.c
index eba6091891..67457418e6 100644
--- a/bfd/reloc.c
+++ b/bfd/reloc.c
@@ -8259,7 +8259,18 @@ bfd_generic_get_relocated_section_contents (bfd *abfd,
 	      goto error_return;
 	    }
 
-	  if (symbol->section && discarded_section (symbol->section))
+	  /* Zap reloc field when the symbol is from a discarded
+	     section, ignoring any addend.  Do the same when called
+	     from bfd_simple_get_relocated_section_contents for
+	     undefined symbols in debug sections.  This is to keep
+	     debug info reasonably sane, in particular so that
+	     DW_FORM_ref_addr to another file's .debug_info isn't
+	     confused with an offset into the current file's
+	     .debug_info.  */
+	  if ((symbol->section != NULL && discarded_section (symbol->section))
+	      || (symbol->section == bfd_und_section_ptr
+		  && (input_section->flags & SEC_DEBUGGING) != 0
+		  && link_info->input_bfds == link_info->output_bfd))
 	    {
 	      bfd_byte *p;
 	      static reloc_howto_type none_howto

-- 
Alan Modra
Australia Development Lab, IBM

Re: PR23425, unresolved symbol diagnostic

[Tom Tromey]

>>>>> "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

Re: PR23425, unresolved symbol diagnostic

[Pedro Alves]

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