[Gc] Re: [PATCH] Dealing with `.data.rel.ro'
hans.boehm at hp.com
Tue Apr 28 10:16:45 PDT 2009
> -----Original Message-----
> From: Ludovic Courtès [mailto:ludo at gnu.org]
> Sent: Tuesday, April 28, 2009 9:01 AM
> To: Boehm, Hans
> Cc: gc at napali.hpl.hp.com
> Subject: Re: [Gc] Re: [PATCH] Dealing with `.data.rel.ro'
> "Boehm, Hans" <hans.boehm at hp.com> writes:
> > My concern here is with the code in the newly added
> PT_GNU_RELRO case.
> > It seems to handle the case in which (start, end) overlaps a single
> > existing exclusion range. In that cases it just adds any additions.
> > It doesn't handle the cases in which
> > - it overlaps multiple such previously registered exclusion
> ranges, or
> > - the overlapping exclusion range is registered later with
> an explicit
> > call.
> I think that the caller has to protect against it anyway.
> > Is the only reason for the explicit test for overlap with a
> > range the fact that
> The reason is that GNU_RELRO segments are subsets of
> previously registered LOAD segments. See
> https://permalink.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/2576 .
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.
> > Another reason I'm worried is that I have pending code that
> > the exclusion range data structure with something more intelligent,
> > but which still insists on non-overlapping ranges.
> We can choose to wait until your changes are committed and
> update the patch then.
> > 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?
In the former case, doesn't it make more sense to just remember the segment (or even a bounded collection of them, if we need to in the future) in a statically allocated buffer, and check LOAD segments against that buffer? That dodges all the issues about overlap with client supplied exclusion ranges. And since it's independent of the exclusion range processing I can make an attempt at adapting your patch, but you're probably better qualified to test.
My inclination would be to initially write the code so that it tracks the largest GNU_RELRO segment, which should work great if there's only one, and act gracefully if somehow we see more.
More information about the Gc