This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

None


Ian Lance Taylor wrote:
> Ian Dall <ian@beware.dropbear.id.au> writes:
> 
> > What happens is that "glob" is a common symbol after assembling, but
> > it causes glob.o to be loaded from libc.a, and then it gets resolved
> > to an address in the text segment and a core dump results when it is
> > assigned to.
> > 
> > Is this behaviour correct? It seems to be as documented except that I
> > think archives should probably only be searched to resolve undefined
> > variables, not common variables.
> 
> That is how archives normally work, although perhaps there is a bug in
> this target.  Use the -M option to confirm that nothing else is
> causing glob to be pulled in from libc.a.

It turns out that this is specific to a.out. I know a.out is no longer
widely used, but still it would be good if this were fixed. In aoutx.h
(aout_link_check_ar_symbols) there is a comment

/* [...] If this object
   file defines a common symbol, then we may adjust the size of the
   known symbol but we do not include the object file in the link
   (unless there is some other reason to include it).  */

and yet this is later contradicted:

	  /* This object file defines this symbol.  We must link it
	     in.  This is true regardless of whether the current
	     definition of the symbol is undefined or common.  [...]

	     FIXME: The SunOS 4.1.3 linker will pull in the archive
	     element if the symbol is defined in the .data section,
	     but not if it is defined in the .text section.  That
	     seems a bit crazy to me, and I haven't implemented it.
	     However, it might be correct.  */

I think current code is clearly wrong. It pollutes the name space for
user programs.  It causes the gcc test suite to fail in a number of
places, but specifically gcc.c-torture/execute/960218-1.c.

There are two possible strategies:
  a) never pull in archive modules to satisfy common symbols
  b) never consider archive *text* symbols to satisfy common symbols.

The weaker change is b) and has the least chance of breaking existing code.
The a) alternative doesn't not allow the case where

	     have already seen an object file including
	         int a;
	     and this object file from the archive includes
	         int a = 5;

to work.

Despite b) being weaker, I cannot think of any case where a) does the right thing, but
b) doesn't.

Both alternatives cause a problem if anyone expects the following to
cause an archive member to be included:

archive
    const int a = 5;  /* Assume compiler uses .text segment for this */

this object file:

   const int a;

Even even then the archive could be pulled in if there is some other reason to do so.
I think this is a minor price to pay.

I propose the following change. First the ChangeLog entry:

2002-07-22  Ian Dall  <ian@sibyl.beware.dropbear.id.au>

	* aoutx.h (aout_link_check_ar_symbols): Avoid including archive members to
	match common symbols with .text segment symbols.

then the patch:

RCS file: /cvs/src/src/bfd/aoutx.h,v
retrieving revision 1.30
diff -c -r1.30 aoutx.h
*** aoutx.h	25 Jun 2002 06:21:47 -0000	1.30
--- aoutx.h	21 Jul 2002 14:40:31 -0000
***************
*** 3232,3242 ****
  	         int a = 5;
  	     In such a case we must include this object file.
  
! 	     FIXME: The SunOS 4.1.3 linker will pull in the archive
! 	     element if the symbol is defined in the .data section,
! 	     but not if it is defined in the .text section.  That
! 	     seems a bit crazy to me, and I haven't implemented it.
! 	     However, it might be correct.  */
  	  if (! (*info->callbacks->add_archive_element) (info, abfd, name))
  	    return false;
  	  *pneeded = true;
--- 3232,3241 ----
  	         int a = 5;
  	     In such a case we must include this object file.
  
! 	     Avoid including this object file to match common symbols with
!              symbols defined in the .text segment. */
! 	  if (h->type == bfd_link_hash_common && type != (N_DATA | N_EXT))
! 	    continue;
  	  if (! (*info->callbacks->add_archive_element) (info, abfd, name))
  	    return false;
  	  *pneeded = true;


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]