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

Boehm, Hans hans.boehm at hp.com
Tue Apr 28 18:20:42 PDT 2009


 

> -----Original Message-----
> From: Ludovic Courtès [mailto:ludo at gnu.org] 
> Sent: Tuesday, April 28, 2009 12:55 PM
> 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:
> 
> > 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?
Right.  This could be a problem.  But it also makes me suspicious that the kind of overlap checking in the current patch isn't very useful.  It only deals with very specific instances of the over lap problem.  And it handles the fact that the same GNU_RELRO segment will be handled repeatedly at every GC.  But that case could be handled more simply.
> 
> >> > 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.
I was afraid that's what you meant.

I assume GNU_RELRO sections can include const data, not just things like exception range tables?  Thus it's not implausible that a user would call GC_exclude_static_roots on something inside a GNU_RELRO section?  And it might often even be a good idea, since not all systems would put such things in a read-only segment.  And the same would hold for the C++0x declare_no_pointers() facility that will replace this.

Eventhough it seems a bit ugly to have two rather similar facilities, I'd still be inclined to just track GNU_RELRO calls in a separate array in dyn_load.c, and then process them when we see the corresponding LOAD section during the next GC.  Since the number of static root segments currently already has a static bound (MAX_ROOT_SETS), I don't think this would be terribly hard.  Again, I can try to generate the code if you're in a position to do some testing on the revised patch.

I think this would also make the patch orthogonal to my pending changes, which is good.

Hans

> 
> 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