bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/16787] New: LD gives wrong error messages


From: ma.jiang at zte dot com.cn
Subject: [Bug ld/16787] New: LD gives wrong error messages
Date: Tue, 01 Apr 2014 09:02:48 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=16787

            Bug ID: 16787
           Summary: LD gives  wrong error messages
           Product: binutils
           Version: 2.24
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: ma.jiang at zte dot com.cn

Created attachment 7512
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7512&action=edit
for bug reproduce

unzip the attached file, put these files into the directory of a cross-compiler
for arm.Run the bug.sh. Linker will throw out error messages like :

t1234.o: In function `t1':
/home/majiang/toolchain_compile/ToolsChain/gcc4.5.2_glibc2.13.0/install/arm_eabi_gcc4.5.2_glibc2.13.0/bin/t1.c:2:
warning: Using 'getgrgid' in statically linked applications requires at runtime
the shared libraries from the glibc version used for linking
t1234.o: In function `tp_842':
/home/majiang/toolchain_compile/ToolsChain/gcc4.5.2_glibc2.13.0/install/arm_eabi_gcc4.5.2_glibc2.13.0/bin/t4.c:12:
undefined reference to `udf'
collect2: ld returned 1 exit status

But, in fact the reference to 'udf' is in t3.c as you can see from the source
codes.The Gnu Linker gives out a totally wrong message here.
==========================================================================
This problem has something to do with the bfd interface
_bfd_dwarf2_slurp_debug_info.This function uses a cached debug info which is
wrong in some circumstance. More specifically, _bfd_dwarf2_slurp_debug_info
load and parse the debug info sections when ld generated getgrgid warning.At
that time,output sections(especially their vma) are not determined. When ld
generated the udf error, output sections have their vma now while
_bfd_dwarf2_slurp_debug_info still use the cached debug info. Finally,the bug
jump out. The find_line function add the section->output_section->vma to the
reloc offset of udf, and the aranges of compilation units in cached debug info
do not change with it. At last, the find_line function find a wrong file/lineno
for the udf reference.
=============================================================================
To fix this problem, ld need to clear the wrong cache when things have changed.
My solution is to call the function below right after the lang_process function
call  lang_size_sections (NULL, ! RELAXATION_ENABLED).

static void reset_all_debuginfo(void)
{
  bfd * input_bfd;
  for (input_bfd = link_info.input_bfds;
       input_bfd != NULL;
       input_bfd = input_bfd->link_next)
  {
      struct elf_obj_tdata *tdata = ((input_bfd) -> tdata.elf_obj_data);
      if (bfd_get_format (input_bfd) == bfd_object && tdata != NULL)
        {
        _bfd_dwarf2_cleanup_debug_info(input_bfd,
&tdata->dwarf2_find_line_info);
        tdata->dwarf2_find_line_info = NULL;
        }      

  }
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]