to post messages and comments.

SEH_Init

On x86_64 windows exception mechanism is no more based on a chained list of handlers addresses on the stack. Instead unwinding information is used to retrieve the exception handler (similar to ZCX GCC mechanism). So in order to register an exception handler we need to put in the final executable some unwinding information. This information might be present statically in the image file inside the .pdata section or registered through RtlAddFunctionTable API. Currently the GCC toolchain does not generate the .pdata information for each function. As we don't need to handle SEH exceptions except for signal handling we are registering a "fake" unwinding data that associate a SEH exception handler to the complete .text section. As we never return from the handler, the system does not try to do the final unwinding using the pdata information. The unwinding is handled by the runtime using either the GNAT SJLJ mechanism or the ZCX GCC mechanism. The current implementation is using the RtlAddFunctionTable.

Here is for information purposes the equivalent using a static .pdata section: …

Теперь понятно, что имеет в виду @vt под «знает, как компилировать под Windows». Если считать Microsoft законодателем мод, то что-то в этом есть, хотя как по мне, — скорее вкусовщина. По-любому, без брандмауэров исключений никакой работы с COM не делается, так что какая разница, что внутри.

ld (или даже gcc) чёт охуел и не запихивает мой няшный глобальный void * volatile hui; в таблицу символов elf'а, так что его не видно из gdb, для чего он собственно и создавался. Чем его уебать?

В новом gcc появился -fsanitize, который заменяет пол валгринда и ловит датарейсы, use-after-freeи out-of-bounds доступы (в рантайме конечно). Вопрос, кто из гентушников в CFLAGS добавлял systemwide и как много сломается?

Сегодня смог продолжить разбираться с libipset ( #2826442 ). Из спортивного интереса попытался обойтись без C, заюзать GCC'шные фичи через доступ к фичам GCC из GNAT. Так вот, эта штука успешно заимпортировалась:
procedure VA_Start (Arg_Ptr : in out System.Address; Prev_Param : System.Address);
pragma Import (Intrinsic, VA_Start, "__builtin_va_start");

Однако, при попытке ею воспользоваться из адской процедуры получается error: 'va_start' used in function with fixed args. Пытался полечить, добавив функции GCC'шный аттрибут. Атрибуты в GNAT можно навешивать через pragma Machine_Attribute, а сам список атрибутов можно посмотреть здесь. Там всякая всячина, но вот заставить функцию быть varargs там нету. Так что я в печали. То немногое из C, что недоступно в GNAT, всё–таки добралось до меня. Можно попробовать найти не–built-in версию va_start, в Delphi прокатывало, либо подключать libffi, заодно и трамплин будет, чем сделать.

А можно Х-й Cmm преобразовать в Гццшный TREE? Ну, и дальше «по команде»: GIMPLE, RTL, асм. Из главных плюшек — LTO, конечно. Ну, может быть и оптимизаицй каких-нибудь перепадёт.

*пиздец Натолкнулся на доставляющую фичу бинутилза под PE/COFF. Что GCC, что GHC вставляют что-то типа .ident "Compiler Version" в генерируемые ассемблерные файлы. Для GCC это отключается по -fno-ident, для GHC — хрен знает.
Под ELF никаких проблем: создаётся секция .comment в объектнике, которая: а) не гузится в память; б) с флагом MERGE (дубли схлопываются при линковке). Т.е. в результате в исходном бинарнике получается секция с «подписями» всех компиляторов, когда-либо участвовавших в его создании. Удобно.
Для PE/COFF... Ну, вы поняли... В объектнике создаётся секция .rdata$zzz, которая мало того с флагами ALLOC и LOAD, так ещё дефолтный линк-скрипт аппендит её к .rdata бинарника. В результате, мусор в конце секции .rdata.
И если в 7.10.2 он занимал небольшое количество относительно размера бинарника, то в 7.10.3 со сменой тулчейна ситуация значительно ухудшилась.
Решение:
1. Подвергнуть живительному экстерминатусу секцию .rdata$zzz во всех объекниках и статических библиотеках strip --strip-unneeded --keep-file-symbols -R .rdata$zzz сделает своё дело. Увы, strip обламывается на HsBase из-за громадного размера, поэтому придётся вручную упаковывать/распаковывать.
2. Добавить строчку в линк-скрипт (перед .rdata) DISCARD : {*(rdata$zzz)}
Увы, хрен его знает как это сделать в GHC.
Гугл молчит, так что прошу распространить.
А вообще, эта «фича», мне кажется, может смело номинироваться на премию «Просос года». Даже боязно смотреть как обстоят дела с «официальными» сборками опенсорса под венду.

