GC / GCJ / and binutils (ld)

[Andrew Haley <aph at redhat dot com>]

Peter Blemel writes:
 > 
 > Hello World,
 > 
 > Right now my GCJ port uses newlib's malloc (plus an sbrk that I've 
 > supplied).   Since garbage collection is a Good Thing (tm) I've been working 
 > with the boehm-gc port.   I've found a couple of issues.  I'll put the one 
 > that I care about most first :
 > 
 > The binutils elf ld script creates a symbol for the end of the data segment 
 > (_edata), and I'm currently configured to find the beginning of the data 
 > segment by walking backwards through VirtualQuery.  This seems to be 
 > something of a hack as it looks like this results in walking back until 
 > VirtualQuery returns 0.   In my RTOS I *think* that this means the code 
 > space winds up being added as a root (it is a windows-like 
 > Virtual{Query|Alloc|Free} but it's a limited subset).   It seems like this 
 > will just slow down GC.
 > 
 > It seems to me that it would be a lot easier if I simply changed the linker 
 > script to emit a symbol at the beginning of the data segment. This assumes 
 > that I know what I am doing (which I don't :-)  The linker script currently 
 > has
 > 
 >   /* We want the small data sections together, so single-instruction offsets
 >      can access them all, and initialized data all before uninitialized, so
 >      we can shorten the on-disk segment size.  */
 >   .sdata          : { *(.sdata) }
 >   _edata  =  .;
 >   PROVIDE (edata = .);
 >   PROVIDE (__edata = .);
 > 
 > Do I simply want to emit the _data symbol before the sdata?  I.e. :
 >   _data  =  .;
 >   PROVIDE (data = .);
 >   PROVIDE (__data = .);
 >   .sdata          : { *(.sdata) }
 >   _edata  =  .;
 >   PROVIDE (edata = .);
 >   PROVIDE (__edata = .);
 > 
 > so the data segment will be bounded by the _data and _edata symbols?

This sounds perfectly reasonable to me.  

Some GNU/Linux systems define __data_start in crt1.o.  Maybe your
crt1.o (or whatever it's called on your RTOS) defines something
similar.

Andrew.