From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DNS_FROM_AHBL_RHSBL,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_PASS,T_FREEMAIL_FORGED_FROMDOMAIN, T_HEADER_FROM_DIFFERENT_DOMAINS autolearn=no autolearn_force=no version=3.4.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version:content-type; bh=UHBZcI2JVjYXdRF45sQL098fVvvqE77ZiCbNHxsUGS0=; b=KDra+zQGuWD+SeQ3g1YTyxW7HMl9Y/Fd4iO/nRS3fgPMIjh59M1UBHvWaTngztO8Zc l8c20/N1dMAUUHoPQcQNaLS6dHG6sa9rJ7vzFS/65ra5/SLSEXtHeKE/Z5U3M1do14Si iFMW7dg5cMOdfMGnSXu2eYwYcXLAAtS4oVA29NkELPC/v/pwL0YBtLYedcdesrjWRGPY JuI65mksOhuGnShK5qU5pv1F1ZrMYMnwZ/w5C0iLgIvyYjPe+fTIlaFYQ65B4YSqVFbq RIkEXBs0zNniFA1m/8wYiYKqq8emo8IsVM3rbUTV64apDoKBcLEhgiS75Upbz9/Woa+7 6zAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:in-reply-to :message-id:references:user-agent:mime-version:content-type; bh=UHBZcI2JVjYXdRF45sQL098fVvvqE77ZiCbNHxsUGS0=; b=H3Espf3lgJDtcqkghmwIdTLW1asHIpEPmF5dXx3bggMUYgGKBcwBPWDnbU6nZOXI3+ EYc5ASfimncuMoFiDT/qXPdPGw4a+VKjyEISAk2YCuvIhOknBBDioYpFRIVqAujI71yP cSoqayvB55R6iVaNYRtrJCo2S/bQWy6HXxSL//ajOO8d1c5uQzdw6IJaz9Vb/yuifB4X DwCnNcs7QchYtQlnJvSEpMUps7hU3HSDyDQmhljv7KzBWt3iwNqXLZ+QPPz61AipIbyS I2EIPLlKw2Z5yG9xwoioAd1O+C+WJ3xcVNUSczZGchOzlNlKbbk0hEsyEJzkwRYCAQjW 8ptw== X-Gm-Message-State: AG10YORa0rkFRVvmXiOR+Kd0Q2X05ikcio5Nnv+dJ88yyVpE674BKaw0sX7uEWzJ/ddGdw== X-Received: by 10.112.118.206 with SMTP id ko14mr5794567lbb.108.1454185250522; Sat, 30 Jan 2016 12:20:50 -0800 (PST) Sender: Ivan Zakharyaschev Date: Sat, 30 Jan 2016 23:20:45 +0300 (MSK) From: Ivan Zakharyaschev X-X-Sender: imz@ovicaa.localdomain To: Alexey Tourbin In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323328-1277168493-1454185247=:3543" Cc: =?KOI8-R?B?7cnbwSDUz9bFIM3V1t7JzsE=?= , =?KOI8-R?B?5NLVx8nFIM3V1t7Jztk=?= Subject: Re: [devel] re-writing GNU C extensions X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2016 20:20:52 -0000 Archived-At: List-Archive: List-Post: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-1277168493-1454185247=:3543 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT 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 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 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 4.9.2-alt3 - Turned on -Wtrampolines by default. Best regards, Ivan --8323328-1277168493-1454185247=:3543--