This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: The bloat sweepstakes...


On Thu, Oct 11, 2001 at 04:03:09PM +1000, Fergus Henderson wrote:
[...]
> > I very much hope it doesn't scan rodata, because I
> > have Cunning Plans to reduce the text size considerably at the expense
> > of a somewhat larger rodata.  Note that much of rodata is strings.
> 
> What it scans is system-dependent.  It's determined by DATASTART and
> DATAEND in gcconfig.h.  On most systems, DATASTART seems to be defined
> as &_etext, and on the systems that I'm familiar with, &_etext generally
> precedes the rodata section.  (At least that is my understanding. 
> I could be wrong about that.  See below.)

Oh, I get it now.  I was thinking in terms of the way the operating
system maps the executable into memory, not the visible symbols
marking text/rodata/data boundaries.  It puts text and rodata in one
chunk mapped read-only, and data+bss+malloc heap in another chunk
mapped read-write.

One could in theory locate the lowest writable address by an algorithm
such as

   char *x = (char *) &symbol_known_to_be_in_data_segment;
   char c;
   x -= (x % PAGESIZE);
   do {
     x -= PAGESIZE;
     c = *x;
     *x = c;
   } while (!segmentation_fault);
   x += PAGESIZE;

This is obviously not necessary in a context where you know that
DATASTART really is the beginning of the writable data segment.  For
paranoia's sake it would be a good idea to distinguish between read
faults on "c = *x;" and write faults on "x = *c;"; the former mean
you've hit unmapped memory and therefore something has gone off the
rails (or the OS puts an unmapped guard page between text and data).

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]