Search code examples
clinuxld

Why does my static variable get dis-aligned on running?


I'm writing tests for code to handle memory on powers-of-two boundaries, and I needed a 1MB block of memory on a 1MB boundary for the tests. The code worked for small blocks, but not big ones. Eventually, I worked out it was because my supposedly aligned data was not aligned to a 1MB boundary.

(I can work around this, obviously, but I want to know what's going on.)

This code compiles without warnings, objdump says the variable is at a reasonable address, but when I run it, it's aligned on a 4K boundary, not 1M.

cat x.c ; gcc --version ; uname -a ; gcc -Wall x.c && ( objdump -x a.out | grep test_data  ; ./a.out )
#include <stdio.h>
#include <string.h>
#include <stdlib.h>

struct data {
  char memory[1024*1024];
};

static struct data __attribute__(( aligned( 0x100000 ) )) test_data = { 0 };

int main( int argc, const char **argv )
{
  printf( "test_data is actually here: %p\n", &test_data );
  return 0;
}


gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Linux Lubuntutu 4.15.0-72-generic #81-Ubuntu SMP Tue Nov 26 12:20:02 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
0000000000400000 l     O .bss   0000000000100000              test_data
test_data is actually here: 0x5600cb9fe000

Running under gdb is interesting:

Reading symbols from ./a.out...done.
(gdb) display &test_data
1: &test_data = (struct data *) 0x400000 <test_data>
(gdb) start
Temporary breakpoint 1 at 0x659: file x.c, line 13.
Starting program: /tmp/a.out 

Temporary breakpoint 1, main (argc=1, argv=0x7fffffffe038) at x.c:13
13    printf( "test_data is actually here: %p\n", &test_data );
1: &test_data = (struct data *) 0x555555954000 <test_data>
(gdb) print &test_data.memory[16]
$1 = 0x555555954010 <test_data+16> ""
(gdb) c
Continuing.
test_data is actually here: 0x555555954000

Solution

  • This is a loader, or possibly security module, feature.

    The code has been moved in memory by a similar amount, presumably as part of address-space layout randomisation, but it is by a random number of 4k pages, which will break any coarser alignment requested by programs.

    Linking the program statically stops that from happening, at least at the moment.