C (или любой) компилятор детерминированной производительности

Question

Во время работы над недавним проектом меня посетил представитель отдела контроля качества клиента, который задал мне вопрос, который я раньше не рассматривал:

Откуда вы знаете, что используемый вами компилятор генерирует машинный код, который точно соответствует функциональности кода c и что компилятор полностью детерминирован?

На этот вопрос у меня не было абсолютно никакого ответа, поскольку я всегда считал компилятор само собой разумеющимся. Он принимает код и выбрасывает машинный код. Как я могу проверить и проверить, что компилятор фактически не добавляет функциональность, о которой я ее не просил? или еще более опасно реализовать код немного иначе, чем я ожидаю?

Я осознаю, что этот процесс не является проблемой для всех, и на самом деле ответом может быть просто ... "ты перебрал баррель и разберись с этим". Однако при работе во встроенной среде вы неявно доверяете своему компилятору. Как я могу доказать себе и QA, что я прав в этом?

Answer 1

Вы можете применить этот аргумент на любом уровне: доверяете ли вы сторонним библиотекам? ты доверяешь ОС? Вы доверяете процессору?

Хороший пример того, почему это может быть серьезной проблемой, конечно, это то, как Кен Томпсон вставил бэкдор в исходную программу 'login' ... и изменил компилятор C так, что даже если вы перекомпилировали login, вы все равно получили черный ход. См. сообщение для получения более подробной информации.

Подобные вопросы были подняты в отношении алгоритмов шифрования - откуда мы знаем, что в DES нет бэкдора, через который АНБ может проследить?

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

Answer 2

Для критичных для безопасности встроенных приложений сертифицирующие агентства должны удовлетворять требованию «проверенного использования» для компилятора. Как правило, существуют определенные требования (вроде «часов работы»), которые должны быть выполнены и подтверждены подробной документацией. Однако большинство людей не могут или не хотят соответствовать этим требованиям, потому что это может быть очень сложно, особенно для вашего первого проекта с новой целью / компилятором.

Еще один подход заключается в том, чтобы вообще НЕ доверять выводу компилятора. Любые недостатки, связанные с компилятором и даже языком (Приложение G стандарта C-90, кто-нибудь?) Должны быть покрыты строгим набором статического анализа, модульного тестирования и тестирования покрытия в дополнение к последующему функциональному тестированию.

Стандарт, подобный MISRA-C , может помочь ограничить ввод для компилятора «безопасным» подмножеством языка Си. Другой подход состоит в том, чтобы ограничить входные данные для компилятора подмножеством языка и проверить, каковы выходные данные для всего подмножества. Если наше приложение построено только из компонентов из подмножества, предполагается, что известно, каким будет вывод компилятора. Обычно идет "квалификация компилятора".

Цель всего этого - уметь ответить на вопрос представителя QA: «Мы не просто полагаемся на детерминизм компилятора, но именно так мы это доказываем ...».

Answer 3

Вы знаете по тестированию. При тестировании вы тестируете как код, так и компилятор.

Вы обнаружите, что вероятность того, что вы или автор компилятора допустили ошибку, намного меньше, чем вероятность того, что вы допустите ошибку, если напишите соответствующую программу на каком-либо языке ассемблера.

Answer 4

Доступны костюмы для проверки компилятора.
То, что я помню, это "Многолетник" .

Когда я работал над компилятором C для встроенного процессора SOC, мы должны были проверить компилятор на соответствие этому и двум другим критериям проверки (я забыл, как называется). Утверждение компилятора до определенного уровня соответствия этим тестовым наборам было частью контракта.

Answer 5

Все сводится к доверию. Ваш клиент доверяет какому-либо компилятору? Используйте это, или, по крайней мере, сравните выходной код между вашим и их.

Если они не доверяют никому, есть ли эталонная реализация для языка? Не могли бы вы убедить их в этом доверять? Затем сравните ваш со ссылкой или используйте ссылку.

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

Во всяком случае, это все еще оставляет вопрос о том, как вы будете проверять, не имея ссылок, компилятор, с нуля. Это, безусловно, выглядит как тонна работы и требует определения языка, который не всегда доступен, иногда это определение является компилятором.

Answer 6

Откуда вы знаете, что используемый вами компилятор генерирует машинный код, который точно соответствует функциональности кода c и что компилятор полностью детерминирован?

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

Единственное программное обеспечение, которое я сертифицировал, - это авионика. Сертификация FAA не является достаточно строгой, чтобы доказать, что программное обеспечение работает правильно, и в то же время она заставляет вас прыгать через определенное количество обручей. Хитрость заключается в том, чтобы структурировать ваш «процесс» так, чтобы он максимально улучшил качество, с минимальным количеством посторонних прыжков с обручем, с которыми вы можете сойти с рук. Таким образом, все, что вы знаете, бесполезно и не будет на самом деле находить ошибки, вы, вероятно, можете избежать этого. И все, что вы знаете, вы должны делать, потому что найдет ошибок, которые явно не запрошены FAA. Лучше всего выкручивать слова до тех пор, пока не будет звучать так, будто вы даете FAA / вашему персоналу QA что они просили.

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

Answer 7

Некоторые интеллектуальные боеприпасы можно найти в Crosstalk, журнале для инженеров по оборонному программному обеспечению. Этот вопрос - вещь, на которую они тратят много часов бодрствования. http://www.stsc.hill.af.mil/crosstalk/2006/08/index.html (Если я найду свои старые заметки из старого проекта, я вернусь сюда ...)

Answer 8

Вы никогда не можете полностью доверять компилятору, даже очень рекомендуемым. Они могут выпустить обновление, в котором есть ошибка, и ваш код компилируется так же. Эта проблема усугубляется при обновлении старого кода с ошибочным компилятором, при тестировании и отправке товара только для того, чтобы клиент позвонил вам через 3 месяца с проблемой.

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

Несколько раз я обнаруживал ошибки в компиляторе. Однажды была ошибка, при которой 16-битные переменные увеличивались, но без переноса, и только если 16-битная переменная была частью структуры extern, определенной в заголовочном файле.

Answer 9

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

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

Тем не менее, как только вы решите, что, по вашему мнению, означает языковая спецификация, вы можете написать хороший, быстрый, автоматизированный тест для каждого нюанса. Вот где написание компилятора имеет огромное преимущество перед написанием других видов программного обеспечения: в тестировании. Каждая ошибка становится автоматизированным тестовым примером, и набор тестов может быть очень тщательным. Производители компиляторов имеют гораздо больше средств для проверки правильности компилятора, чем вы (у вас уже есть дневная работа, верно?).

Что это значит для вас? Это означает, что вы должны быть открыты к возможностям ошибок в вашем компиляторе, но есть вероятность, что вы сами их не найдете.

Я бы выбрал поставщика компилятора, который вряд ли обанкротится в ближайшее время, у которого есть история высокого качества в их компиляторах, и который продемонстрировал свою способность обслуживать (исправлять) свои продукты. Компиляторы, похоже, со временем становятся более корректными, поэтому я бы выбрал тот, который был где-то десять или два.

Сосредоточьте свое внимание на правильном коде. Если он понятен и прост , то когда вы do нажмете ошибку компилятора, у вас не будет думать очень трудно, чтобы решить, в чем проблема. Напишите хорошие модульные тесты , которые гарантируют, что ваш код будет делать то, что вы ожидаете.

Answer 10

... вы доверяете своему компилятору неявно

Вы перестанете делать это в первый раз, когда столкнетесь с ошибкой компилятора. ; -)

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