This is the mail archive of the libc-hacker@sourceware.org mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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!
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |