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

Boehm, Hans hans.boehm at hp.com
Tue May 5 18:17:46 PDT 2009


Here's a patch, derived from yours.  I ended up doing things a bit differently, and just buffering LOAD segments.  This seems likely to both avoid quadratic behavior and keep the data structures simple.  I will also try to do some more testing.

Thanks.

(Probably MAX_LOAD_SEGS should just be MAX_ROOT_SETS, instead of multiplying by 3/4.  There aren't too many other sources of static root segments.  I'll fix that.)

Hans

> -----Original Message-----
> From: Ludovic Courtès [mailto:ludo at gnu.org] 
> Sent: Wednesday, April 29, 2009 1:08 AM
> To: Boehm, Hans
> Cc: gc at napali.hpl.hp.com
> Subject: Re: [Gc] Re: [PATCH] Dealing with `.data.rel.ro'
> 
> Hello,
> 
> "Boehm, Hans" <hans.boehm at hp.com> writes:
> 
> > I assume GNU_RELRO sections can include const data, not just things 
> > like exception range tables?
> 
> It typically contains relocatable read-only data, such as 
> constant pointers to global variables.  It may be that 
> exception tables fall into this category, I don't know.
> 
> > Thus it's not implausible that a user would call 
> > GC_exclude_static_roots on something inside a GNU_RELRO section?
> 
> Yes, although users could assume that `const'-qualified areas 
> are not scanned by default, regardless of whether they are 
> relocatable or not (I mean, an application writer doesn't 
> necessarily pay attention to 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.
> 
> Fine by me, especially since you know more about the 
> implications of such a change than I do.  I'll be happy to 
> test it when it's ready.
> 
> Thank you!
> 
> Ludo'.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dyn_load.c.diff
Type: application/octet-stream
Size: 4508 bytes
Desc: dyn_load.c.diff
Url : http://napali.hpl.hp.com/pipermail/gc/attachments/20090506/d177e112/dyn_load.c.obj


More information about the Gc mailing list