From: "David S. Miller" <davem@davemloft.net>
To: libc-hacker@sources.redhat.com
Subject: weird versioning crash...
Date: Wed, 29 Mar 2006 00:23:00 -0000 [thread overview]
Message-ID: <20060328.162324.107326686.davem@davemloft.net> (raw)
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!
next reply other threads:[~2006-03-29 0:23 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-29 0:23 David S. Miller [this message]
2006-03-29 1:46 ` David S. Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060328.162324.107326686.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=libc-hacker@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).