[Gc] Re: [PATCH] Dealing with `.data.rel.ro'
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.
(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.)
> -----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'
> "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
> > 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!
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4508 bytes
Url : http://napali.hpl.hp.com/pipermail/gc/attachments/20090506/d177e112/dyn_load.c.obj
More information about the Gc