Glibc 2.14

>Дык это случай абсолютно обратный рассматриваемому.

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

Велосипед не мой, а Торвальдса.

Проблема в том, что и Торвальдс и разработчики glibc по-своему правы. Вопрос «кто правее» достаточно сложный.

Они не рубили совместимость.
Они изначально написали: 'знаете, если вы будете совать туда пересекающиеся куски, у вас будет грустно'.
Но программисты, использовавшие эти функции оказались идиотами. Это их проблемы, никак не glibc.

>>Исправлено более 90 ошибок

Glibc 2.14

А чё не glibc 3.0? Как-то выбивается из общего ряда последних новостей на ЛОРе. Непорядок.

В убунте и дебиане нет?-нет.значит не нужно.

В убунте и дебиане нет?-нет.значит не нужно.

Первая ассоциация

> В убунте и дебиане нет?-нет

Значит, убунта и дебиан не нужны. Ничего личного, просто симметричный ответ

Не велосипед, а мопед. Уважайте классику.

>В убунте и дебиане нет?-нет.значит не нужно.

Дурашка, а что такое libc6, по-твоему?

eglibc

> Исправлено более 90 ошибок
Немного меньше решето...

Новые кодировки: CP770, CP771, CP772, CP773, CP774

Спасибо им: раньше эти кодировки были нам недоступны, а вот теперь же они просто никому не нужны.
---
uClibc, elibc, bionic, musl, Plan 9 libc...

это glibc с переделанными скриптами сборки

>Проблема в том, что и Торвальдс и разработчики glibc по-своему правы. Вопрос «кто правее» достаточно сложный.

Вопрос прост. Glibc не является самоценным продуктом. Нет такой программы - glibc! Вся ее ценность определяется важностью ПО, которое с ним слинковано. И таких программ очень и очень много. Это основа системы.

Отсюда повышенные требования к стабильности. Любые изменения в столь важном проекте должны быть оправданы. Изменение поведения memcpy было ничем не неоправдано. Ладно, проморгали, попробовали, напоролись - ну так верните обратно! Нет, не вернули. Устроили срач. Молодцы.

Не совсем корректно.

Системная библиотека.ваш К.О

Да, давайте из-за каждой кривой поделки пьяного программиста менять стандартное поведение системных библиотек, работа рассматриваемых функций которых немногозначно расписана в документации.
NO WAY!
Это Вы лучше в Adobe жалобы пишите, почему они не почесались привести своё поделие в порядок, в соответствии с общепринятой документацией. Особенные, что ли?

прелинк ещё с 2.13-r1 нормально работает

во-первых прелинк
во-вторых бага была в глибц
т.е. гента тут вообще никаким боком

> Вся ее ценность определяется важностью ПО, которое с ним слинковано.
Да.

Ладно, проморгали, попробовали, напоролись - ну так верните обратно!

Нет, не вернули. Устроили срач. Молодцы.

Нет.
Они сделали всё верно: поставили на memcpy() версию.
Теперь, старые проги используют старую реализацию, но новые
сборки уже получают новую. Таким образом, проблема будет теперь
вылезать только у разработчиков. Это и есть самое верное решение
проблемы.

>это glibc с переделанными скриптами сборки
ну-ну

спасибо, родной :)
уже накатил и пользуюсь

По хорошему, если уж копировать 64битным movsq, то сначала надо хотя

бы один из операндов выровнять.

Полагаю, что проц сам в состоянии соптимизировать rep movsq, а
не тупо крутить цикл N раз. Всё же это одна команда, хоть и с
префиксом. А вот в вашем случае, команд было бы больше.
Кроме того, благодаря кешированию и префетчингу, кол-во обращений
ко внешней памяти, для данных, вероятно, не изменилось бы, а вот
для инструкций - возрастёт.
По крайней мере, уверяю вас, что Линус знает про оптимизацию
гораздо больше любого из ЛОРовцев, и раз он сделал именно так,
то тому были причины.

>Это Вы лучше в Adobe жалобы пишите, почему они не почесались привести своё поделие в порядок, в соответствии с общепринятой документацией. Особенные, что ли?

Одно другому не мешает. Лучи поноса в сторону Адоба пущены. Но еше раз, проблема не только в ПО Адобе и проблемы, к сожалению, не у Адобы, а у пользователей флеша.

>Они сделали всё верно: поставили на memcpy() версию. Теперь, старые проги используют старую реализацию, но новые сборки уже получают новую. Таким образом, проблема будет теперь вылезать только у разработчиков. Это и есть самое верное решение проблемы.

Это в этой версии сделали? Ну тогда теперь вопрос закрыт. Но осадочек все равно остался. Полгода же прошло...

Это в этой версии сделали?

В багзилле сделали:
http://sourceware.org/bugzilla/show_bug.cgi?id=12518#c14
А вот в какую версию это вошло, и вошло ли - увы, не в курсе.
Рскопаете - сообщите. :)

Да, прелинк, точно. Бага в глибц это круто, но когда бага садится мне на голову это проблема дистрибутива, а не пакета.

>bionic

x86_64?

