Компания Google объявила (http://google-opensource.blogspot.ru/2016/05/xray-function-c...) о скором открытии исходных текстов проекта XRay (https://storage.googleapis.com/xray-downloads/whitepaper/XRa...), в рамках которого развивается система трассировки вызова функций в приложениях, активно используемая для отладки внутренних сервисов Google, таких как BigTable и движка контекстной рекламы. Система примечательна поддержкой динамической активации, позволяющей включать отладочный режим, создающий паразитную нагрузку, только при необходимости, в остальное время практически не создавая накладных расходов. Подобный подход позволяет использовать XRay для отладки высоконагруженных приложений в их естественной рабочей среде, где невозможно применение обычных систем отладки и профилирования.Основу XRay составляют добавляемые во время компиляции точки перехвата и динамически загружаемая библиотека. В обычном режиме точки перехвата работают как пустые заглушки ("nop sleds"), а библиотека может включаться и выключаться на лету, во время работы приложения. При включении библиотеки заглушки заменяются на вызовы предоставляемых библиотекой обработчиков, выполняющих операции детализированной трассировки. Подлежащие трассировке функции помечаются в исходных текстах через добавление специальных аннотаций ("__attribute__(...)");
Трассировка достаточно точно отражает все возникающие задержки вызова в условиях работы приложения в промышленной эксплуатации. Для изучения собранных данных подготовлен специальный аналитический инструментарий, в том числе позволяющий наглядно оценить возможные проблемы на графике. В ближайшие недели наработки XRay будут переданы (http://lists.llvm.org/pipermail/llvm-dev/2016-April/098901.html) сообществу LLVM.
URL: http://google-opensource.blogspot.ru/2016/05/xray-function-c...
Новость: https://www.opennet.ru/opennews/art.shtml?num=44387
Понапридумают же всякой фигни..
Пока читал заголовок, думал что о рейтрейсинге речь идёт.
Тоже
у меня в голове вообще автоваз всплыл
>Пока читал заголовок, думал что о рейтрейсинге речь идёт.Для моделирования рентгеновских снимков? о_О
А я подумал о трассировке лучей.
>>открытии исходных текстов проекта XRay
>В ближайшие недели наработки XRay будут переданы сообществу LLVM.Как это понимать? Откроют только для LLVM или "сообществу LLVM" будет оказана дополнительная помощь при разборе этого кода?
GCC уже не нужен гуглу.
а зачем это GCC ? у них есть высокие идеалы которые запрещают использовать плагины под GPL v2/MIT/BSDL вместе с последними версиями gcc... так что gcc в пролете.
уже прошло достаточно много времени существования llvm/clang и последнее не очень таки выстрелило, а именно уже сливает не только по среднему качеству кода, но и по скорости компиляции что изначально заявлялась как киллер фича. А какие-нибудь lldb так вообще полные дерьмища и им ещё лет 10 догонать gdb. В общем, помешательство на llvm/clang в скором будущем закончится.
Rust и Swift с вами не согласны
> В общем, помешательство на llvm/clang в скором будущем закончится.Ага, фантазируй больше. Всё только начинается ;)
Овощ, ты умеешь читать содержимое ссылок которые даёшь и в особенности дату публикации?
А что то изменилось в худшую сторону для clang?
PS: особо не надеюсь на здравомыслие, тут редко такое встретишь, обычно фанатизм людям заменяет мозг. И мысли чётко детско-максималистичные. Хотя бывают исключения.
PSS: естественно читал и ссылки в той статье и комментарии (тогда ещё), да и вообще за этой темой поглядываю.
Добро пожаловать на лор https://www.linux.org.ru/news/gnu/12552668
результаты измерений в треде
Не нашёл там особого здравомыслия. Один вообще не понятно какой замер и полтреда спецолимпиады по дисциплине "c++ vs pascal"
Ну вот http://www.phoronix.com/scan.php?page=article&item=clang-37-...
Что-то примерно равное.
> ОвощФрукт, ну на тебе ещё.
Если бы полтора года назад google напоролся бы на 'ужасный' clang
То наверно бы не было вот этого перевода Android NDK c gcc на clang в декабре 2015 года
> Основу XRay составляют добавляемые во время компиляции ... через добавление специальных аннотаций ("__attribute__(...)");Сколько же можно плодить такие велосипеды.
у тебя есть альтернатива?
Из известных systemtap, dtrace, lwtrace
Неосиляторы гугла сочли dtrace слишком сложным.
Согласен. Надо через #pragma.
по-другому невозможно при таком ТЗ.
вы просто не поняли огромности ее функций. Это круче дебаггеров.
это как дебаггер со скриптом но вместо интерпретатора скрипта там - скомпилированный код и оно может практич без потерь в производительности работать в продакшене
> это как дебаггер со скриптом но вместо интерпретатора скрипта там - скомпилированный код и оно может практич без потерь в производительности работать в продакшенеТо есть, DTrace
> это как дебаггер со скриптом но вместо интерпретатора скрипта там...Что ты мне тут эту херь втираешь? Точно так же работают все вышеобозначенные методы. Между ними и топиком есть только одно отличие - отсутствие поддержки со стороны компилятора, т.е. нужно несколько больше ручной работы. Но, с другой стороны, они допускают сложные параметрические пробы.
хмм, dtrace умеет делать подобное без каких либо указаний компилятору
подозреваю, что не всё так просто. dtrace, по-идее, может перехватывать только на границе функций, а если тебе нужно, скажем, один цикл внутри функции померять, то уже и не получится (нужно, чтобы в машинном коде появилось место для внедрения точки перехвата, соответственно нужно компилятору указать, в каких местах nop-инструкции ставить)
Для этого в dtrace можно эти самые точки (пробы) точно так же вставлять в код, компилировать и затем использовать по мере необходимости.
DTrace умеет это делать для любой инструкции, правда разрешено это для юзерспейсных приложений:$ /usr/sbin/dtrace -l -n 'pid$target::main:*' -c /bin/true
SystemTap еще умеет к строчкам кода привязываться