Description of problem:

gcc 10.2 generates code that segfaults due to placing global const pointers in read-only memory area rather than read-write as previous compilers

Version-Release number of selected component (if applicable):

gcc (GCC) 10.2.1 20200723 (Red Hat 10.2.1-1)

How reproducible:

Compile program with a global const pointer prototype to be initialized later.

Additional info:

Here is the simplest program I could come up with to demonstrate the 
problem. I call the program "maptest.c" because I'm looking at where 
things get mapped to memory by looking in /proc/<pid>/maps and seeing 
what permissions each chunk of memory has and where it is located. Using 
the debugger I can tell where in that memory space my variables are located.

Here's the program:


/* A program to try and find where a SIGSEV error occurs as
  * part of the program DOSEMU
  */

# include <stdio.h>
# include <stdlib.h>

char * const lowmem_base;

int main(int argc, char **argv)

{

   void *addr = malloc(114112);

   *(char **)(&lowmem_base) = addr;

   printf("Hello World!\n");

   free(addr);
}

I could probably delete the Hello World! to make it even smaller but 
it's an experiment.

When I compile this with gcc like this:

$ gcc -g -Wall -o maptest maptest.c

I get an ELF executable called "maptest" with debug information as expected.

When I compile the program with gcc version 9.1.2 as found in Fedora 31, 
the programs runs and exits normally. Running in the debugger shows that 
the variable lowmem_base is located in a portion of the maptest space 
that is marked rw-p. Activating the disassembler in gdb shows that the 
value of addr is in a register and moves to the memory location of 
lowmem_base.

When I compile the program with gcc version 10.2.1 as found in Fedora 
32, the program runs and segfaults on the line:

   *(char **)(&lowmem_base) = addr;

Running in the debugger shows that the variable lowmem_base is located 
in a region of maptest marked as read only.

If I copy the binary from Feodra 31 to Fedora 32 it runs fine so I don't 
think it has anything to do with any of the shared libraries.

The equivalent of this program has been working since before 2012, so I 
think that there is a problem with gcc.

If I compile the program with clang, it functions as expected without a segfault.