Очевидно же, что не нужно :))

firefox 5.0b1-b3, transmission 2.30 рандомно крэшатся с glibc-2.14. С glibc-2.13 всё ок. Почините. А ещё glibc-2.14 не собирается с gcc-4.6.0, приходится патчить. Когда-нибудь будет написан glibc, который не придётся патчить для сборки?

Некоторые программы используют хак с memcpy для создания паттернов. Некоторые программы считают что при определенных видах пересечений блоков памяти все будет скопированно правильно.

Но это же потенциальные баги! При переносе такой софтины на другую платформу, где memcpy копирует от конца к началу эти чудо программы опять таки перестанут работать.

Поправить glibc , конечно, не сложно. Но поощрять хаки - глупая затея. Правильным будет либо стандарт изменить (прописать там, что memcpy всегда копирует с начала в конец, прописать поведение для перекрывающихся областей) и только потом менять код glibc

Аргументы Линуса , что, дескать, user dont care - мягко говоря , идиотизм.

И потом - чем больше софта начнет глючить из-за этого изменения memcpy, тем лучше. Тем быстрее баги в этих софтинках будут вычищены. И ведь в стандарте специально об этом написано - об undefined behaviour. Так нет, все похрен господам разработчикам. И Линус туда-же. Нет, чтобы на Адоб бочку покатить - покатил на glibc.

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

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

По хорошему, если уж копировать 64битным movsq, то сначала надо хотя бы один из операндов выровнять.

Полагаю, что проц сам в состоянии соптимизировать rep movsq, а не тупо крутить цикл N раз. Всё же это одна команда, хоть и с префиксом. А вот в вашем случае, команд было бы больше. Кроме того, благодаря кешированию и префетчингу, кол-во обращений ко внешней памяти, для данных, вероятно, не изменилось бы, а вот для инструкций - возрастёт.

Боюсь вы недопоняли (возможно, я недостаточно четко выразился). Мой пойнт в том, что многобайтные (в данном случае восьмибайтные) обращения к памяти происходят гораздо медленнее, если адрес не выравнен кратно количеству байтов.

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

Что касается цены, то она не так уж и велика: несколько инструкций чтоб сосчитать длину выравнивания, и один дополнительный короткий rep movsb:

#include <sys/types.h>

void *memcpy(void *dst, const void *src, size_t size)
{
    void *orig = dst;
//----------------------------
    int align = (-src) & 7;
    size -= align;
    asm volatile("rep ; movsb" :"=D" (dst), "=S" (src) :"0" (dst), "1" (src), "c" (align) :"memory");
//-----------------------------
    asm volatile("rep ; movsq" :"=D" (dst), "=S" (src) :"0" (dst), "1" (src), "c" (size >> 3) :"memory");
    asm volatile("rep ; movsb" :"=D" (dst), "=S" (src) :"0" (dst), "1" (src), "c" (size & 7) :"memory");
    return orig;
}

Как-то так.

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

Я думаю он особо и не задумывался об оптимизации этого куска.

Ну, и надо еще длину проверить, конечно:

#include <sys/types.h>

void *memcpy(void *dst, const void *src, size_t size)
{
    void *orig = dst;
//----------------------------
    int align = size > 7 ? (-src) & 7 : 0;
    size -= align;
    asm volatile("rep ; movsb" :"=D" (dst), "=S" (src) :"0" (dst), "1" (src), "c" (align) :"memory");
//-----------------------------
    asm volatile("rep ; movsq" :"=D" (dst), "=S" (src) :"0" (dst), "1" (src), "c" (size >> 3) :"memory");
    asm volatile("rep ; movsb" :"=D" (dst), "=S" (src) :"0" (dst), "1" (src), "c" (size & 7) :"memory");
    return orig;
}

Боюсь вы недопоняли (возможно, я недостаточно четко выразился).

Мой пойнт в том, что многобайтные (в данном случае восьмибайтные)

обращения к памяти происходят гораздо медленнее, если адрес не

выравнен кратно количеству байтов.

Я-то как раз вас понял, и утверждаю, что микрокод проца сам
способен сделать предложенную вами оптимизацию. И это будет
эффективнее, чем делать её вручную. К оптимизирующим компиляторам
все привыкли, но и процы сейчас уже давно не тупые чайники. И,
видя всего одну инструкцию, rep movsq, уж как-нить догадаются,
как её выполнить более оптимально, чем просто N раз цикл тупо крутить.
Вы, возможно, удивитесь, узнав, сколько оптимизации Интел засовывает
в свои кирпичики. Более другие производители считают, что об этом
компилятор должен заботиться, и разрабатывают архитектуры процов
с прицелом на оптимизацию компилятора. Но x86 - это наследие
мамонта, и вынести всю оптимизацию на откуп компилятора там нельзя.
По тому её встроили и в проц тоже.
Я утверждаю, что, скорее всего, ваш код реально не будет быстрее
Линусовского. На 386 - может и будет, но не на пне. +префетчинг и
кеширование.

Если же обращения идут к некэшируемой памяти, то замедление будет

существенным.

