This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fix relro when COMMONPAGESIZE < MAXPAGESIZE


On Thu, Sep 09, 2004 at 02:35:17PM +0200, Andreas Schwab wrote:
> > When there is no COMMONPAGESIZE definition, that tells the linker
> > to not do any DATA_SEGMENT_* adjustements (as even without -z relro
> > they are disk space unfriendly; though without -z relro they may
> > waste just up to COMMONPAGESIZE bytes on the disk).
> 
> If COMMONPAGESIZE is equal to MAXPAGESIZE then DATA_SEGMENT_ALIGN is a
> no-op anyway.

It is not a no-op.
Depending on the size of the RW segment, it is either a no-op
(in which case RW segment starts at RO segment end + MAXPAGESIZE
virtual and immediately after RO segment in file), or moves the start
of RW segment to minimize memory requirements (and increase disk
size).

Consider:
test.c:
char bar[3096];
int foo (void)
{
}
gcc -m32 -shared -o test1.so test.c
gcc -m32 -shared -o test2.so test.c -Wl,-T,test.lds
# Where test.lds is gcc -m32 -shared linker script with
# DATA_SEGMENT_* stuff removed (as if COMMONPAGESIZE was not defined)
The former library has:
  LOAD           0x000000 0x00000000 0x00000000 0x00544 0x00544 R E 0x1000
  LOAD           0x001000 0x00001000 0x00001000 0x000f8 0x00d38 RW  0x1000
the latter:
  LOAD           0x000000 0x00000000 0x00000000 0x00544 0x00544 R E 0x1000
  LOAD           0x000544 0x00001544 0x00001544 0x000f8 0x00d34 RW  0x1000
where the former is 7044 bytes long and the latter only 4292.
But, the reason for DATA_SEGMENT_* is that the former library needs
2 4K pages of memory (one shareable, one non-shareable) while the latter
needs 3 4K pages (one shareable, two non-shareable).
If the RW segment size is such that there is no memory gain from adding
a gap (if RW segment size in this case % 4096 is <= 0xabc), then the gap
is not added and it acts as a no-op.

Now, can you look at your proposed relro patch and verify that it will
not cause bigger memory requirements (which at least for me are far worse
than bigger diskspace, as you need to multiply the additional writable
page by the number of processes that have the shared library mapped)?

	Jakub


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