Этого я точно не видел, поэтому спасибо за совет! Конечно, нужно посмотреть, как аналогичные задачи решались существующими инструментами. Просто удивило, что даже совсем примитивная стратегия тоже на что-то способна.
Насчёт добавления — тут есть нюанс, изначально не указанный в статье, который я сейчас дописал: у меня нет сериализаторов, превращающих AST в текст. Зато существующие языковые модули проставляют начало и конец узла в исходном тексте, поэтому можно взять оригинальный файл и "выкинуть лишнее" — отсюда изначальный посыл с итеративным выкидыванием лишнего. Это не ответ "нет" на ваш комментарий — просто обоснование, почему изначальное решение было таким.
Может это потому, что AFL смотрит что внутри экзешника что-то стриггерилось (у него там мапа специальная есть) и начинает эти места лучше проверять, делает ли так-же libFuzzer я не вкурсе.
Насколько я понимаю, там ещё отдельное искусство выбора того, какие мутации более перспективные — см., например, afl-rb и сравнение с другими подходами. Также можно посмотреть в документации на тему используемого в AFL подхода и мотивации выбрать именно такой.
UPD: ltrace, может, и не "устарел", но с ходу я не нашёл активности за последние 4 года в официальном репозитории. Впрочем, в таком же состоянии долго пребывал bzip2, а потом, вроде, кто-то принял "эстафету поддержки".
У меня есть смутное ощущение, что, в отличие от вовсю обновляющегося strace, трассировщик ltrace малость устарел. И тут начинаешь думать: "Это же должно делаться в кооперации с ld-linux.so, иначе можно наткнуться на внезапное расхождение". И тут, внезапно, натыкаешься на sotruss, который по крайней мере на моей системе реально идёт в пакете libc-dev-bin.
Кстати, для Windows есть попытка сделать аналог strace на динамической инструментации через DynamoRIO — drstrace, но вот работает он, по моим ощущениям, хуже. Ну и strace всё-таки работает через системный вызов ptrace, а не инструментацию всего кода.
Возможно, LKL рассчитывает на GNU ld, а вас, может, lld или GNU ld древней версии… Это, конечно, может вызвать проблемы и далее, но конкретно в этом случае есть ощущение, что оно просто проверяет: на Винде мы или на Юниксе — можно просто закомментировать пока лишнюю ветвь, и если вдруг остальное заработает — можно им issue написать.
PS: не знаю, как с lld, а clang'ом свежее ядро вполне собирается.
Не путаете ли вы его с LibOS? Тот уже пару лет назад выглядел запущенным, а LKL более-менее обновляется: сейчас в него вмержена версия 5.3+, если верить логам против актуальной 5.4.2 — тоже, конечно, не идеально, но и совсем запущенным не назовёшь. Хотя, в какие-то периоды, действительно, создавалось ощущение застоя. А уязвимости — это, конечно, грустно.
Можно. Например, с помощью Binaryen можно собрать из "ассемблерного листинга", а можно генерировать на ходу программно. Во втором случае поддерживается не только высокоуровневый control flow (if / while / switch или что там), но и низкоуровневые передачи управления между basic block'ами, а он уже сам сделает relooping (т.е. сведёт к первому случаю, как требуется в wasm) — это пригодится, если у вас уже некое промежуточное представление, а не человекочитаемый код, который вы вручную пишете.
Ну, на качество выходных бинарников ещё не смотрел. А вот со скоростью по прошлым впечатлением, действительно, было куда расти. Особенно неприятно было на относительно слабом ноутбуке (Core i3-380M и 8Gb оперативки, ага) заметить ошибку, поправить один файл и минуту ждать линковки. Если новый backend это устраняет, то это очень радует!
Ну, для пользователя разница, видимо, будет не сильно заметной, своя у них поддержка или из upstream LLVM (всё равно всё работало через LLVM с давних времён). Скорее, это важно для остальной экосистемы LLVM и его frontend'ов.
UPD: говорят, компилируется значительно быстрее. Надо бы посмотреть...
Правда, они либо ещё не обновили документацию, либо не переключились по умолчанию на использование upstream backend:
Emscripten can currently (July 2019) use 2 backends to generate WebAssembly: fastcomp (the asm.js backend, together with asm2wasm) and the upstream LLVM wasm backend.
Fastcomp is currently the default, but we hope to switch the default soon to the upstream backend.
Как вариант: Emscripten позволяет транслировать большое количество кода на C в JS, но при этом он часто не прощает Undefined Behavior, на который ПОКА забивают многие другие компиляторы (UB — это всегда плохо, так что это не баг). Emscripten — это фактически backend для LLVM + run-time, изображающий из себя API системных вызовов чего-то POSIX'ного для musl libc. Также он может использоваться для C++, вроде бы для Rust, да и много ещё, наверное, для чего.
Также есть родственный ему проект Binaryen — своего рода binutils для WASM. Можно хоть из JS генерировать WASM на ходу (если собрать Binaryen в JS или WASM с помощью Emscripten), но помни, Золушка после приблизительно тысячного WASM-модуля вкладка Chrome превращается в тыкву.
То есть к ограничениям ООП, Kotlin добавляет ещё и ограничения ФП?))) Воинстину брейнфак.
Не Kotlin, а Scala и не ограничения, а возможности. :) Можно писать как на упрощённой Java с удобным автоматическим выводом типов и лаконичными конструкциями, имея при этом доступ ко всему наследию Java. Можно (но не обязательно) и как на ФП (правда, как раз-таки без ограничений на сайд-эффекты, например).
Kotlin, как я понимаю, это попытка упростить синтаксис Java и обуздать некоторые опасные вещи вроде null, который в Java может выскочить практически, где угодно. Но врать не буду — про Kotlin я лишь слышал чужие рассказы.
Вы сначала определитесь, что хотите писать, а потом уже выбирайте язык под эти цели.
Это само собой. Просто забавно, что язык подходит сразу для многого, и при этом удобным образом (потому что одно из предназначений по задумке — DSL).
Мда… Как-то мы умудрились затеять развесистое обсуждение Scala в треде про WASM, в который она даже и не факт, что компилируется...
На самом деле, тоже не вполне понимаю, зачем писать на JS на Scala — скорее, к слову пришлось. Ну, то есть, это в каком-то смысле уже не та разрекламированная Scala, опирающаяся на всю экосистему библиотек на JVM, а просто язык с прикольной системой типов и некоторыми библиотеками, поддерживающими Scala.JS.
Впрочем "современная Java" — это, скорее Kotlin. Насколько мне известно, совместить ООП и ФП вместе со статической типизацией в одном языке — это был гигантский труд. В этом плане Scala — это скорее "новый язык, опирающийся на экосистему JVM".
Кстати, на Scala даже пишут продвинутые генераторы процессоров. Хотя, справедливости ради, на чём сейчас железо только не пишут (в качестве DSL) — на Haskell, Python, разве что, не на ассемблере.
Наверное, вы правы — и сам я именно в таком порядке знакомился — но на момент написания комментария DMP7 мне казался "JS-хейтерохейтером" и я в порыве обсуждения предложил ему что-то менее вызывающее отторжение у человека, у которого нет жгучего желания узнать, что же это за ФП, а просто интересующегося. Scala — она и в плане синтаксиса меньше мозг выносит, и используется сильно больше где. Впрочем, и сам я и близко не "чистый функциональщик".
С другой стороны, напротив, вариант "полностью сломать мозг Хаскелем и нести ФП в родной JS" (а JS, насколько я понимаю, вполне позволяет использовать некоторые подобные вещи) тоже имеет право на жизнь.
Ох… С "философией" и классификацией у меня вечные проблемы… Видимо, да. Скорее, может, как переосмысление идей ООП и ФП (ну и статической типизации, но с каждым по отдельности она и так отлично совмещается) внутри одного языка, преимущественно нацеленное на JVM (но также на компиляцию в JS и нативный код). Кстати, насколько мне известно, часть бекенда в Twitter как раз на Scala.
Упс, прошу прощения за неточность формулировки: под run-time в данном случае я подразумевал "во время выполнения" (например, у клиента в браузере) в противовес compile-time (которое у вас на рабочем месте или на сборочном сервере).
Когда переходил на Scala, делал это с осторожностью, поскольку против Java испытывал некоторые предрассудки. В итоге на Scala особо "паттерны ради паттернов" не использовал. И здесь расчёт был как раз на то, что "надо будет — спрошу у Идеи все места использования, поправлю, проверю что всё компилируется — и после этого буду достаточно спокоен". Вот здесь как раз и помогала развесистая статическая типизация.
Map, filter и т.п. — это ещё ES5 синтаксис для JS. Основное развитие пошло с ES6+ стандартов. Если взгляните, то увидите, сколько «сахара» сейчас предлагает JS.
Это да, сейчас, кстати, и в Java всякие stream API появились — к счастью, языки заимствуют хорошие особенности друг у друга. Вот только когда я последний раз читал документацию по Python (довольно давно), там эти filter и т.д. по непонятной для меня причине были помечены как нежелательные к использованию.
А вот с этим соглашусь! Только один нюанс: неверный тип в Scala/Rust (в TS, наверное, тоже) прилетит при компиляции, и вы его неспешно изучите и поправите, а вот undefined is not a function — в рантайме, и поправить может понадобиться срочно. Извините за приступ графоманства :) Просто сейчас у некоторых людей есть мода выставлять JS серебряной пулей вообще для всего. Вот против этого, а не написания фронтенда на JS, в моём представлении выступают JS-хейтеры.
Если вам уровень мышления позволяет без проблем проанализировать консоль и понять откуда что прилетело, то JS, если нет то TS, WebAsembly и т.п. вам больше подойдут.
Эк вы мощно — звучит как "Если мозгов хватает, пиши на JS" :) (извините, если неправильно понял) Я вообще-то про другое: для "более строгих" языков тоже мозги нужны, и не меньше — просто требуются другие сильные и прощаются другие слабые стороны. Вообще, в идеале для некоторых задач (не уверен, что фронтенд к ним относится) было бы удобно, чтобы "мозгов хватило — написал хорошо, не хватило — не написал никак". В этом плане впечатляют рассказы про Rust (который я мечтаю когда-нибудь изучить) от людей, пол-часа бившихся с компилятором, выполнявших его подсказки, и в итоге таки написавших безопасный многопоточный код. В то же время компилятор C++ согласился бы почти сразу, и оно почти всегда бы работало — это-то и страшно...
Этого я точно не видел, поэтому спасибо за совет! Конечно, нужно посмотреть, как аналогичные задачи решались существующими инструментами. Просто удивило, что даже совсем примитивная стратегия тоже на что-то способна.
Насчёт добавления — тут есть нюанс, изначально не указанный в статье, который я сейчас дописал: у меня нет сериализаторов, превращающих AST в текст. Зато существующие языковые модули проставляют начало и конец узла в исходном тексте, поэтому можно взять оригинальный файл и "выкинуть лишнее" — отсюда изначальный посыл с итеративным выкидыванием лишнего. Это не ответ "нет" на ваш комментарий — просто обоснование, почему изначальное решение было таким.
Насколько я понимаю, там ещё отдельное искусство выбора того, какие мутации более перспективные — см., например, afl-rb и сравнение с другими подходами. Также можно посмотреть в документации на тему используемого в AFL подхода и мотивации выбрать именно такой.
UPD: ltrace, может, и не "устарел", но с ходу я не нашёл активности за последние 4 года в официальном репозитории. Впрочем, в таком же состоянии долго пребывал bzip2, а потом, вроде, кто-то принял "эстафету поддержки".
У меня есть смутное ощущение, что, в отличие от вовсю обновляющегося
strace, трассировщикltraceмалость устарел. И тут начинаешь думать: "Это же должно делаться в кооперации с ld-linux.so, иначе можно наткнуться на внезапное расхождение". И тут, внезапно, натыкаешься наsotruss, который по крайней мере на моей системе реально идёт в пакетеlibc-dev-bin.Кстати, для Windows есть попытка сделать аналог
straceна динамической инструментации через DynamoRIO —drstrace, но вот работает он, по моим ощущениям, хуже. Ну иstraceвсё-таки работает через системный вызовptrace, а не инструментацию всего кода.Возможно, LKL рассчитывает на GNU ld, а вас, может, lld или GNU ld древней версии… Это, конечно, может вызвать проблемы и далее, но конкретно в этом случае есть ощущение, что оно просто проверяет: на Винде мы или на Юниксе — можно просто закомментировать пока лишнюю ветвь, и если вдруг остальное заработает — можно им issue написать.
PS: не знаю, как с lld, а clang'ом свежее ядро вполне собирается.
Не путаете ли вы его с LibOS? Тот уже пару лет назад выглядел запущенным, а LKL более-менее обновляется: сейчас в него вмержена версия 5.3+, если верить логам против актуальной 5.4.2 — тоже, конечно, не идеально, но и совсем запущенным не назовёшь. Хотя, в какие-то периоды, действительно, создавалось ощущение застоя. А уязвимости — это, конечно, грустно.
-
Можно. Например, с помощью Binaryen можно собрать из "ассемблерного листинга", а можно генерировать на ходу программно. Во втором случае поддерживается не только высокоуровневый control flow (if / while / switch или что там), но и низкоуровневые передачи управления между basic block'ами, а он уже сам сделает relooping (т.е. сведёт к первому случаю, как требуется в wasm) — это пригодится, если у вас уже некое промежуточное представление, а не человекочитаемый код, который вы вручную пишете.
Ну, на качество выходных бинарников ещё не смотрел. А вот со скоростью по прошлым впечатлением, действительно, было куда расти. Особенно неприятно было на относительно слабом ноутбуке (Core i3-380M и 8Gb оперативки, ага) заметить ошибку, поправить один файл и минуту ждать линковки. Если новый backend это устраняет, то это очень радует!
Ну, для пользователя разница, видимо, будет не сильно заметной, своя у них поддержка или из upstream LLVM (всё равно всё работало через LLVM с давних времён). Скорее, это важно для остальной экосистемы LLVM и его frontend'ов.
UPD: говорят, компилируется значительно быстрее. Надо бы посмотреть...
Правда, они либо ещё не обновили документацию, либо не переключились по умолчанию на использование upstream backend:
Как вариант: Emscripten позволяет транслировать большое количество кода на C в JS, но при этом он часто не прощает Undefined Behavior, на который ПОКА забивают многие другие компиляторы (UB — это всегда плохо, так что это не баг). Emscripten — это фактически backend для LLVM + run-time, изображающий из себя API системных вызовов чего-то POSIX'ного для musl libc. Также он может использоваться для C++, вроде бы для Rust, да и много ещё, наверное, для чего.
Также есть родственный ему проект Binaryen — своего рода binutils для WASM. Можно хоть из JS генерировать WASM на ходу (если собрать Binaryen в JS или WASM с помощью Emscripten),
но помни, Золушкапосле приблизительно тысячного WASM-модуля вкладка Chrome превращается в тыкву.На правах рекламы:вот здесь можно почитать, как я портировал QEMU для выполнения в браузере — там и Emscripten, и Binaryen, и JIT...Не Kotlin, а Scala и не ограничения, а возможности. :) Можно писать как на упрощённой Java с удобным автоматическим выводом типов и лаконичными конструкциями, имея при этом доступ ко всему наследию Java. Можно (но не обязательно) и как на ФП (правда, как раз-таки без ограничений на сайд-эффекты, например).
Kotlin, как я понимаю, это попытка упростить синтаксис Java и обуздать некоторые опасные вещи вроде
null, который в Java может выскочить практически, где угодно. Но врать не буду — про Kotlin я лишь слышал чужие рассказы.Это само собой. Просто забавно, что язык подходит сразу для многого, и при этом удобным образом (потому что одно из предназначений по задумке — DSL).
Мда… Как-то мы умудрились затеять развесистое обсуждение Scala в треде про WASM, в который она даже и не факт, что компилируется...
На самом деле, тоже не вполне понимаю, зачем писать на JS на Scala — скорее, к слову пришлось. Ну, то есть, это в каком-то смысле уже не та разрекламированная Scala, опирающаяся на всю экосистему библиотек на JVM, а просто язык с прикольной системой типов и некоторыми библиотеками, поддерживающими Scala.JS.
Впрочем "современная Java" — это, скорее Kotlin. Насколько мне известно, совместить ООП и ФП вместе со статической типизацией в одном языке — это был гигантский труд. В этом плане Scala — это скорее "новый язык, опирающийся на экосистему JVM".
Кстати, на Scala даже пишут продвинутые генераторы процессоров. Хотя, справедливости ради, на чём сейчас железо только не пишут (в качестве DSL) — на Haskell, Python, разве что, не на ассемблере.
Наверное, вы правы — и сам я именно в таком порядке знакомился — но на момент написания комментария DMP7 мне казался "JS-хейтерохейтером" и я в порыве обсуждения предложил ему что-то менее вызывающее отторжение у человека, у которого нет жгучего желания узнать, что же это за ФП, а просто интересующегося. Scala — она и в плане синтаксиса меньше мозг выносит, и используется сильно больше где. Впрочем, и сам я и близко не "чистый функциональщик".
С другой стороны, напротив, вариант "полностью сломать мозг Хаскелем и нести ФП в родной JS" (а JS, насколько я понимаю, вполне позволяет использовать некоторые подобные вещи) тоже имеет право на жизнь.
Ох… С "философией" и классификацией у меня вечные проблемы… Видимо, да. Скорее, может, как переосмысление идей ООП и ФП (ну и статической типизации, но с каждым по отдельности она и так отлично совмещается) внутри одного языка, преимущественно нацеленное на JVM (но также на компиляцию в JS и нативный код). Кстати, насколько мне известно, часть бекенда в Twitter как раз на Scala.
Упс, прошу прощения за неточность формулировки: под run-time в данном случае я подразумевал "во время выполнения" (например, у клиента в браузере) в противовес compile-time (которое у вас на рабочем месте или на сборочном сервере).
Когда переходил на Scala, делал это с осторожностью, поскольку против Java испытывал некоторые предрассудки. В итоге на Scala особо "паттерны ради паттернов" не использовал. И здесь расчёт был как раз на то, что "надо будет — спрошу у Идеи все места использования, поправлю, проверю что всё компилируется — и после этого буду достаточно спокоен". Вот здесь как раз и помогала развесистая статическая типизация.
Это да, сейчас, кстати, и в Java всякие stream API появились — к счастью, языки заимствуют хорошие особенности друг у друга. Вот только когда я последний раз читал документацию по Python (довольно давно), там эти
filterи т.д. по непонятной для меня причине были помечены как нежелательные к использованию.А вот с этим соглашусь! Только один нюанс: неверный тип в Scala/Rust (в TS, наверное, тоже) прилетит при компиляции, и вы его неспешно изучите и поправите, а вот
undefined is not a function— в рантайме, и поправить может понадобиться срочно. Извините за приступ графоманства :) Просто сейчас у некоторых людей есть мода выставлять JS серебряной пулей вообще для всего. Вот против этого, а не написания фронтенда на JS, в моём представлении выступают JS-хейтеры.Эк вы мощно — звучит как "Если мозгов хватает, пиши на JS" :) (извините, если неправильно понял) Я вообще-то про другое: для "более строгих" языков тоже мозги нужны, и не меньше — просто требуются другие сильные и прощаются другие слабые стороны. Вообще, в идеале для некоторых задач (не уверен, что фронтенд к ним относится) было бы удобно, чтобы "мозгов хватило — написал хорошо, не хватило — не написал никак". В этом плане впечатляют рассказы про Rust (который я мечтаю когда-нибудь изучить) от людей, пол-часа бившихся с компилятором, выполнявших его подсказки, и в итоге таки написавших безопасный многопоточный код. В то же время компилятор C++ согласился бы почти сразу, и оно почти всегда бы работало — это-то и страшно...