[Gc] Re: [PATCH] Dealing with `.data.rel.ro'

Ludovic Courtès ludo at gnu.org
Tue Apr 28 12:55:24 PDT 2009


"Boehm, Hans" <hans.boehm at hp.com> writes:

> I think we're miscommunicating here.  I understand that they're
> subsets of LOAD segments.  But load segments don't usually result in
> exclusion ranges.  As far as I know, other sources of exclusion ranges
> are:
>
> - The collector internally registers its owndata structures.  I don't
> think those are marked read-only, and hence shouldn't overlap with the
> range registered as a result of GNU_RELRO segments.
>
> - Client code may register its own data.  That's probably going to
> happen after the initial GNU_RELRO processing, and hence will probably
> fail anyway if there is any overlap.

Yes, and these sources of exclusion ranges may conflict with this
internal use.  That's what you meant, right?

>> > How many such GNU_RELRO segments do you expect?
>>  One, since there's essentially a one-to-one mapping between
>> .data.rel.ro' and `GNU_RELRO'.
> There's only one even if there are multiple dynamic libaries?  Or one
> per library?

Sorry, I meant one per library.

For example:

--8<---------------cut here---------------start------------->8---
#include <gc.h>
int main (int argc, char *argv[]) { GC_INIT (); return 0; }
--8<---------------cut here---------------end--------------->8---

For this program linked with libgc, which in turn is linked with
libphread, libdl, etc., `GC_register_dynlib_callback ()' gets to see 4
`GNU_RELRO' segments: 1 from libc, 1 from libpthread, 1 from libdl, and
another one from ld-linux.so.

So we really want libgc to remember not to scan any of these areas.

Thanks,
Ludo'.



More information about the Gc mailing list