Неожиданное разрешение exec от mmap, когда файлы сборки включены в проект

Я бьюсь головой об стену с этим.

В моем проекте, когда я выделяю память с помощью mmap, отображение (/proc/self/maps) показывает, что это читаемая и исполняемая область , несмотря на то, что я запрашивал только читаемую память.

После изучения strace (который выглядел хорошо) и другой отладки я смог определить единственное, что, по-видимому, позволяет избежать этой странной проблемы: удаление файлов сборки из проекта и оставление только чистого C. (что ?!)

Итак, вот мой странный пример: я работаю над Ubunbtu 19.04 и gcc по умолчанию.

Если вы компилируете целевой исполняемый файл с файлом ASM (который является пустым), то mmap возвращает читаемую и исполняемую область, если вы строите без нее, она ведет себя правильно. Смотрите вывод из /proc/self/maps, который я встроил в мой пример.

example.c

#include <stdio.h>
#include <string.h>
#include <sys/mman.h>

int main()
{
    void* p;
    p = mmap(NULL, 8192,PROT_READ,MAP_ANONYMOUS|MAP_PRIVATE,-1,0);

    {
        FILE *f;
        char line[512], s_search[17];
        snprintf(s_search,16,"%lx",(long)p);
        f = fopen("/proc/self/maps","r");
        while (fgets(line,512,f))
        {
            if (strstr(line,s_search)) fputs(line,stderr);
        }

        fclose(f);
    }

    return 0;
}

example.s : пустой файл!

Выходы

С ASM включена версия

VirtualBox:~/mechanics/build$ gcc example.c example.s -o example && ./example
7f78d6e08000-7f78d6e0a000 r-xp 00000000 00:00 0 

Без ASM включена версия

VirtualBox:~/mechanics/build$ gcc example.c -o example && ./example
7f1569296000-7f1569298000 r--p 00000000 00:00 0