Да с чего вдруг? Особенно применительно к Адобе Флаш и прочим
пострадавшим прогам.

Смотри. Все просто. Софт с багом попал в репо => попал к пользователю => проблема дистрибутива.

понятно
свободен
в голову ты только ешь
проблема дистра - это дистроспецифичный баг

Хороший ты человек. Понимающий. Отравишься в кафешечке печеньем - проблема печенья. Читать этикетку надо было >_<

именно

кстати, 2.13 только в ~
понимаешь?
или никак?

Ну и чо? Оно ж уже в дистрибутиве, хоть и анстейбл

а то
это тестовая ветка - вот и тестят
в чём проблема?
тебя насильно заставили ставить?
я вот узнал о баге ---> замаскировал эту версию ---> поведал людям на лоре
всё хорошо

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

узнал о баге ---> проблема дистрибутива --> замаскировал эту версию ---> багрепорт в багзиллу дистрибутива --> ..

А так меня и генту никто насильно ставить не заставлял. Мог бы поставить CentOS там какой нибудь :]

>> Боюсь вы недопоняли (возможно, я недостаточно четко выразился). Мой пойнт в том, что многобайтные (в данном случае восьмибайтные) обращения к памяти происходят гораздо медленнее, если адрес не выравнен кратно количеству байтов.

Я-то как раз вас понял, и утверждаю, что микрокод проца сам способен сделать предложенную вами оптимизацию. И это будет эффективнее, чем делать её вручную. К оптимизирующим компиляторам все привыкли, но и процы сейчас уже давно не тупые чайники. И, видя всего одну инструкцию, rep movsq, уж как-нить догадаются, как её выполнить более оптимально, чем просто N раз цикл тупо крутить. Вы, возможно, удивитесь, узнав, сколько оптимизации Интел засовывает в свои кирпичики. Более другие производители считают, что об этом компилятор должен заботиться, и разрабатывают архитектуры процов с прицелом на оптимизацию компилятора. Но x86 - это наследие мамонта, и вынести всю оптимизацию на откуп компилятора там нельзя. По тому её встроили и в проц тоже.

Если это действительно так, то зачем вообще извращаться с делением, нахождением остатков и movsq? Написать rep movsb и пускай проц внутри себя оптимизирует.

Я утверждаю, что, скорее всего, ваш код реально не будет быстрее Линусовского. На 386 - может и будет, но не на пне. +префетчинг и кеширование.

Открою вам страшную тайну: ни в 386, ни в пне (до части четвертых) нет movsq. Это команда из amd64.

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

Да с чего вдруг? Особенно применительно к Адобе Флаш и прочим пострадавшим прогам.

А я понятия не имею, какие проги пострадали, и что и куда они там копируют.

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

Более другие – это вы про интеловский итаник? :)

> И, видя всего одну инструкцию, rep movsq, уж как-нить догадаются, как её выполнить более оптимально, чем просто N раз цикл тупо крутить.

Я, кстати, не уверен, что проц имеет право менять семантику обращений к некэшируемой памяти, например перекомбинировать их как-то.

Если это действительно так, то зачем вообще извращаться с делением,

нахождением остатков и movsq? Написать rep movsb и пускай проц

внутри себя оптимизирует.

А может, так и можно? А может, такую оптимизацию в проце не сделали,
зная, что все существующие библиотеки её делают сами. Надо проверять.

Открою вам страшную тайну: ни в 386, ни в пне (до части четвертых)

нет movsq. Это команда из amd64.

Хорошо, но оптимизацию это не отменяет.

Я, кстати, не уверен, что проц имеет право менять семантику обращений

к некэшируемой памяти, например перекомбинировать их как-то.

Но я ещё раз повторяю, что речь шла о кешируемой.
Это юзерспейс, а не ядро. Откуда тут некешируемая то?
mmap на /dev/mem или аналогичные примеры не приводить. :)

>> Если это действительно так, то зачем вообще извращаться с делением, нахождением остатков и movsq? Написать rep movsb и пускай проц внутри себя оптимизирует.

А может, так и можно? А может, такую оптимизацию в проце не сделали, зная, что все существующие библиотеки её делают сами. Надо проверять.

Если можно, зачем Линус писал с movsq?

Я, кстати, не уверен, что проц имеет право менять семантику обращений к некэшируемой памяти, например перекомбинировать их как-то.

Но я ещё раз повторяю, что речь шла о кешируемой. Это юзерспейс, а не ядро. Откуда тут некешируемая то?

Элементарный пример – блиты в/из фреймбуфера. По-хорошему ими должен dma engine в видюхе заниматься, но если драйвер не ускоренный (типа xorg-video-vesa или, например, консольный uvesa), придется блитить процом. Кроме того, возможно какие-то дрова из video4linux дают доступ к фреймбуферу в тюнере.

Пакет: dbus (1.5.2-1 и другие)
http://packages.debian.org/experimental/dbus

dbus (1.5.2-1) experimental; urgency=low

* Merge from unstable
* New(er) upstream version

 — Simon McVittie <smcv@debian.org> Wed, 01 Jun 2011 16:32:25 +0100

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