[devel] re-writing GNU C extensions

[devel] re-writing GNU C extensions

[Alexey Tourbin]

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

Мужчина, меня заинтересовало ваше письмо.

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

Мужчина, а какая вам разница, read-only вложенные функции или read-write?
Если они не дай бог read-write, то вы что тогда, свечку будете держать?
На самом самом деле в общем случае, как мне представляется, никакой разницы нет.

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 глобальной, но это будет
нереентерабельно и т.п.

Re: [devel] re-writing GNU C extensions

[Kirill A. Shutemov]

On Sat, Jan 30, 2016 at 09:56:04AM +0300, Alexey Tourbin wrote:
> В общем, кажется, не существует хорошего способа развернуть такой код
> на стадии компиляции (в отличие от трамполайнов, которые работают в рантайме).
> Если только сделать переменную ctx глобальной, но это будет
> нереентерабельно и т.п.

qsort_r() и компания решают. И, да, это гнушное расширение.

-- 
 Kirill A. Shutemov

Re: [devel] re-writing GNU C extensions

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 7629 bytes --]

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

Re: [devel] re-writing GNU C extensions

[Alexey Tourbin]

2016-01-30 23:20 GMT+03:00 Ivan Zakharyaschev <imz@altlinux.org>:
> Речь шла во многом о планировании поэтапном этой работы и обвязки этого
> всего и демонстрации, а не о принципиальном различии этих классов вложенных
> функций для наших целей.

Мужчина, прежде чем переходить к поэтапному планированию, вы должны были
убедиться в принципиальной осуществимости сабжа, rewritng GNU C extensions.
Я вам доказываю, что сабж в принципе неосуществим в достаточно широком
классе случаев.
Так, техника трамполайнов неосуществима на стадии компиляции. Поэтому
вы не сможете
избавиться от всех вложенных функций, даже если вы вскоре разберётесь
с механикой
редактирования AST в language-c.

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

Мужчина, то есть вы хотите получать деньги за свою работу, которая,
как заранее известно,
ни к чему не ведет, кроме обмена умными высказываниями. Сматывайте удочки.

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

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

Re: [devel] re-writing GNU C extensions

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 3983 bytes --]

On Sun, 31 Jan 2016, Alexey Tourbin wrote:

> Мужчина, прежде чем переходить к поэтапному планированию, вы должны были
> убедиться в принципиальной осуществимости сабжа, rewritng GNU C extensions.

Сужение задачи до кода, где не берутся указатели на вложенные функции, 
было понятно сразу. Проверил -- в сообщениях в devel такое уточнение не 
прозвучало, что неправильно, конечно; теперь исправлено, хоть и 
"напоследок".

> Я вам доказываю, что сабж в принципе неосуществим в достаточно широком
> классе случаев.
> Так, техника трамполайнов неосуществима на стадии компиляции. Поэтому

Хорошо.

> вы не сможете
> избавиться от всех вложенных функций, даже если вы вскоре разберётесь
> с механикой
> редактирования AST в language-c.

Если порассуждать теоретически пока на эту тему: даже с задачей в общей 
постановке какой-то путь можно увидеть, учитывая, что мы имеем дело с 
репозиторием open-source проектов. Где-то уже имеется упомянутый Кириллом 
вариант функции вроде qsort_r; где нет (но нужно, потому что в функцию 
передали указатель на вложенную функцию где-то, где её использовали) -- 
можно механически породить такой вариант на C. Осуществимо, но анализ 
нельзя ограничить одним C translation unit или даже пакетом.

Я это пишу не ради спора, с тем, что:

> Так, техника трамполайнов неосуществима на стадии компиляции. Поэтому

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

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

Сборка Sisyphus на платформах без GCC.

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

Best reagrds,
Ivan

Re: [devel] re-writing GNU C extensions

[Hihin Ruslan]

[-- Attachment #1: Type: text/plain, Size: 423 bytes --]

Здравствуйте Ivan Zakharyaschev
  В сообщении от 31 января 2016 Ivan Zakharyaschev написал(a):
> Сборка Sisyphus на платформах без GCC.

Не нравится мне такая цель :)

-- 
  А ещё говорят так  (fortune):
 
Quantum Mechanics is a lovely introduction to Hilbert Spaces! -- 
Overheard at last year's Archimedeans' Garden Party 
________________________________________________________________________
С уважением Хихин Руслан

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] re-writing GNU C extensions

[Sergey Y. Afonin]

On Sunday 31 January 2016, Hihin Ruslan wrote:

> > Сборка Sisyphus на платформах без GCC.
> 
> Не нравится мне такая цель :)
 
А вариантов не много. Речь, очевидно, про Эльбрус.

-- 
С уважением, Сергей Афонин

Re: [devel] re-writing GNU C extensions

[Aleksey Novodvorsky]

31 января 2016 г., 16:15 пользователь Sergey Y. Afonin
<asy@altlinux.ru> написал:
> On Sunday 31 January 2016, Hihin Ruslan wrote:
>
>> > Сборка Sisyphus на платформах без GCC.
>>
>> Не нравится мне такая цель :)
>
> А вариантов не много. Речь, очевидно, про Эльбрус.

Да, мы экспериментируем с Эльбрусом. Проблема с nested function,
впрочем, есть не только у используемого там закрытого фронтенда от
Edison, но, например, у Clang. legion@ указал на проблему, --
обеспечивать жизненный цикл системы, поддерживая гигантские патчи
пакетов GNU,  сложно, мягко говоря. imz@ пробует найти иные подходы к
решению.

Rgrds, Алексей

Re: [devel] re-writing GNU C extensions

[Alexey Gladkov]

On Sun, Jan 31, 2016 at 02:28:58AM +0300, Ivan Zakharyaschev wrote:
> Сборка Sisyphus на платформах без GCC.

Проекты, которые используют GNU C extensions вряд ли будут от них
отказываться. Некоторые проекты используют их потому что они сами GNU.

Как вы планируете поддерживать патчи, когда и если они будут получены ?

-- 
Rgrds, legion

Re: [devel] re-writing GNU C extensions

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 959 bytes --]

Hi!

On Sun, 31 Jan 2016, Alexey Gladkov wrote:

> On Sun, Jan 31, 2016 at 02:28:58AM +0300, Ivan Zakharyaschev wrote:
>> Сборка Sisyphus на платформах без GCC.
>
> Проекты, которые используют GNU C extensions вряд ли будут от них
> отказываться. Некоторые проекты используют их потому что они сами GNU.
>
> Как вы планируете поддерживать патчи, когда и если они будут получены ?

Как раз важная часть задумки -- что патчей (по крайней мере на эту тему) 
не будет.

Я тут думал так же, как legion@. Отношусь к идее людям переписывать 
программы с языка (чуть) более высокого уровня на язык более низкого 
уровня (без GNU C extensions) и поддерживать такие патчи плохо.

Отразил это в названии: c uglify. Но здесь работа по обезображиванию кода 
будет выполняться автоматом, а не человеком, каждый раз при сборке пакета, 
незаметно, с сохранением задуманной программистом и мейнтейнером 
семантики конструкций языка и опций компилятора.

-- 
Best regards,
Ivan