Hi!

On Sat, 30 Jan 2016, Alexey Tourbin wrote:

> Мужчина пишет:
>> Вот продолжение -- промежуточный этап (пока не очень полезный)
>> создания переписывателя GNU C extensions.
>>
>> На этом этапе он должен ставить вложенные функции на верхний уровень
>> (без какой-либо проверки и переписывания параметров и т.п.; но с точки
>> зрения внутреннего устройства это приближает к реализации цели).
>
> Мужчина, меня заинтересовало ваше письмо.

Если что, сохраняю коммиты на эту тему в 
http://hub.darcs.net/imz/language-c_WIP ; приветствую предложения и 
вопросы.

>> Как я писал, по сложности переписывания их можно классифицировать на:
>> 1. pure (придумалось короткое понятное слово для их обозначения),
>> 2. read-only
>> 3. и read-write.
>
> Мужчина, а какая вам разница, read-only вложенные функции или read-write?
> Если они не дай бог read-write, то вы что тогда, свечку будете держать?
> На самом самом деле в общем случае, как мне представляется, никакой разницы нет.

Да, так. Специально задачу различения одних от других я не ставлю. Речь 
шла просто о том, что в один момент я выложу код переписывателя, который 
будет давать корректный результат переписывания для read-only вложенных 
функций, и его успешную работу по сборке пакета компилятором, не умеющим 
GNU C extensions, можно будет продемонстрировать, если там в C-коде только 
такие функции. А добавление реализации "переименования" переменных, точнее 
замены переменных на указатели (как v1 на (*v1) в процитированном примере 
ниже), займёт ещё некоторое время (ну не очень долго, конечно). В это 
время встраиванием переписывателя в инструменты сборки и отлаживанием этой 
схемы можно заниматься параллельно; и даже получать корректный результат, 
если функции были read-only или pure (на ещё более раннем этапе).

Речь шла во многом о планировании поэтапном этой работы и обвязки этого 
всего и демонстрации, а не о принципиальном различии этих классов 
вложенных функций для наших целей.

Да, а принципиальное различие есть между случаями, которые Алексей 
описывает дальше. (Мы, когда это обсуждали сначала, это так же понимали, а 
в письма, возможно, явное обсуждение этого не попало, хотя нужно это знать 
для понимания общей картины.)

> 1) Итак, рассмотрим общий случай разворачивания вложенной функции.
> Пусть имеется код вида
>
> void outer(T1 v1)
> {
>    T2 v2;
>    ...
>    void inner(T1 a1, T2 a2) {
>        // uses a1, a2
>        // references v1, v2
>    }
>    ...
>    inner(a1, a2);
>    ...
> }
>
> Тогда в первом и достаточно хорошем приближении преобразование состоит
> в следующем: функция inner разворачивается во внешнюю функцию outer_inner
> с прототипом
> void outer_inner(T1 a1, T2 a2, T1 *v1, T2 *v2);
> а вхождения v1 и v2 в этой функции заменяются на (*v1) и (*v2).
>
> Соответственно, вызов функции
> inner(a1, a2);
> заменяется на
> outer_inner(a1, a2, &v1, &v2);
>
> 2) Но есть еще один важный случай - когда берется указатель на inner.
> Рассмотрим вот такой boilerplate:
>
> void sort_objects(Ctx *ctx, Object **objects, size_t n)
> {
>    int cmp(Object *o1, Object *o2) {
>        // compares o1, o2
>        // references ctx
>    }
>    qsort(objects, n, cmp);
> }
>
> Мужчина, вы понимаете, что такое указатель на функцию в языке Си?
> Указатель на функцию - ну это такая штука, которую можно вызвать
> с помощью C calling conventions, передав ей аргументы. Функция cmp в
> этом смысле нормальной не является, потому что кроме аргументов
> она еще сует нос в чужой стек фрейм. Чтобы взять ее адрес, gcc делает
> трамполайн. Трамполайн - это такая обертка, которая прямо перед вызовом
> ненормальной функции показывает, куда ей надо совать свой нос.
>
> В общем, кажется, не существует хорошего способа развернуть такой код
> на стадии компиляции (в отличие от трамполайнов, которые работают в рантайме).
> Если только сделать переменную ctx глобальной, но это будет
> нереентерабельно и т.п.

Да, пока хороших идей по 2) нет -- как хорошо развернуть такой код на 
этапе компиляции. Если будут у кого-нибудь продуманные предложения, 
интересно их узнать.

Пока задачи решать 2) у нас нет, потому что мы хотим продвинуться в том, 
чтобы уметь собирать не-GCC те пакеты, которые в Sisyphus успешно 
собираются. А trampolines и executable stack в Sisyphus не пропускаются -- 
glebfm@ рассказывал:

rpm:

* Пт мар 20 2015 Gleb F-Malinovskiy <glebfm@altlinux.org> 4.0.4-alt100.82
- platform.in: removed -Wtrampolines from %optflags_warnings (enabled
   by default in gcc >= 4.9.2-alt3).

* Вт янв 27 2015 Dmitry V. Levin <ldv@altlinux.org> 4.0.4-alt100.80
- verify-elf: resurrected verify_stack.

(Это про проверку на executable stack --
http://git.altlinux.org/people/ldv/packages/?p=rpm.git;a=commitdiff;h=a44f6ae5236165536f2be05bc9fea8cfc3030d94 
)

gcc:

* Ср мар 18 2015 Gleb F-Malinovskiy <glebfm@altlinux.org> 4.9.2-alt3
- Turned on -Wtrampolines by default.

Best regards,
Ivan