This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: vi and glibc 2.12: Assertion `_rtld_global_ro._dl_pagesize != 0


On Wed, Aug 18, 2010 at 1:31 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Tue, Aug 17, 2010 at 10:36 PM, Mike Frysinger wrote:
>> i'm certainly not familiar with glibc's ldso implementation due to
>> it's crazy large & complicated code base, but i imagine this could be
>> resolved best by having the ldso declare an initializer that calls the
>> same functions as the ldso does when bootstrapping a normal
>> application (_dl_sysdep_start/etc...). ?this is because the nss libs
>> are dlopened like any other ELF, and it tails into libc.so which tails
>> into the ldso. ?there is no special code that i can see that goes
>> "this is the ldso, do xxx specially" which makes perfect sense. ?only
>> outstanding issue there would be whether the ldso will process its own
>> initializers when bootstrapping a standard application.
>>
>> we could back out the assert in __getpagesize(), but that would only
>> "fix" things until the next time someone adds code which relies on
>> initialized GLRO() state.
>
> after some experimenting, i guess the init method isnt feasible. ?as
> the GLRO() name indicates, the struct is backed by read-only mappings,
> and the ELF processing has already set up all the mappings with proper
> permissions per the program headers by the time it calls any
> initializers for that ELF. ?temporarily remapping itself isnt feasible
> as some kernels prevent re-enabling write access to a read/execute
> only mapping.

Does DL_STATIC_INIT solve the problem?

See dl-static.c as implemented by ia64 and mips.

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]