Начало года у наших коллег из GCC, несмотря на перерывы на мероприятия, выдалось деятельное, и новостей довольно много.

Конкуренция GCC с LLVM однозначно пошла проекту (проектам) на пользу, о чем мы постоянно говорим. Например, мы уже рассказывали вам о работе наших соотечественников, которые реализовали offloading в GCC. Но также мы упомянули, что на самом деле основными проблемами является монолитность GCC (ну, там тоже не все так просто, но скажем так - "большая" монолитность по сравнению с LLVM) и непоощряющийся доступ к внутреннему представлению GCC. И вот, обе проблемы вновь широко обсуждаются.

Для начала, по наводке LWN, мы с интересом ознакомились с январской дискуссией о доступе к IR GCC в Emacs (это часть древнего треда в списке рассылки Emacs, но он настолько большой, что с трудом открывается в Firefox). Доступ к внутренностям GCC помог бы Emacs конкурировать с тяжелыми проприетарными IDE. Мы уж не будем в очередной раз упоминать тут GCC-XML, которому бы это тоже сильно облегчило жизнь.

К сожалению, надо признать, что RMS занял очень неконструктивную позицию - по всей видимости он все еще боится, что вендоры будут клепать проприетарные модули, оперирующие IR GCC, и предлагает искусственно "оглуплять" выхлоп GCC IR, чтоб его еще можно было загружать в Emacs для чего-нибудь полезного, но нельзя было использовать в проприетарных утилитах. Ему на это привели ряд возражений практического и теоретического плана, но, как и обычно бывает, религиозные воззрения всегда побеждают рациональные доводы. RMS готов терпеть отток студентов и аспирантов, переключающихся в научной деятельности на LLVM. Он готов страдать от падения интереса со стороны железячных вендоров, которые хотят быстро разрабатывать поддержку новых архитектур (например, OpenCL и Vulkan). Он безразличен к уходу больших домов (Apple), которым нужен больший контроль над процессом компиляции, чтоб делать свои IDE (Xcode) еще умнее. Он не видит в надвигающемся отставании Emacs от (полу)открытых и проприетарных тяжелых IDE большой проблемы. Ведь свобода лучше несвободы наличием свободы.

В принципе, чтоб ублажить старика, можно сесть и устроить мутное пип-шоу из внутренностей GCC, отсортировав то, что можно показывать, и то, что нельзя. К сожалению, таким унылым делом могут заниматься лишь религиозно мыслящие люди, т.к. инженерный подход к такому стриптизу сразу приведет к разумному предложению - раздеться сразу, чтоб сэкономить время вывалить все, как есть, а там пусть каждый смотрит на то, что нравится. Хорошо, предположим, что такие бедолаги найдутся, но проблема еще и в том, что IDE непрерывно развиваются и улучшаются, и с каждой итерацией им требуется больше обратной связи с инструментарием компиляторов, причем обменом сильно структурированными данными (грубо говоря, Unix-вэй и тут давно уже сдерживает развитие). Поэтому придется постоянно то открывать, то прикрывать отдельные куски IR. Вот, например, современный тулкит для компиляторов, LLVM, пишется инженерами, а не религиозными любителями трогать друг друга текстами через пайпы, и там структура, как говорят, сильно упрощает взаимодействие с ним из IDE, чего и добивается Apple (хотя популярная городская легенда говорит о том, что им просто не нравится GPL).

Вероятно, как и у многих других любителей Unix-вэя, у RMS горизонт видения ограничивается религиозными воззрениями, и про возможности, предоставляемые современными IDE он, если и слышал, то уж точно не пробовал. Теория без практики, увы, бесплодна. Тут практика подразумевается в живом обмене идеями, и проверке подходов, невзирая на личные предпочтения. В диалоге оказалось, что его потолок, это autocomplete. Когда ему сообщили о различных advanced фичах для сложных языков, таких, как С++, он перепугался и решил, что ему всерьез угрожают и требуют отказаться от его свободы.

К счастью, народ догадался нажать RMS на его известную мозоль - ему в лоб сказали, что своим упрямством он угрожает свободному ПО проигрышем по "feature parity" проприетарным продуктам. Конечно, так таскать уважаемых людей за бороду неэтично, но прогресс важнее.

