LINUX.ORG.RU

Glibc 2.14

 ,


0

0

31-го мая вышла новая версия системной библиотеки Glibc-2.14
Изменения:

  • Исправлено более 90 ошибок
  • Реализация RPC объявлена устаревшей. На смену пришла TI-RPC
  • Поддержка программных интерфейсов новых версий ядра: clock_adjtime, name_to_handle_at, open_by_handle_at, syncfs, setns, sendmmsg
  • Новые локали: os_RU, bem_ZA, en_ZA, ff_SN, sw_KE, sw_TZ, lb_LU, wae_CH, yue_HK, lij_IT, mhr_RU
  • Новые кодировки: CP770, CP771, CP772, CP773, CP774
  • Новая утилита sotruss для отслеживания вызовов через PLT
  • Возможность установки хука на вызов malloc объявлена устаревшей и будет удалена в следующей версии

исходный код

>>> Подробности

★★★★

Проверено: JB ()
Последнее исправление: megabaks (всего исправлений: 1)

Ответ на: комментарий от geekless

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

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

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

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

arknir
()

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

Glibc 2.14

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

prishel_potrollit
()
Ответ на: комментарий от Ubuntu1104

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

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

dexpl ★★★★★
()

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

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

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

quantum-troll ★★★★★
()
Ответ на: комментарий от elverion

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

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

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

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

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

mcdebugger ★★
()
Ответ на: комментарий от AVL2

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

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

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


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

anonymous
()
Ответ на: комментарий от Reset

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

megabaks ★★★★
() автор топика
Ответ на: комментарий от megabaks

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

tazhate ★★★★★
()
Ответ на: комментарий от vadic

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

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

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

anonymous
()
Ответ на: комментарий от mcdebugger

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

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

AVL2 ★★★★★
()
Ответ на: комментарий от anonymous

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

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

AVL2 ★★★★★
()
Ответ на: комментарий от megabaks

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

vasily_pupkin ★★★★★
()

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

anonymous
()
Ответ на: комментарий от AVL2

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от vasily_pupkin

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

megabaks ★★★★
() автор топика
Ответ на: комментарий от anonymous

По хорошему, если уж копировать 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;
}

Как-то так.

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

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

vadic
()
Ответ на: комментарий от vadic

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

#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;
}
vadic
()
Ответ на: комментарий от vadic

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

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

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от vasily_pupkin

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

megabaks ★★★★
() автор топика
Ответ на: комментарий от megabaks

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

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

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

vasily_pupkin ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

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

vadic
()
Ответ на: комментарий от anonymous

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

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

vadic
()
Ответ на: комментарий от anonymous

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

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

vadic
()
Ответ на: комментарий от vadic

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

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

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

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

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

vadic
()
Ответ на: комментарий от AVL2

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

kernelpanic ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.