2015-08-09 3 views
0

Я изменяю сборку, используя Mono.Cecil, и я хочу проверить ее на достоверность (будет ли результат вообще запущен). Я пытаюсь использовать PEVerify, но у меня проблема.Может ли PEVerify сказать мне серьезность каждой ошибки?

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

  1. Использование указателей и им подобных.
  2. Не устанавливать .locals init, когда метод имеет местных жителей.
  3. Вызов .ctor из неконструктора.

Вопросы, которые делают IL не работать, включают:

  1. член не доступен с места он используется в
  2. член не существует..

Есть ли способ заставить его дать мне указание на серьезность проблемы? Если нет, есть ли другой инструмент, который может это сделать?

+0

Это не то, что делает PEVerify. Он проверяет, является ли IL действительным, это ответ «Да/Нет». Безопасность и «глюки» вообще не рассматриваются. Использование неправильной версии PEVerify было просто глупой ошибкой. –

+0

@HansPassant Я думаю, что я, возможно, был неясен или что-то в этом роде, если вы не говорите, что непроверенный IL не может бежать. Я обновил вопрос. Если я все еще что-то недопонимаю, не могли бы вы написать ответ? Я хотел бы знать. – GregRos

+0

Использование указателей всегда создает непроверяемое приложение. Остальные - это просто ошибки, которые вам нужно исправить, когда PEVerify сообщает вам, что вы делаете это неправильно. –

ответ

1

@ HansPassant уже пытался объяснить это, но просто чтобы мы все понимали друг друга, вот что происходит.

PEVerify проверяет вашу сборку на конструкции, которые не в порядке. Тем не менее, PEVerify не является компилятором JIT. Сам компилятор JIT не проверяет сборку IL - он просто захватывает метод, который он собирается вызывать, изменяет его на форму SSA, оптимизирует, компилирует, а затем вызывает итоговую двоичную сборку.

Теперь компилятор будет развиваться со временем. Оптимизации меняются и добавляются, а роль компилятора не обязательно проверять на наличие ошибки (если она находит ее как побочный продукт, она, вероятно, сообщит об этом, но не гарантирует). Помните, что JIT-компилятор неустанно оптимизирован только для одной вещи, а именно для создания довольно хорошего ассемблерного байтового кода (потому что это язык JIT, время, необходимое для компиляции, действительно важно). Итак, два разных инструмента.

В основном это приводит к следующему:

  • Компилятор компилировать и выполнять то, что оно было дано.
  • PEVerify сообщит вам, задан ли результат метода/сборки.

Если вы игнорируете ошибку PEVerify, это в основном означает, что результат будет неопределенного поведения - что может быть что угодно от рабочего исполняемого на жесткие аварии. Нет такой вещи, как «предупреждение».

+0

: S Я действительно смущен. То, что вы говорите, противоречит [описанию самого инструмента] (https://msdn.microsoft.com/en-us/library/62bwd2yd (v = vs.110) .aspx), а также мое понимание спецификация ECMA335. Например, у меня создалось впечатление, что не указывать '.locals init' просто не инициализировали локали, а не вызывают неопределенное поведение. – GregRos

+0

@ GreĝRos Ну, это зависит от того, ожидает ли JIT это, не так ли? Код, который не может быть проверен, не может быть проверен - просто. http://stackoverflow.com/questions/17645487/how-to-understand-these-paragraphs-in-emca-335-regarding-locals-init. Достаточно справедливо, это «иногда определенное поведение» ... (я бы просто не пошел на это). – atlaste

+0

Мне интересно, зачем вам это нужно в первую очередь. Если вы инициализируете его до нуля и затем что-то еще, то 0 init станет жертвой уничтожения мертвого кода. Практически во всех случаях я не ожидал, что вы получите что-либо от пропусков '.locals init' ... – atlaste

Смежные вопросы