Но каков изгиб истории! Человек, начавший разработку Free Software с того, что проприетарное ПО было ограничено, призывает к ограничению функциональности Free Software. Например, в феврале он выступил против включения поддержки LLDB в Emacs, назвав это "систематическими атаками на GNU". Новость тогда широко обсуждалась коллегами-аналитиками на OpenNET.ru.

Коллега-аналитик рационально оценивает высказывания RMS

Продолжим хорошими новостями. Инженер Red Hat, Pedro Alves начал работу по переводу GDB с C на C++, который лучше подходит для разработки столь сложного инструмента. А недавно вышла версия 7.9, в которой появилась поддержка интересной функциональности - инъекция произвольного C-кода (требуется GCC 5 или старше). Начата работа по расширению этого функционала инъекцией уже C++-кода.

Требование 5го GCC вполне реалистично. Fedora 22 выходит с GCC 5. Это изменение, как всегда, запустило полную пересборку всех пакетов - увлекательное занятие, зачастую пропускаемое другими дистрибутивами. Помимо технической проблемы с меняющимся ABI с каждой мажорной версией GCC, мы еще решаем социально-философскую задачу - ищем и исправляем пакеты, несовместимые с новыми функциями и проверками GCC. Это, как считают некоторые, самая важная задача. В этот раз интрига была закручена сильнее - ABI менялся радикально, т.к. того требовало соответствие стандарту C++-11, и в срок мы не успевали. После ожесточенных дискуссий, было решено пойти на компромисс - ABI будет почти как старый, но возможности будут от нового GCC. Подробнее об этом наши коллеги написали в статье про ABI.

После обнародования списка организаций-участников GSoC 2015, настало время и второго этапа. Завтра, 16 марта, открывается регистрация студентов, желающих поучаствовать. В проекте GCC появилось уже пара интересных идей. Первая идея пришла от анонима, и не факт, что он будет участвовать в ее реализации, но тем не менее - это добавление бэкенда для SPIR-V в GCC. Т.е. предлагается задуматься о перспективе писать шейдеры на любом языке, поддерживемом GCC. Описание, опять же, напоминает offloading для GCC. Вообще, идея писать код на одном языке, который потом будет собираться в нативный, и в один или несколько модулей для сопроцессоров, выглядит интересной. Технически это возможно, например, с помощью gccjit, о котором мы упоминали.

К сожалению, сейчас у gccjit есть существенное ограничение - он подразумевает, что хостовая архитектура совпадает с целевой (что не так, в случае трансляции кода в байткод для сопроцессора, например OpenCL, CUDA, Intel MIC и т.п.). Наш коллега, инженер Red Hat, David Malcolm, обещает, что к GCC 6 ситуация будет исправлена, и gccjit можно будет перенацелить на одну или несколько архитектур, отличающихся от хостовой, и тогда SPIR-V байткод или его "ассемблер" можно будет использовать в GCC. Пока отметим, что SPIR-V разрабатывается с помощью LLVM, за что спасибо RMS (см. выше).

Второе предложение пришло от студента, который, как видится со стороны, взялся за слишком большой вес. Он вызвался на задачу по модуляризации GCC, к которой из-за ее неподъемности и огромности не подступали и бывалые профессионалы. К его чести, он правильно оценил ее и попросил экспертов сузить область деятельности. Наши коллеги с радостью отозвались.

Конечно, модуляризация продукта, который специально делался немодульным, это непросто. Однако определенные части задачи вполне поддаются выполнению за срок до полугода. Например ...пабабабам! удобный доступ к GCC IR (см. драму в @emacs-devel по ссылкам выше). Понятно, что если жестко стандартизировать формат обмена между подсистемами GCC, сделать их самодостаточными и предоставить к ним доступ, то это откроет перспективы, которые RMS не снились в самых страшных его кошмарах. Если мыслить совсем уж научно-фантастически, то можно будет заменять куски GCC аналогами LLVM, и наоборот. Из совсем уж приземленных вещей, изоляция в пределах подсистемы позволила бы упростить разработку и отладку проекта, сделав сам проект более LLVM-подобным. Отладка GCC, это отдельная история, и мы все чаще и чаще вынуждены проводить аналогии с коротким одеялом - чуть потянешь за опции, и вылезают какие-то странные эффекты, особенно в не самых освещенных углах пакета, например в Ada-фронтэнде.

Ну и напоследок, наш коллега, Petr Machata, представляет написанную им утилиту для изучения DWARF-файлов - dwgrep. Выглядит очень полезной для разработчиков инструментария для разработчиков.