weird versioning crash...

weird versioning crash...

[David S. Miller]

I've been working on a cryptic problem with MONO on sparc,
and after finally getting a usable core dump I'm much closer
to tracking things down.

It crashes in do_lookup_x() while indexing into the map->l_versions[]
array.

This is /usr/bin/mono the dynamic linker is working on and the dynamic
symbol table is very small, the entry of interest is "_etext":

DYNAMIC SYMBOL TABLE:
00010830 g    D  *ABS*  00000000 ()           _etext
00010460 g    DF .init  00000000  Base        _init
00020a04 g    D  *ABS*  00000000  Base        __bss_start
000209c8      DF *UND*  00000198  GLIBC_2.0   __libc_start_main
00010800 g    DF .fini  00000000  Base        _fini
00000000  w   DF *UND*  0000010c  GLIBC_2.1.3 __cxa_finalize
00020a04 g    D  *ABS*  00000000  Base        _edata
00020a08 g    D  *ABS*  00000000  Base        _end
00010830 g    DO .rodata        00000004  Base        _IO_stdin_used
000209ec      DF *UND*  00001d68  VER_1       mono_main
00000000  w   D  *UND*  00000000              _Jv_RegisterClasses
00000000  w   D  *UND*  00000000              __gmon_start__

(Note the "()" version output.)

do_lookup_x() is working on "_etext" right here:

		  /* We can match the version information or use the
		     default one if it is not hidden.  */
		  ElfW(Half) ndx = verstab[symidx] & 0x7fff;
		  if ((map->l_versions[ndx].hash != version->hash
		       || strcmp (map->l_versions[ndx].name, version->name))
		      && (version->hidden || map->l_versions[ndx].hash
			  || (verstab[symidx] & 0x8000)))
		    /* It's not the version we want.  */
		    continue;

The "ndx" VERSYM entry for _etext is "0xa822", which is 0x2822 with
the "hidden" 0x8000 bit masked out.  That is way out of range.

Sometimes things work because something happens to be mapped at that
offset from the map->l_versions[] table.

What I can't figure out is if that bogus hidden _etext entry is there
due to a binutils bug, or perhaps bad arguments given to the link of
the mono binary at build time.  What could cause such a hidden
version entry to _etext to end up in a binary like that?

Thanks!

Re: weird versioning crash...

[David S. Miller]

From: "David S. Miller" <davem@davemloft.net>
Date: Tue, 28 Mar 2006 16:23:24 -0800 (PST)

> The "ndx" VERSYM entry for _etext is "0xa822", which is 0x2822 with
> the "hidden" 0x8000 bit masked out.  That is way out of range.
> 
> Sometimes things work because something happens to be mapped at that
> offset from the map->l_versions[] table.
> 
> What I can't figure out is if that bogus hidden _etext entry is there
> due to a binutils bug, or perhaps bad arguments given to the link of
> the mono binary at build time.  What could cause such a hidden
> version entry to _etext to end up in a binary like that?

It seems that this is caused by the verioning linker scripts that mono
uses.

First it links libmono.so with this:

VER_1 {
      global: 
              mono_*;
              GC_push_all_stack;
              GC_start_blocking;
              GC_end_blocking;
              gc_thread_vtable;
      local:
              *;
};

Then it links everything together, including libmono.so, into the
"mono" binary using this versioning linker script:

{
      global: 
              mono_*;
              GC_push_all_stack;
              GC_start_blocking;
              GC_end_blocking;
              gc_thread_vtable;
      local:
              *;
};

and that seems to be how we end up with that weird _etext versioning
entry above.