Можно ли считать компилятор GNU GCC свободным?
Конечно, нет.
Одно из первейших требований к свободному ПО это возможность собрать программу из доступных исходников.
Просто взять исходники и собрать GNU GCC нельзя (особенно, если речь идёт о сборке кросскомпилятора), понадобится шаманство и пляски с бубном, так что GNU GCC можно считать свободной программой лишь частично.

почему gcc такой жиробас?
[email protected]:~$ ls -lhS /usr/portage/distfiles/ | egrep 'llvm|clang'
-rw-rw-r-- 1 portage portage 16M May 8 00:10 llvm-3.4.1.src.tar.gz
-rw-rw-r-- 1 portage portage 226K Dec 28 11:46 clang-tools-extra-3.4.src.tar.gz
-rw-rw-r-- 1 portage portage 33K Jan 6 23:29 llvm-3.4-manpages.tar.bz2
[email protected]:~$ ls -lhS /usr/portage/distfiles/ | grep gcc
-rw-rw-r-- 1 portage portage 83M May 22 15:22 gcc-4.8.3.tar.bz2
-rw-rw-r-- 1 portage portage 20K Jun 16 06:06 gcc-4.8.3-patches-1.1.tar.bz2
-rw-rw-r-- 1 portage portage 13K Jun 2 03:05 gcc-4.8.3-piepatches-v0.5.9.tar.bz2
-rw-rw-r-- 1 portage portage 3.0K Jun 2 03:05 gcc-4.8.3-uclibc-patches-1.0.tar.bz2
-rw-rw-r-- 1 portage portage 2.0K Jun 18 2010 gcc-4.4.3-specs-0.2.0.tar.bz2

Как из программы узнать полный путь к ее запущенному исполняемому файлу? Цель: искать конфиг в одной директории с исполняемым файлом.

Фортрановскими процедурами GETARG, GET_COMMAND, GET_COMMAND_ARGUMENT можно узнать только, какая команда использовалась для ее запуска, т. е. без полного пути.
То есть, для запуска в набиралась команда "./a.out ",функция вернет "./a.out ", а если команда "a.out" , получишь "a.out".

Я подозреваю. что-то можно извлечь из переменных окружения (процедурами GETENV или GET_ENVIRONMENT_VARIABLE) или с использованием какой-то функции gcc для C++. но разобраться не получается.

Помогите. пожалуйста.

GCC

По умолчанию gcc, если видит одновременно и статическкую, и shared библиотеку, линкует программу с динамической.
Как можно задать принудительную линковку со статической?
Помогите, не разберусь в документации.

Эрик Реймонд пришёл в рассылку GCC через несколько лет после поялвения возможности писать плагины к GCC и потребовал от разработчиков создать интерфейс, позволяющий писать плагины? Гм. Окай.

Жуйк, а подскажи название заклинания. Задача такая: есть разделяемая библиотека A, которая при сборке статически линкуется с библиотекой B. При этом я вижу, что символы из B начинают экспортироваться в A. Хочется, чтобы 1) из A экспортировался единственный определенный мной символ 2) если это возможно, код для неиспользуемых символов удалялся.

Навеяно #2530271
Проблема линковки решается путем смены последовательности параметров
вот так не компилит
g++ -lyobalib yobabin.cpp
а вот так компилит
g++ yobabin.cpp -lyobalib
Все дело в том, что ld при линковке учитывает порядок аргументов и линкует объектники в том порадке, в котором указано, хотя почему при этом не находятся символы либы (ведь в обоих случаях символы уникальны) для меня все равно осталось загадкой.

gcc.gnu.org
да ну нахуй ! Как это реализовано вообще не понятно, либо это тупо лок переменных на время работы (то есть нифига не stm) толи там и правда транзакционное изменение без блокировок, но тогда как реализованы перезапуски транзакций ?