Разработчики из компании Google возобновили (https://lwn.net/SubscriberLink/771974/ade4e5fb18058302/) попытки переноса в основное ядро Linux изменений, развиваемых в варианте (https://source.android.com/devices/architecture/kernel/andro...) ядра для платформы Android. В настоящее время в устройствах с платформой Android применяются отдельные модифицированные ветки ядра, на поддержание которых тратятся большие ресурсы. Первые попытки передачи в основное ядро всех специфичных для Android исправлений были (https://www.opennet.dev/opennews/art.shtml?num=25274) предприняты (https://www.opennet.dev/opennews/art.shtml?num=32630) в 2010 и 2011 годах, но привели лишь к частичной передаче кода.Разработка всех развиваемых для Android дополнений в основном ядре даст возможность пользователям и авторам прошивок применять свежие выпуски обычного ядра Linux, не ограничиваясь ядрами, предлагаемыми Google. В свою очередь разработчики Android смогут существенно упростить сопровождение ядра для Android, избавившись от трудоёмкого процесса переноса исправлений ошибок в старые Android-ядра и портирования изменений при подготовке очередной новой ветки ядра для Android.
Последнее стабильное ядро для Android базируется (https://android.googlesource.com/kernel/common/+refs) на выпуске 4.14, но сохраняется поддержка веток 3.18, 4.4 и 4.9, которые продолжают применяться в актуальных прошивках на основе Android 8. Отличия ядер для Android включают как необходимые для платформы изменения (MTP/PTP, параноидальный режим для сетевой подсистемы, интерактивный cpufreq governor, EAS (Energy Aware Scheduling)), так и изменения для поддержки оборудования, продвигаемые поставщиками устройств (sdcardfs, специфичные драйверы).
Судя по прозвучавшему на конференции Linux Plumbers Conference 2018 докладу, в последнее время процесс синхронизации с основным ядром существенно продвинулся вперёд и возможность использования обычного ядра Linux вместе с Android, хоть ещё не достигнута, но уже достаточно близка к воплощению. Команда сопровождающих ядро для Android теперь пытается вначале продвинуть изменения в основное ядро перед публикацией, а также ведёт работу по решению проблем и уязвимостей непосредственно в upstream.
В текущем виде число специфичных изменений в Android Common Kernel, необходимых для загрузки платформы Android, сокращено до 30 патчей, охватывающих 6500 строк кода (ранее размер изменений достигал нескольких миллионов строк). Из целей на будущее отмечается перенос модулей ashmem и ion из дерева staging, улучшение использования в Android структуры "Device Tree (https://elinux.org/Device_Tree_Reference)", решение проблемы с наследованием приоритетов в binder и перенос кода EAS (Energy Aware Scheduling) и SDCardFS в основное ядро.
Несмотря на то, что Google регулярно выпускает обновления своих Android-ядер (Android Common Kernel), часто поставщики не спешат поставлять эти обновления или вообще используют одно ядро на протяжении всего жизненного цикла устройства. Для исправления ситуации Google развивает систему Treble (https://www.opennet.dev/opennews/art.shtml?num=48588), позволяющую производителям создавать универсальные компоненты поддержки оборудования, не привязанные к конкретным версиям Android и используемым выпускам ядра Linux. Treble даёт возможность использовать в качестве основы уже готовые обновления от Google, интегрируя в них специфичные для конкретного устройства компоненты. Для стимулирования доставки обновлений Google намерен применить административный ресурс на уровне отдельного требования в OEM-соглашении.В конечном счёте, Google планирует предложить поставщикам базовое ядро на основе свежей кодовой базы основного ядра Linux. Компоненты для поддержки оборудования должны будут поставляться поставщиками в только в виде дополнительных модулей ядра, без возможности использования патчей для изменения основного ядра (например, поставщик не сможет изменить логику работы штатного планировщика процессов). В модулях обязательно должна будет обеспечиваться совместимость с основным ядром на уровне пространства имён символов ядра. Все изменения, затрагивающие основное ядро должны будут продвигаться в upstream.
Дополнительно можно отметить другую инициативу (https://github.com/ClangBuiltLinux/) Google, связанную с обеспечением сборки ядра Linux с использованием компилятора Clang. Утверждается (https://docs.google.com/presentation/d/1vJrsJ7fRSi6uidJWVSI2.../), что ядра для устройств Pixel 2 и Pixel 3 уже успешно собираются с использованием Clang. Более того, ядро для Pixel 3 собирается с включением оптимизаций на этапе связывания (LTO) и механизма проверки целостности выполнения программы CFI (Control Flow Integrity). Варианты ядра, собираемые при помощи Clang, также развивают проекты Linaro и CrOS (https://getchrome.eu/).
Изменения, необходимые для сборки применяемых в Android ядер Linux, уже включены в Clang 7.0 и находящуюся в разработке ветку 8.0. Например, добавлена поддержка конструкции "asm goto (https://reviews.llvm.org/D53765)", применения регистров rN для AArch64, режимов "-fno-delete-null-pointer-checks", "-fcall-used" и "-fcall-saved". Подготовлены патчи для поддержи "__builtin_constant_p". Из достижений на уровне ядра стало избавление (https://lkml.org/lkml/2018/10/28/189) от использования в коде массивов переменной длины, реализуемых GCC-расширением VLAiS (Variable Length Arrays, возможность использования переменной в качестве размера при создании массива, например "void foo(int n){ int m[n];").
URL: https://news.ycombinator.com/item?id=18494190
Новость: https://www.opennet.dev/opennews/art.shtml?num=49648
Это хорошая новость. Гуглу бы я развитие Линукса доверил.
Ага, сбор данных и рекламный зонд на уровне ядра - то, что нужно :-)
Вот не пофигу ли с какого уровня это собирать/принимать? ))
Если ответить "да, пофигу", то зонд в мозг напрямую в подарок? :-D
Морфеус, ты ли это?
Был бы умный, знал бы - не пофигу. На уровне приложений ты ещё можешь что-то блокировать. Как только зонд всунут глубже - всё, из ведра ты уже ничего не вынешь и не запретишь. Ну разве что будешь делать реверс-патчи к гуглозондам :)
Уже всунули. Привет от Intel.
При этом реверс-патчи к фирмвари вообще не сделаешь, плюс не опен сорсю
Не пофигу когда у тебя через iptables заблокирован гугл :)
А если айпитаблес откажется блокировать гугл, потому что в целях безопасности гугл это запретил - тогда как? :)
Не беспокойтесь так, на уровне проца уже есть.
Слишком толсто
Это точно, пора уже Алфавиту прикупить МежДелМаш
Или межделмашу алфавит. Какая на... разница...
Есть такое правило. Никогда не доверяй корпорациям!И это правило работает.
Почему только корпорациям? Доверять нельзя никому, даже себе.// Мне - можно.
> Почему только корпорациям? Доверять нельзя никому, даже себе. // Мне - можно.Не вижу смысла доверять лично вам, ведь можно доверять всем кроме корпораций и людям из черного списка.
Тем более если не доверяешь себе, то уж тогда не делай то что хочешь делать ведь результат действия будет равен результату бездействия и вообще несет явный вред. А если хочешь бездействия то боюсь ты точно наносишь себе вред сильнее чем мышьяк наносит вред остальным.
вот и выросло поколение, которое Мюллера не видело...
> вот и выросло поколение, которое Мюллера не видело...[I]--Битнер, опять допрашивали пастора [/I]моим[I] двухтомником на 70тыс? Тоньше надо, тоньше! Мастера справляются и с однотомным 40тыс-ным изданием.
Товарищ полковник, перелогиньтесь и цитату не искажайте.
Компаниям тоже не доверяй. Linux Foundation, например.
Linux Foundation, например, не компания.
Консорциум.
С вики:
Консорциум (от лат. Consortium — соучастие, сообщество) — организационная форма временного объединения независимых предприятий и организаций с целью координации их предпринимательской деятельности.Короче, та же корпорация.
Только нынче в линукс корпорации и коммитят.
> Гуглу бы я развитие Линукса доверилДа ты первому встречному доверил бы, лишь бы самому этим не заниматься.
Только Apple. Благодаря им FreeBSD занимает больше в процентном соотношении чем Linux на дектопе.
А если еще посчитать инсталляции Windows, в которых тоже есть код, надерганный из BSD, то превосходство вообще ошеломительное
Пусть сначала сделает доступ к файловой системе пользователя через USB, чтобы ее можно было примонтировать, причем не заморачиваясь, типа всунул шнурок в принтер и печатай. В базовый набор программ надо включить ftp, rsync и ssh, просмотрщики pdf и djvu. Ну и нормальный калькулятор, чтобы ленту вычислений держал.
>к файловой системе пользователя через USB
>ftp, rsync и ssh, просмотрщики pdf и djvughostscript(, +его "активацию" на все иконки), telnet, samba, wine, php, js+npm, ....
...и все-все-все другие резиново-продырявленные изделия...
не забыл??>Ну и нормальный калькулятор, чтобы ленту
>даст возможность пользователям и авторам прошивок применять свежие выпуски обычного ядра Linux, не ограничиваясь ядрами, предлагаемыми Google.ага, щаз.
Конечно, главная задача - скинуть на комьюнити поддержку своего барахла. Гугл в этом плане не первый и не последний, куча корпораций влила в ядро своего кода, чтобы не заморачиваться с поддержкой - если комьюнити готово забесплатно работать, то что бы и нет: компьюнити получает плюшки и таски, корпорации снижают нагрузку по сопровождению и портированию.
Распиаренное линуксовое "камюнити" составляет 3% от числа всех разработчиков ядра Linux. Их мнение никого не интересует.И да, держу пари, что ты в эти 3% даже не входишь.
Это золотое правило жизни - 5 человек скромно работают, 95 подбадривают давай-давай, не останавливайтесь, раз-два, раз-два...
CrOs разве ещё что-то развивает? вроде уже лет пять как помер..
Какой смысл продавливать патчи под своё ведроподелие, если они же сами и хотят его похоронить?!
Видимо это только слухи
Похоронить и перейти на Фунчезу(или как ее там)?
Фуксию.
Но с учетом того что самые прибыльные приложения в Гуглезинчике - игры, а игры собираются под target native-gnu-linux, ждать еще долго.
>игры собираются под target native-gnu-linuxв андроиде нет никакого "gnu"
Симбу в своё время за 5-6 лет завернули. Так что если захотят - не долго. Особенно учитывая современный жизненный цикл девайсов в 3-4 года максимум.
В данном случае, без разницы.
Давно пора, чтобы не тратить впустую человеко-часы на мержинг.
Нет спасибо. У меня куча серверов на линуксе и они стабильны как скала.
При этом каждый мой телефон на андроиде глючил как трындец.
Пожалуйста, мухи отдельно котлеты отдельно.
linux/.config ?
> linux/.configты уже kpti оттуда выпилил, вместе с ibrs? Ну, вот и эти 6500 строк мутного кода не сможешь.
KPTI я низачто выпиливать не стану, ибо на сервере точно есть sshd и бывает VPN.
> KPTI я низачто выпиливать не стану, ибо на сервере точно есть sshd и бывает VPN.... а ещё потому что не могу. Но в основном из-за sshd и VPN, да.
> При этом каждый мой телефон на андроиде глючил как трындец.А причём тут ядро? Или он глючил непосредственно на его уровне?
Да, я видел несколько раз глючные драйвера в Андроиде, но в so called премиум брендах такое бывает редко. Ну а дешевые и noname-устройства глючат и в серверах с десктопами.
Дык, глюки в ведройде поставляются не на уровне ядра а на уровне софта и то спецом, что бы вынудить тебя выкупать новый, "более быстрый" смартфон, так делают @все "умные" производители. в месте с обновлением подкидывают кучу багов и новых тормозо-фич.А вот само ядрышко работает кстати там исправно.
Ну да, тормоза то наверное патчи для mtp вызывают, конечно
Я не видел на мобильных телефонах с Android - бага 12309. Эти изменения нужно перенести в апстрим
А я видел на устройствах с Android
- рандомные перезагрузки и отключения
- тормоза
- зависания
- окирпичивание
- кучу костылей размером с галактику(в Toshiba AC100 команды модулю ядра передавали через в текстовом формате в одну сторону и бинарным в другую http://stoplinux.org.ru/forum/viewtopic.php?id=1861)
- блобы, блобы, блобы.
Это тоже надо перенести в апстрим?
> AC100Это худшее поделие, что мне попадалось в жизни. Не стоит его упоминать.
лучший девайс, что мне попадался. жаль, таких больше не будет. а с по да, подвели тошибы
Часто проблемы в железе, тут уж без разницы какая ОС.
Я его на десктопе не видел.
я ж вам закрыл этот баг, как вы можете его видеть, когда его нет?!
Это позволит запускать произвольный юзерленд (читай: GNU/Linux) на любом телефоне?Так... Значит состав алюминия ты мне сейчас, а душу тебе после смерти?
Нет. Зато это позволит серверам на линуксе обновлять ядро через зажатие RESET+POWER+F1, держать 10 секунд, в 10% случаев возможно окирпичивание сервера.
Останется передать код google-playd.
А серверное ПО можно будет устанавливать прямо из Google Play.
Вам мало бардока тврюорящегося в npm?
что такое npm?
ну мы же заменим вам его по гарантии! Все те полтора года, что она действует.
> ну мы же заменим вам его по гарантии!И даже перенесём на новый фоточки котиков. :)
А вот и нет. Дров-то так и не видать.
> А вот и нет. Дров-то так и не видать.Драйвера как раз якобы должны иметься в установленном на устройстве ядре:
"Компоненты для поддержки оборудования должны будут поставляться поставщиками в только в виде дополнительных модулей ядра, без возможности использования патчей для изменения основного ядра"
То есть: берём готовое ядро, накатываем свой юзерленд. Зачем нужен Гуглу такой поворот? Вероятно, в ядре будут ещё какие-то интересные компоненты. :)
Очень хочет хвост вертеть собакой. :)
Почему сборка Clang'ом намного круче, чем Gcc? Из-за возможности собирать полуоткрытые исходники?
Скорее всего разработчики андроида хотят его собирать на своих макбуках прямо из икскода и не заморачиваться на установку гцц.
Я: конечно понимаю, что шутка... Но блин, страшно представить сколько часов(дней?) будет оно собираться на топовом макбуке
> Но блин, страшно представить сколько часов(дней?)Ядро линуксовое? У тебя всё нормально?
Что тут старшного? Часа всяко хватит.
минут 15...
секунд 15
Я почему-то про Android целиком подумал вместе с ядром
Ну этак часа три. Тоже не особо страшно для такого крупного проекта.
Потому, что стильно, модно, молодёжно!
Потому что проприетарщикам не подходит лицензия GCC.
Нет.
https://github.com/android-ndk/ndk/issues/26#issuecomment-19...
#>> круче, чем Gcc? Из-за возможности собирать полуоткрытые исходники?
> Нет.
> https://github.com/android-ndk/ndk/issues/26#issuecomment-19...А-а-а!... Да, из-за оплаты работы отдела маркетинга. Понел-понел.
Причем тут маркетинг? Всякие санитайзеры и прочую инструментацию впиливать в llvm тупо удобнее
> Причем тут маркетинг? Всякие санитайзеры и прочую инструментацию впиливать в llvm тупо
> удобнееДа, именно! То, что вы это говорите, то, чито оне там в баге пишут, что лицензии совсем-совсем не при чём, не при чём -- это и есть маркетинг, оправдание действий пустой болтовнёй.
Т.е. экономия человекочасов - это пустая болтовня? По-моему тут только вы болтовней занимаетесь
Еще гугловцы любят допиливать компилятор, когда он генерирует тормозной код. Но в gcc править оптимизатор это та еще работенка, поэтому им приходилось использовать гравицапы вроде http://web.archive.org/web/20160118223444/http://code.google... чтобы проверить, стоит ли конкретная оптимизация затраченной на ее раализацию работы. А с llvm можно быстро и просто прикрутить свою оптимизацию в любом месте пайплайна
Потому что шланг - это кросскомпилятор. Один шланг заменяет все специализированные тулчейны для разных платформ. То есть ставишь 1 шланг, и им можешь собирать хоть под ARM, хоть под MIPS, хоть под x86, всего лишь target triple задать надо и путь к sysroot .
>Из-за возможности собирать полуоткрытые исходники?Что такое полуоткрытые исходники, и почему их можно собирать только clang'ом?
> Что такое полуоткрытые исходникичто-то, что даже может и открытое - но не gpl.
почему - поинтересуйся, что такое libgcc_s.so и зачем она линкуется к чему ни попадя.Собственно, этого факта вполне достаточно, чтобы из любого проекта вышвыривать больных диверсантов и их поделку поганой метлой. Но нет, им показалось мало, и они отдельно запретили еще и возможность добавления своих не-gpl-модулей в тулчейн, ровно в тот момент, когда интел мягко намекнул, что вообще-то умеет оптимизации на этапе компоновки получше чем они.
Результат немного предсказуем - даже полуработающий clang многим показался лучшим выбором, чем программа в которую намеренно засунут заведомо вредный код с исключительно идеологическими целями - в лучших традициях microsoft 80х, только те с тех пор сильно поумнели, в отличие от.
Ну и ему активно стали помогать стать совсем работающим - хотя последствия недокорма в детском возрасте все еще заметны. Заметьте - никакой идеологии, ядро ведроида все равно остается под gpl, исключительно прагматика.
>почему - поинтересуйся, что такое libgcc_s.so и зачем она линкуется к чему ни попадяРантаймовая библиотека компилятора, через нее с++ исключения работают, например. Никаких ограничений на лицензию программ, слинкованных с ней, она не накладывает
>программа в которую намеренно засунут заведомо вредный код с исключительно идеологическими целями
Щито?
короче нахуй
ублюдомодеры как хуёвая идиотская замена блядской кнопки удаления...
> Дополнительно можно отметить другую инициативу Google, связанную с обеспечением сборки ядра Linux с использованием компилятора Clang. Утверждается, что ядра для устройств Pixel 2 и Pixel 3
> Пользователи жалуются на большое количество багов в телефоне Pixel 3, среди которых:- перезагрузки
- появление второй челки сбоку,
- невозможность использовать камеру...
Хм...
Собирал я одну индусскую прошивку для китайфона, где для ядра использовался clang.
Все бы ничего, но с некоторых коммитов собиралось ядро, не способное загрузиться, а еще при каждой сборке линковщик раз по 20 выпадал в segfault.Правда когда прошивка собиралась и загружалась, серьёзных проблем с ней не было.
Падение линковщика говорит лишь о качестве самого линковщика. Привет пишущим на си/крестах.
пока пишущим скрипты
>а еще при каждой сборке линковщик раз по 20 выпадал в segfaultна телефоне собирал?
> сохраняется поддержка веток 3.18, 4.4 и 4.9А 3.10 всё?
Судя по тому, что последний коммит был октябре - пока нет.
https://android.googlesource.com/kernel/common/+/android-3.10
> В настоящее время в устройствах с платформой Android применяются отдельные модифицированные ветки ядра, на поддержание которых тратятся большие ресурсы.Вот и надо писать свой Android так, чтобы он работал на основной ветке ядра. Зачем всякое Г тащить в него.
> Вот и надо писать свой Android так, чтобы он работал на основной ветке ядра.
> Зачем всякое Г тащить в него.иначе вы будете вынуждены тащить с собой вместо лопатки - жужжащий ящик весом в 15 килограмм, на котором работает "основная ветка ядра".
правда, зачем этот код владельцам тех ящиков - нам пока не удалось правдоподобно придумать. Мы работаем над этим.
> правда, зачем этот код владельцам тех ящиков - нам пока не удалось правдоподобно придумать. Мы работаем над этим.В этом и проблема. Если это Г нужно всем, его в ядро примут без особых разговоров. Придумайте уже что-нибудь действительно полезное.
EAS, Interactive говернор и прочее не нужны на десктопе. Сюрприз, да? Стоит обращать внимание хотя бы на содержание патчей, прежде чем демонстрировать свое невежество
Кажется, невежество - это ваше.
Во-первых, про десктоп я ничего не говорил. Здесь речь о ядре Linux, которое используется и в серверах, и во всяких роутерах и даже в кофеварках.
Во-вторых, то что вам не нужно, не означает что это не нужно другим, дорогой мой обращатель внимание на содержание патчей.
В том то и дело, что нужно. На портативных устройствах. Вы же говорите "ааа не надо это тащить в ядро". Определитесь
> EAS, Interactive говернор и прочее не нужны на десктопе. Сюрприз, да? Стоит
> обращать внимание хотя бы на содержание патчей, прежде чем демонстрировать свое
> невежествоа десктопный гувернёр не нужен на серверах (больших типо кластеров и маленьких типо роутеров), накой он в линуксе?
и вы не нужны, ибо несёте ненужно
>> EAS, Interactive говернор и прочее не нужны на десктопе. Сюрприз, да? Стоит
>> обращать внимание хотя бы на содержание патчей, прежде чем демонстрировать свое
>> невежествотак как это был ответ на
"В этом и проблема. Если это Г нужно всем, его в ядро примут без особых разговоров. Придумайте уже что-нибудь действительно полезное."
извиняюсь, неправильно понял
>EAS, Interactive говернор и прочее не нужны на десктопеИ че? Как будто кому-то есть дело до линукса на десктопе
Если на Линуксе наконец-то нативно можно будет запускать Андроидные игры, то это будет тортище. Вайн или стим с его доработкой для виндовых игр, плюс нативные линуксовые игры, плюс андроидные - винда на домашних десктопах сможет пойти лесом наконец-то.
Ядро != либы поверх него, плюс в ведре же совя реализация графического сервера
андроед это не только изувеченное китайцами ядро, но ещё и написанный индусами юзерспейс который таки сильно отличается от gnu/linuxссылку на губозакатывательную машинку за недорого дать?
Есть уже, anbox.io, но официально поддерживается (пока) только убунта.
там, в андроид-е, когда-то решили пойти другим путём, и потому сели на другие базовые библиотеки ( BIONIC ( https://en.wikipedia.org/wiki/Bionic_(software) ))
С одной стороны это неплохо можно будет запустить линуху на любом кирпиче без применения тонны патчей и костылей ... С другой стороны дашь Им(гуглу) палец они руку по уши откусят (в данном случае возможно засрут ядро)
> С одной стороны это неплохо можно будет запустить линуху на любом кирпичеТы почему-то думаешь, что там наверху гугль что-то делает для тебя?
Правда??
А Я и не думаю, гугл решает свои задачи Я свои.
Гугл решает свои задачи, ты - нет.
Расскажи ко мне О ВЕЛИКИЙ Диванный специалист почему это Я не решаю свои задачи ? Я жду чётких доказательств, а не мямленье малолетних всё знающих и всевидящих ..
Вы знаете обо мне всё и вся ? Знаете какие задачи я решаю а какие нет ?
> гугл решает свои задачи Я свои.Точнее, ты тоже решаешь его задачи.
>> гугл решает свои задачи Я свои.
> Точнее, ты тоже решаешь его задачи.Ок, поясните мне Великий диванный спец №2 какие задачи гугла Я решаю ? И докажите пожалуйста почему =)
нельзя будет, потому-что ядро в Андроид не обеспечивает полной поддержки работы устройства
>в данном случае возможно засрут ядроВ лучшем случае в ядро добавится код, полезный для разработчиков embedded-систем на неандроидовом линуксе. В худшем случае будет куча кода под CONFIG_ANDROID, который никто, кроме андроидоводов не будет собирать
Ага, Линус "подобрел", теперь ему можно всякую чушь в ядро совать?
Надеюсь он их пошлет куда подальше, просто в более деликатно форме.
C код он такой да
Java код был бы в 500 миллионов строк больше кода еще включая и скачку из Maven/Ant.
> Google возобновили попытки переноса в основное ядро Linux измененийЗначит скоро появится проект Ungoogled-Linux?
Интересно будет посмотреть, как они свой чудесный CONFIG_ANDROID_PARANOID_NETWORK будут пробовать запихнуть в ядро.
>Изменения, необходимые для сборки применяемых в Android ядер Linux, уже включены в Clang
>Например, добавлена поддержка <...> "-fno-delete-null-pointer-checks"Но зачем удалять такие проверки? Что это за компилятор?!
Тут или падать или быть с дыркой. Андроид хочет не падать с открытым зондом.
Судя по названию опции, она как раз отключает удаление таких проверок компилятором на этапе оптимизиации.
> Судя по названию опции, она как раз отключает удаление таких проверок компилятором
> на этапе оптимизиации.-fdelete-null-pointer-checks
Assume that programs cannot safely dereference null pointers, and that no code or data element resides at address zero.
This option enables simple constant folding optimizations at all optimization levels. In addition, other optimization
passes in GCC use this flag to control global dataflow analyses that eliminate useless checks for null pointers; these
assume that a memory access to address zero always results in a trap, so that if a pointer is checked after it has already
been dereferenced, it cannot be null.Note however that in some environments this assumption is not true. Use -fno-delete-null-pointer-checks to disable this
optimization for programs that depend on that behavior.This option is enabled by default on most targets. On Nios II ELF, it defaults to off. On AVR, CR16, and MSP430, this
option is completely disabled.
>Но зачем удалять такие проверки? Что это за компилятор?!Ваш любимый GCC по-умолчанию это делает: https://habr.com/company/abbyy/blog/234033/
>>Но зачем удалять такие проверки? Что это за компилятор?!
>Ваш любимый GCC по-умолчанию это делаетИ зачем нам тогда два компилятора с подобной ерундой?
не вам, а нам. У нас без подобной ерунды ведроид неработоспособный получается.вот такая хрень примерно происходит: https://www.opennet.dev/opennews/art.shtml?num=39992
причем искать по всему коду подобные проблемные места, которые раньше чисто по недоразумению работали (ну вызовется ненужный memmove на нулевой указатель но с нулевой же длинной - ничего, разумеется, не мувнет, и не испортит, проверка потом этот ноль заметит и ничего туда класть тоже не будет) нам как-то не хочется, проще заставить разработчиков компилятора переделать.они, в принципе, не особо и возражали - так и так undefined behavior.
>инициативу Google, связанную с обеспечением сборки ядра Linux с использованием компилятора Clangв чём смысл собирать ядро другим компилятором?