* weird versioning crash...
@ 2006-03-29 0:23 David S. Miller
2006-03-29 1:46 ` David S. Miller
0 siblings, 1 reply; 2+ messages in thread
From: David S. Miller @ 2006-03-29 0:23 UTC (permalink / raw)
To: libc-hacker
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!
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: weird versioning crash...
2006-03-29 0:23 weird versioning crash David S. Miller
@ 2006-03-29 1:46 ` David S. Miller
0 siblings, 0 replies; 2+ messages in thread
From: David S. Miller @ 2006-03-29 1:46 UTC (permalink / raw)
To: libc-hacker
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.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2006-03-29 1:46 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-03-29 0:23 weird versioning crash David S. Miller
2006-03-29 1:46 ` David S. Miller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).