[Gc] Re: [PATCH] Dealing with `.data.rel.ro'
hans.boehm at hp.com
Fri Apr 24 17:43:30 PDT 2009
Sorry about the very slow reply.
> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Ludovic Courtès
> Sent: Tuesday, March 03, 2009 2:38 PM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] Re: [PATCH] Dealing with `.data.rel.ro'
> Hi Hans,
> "Boehm, Hans" <hans.boehm at hp.com> writes:
> > Did you encounter problems without the overlap checking for
> > ranges?
> Yes. As mentioned in the comment added by the patch, the
> address range covered by the `PT_GNU_RELRO' entry is a subset
> of a previously encountered `LOAD' segment, so it needs to be
> excluded. It's easy to notice with readelf(1) (see
> We could add a test here that would build a shared library
> with "-z relro" when using GNU ld. We could arrange so that
> this test is only run on GNU systems.
> > 1) I think this only handles a partial overlap with exactly
> one other
> > range. I don't immediately see why it's more important to
> handle that
> > case than overlaps withmultiple existing exclusion ranges.
> Exclusion ranges cannot overlap. This is enforced in
> `GC_exclude_static_roots ()'.
> > 2) This only works if the ranges are added in the right order.
> Hmm, what do you mean?
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.
Is the only reason for the explicit test for overlap with a previous range the fact that this will get called on every GC, but I really only want to do this the first time? Thus if I find anoverlapping exclusion range, it's the one I registered last time around, possibly merged with some others? This if any part of it is already there, I don't have to do anything this time?
If so, I'd like to simplify the code, and state that in a comment. If you are really seeing overlap with an unrelated exclusion range, I'm worried about the other cases above.
Another reason I'm worried is that I have pending code that replaces the exclusion range data structure with something more intelligent, but which still insists on non-overlapping ranges.
How many such GNU_RELRO segments do you expect? Since I believe this gets called on every GC in order to catch newly loaded libraries, an alternate plan might be just to remember these in a local data structure, and look at that when processing future LOAD segments. That way you'd accidentally scan them the first time around, but that's probably no big deal.
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc