How to become an author
Search
Write a publication
Pull to refresh

Comments 51

Проблема тут не в том, что в стек записываются данные до изменения rsp (смещение входит в red zone, там перед этим кодом ещё несколько изменений в rsp. Дело в том, что ядро собирается без red zone, а gcc это игнорирует при записи констант в стек и подразумевает, что код исполняется c red zone.
Total votes 32: ↑32 and ↓0+32
Линус как раз об этом и пишет дальше в письме, но Ализар решил не переводить почему-то.
Total votes 95: ↑95 and ↓0+95
Иначе он не был бы alizar'ом
Total votes 24: ↑21 and ↓3+18
Только могу себе представить, что это за ужасное чувство когда Линус Торвальдс говорит что то подобное про твою программу
Total votes 68: ↑67 and ↓1+66
Ваш код никогда не ругали? Вы сразу начали писать чистый код по феншую? За что то из прошлого, мне очень стыдно, он работает до сих пор, но я надеюсь, этого никто не увидит.
Total votes 27: ↑9 and ↓18-9
>Линус Торвальдс говорит про твою программу
Total votes 80: ↑78 and ↓2+76
Зато как говорит! Читать интересно
Total votes 7: ↑5 and ↓2+3
Знал, что доверять gcc который непонятно кто разрабатывает (в ссср такую форму собственности называли колхоз) — нельзя.
Удивлен, что gcс вообще как-то работает.
Total votes 123: ↑13 and ↓110-97
UFO just landed and posted this here
«дэ-эс-эс» тоже признак, наверное…
Total votes 2: ↑1 and ↓10
Назовите компилятор, которому вы доверяете, и имена хотя бы трех человек, которые его разрабатывают.
Total votes 9: ↑9 and ↓0+9
UFO just landed and posted this here
по большому счету, доверять нельзя никому.

с gcc 4.6 лично натыкался на баги компиляции.
Total votes 1: ↑1 and ↓0+1
Возможно, доверия заслуживает CompCert (wiki, compcert.inria.fr/, вход — подмножество Си, выход — ассемблер PowerPC/ARM/x86) — формально верифицированный компилятор. Один из авторов — Xavier Leroy — разработчик OCaml, ранее — разработчик LinuxThreads (библиотеки эмуляции posix threads для ранних версий glibc под linux — 1998-2004). Презентация о компиляторе: research.microsoft.com/en-us/um/redmond/events/ss2011/slides/friday/xavier_leroy.pdf На верификацию ушло 4 человеко-года и 50000 строк Coq.
Total votes 2: ↑1 and ↓10
То ли дело ICC.
Всё продумано, всё разумно, даже стандарт Cripple AMD поддерживается.
Total votes 7: ↑6 and ↓1+5
ни в коем случае не использовать этот компилятор,

В оригинале говорится о конкретной версии компилятора, а не о компиляторе в целом.
nobody compiles with gcc-4.9.0
Total votes 18: ↑18 and ↓0+18
Я вот прочитал пост, но так и не понял, в чём суть проблемы, какая часть компилятора работает неправильно и какая особенность компилятора приводит к багам (буду рад, если кто-то мне это пояснит ответом на этот комментарий).

Мне кажется, в данном посте стоило разъяснить именно суть проблемы, пояснить используемые термины (например, термин «непосредственная константа», который на русском языке почти не гуглится; ведь средний уровень знаний читателей поста немного ниже, чем уровень разработчиков ядра Linux из рассылки), а не использовать громкие фразы вроде: «Линус Торвальдс сказал, что GCC — дерьмо.&raquo Не думаю, что человеку будет приятно, когда его отрицательный отзыв о компиляторе из технической рассылки, вырванный из контекста (где речь идёт о конкретной версии), сейчас растиражирует весь Интернет.
Total votes 16: ↑16 and ↓0+16
Мне пришлось гуглить и разбираться, потому что дико интересно, и я ничегошеньки из статьи не понял. Если я не прав, пусть меня поправят знающие люди.

Проблема в порче стека в этом куске кода:
movq $load_balance_mask, -136(%rbp) #, %sfp
subq $184, %rsp #,


rbp указывает на начало стека, rsp — на его вершину.
Так вот, сначала gcc записывает константу за пределы стека, глубоко вниз, 136 байт от начала; и только потом изменяет размер стека, поменяв указатель на вершину стека. Если между двумя этими операциями произойдет прерывание, стек может быть испорчен.

Почему gcc так делал? Возможно, потому что он считал, что работает в «красной зоне».

Тут стоит процитировать AMD64 ABI:
Скрытый текст
The 128-byte area beyond the location pointed to by %rsp is considered to be reserved and shall not be modified by signal or interrupt handlers. Therefore, functions may use this area for temporary data that is not needed across function calls. In particular, leaf functions may use this area for their entire stack frame, rather than adjusting the stack pointer in the prologue and epilogue. This area is known as the red zone.


АМД рекомендует сохранять 128 байт перед rsp, как «красную зону», неприкасаемую для прерываний. Это позволяет использовать стек, не изменяя его размера, что бывает полезно при оптимизациях. Т.е. виртуально стек становится на 128 байт больше.

Но ядро линукса компилируется с флагом -mno-red-zone, без использования «красной зоны», а код, создаваемый gcc подразумевает её использование. Т.е. gcc в какой-то из оптимизаций проигнорировал этот флаг, и записал данные за пределы стека.

Как по мне — этот баг не заслуживает эпитетов «неизлечимо сломан», «чистое и полное дерьмо», ну и так далее.
Total votes 43: ↑42 and ↓1+41
P.S. Похоже, что баг был непосредственно в определении, когда класть константу на стек, а когда изменять размер этого стека, но из-за «красной зоны», этот баг не проявлялся в 99% приложений.
Total votes 2: ↑2 and ↓0+2
Смысл в том, что константу вообще можно было никуда не записывать. В нормальных условиях спиллинг применяется для переменных, а константу можно просто запомнить а потом применить в том месте, где производится загрузка значения для использования.

Наблюдаемое же поведение компилятора теряет производительность на пустом месте, организуя совершенно не нужное чтение из памяти (да еще и с нарушением настроек red zone).
Total votes 11: ↑10 and ↓1+9
Вот, теперь когда я благодаря вам знаю, что такое spilling, вся картина для меня стала понятной.
Спасибо.
Total votes 3: ↑3 and ↓0+3
Смысл все-таки в неправильной последовательности действий. Спиллинг константы хоть и глупое, но все же корректное поведение.
This comment wasn’t rated yet0
Разумеется. Объективно, проблема только одна — несоблюдение настройки red zone. Если она включена, то компилятор вполне имеет право поменть операции местами.
This comment wasn’t rated yet0
Если я правильно понял этот пост, то red zone никак не учитывается в этом коде (ни её наличие, ни её отсутствие). Похоже её включение просто скрывало этот баг до поры.

Но это пост не от разработчика gcc, так что он может ошибаться.
This comment wasn’t rated yet0
Господи, да этому компилятору нельзя ещё выходить из детского сада. Мы говорим о дебиле, которого в детстве уронили головой — такой здесь уровень задержки в развитии
После таких слов, мне как то стало жаль этот компилятор!
Total votes 28: ↑27 and ↓1+26
Компиляторы не предупреждают Линуса Торвальдса, Линус Торвальдс предупреждает компиляторы.
Total votes 58: ↑58 and ↓0+58
Открытый Линусом баг 61904 (gcc bugzilla) был закрыт как дубликат бага 61801. 61801 существовал в версиях gcc с 4.5.0 по 4.8.3, 4.9.0 и 4.9.1 (однако до 4.9.0 ошибка не приводила к спиливанию константы в коде load_balance). Исправлено начиная с 4.8.4, 4.9.2, 4.10.0. Патч — одна строчка в sched_analyze_2.
Total votes 36: ↑35 and ↓1+34
Вот вам и ализаровское «неизлечимо сломан»
Total votes 8: ↑6 and ↓2+4
Вот вам и линусовое «неизлечимо сломан»
This comment wasn’t rated yet0
Блин. Не, я, конечно, всё понимаю, ситуация нехорошая, но так отзываться о обычном баге? Не слишком ли Линус несдержан? Баги были, есть и будут. В том числе и очень трудноуловимые, уж он то должен это знать!
Total votes 24: ↑21 and ↓3+18
Я так думаю, что не стоит приравнивать написанное в письме в рассылке к «официальному заявлению». Это даже не дотягивает до записи в бложик, не говоря уже о статье в каком-нибудь журнале.
А выхватывать цитату из контекста — это стиль современной журналистики.
Total votes 10: ↑8 and ↓2+6
В оригинальном баг репорте нет никакой истерики. Всю драму развели в репостах.

Линус обозначил проблему и удивился, какого хрена компилятор вообще спилит константу, что является абсолютно резонным вопросом.
Total votes 8: ↑8 and ↓0+8
В баг репорте уже всё цивильно. А вот в обсуждении по почте были как раз выражения из этого поста. Судя по всему он провел несколько часов (дней?) собирая ядро новым компилятором и не мог понять какой из коммитов в ядра так сильно всё поломал. И в конце концов он полез смотреть ассемблерный код, и сравнивать его с исходниками, чтобы понять почему оно работает не так как надо. После детального изучения стало ясно что баг в свежем gcc, а не в ядре, ну и тут понеслась.
Total votes 14: ↑14 and ↓0+14
Ну, его вполне можно понять. Любой баг в программе это проблема, нервное напряжение и плохое настроение. Особенно если это гейзенбаг. Особенно если оказывается, что он в компиляторе, проверять который программист полезет только в последний момент, когда уже испробовано все.

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

P.S.: Послушать разговоры в офисе при сдаче очередного релиза, так вообще каждого второго можно расстрелять за преступления против человечества.
Total votes 27: ↑26 and ↓1+25
Это внутренний список рассылки разработчиков ядра, исключительно внутреннее общение (разве что выставленное на всеобщее обозрение). Примерный аналог разговора коллег в офисе (или в каком-нибудь мессенджере). Так что еще очень мягко :)
Total votes 3: ↑2 and ↓1+1
В этом примере Линус просто «возвращает» оппоненту его же стиль общения в первой фразе. Остальные доводы хоть и эмоциональны, но вполне корректно сформулированы.
Total votes 1: ↑1 and ↓0+1
Да, это письмо интереснее :)
Total votes 2: ↑2 and ↓0+2
Пускай и несдержан, зато не болен толерантностью головного мозга, что на мой взгляд на много лучше.
This comment wasn’t rated yet0
Really = Реально.
Никогда так больше не переводи.
Total votes 14: ↑10 and ↓4+6
Мне показалось, в контексте «разборок по понятиям» это наиболее подходящий вариант. :)
Total votes 11: ↑8 and ↓3+5
Тогда уж и «в натуре» можно, ёпта.

Страна победившего блатняка, Линус у нас «по понятиям» уже «разбирается».
Total votes 17: ↑15 and ↓2+13
Скажите, а почему gcc поменял местами эти инструкции, если указатель кадра и указатель стека все равно не приравниваются (тут, в этом куске по крайней мере). Т.е. и rbp и rsp определены заранее, раз компилятор так запросто опирается на rbp до rsp -> rbp.
В чем оптимизация, как можо что-то выиграть, записывая в стек до изменения указателя? Так лучше загружается конвейер?

Если бы (лучше знаком с IA32), было бы так:
sub esp, 64
mov ebp, esp
mov [ebp + 12], xyz

все бы три инструкции выполнялись последовательно, т.к. каждая последующая зависит от результатов предыдущей. Если (не помню точно ни по тактам, ни по спариванию в разных пайпах) пересылка регистр-регистр, выполняется за 1 такт, а вычитание — за большее кол-во, был бы смысл менять местами, заранее прибавляя к ebp константу с учетом того, что esp подвинется позже.

Но в обсуждаемом куске? Я что-то упускаю?
This comment wasn’t rated yet0
В чем оптимизация, как можо что-то выиграть, записывая в стек до изменения указателя?

Можно работать со стеком, не меняя значение указателя, экономя на командах push/pop. В данном случае — похоже, просто баг, а не излишняя оптимизация.
This comment wasn’t rated yet0
экономя на командах push/pop

Это понятно, здесь же mov через кадр. Но, как я понимаю из статьи, баг именно в очередности операций и прерывании, которое поступает между инструкциями. Пытаюсь понять, чего хотел gcc достичь.
This comment wasn’t rated yet0
Линус Торвальдс показал варнинг компилятору.
Total votes 11: ↑11 and ↓0+11
Прошел год, баг до сих пор не закрыт. Недавно наткнулся на то, что gcc просто рандомно выкидывает ссылки из код на C++, segfault как итог…
Total votes 1: ↑0 and ↓1-1
Sign up to leave a comment.

Articles

Show the best of all time

Your account

Sections

Information

Services

Support
© 2006–2024, Habr