[Gc] Dealing with `.data.rel.ro'

Boehm, Hans hans.boehm at hp.com
Tue Feb 3 12:05:41 PST 2009

I don't see the problem on my Itanium Linux box.  But maybe things are different enough there that the problem just doesn't show up with this example.  Or I'm running too old a tool chain?

The collector has two ways to identify dynamic library data regions.  Which one is used depends on the build flags.  (REDIRECT_MALLOC may affect this.)  Both should avoid tracing from non-writable sections, on the assumption that you couldn't have stored a legitimate pointer there.

The default method uses dl_iterate_phdr to walk the list of dynamic libraries.  The code starts at around line 380 in dyn_load.c.  It explicitly checks for writability, by looking at p_flags & PF_W.  That seems to work on my box, though I'm not sure I understand the meaning of those flags sufficiently to guarantee that this is intended to work for sections requiring relocation.

The other possible approach used by the collector is to look at /proc/self/maps.  But I believe that code also checks.  Since it's looking at the current mappings, it shouldn't be affected by relocation.

It would be good to verify that in your case the appropriate segment does eventually get mapped read-only.  Setting the GC_PRINT_ADDRESS_MAP emvironment variable should tell you, or you can put in a sleep() call and explicitly look at /proc.  If it is mapped ro, but the PF_W bit is set in the section header, then we would probably need to refine that test.


> -----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: Sunday, February 01, 2009 1:28 PM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] Dealing with `.data.rel.ro'
> Hello,
> I was wondering whether GC was able to somehow be aware of 
> `.data.rel.ro' sections on GNU systems [0], or whether it was 
> able to unregister the corresponding memory region when the 
> loader mprotects them.  A quick look at `os_dep.c' suggests 
> that GC isn't able to deal with this, is that right?
> The following example seems to suggest that even the 
> `.rodata' section of a library is registered as a static 
> root.  Suppose the following
> program:
>   #include <gc/gc.h>
>   #include <stdio.h>
>   extern const char *const my_const_data[];
>   int
>   main (int argc, char *argv[])
>   {
>     GC_INIT ();
>     GC_gcollect ();
>     GC_dump ();
>     printf ("%p--%p\n", my_const_data, &my_const_data[1000000]);
>     return 0;
>   }
> Suppose this program is linked with `libfoo.so' (compiled 
> with "-shared -fPIC"), which contains this:
>   const char *const my_const_data[1000000] = { 0 };  /* in 
> `.rodata' */
> Looking at the output of `GC_dump ()', it appears that the 
> region containing `my_const_data' is indeed registered as a 
> static root.  Am I missing something?
> Thanks,
> Ludo'.
> [0] https://www.airs.com/blog/archives/189
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/

More information about the Gc mailing list