Re: bfd assertion failed with gcc 950607

Re: bfd assertion failed with gcc 950607

[H.J. Lu]

> 
> > Please apply this patch to binutils 2.5.2l.17 and let me know what you
> > get.
> 
> After applying your patch, I have some sensible error messages.
> This is the smallest case I have been able to produce.  I give
> you the two source files, Makefile, the .s files produced
> en route, and the log giving the assertion failures.  Note that
> this did not happen with the previous snapshots.  I am using
> the ldscripts from your binutils distribution, not those
> produced when recompiling binutils.
> 
>      -- Owen
>      LeBlanc@mcc.ac.uk
> 

How should we treat common and weak symbols? I don't know what I
am doing. But I think I am right. The ld on Solaris doesn't
complain. Could someone please take a look at this patch?

Thanks.


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com
-----
*** bfd.c.orig	Mon Jun 12 12:47:53 1995
--- ./bfd.c	Mon Jun 12 13:17:15 1995
***************
*** 638,643 ****
--- 638,657 ----
  }
  
  
+ void
+ bfd_assert_symbol(file, line, symbol)
+ char *file;
+ int line;
+ char *symbol;
+ {
+   if (symbol)
+     fprintf(stderr, "bfd assertion fail %s:%d due to symbol: `%s'. possible cause:\n\tmismatched types in library and program.\n",
+ 	file,line,symbol);
+   else
+     fprintf(stderr, "bfd assertion fail %s:%d\n",file,line);
+ }
+ 
+ 
  /*
  FUNCTION
  	bfd_set_start_address
*** elf32-i386.c.orig	Mon Jun 12 12:18:15 1995
--- ./elf32-i386.c	Wed Jun 14 09:46:07 1995
***************
*** 607,613 ****
    dynobj = elf_hash_table (info)->dynobj;
  
    /* Make sure we know what is going on here.  */
