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

Boehm, Hans 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 
> exclusion 
> > 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 
> http://permalink.gmane.org/gmane.comp.programming.garbage-coll
ection.boehmgc/2576).
> 
> 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.

Hans

> 
> Thanks,
> Ludo'.
> 
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> 


More information about the Gc mailing list