Re: Question about elf data segment address adjustment

[Alan Modra <amodra at gmail dot com>]

On Thu, Oct 19, 2017 at 12:11:27PM +0200, Douglas B Rupp wrote:
> On 10/19/2017 11:44 AM, Nick Clifton wrote:
> >Hi Douglas,
> >
> >>In ld/scripttempl/elf.sc about line 562 there's a comment that pre-dates the 1999 sourceware import, so I can't track it down.

The history is there, but when the older repo was stitched in it seems
some trouble was encountered.   Here's what you do when you run into
^252b513 in "git blame" output.

Type "git log" and search for 252b513.  Skip over all the "import",
"generated by cvs2svn", and "Initial creation" commits until you reach
a normal commit.  That happens to be
commit 1730ec6b1848f0f32154277f788fb29f88d8475b
Author: Mark Alexander <marka@cygnus>
Date:   Mon Feb 15 02:23:56 1999 +0000

Now run "git blame 1730ec6b1 <file of interest>"

> I can post a powerpc-vxworks7 example, but the same problem can be seen
> looking at a map file on x86-64-linux.  The intent of this enhancement of
> 1996 seems to have been lost somewhere along they way.
> 
> A trivial "C" program:
> --------------
> $ cat foo3.c
> #include <stdio.h>
> 
> extern int my_global;
> 
> void
> main ()
> {
>   printf ("%d\n", my_global);
> }
> ----------------
> $ cat bar3.c
> int my_global = 0;
> ----------------
> $ gcc -c foo3.c
> $ gcc -c bar3.c
> $ gcc -o foo3 foo3.o bar3.o -Wl,-M >foo3.map
> 
> Shows that there's a huge chunk of wasted space if I'm understanding the map
> file correctly.  Note the gap between .eh_frame and .exception_ranges
> 
> ....
> 
>  .eh_frame      0x0000000000400700        0x4
> /usr/lib/gcc/x86_64-linux-gnu/5/crtend.o
>  *(.eh_frame.*)
> 
> .gcc_except_table
>  *(.gcc_except_table .gcc_except_table.*)
> 
> .gnu_extab
>  *(.gnu_extab*)
> 
> .exception_ranges
>  *(.exception_ranges .exception_ranges*)
>                 0x0000000000600e10                . = DATA_SEGMENT_ALIGN
> (0x200000, 0x1000)
> 
> ....

This is almost certainly due to your compiler passing -z relro by
default to the linker, or the linker being configured for -z relro by
default.  In many binaries you pay a size penalty for the extra
security, because for -z relro to work properly the transition from
the relro area to read/write must occur on a page boundary.  This
constrains the start of the relro area, "wasting" some memory and disk
space (if the start of a segment is on the same disk page offset but
next page up from the end of the previous segment, then the two
segments can be adjacent on disk).

Note also that powerpc moved to a common-page-size of 0x10000 because
powerpc64 linux kernels are often built supporting that page size, and
if the system page size is larger than common-page-size then relro
binaries run but don't have the relro protection over the entire relro
area..

See also ld/NEWS for 2.27.

-- 
Alan Modra
Australia Development Lab, IBM