!   BFD_ASSERT (dynobj != NULL
  	      && ((h->elf_link_hash_flags & ELF_LINK_HASH_NEEDS_PLT)
  		  || ((h->elf_link_hash_flags
  		       & ELF_LINK_HASH_DEF_DYNAMIC) != 0
--- 607,613 ----
    dynobj = elf_hash_table (info)->dynobj;
  
    /* Make sure we know what is going on here.  */
!   BFD_ASSERT_SYMBOL (dynobj != NULL
  	      && ((h->elf_link_hash_flags & ELF_LINK_HASH_NEEDS_PLT)
  		  || ((h->elf_link_hash_flags
  		       & ELF_LINK_HASH_DEF_DYNAMIC) != 0
***************
*** 618,627 ****
  		      && (elf_elfheader (h->root.u.def.section->owner)->e_type
  			  == ET_DYN)
  		      && (h->root.type == bfd_link_hash_defined
  			  || h->root.type == bfd_link_hash_defweak)
  		      && (bfd_get_flavour (h->root.u.def.section->owner)
  			  == bfd_target_elf_flavour)
! 		      && h->root.u.def.section->output_section == NULL)));
  
    /* If this is a function, put it in the procedure linkage table.  We
       will fill in the contents of the procedure linkage table later,
--- 618,629 ----
  		      && (elf_elfheader (h->root.u.def.section->owner)->e_type
  			  == ET_DYN)
  		      && (h->root.type == bfd_link_hash_defined
+ 			  || h->root.type == bfd_link_hash_common
  			  || h->root.type == bfd_link_hash_defweak)
  		      && (bfd_get_flavour (h->root.u.def.section->owner)
  			  == bfd_target_elf_flavour)
! 		      && h->root.u.def.section->output_section == NULL)),
! 		      h->root.root.string);
  
    /* If this is a function, put it in the procedure linkage table.  We
       will fill in the contents of the procedure linkage table later,
*** elfcode.h.orig	Mon Jun 12 12:44:56 1995
--- ./elfcode.h	Wed Jun 14 09:45:25 1995
***************
*** 4712,4719 ****
        weaks = hlook->weakdef;
        hlook->weakdef = NULL;
  
!       BFD_ASSERT (hlook->root.type == bfd_link_hash_defined
! 		  || hlook->root.type == bfd_link_hash_defweak);
        slook = hlook->root.u.def.section;
        vlook = hlook->root.u.def.value;
  
--- 4712,4721 ----
        weaks = hlook->weakdef;
        hlook->weakdef = NULL;
  
!       BFD_ASSERT_SYMBOL (hlook->root.type == bfd_link_hash_defined
! 		  || hlook->root.type == bfd_link_hash_common
! 		  || hlook->root.type == bfd_link_hash_defweak,
! 		  hlook->root.root.string);
        slook = hlook->root.u.def.section;
        vlook = hlook->root.u.def.value;
  
*** libbfd-in.h.orig	Mon Jun 12 12:46:59 1995
--- ./libbfd-in.h	Mon Jun 12 12:53:18 1995
***************
*** 402,409 ****
--- 402,414 ----
  
  void	bfd_assert PARAMS ((char*,int));
  
+ void	bfd_assert_symbol PARAMS ((char*,int,char*));
+ 
  #define BFD_ASSERT(x) \
  { if (!(x)) bfd_assert(__FILE__,__LINE__); }
+ 
+ #define BFD_ASSERT_SYMBOL(x,s) \
+ { if (!(x)) bfd_assert_symbol(__FILE__,__LINE__,s); }
  
  #define BFD_FAIL() \
  { bfd_assert(__FILE__,__LINE__); }
*** libbfd.h.orig	Mon Apr 17 19:38:23 1995
--- ./libbfd.h	Mon Jun 12 13:02:56 1995
***************
*** 402,409 ****
--- 402,414 ----
  
  void	bfd_assert PARAMS ((char*,int));
  
+ void	bfd_assert_symbol PARAMS ((char*,int,char*));
+ 
  #define BFD_ASSERT(x) \
  { if (!(x)) bfd_assert(__FILE__,__LINE__); }
+ 
+ #define BFD_ASSERT_SYMBOL(x,s) \
+ { if (!(x)) bfd_assert_symbol(__FILE__,__LINE__,s); }
  
  #define BFD_FAIL() \
  { bfd_assert(__FILE__,__LINE__); }
------
#! /bin/sh
# This is a shell archive.  Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file".  To overwrite existing
# files, type "sh file -c".  You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g..  If this archive is complete, you
# will see the following message at the end:
#		"End of shell archive."
# Contents:  Makefile foo.c fred.c junk.c log
# Wrapped by hjl@jalod on Wed Jun 14 09:58:00 1995
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f 'Makefile' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'Makefile'\"
else
echo shar: Extracting \"'Makefile'\" \(188 characters\)
sed "s/^X//" >'Makefile' <<'END_OF_FILE'
XCC=gcc -v -b i486-linux
X
Xall:	junk
X
Xjunk:	junk.o fred.o libfoo.so
X	$(CC) -o $@ junk.o fred.o -lfoo -L.
X
Xlibfoo.so: foo.c
X	$(CC) -shared -o $@ -fPIC foo.c
X
Xclean:
X	rm -rf junk *.o *.s *.so
END_OF_FILE
if test 188 -ne `wc -c <'Makefile'`; then
    echo shar: \"'Makefile'\" unpacked with wrong size!
fi
# end of 'Makefile'
fi
if test -f 'foo.c' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'foo.c'\"
else
echo shar: Extracting \"'foo.c'\" \(52 characters\)
sed "s/^X//" >'foo.c' <<'END_OF_FILE'
X#pragma weak fooo=_fooo
X
Xint _fooo = 0;
X
Xfoo ()
X{
X}
END_OF_FILE
if test 52 -ne `wc -c <'foo.c'`; then
    echo shar: \"'foo.c'\" unpacked with wrong size!
fi
# end of 'foo.c'
fi
if test -f 'fred.c' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'fred.c'\"
else
echo shar: Extracting \"'fred.c'\" \(10 characters\)
sed "s/^X//" >'fred.c' <<'END_OF_FILE'
Xint fooo;
END_OF_FILE
if test 10 -ne `wc -c <'fred.c'`; then
    echo shar: \"'fred.c'\" unpacked with wrong size!
fi
# end of 'fred.c'
fi
if test -f 'junk.c' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'junk.c'\"
else
echo shar: Extracting \"'junk.c'\" \(57 characters\)
sed "s/^X//" >'junk.c' <<'END_OF_FILE'
Xextern int fooo;
Xvoid main(void)
X{
X  fooo=0;
X  foo ();
X}
END_OF_FILE
if test 57 -ne `wc -c <'junk.c'`; then
    echo shar: \"'junk.c'\" unpacked with wrong size!
fi
# end of 'junk.c'
fi
if test -f 'log' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'log'\"
else
echo shar: Extracting \"'log'\" \(4649 characters\)
sed "s/^X//" >'log' <<'END_OF_FILE'
Xgcc -v -b i486-linux    -c junk.c -o junk.o
XReading specs from /usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305/specs
Xgcc driver version 2.6.4 snapshot 950305 executing gcc version 2.6.4
X /usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305/cpp -lang-c -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=6 -D__ELF__ -Dunix -Di386 -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__i386 -D__linux -Asystem(unix) -Asystem(posix) -Acpu(i386) -Amachine(i386) -D__i486__ junk.c /usr/tmp/cca02276.i
XGNU CPP version 2.6.4 snapshot 950305 (i386 Linux/ELF)
X#include "..." search starts here:
X#include <...> search starts here:
X /usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305/include
X /usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305/sys-include
X /usr/gnu/i486-linux/include
XEnd of search list.
X /usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305/cc1 /usr/tmp/cca02276.i -quiet -dumpbase junk.c -version -o /usr/tmp/cca02276.s
XGNU C version 2.6.4 snapshot 950305 (i386 Linux/ELF) compiled by GNU C version 2.6.4 snapshot 950305.
X /usr/gnu/i486-linux/bin/as -V -Qy -o junk.o /usr/tmp/cca02276.s
XGNU assembler version 950421 (i486-linuxelf), using BFD version cygnus-2.5
Xgcc -v -b i486-linux    -c fred.c -o fred.o
XReading specs from /usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305/specs
Xgcc driver version 2.6.4 snapshot 950305 executing gcc version 2.6.4
X /usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305/cpp -lang-c -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=6 -D__ELF__ -Dunix -Di386 -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__i386 -D__linux -Asystem(unix) -Asystem(posix) -Acpu(i386) -Amachine(i386) -D__i486__ fred.c /usr/tmp/cca02280.i
XGNU CPP version 2.6.4 snapshot 950305 (i386 Linux/ELF)
X#include "..." search starts here:
X#include <...> search starts here:
X /usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305/include
X /usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305/sys-include
X /usr/gnu/i486-linux/include
XEnd of search list.
X /usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305/cc1 /usr/tmp/cca02280.i -quiet -dumpbase fred.c -version -o /usr/tmp/cca02280.s
XGNU C version 2.6.4 snapshot 950305 (i386 Linux/ELF) compiled by GNU C version 2.6.4 snapshot 950305.
X /usr/gnu/i486-linux/bin/as -V -Qy -o fred.o /usr/tmp/cca02280.s
XGNU assembler version 950421 (i486-linuxelf), using BFD version cygnus-2.5
Xgcc -v -b i486-linux -shared -o libfoo.so -fPIC foo.c
XReading specs from /usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305/specs
Xgcc driver version 2.6.4 snapshot 950305 executing gcc version 2.6.4
X /usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305/cpp -lang-c -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=6 -D__ELF__ -Dunix -Di386 -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__i386 -D__linux -Asystem(unix) -Asystem(posix) -Acpu(i386) -Amachine(i386) -D__PIC__ -D__pic__ -D__i486__ foo.c /usr/tmp/cca02284.i
XGNU CPP version 2.6.4 snapshot 950305 (i386 Linux/ELF)
X#include "..." search starts here:
X#include <...> search starts here:
X /usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305/include
X /usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305/sys-include
X /usr/gnu/i486-linux/include
XEnd of search list.
X /usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305/cc1 /usr/tmp/cca02284.i -quiet -dumpbase foo.c -version -fPIC -o /usr/tmp/cca02284.s
XGNU C version 2.6.4 snapshot 950305 (i386 Linux/ELF) compiled by GNU C version 2.6.4 snapshot 950305.
X /usr/gnu/i486-linux/bin/as -V -Qy -o /usr/tmp/cca022841.o /usr/tmp/cca02284.s
XGNU assembler version 950421 (i486-linuxelf), using BFD version cygnus-2.5
X /usr/gnu/i486-linux/bin/ld -m elf_i386 -shared -o libfoo.so /usr/gnu/i486-linux/lib/crti.o /usr/gnu/i486-linux/lib/crtbeginS.o -L/usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305 -L/usr/gnu/i486-linux/lib /usr/tmp/cca022841.o /usr/gnu/i486-linux/lib/crtendS.o /usr/gnu/i486-linux/lib/crtn.o
Xgcc -v -b i486-linux -o junk junk.o fred.o -lfoo -L.
XReading specs from /usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305/specs
Xgcc driver version 2.6.4 snapshot 950305 executing gcc version 2.6.4
X /usr/gnu/i486-linux/bin/ld -m elf_i386 -dynamic-linker /lib/elf/ld-linux.so.1 -rpath /lib/elf/ -o junk /usr/gnu/i486-linux/lib/crt1.o /usr/gnu/i486-linux/lib/crti.o /usr/gnu/i486-linux/lib/crtbegin.o -L. -L/usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305 -L/usr/gnu/i486-linux/lib junk.o fred.o -lfoo -lgcc -lc -lgcc /usr/gnu/i486-linux/lib/crtend.o /usr/gnu/i486-linux/lib/crtn.o
Xbfd assertion fail /home/titanic/hjl/gnu/gas/binutils-2.5.2l.17/bfd/elfcode.h:4717 due to symbol: `fooo'. possible cause:
X	mismatched types in library and program.
Xbfd assertion fail /home/titanic/hjl/gnu/gas/binutils-2.5.2l.17/bfd/elf32-i386.c:625 due to symbol: `fooo'. possible cause:
X	mismatched types in library and program.
END_OF_FILE
if test 4649 -ne `wc -c <'log'`; then
    echo shar: \"'log'\" unpacked with wrong size!
fi
# end of 'log'
fi
echo shar: End of shell archive.
exit 0

Re: bfd assertion failed with gcc 950607

[Roland McGrath]

I am certain that your test case is a valid program and that the references
to `fooo' in junk.c should resolve to the common defn in fred.c rather than
to `_fooo' in foo.c.

So if that is what your patches accomplish, I would say they might be
right.  I don't think there is anyone available this month who really
understands ld well enough to be sure if that is the best way to fix it.

Re: bfd assertion failed with gcc 950607

[H.J. Lu]

> 
> I am certain that your test case is a valid program and that the references
> to `fooo' in junk.c should resolve to the common defn in fred.c rather than
> to `_fooo' in foo.c.

No. Solaris uses `_fooo' in foo.c. The GNU ld does the samething.
It just complains about it.

> 
> So if that is what your patches accomplish, I would say they might be

No, my patches only turn off the complaints.

> right.  I don't think there is anyone available this month who really
> understands ld well enough to be sure if that is the best way to fix it.
> 


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com

Re: bfd assertion failed with gcc 950607

[Roland McGrath]

> > 
> > I am certain that your test case is a valid program and that the references
> > to `fooo' in junk.c should resolve to the common defn in fred.c rather than
> > to `_fooo' in foo.c.
> 
> No. Solaris uses `_fooo' in foo.c. The GNU ld does the samething.
> It just complains about it.

That is contrary to the specification of the SVR4 ABI, page 4-27:
"Similarly, if a common symbol exists (i.e., a symbol whose st_shndx field
holds SHN_COMMON), the appearance of a weak symbol with the same name will
not cause an error.  The link editor honors the common definition and
ignores the weak ones."

Re: bfd assertion failed with gcc 950607

[H.J. Lu]

> 
> > > 
> > > I am certain that your test case is a valid program and that the references
> > > to `fooo' in junk.c should resolve to the common defn in fred.c rather than
> > > to `_fooo' in foo.c.
> > 
> > No. Solaris uses `_fooo' in foo.c. The GNU ld does the samething.

I take it back. The GNU ld does right thing. But it just complains
about. I don't have a right fix it. I don't want to hack the code.
Basically a common symbol is very tricky. Although the GNU ELF
linker handles it right, BFD_ASSERT in elf32-i386.c around
625 doesn't take it into account.

> > It just complains about it.
> 
> That is contrary to the specification of the SVR4 ABI, page 4-27:
> "Similarly, if a common symbol exists (i.e., a symbol whose st_shndx field
> holds SHN_COMMON), the appearance of a weak symbol with the same name will
> not cause an error.  The link editor honors the common definition and
> ignores the weak ones."
> 


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com

Re: bfd assertion failed with gcc 950607

[Ken Raeburn]

   Date: Wed, 14 Jun 1995 12:51:39 -0400
   From: Roland McGrath <roland@gnu.ai.mit.edu>

   > No. Solaris uses `_fooo' in foo.c. The GNU ld does the samething.
   > It just complains about it.

   That is contrary to the specification of the SVR4 ABI, page 4-27:
   "Similarly, if a common symbol exists (i.e., a symbol whose st_shndx field
   holds SHN_COMMON), the appearance of a weak symbol with the same name will
   not cause an error.  The link editor honors the common definition and
   ignores the weak ones."

The paragraph you quote starts with "When the link editor combines
several relocatable object files...."  So a shared library should be
treated like a random .o file, instead of like an archive library?
That seems counterintuitive.  Is a shared library really considered a
"relocatable object file"?

The ABI description doesn't seem all that clear to me, actually.  At
the start of chapter 4, it's described as a third type of object file,
distinct from relocatable files and executable files.

Re: bfd assertion failed with gcc 950607

[H.J. Lu]

> 
> 
>    Date: Wed, 14 Jun 1995 12:51:39 -0400
>    From: Roland McGrath <roland@gnu.ai.mit.edu>
> 
>    > No. Solaris uses `_fooo' in foo.c. The GNU ld does the samething.
>    > It just complains about it.
> 
>    That is contrary to the specification of the SVR4 ABI, page 4-27:
>    "Similarly, if a common symbol exists (i.e., a symbol whose st_shndx field
>    holds SHN_COMMON), the appearance of a weak symbol with the same name will
>    not cause an error.  The link editor honors the common definition and
>    ignores the weak ones."
> 
> The paragraph you quote starts with "When the link editor combines
> several relocatable object files...."  So a shared library should be
> treated like a random .o file, instead of like an archive library?
> That seems counterintuitive.  Is a shared library really considered a
> "relocatable object file"?
> 
> The ABI description doesn't seem all that clear to me, actually.  At
> the start of chapter 4, it's described as a third type of object file,
> distinct from relocatable files and executable files.
> 

The current GNU ELF ld does what was quoted by Roland from SVR4 ABI.
It honors the common symbol instead of the weak one in shared
libraries. BFD_ASSEET just complains something which ld can handle
but not expected by BFD_ASSEET.

-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com