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] | |
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.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |