LINUX.ORG.RU

условный tracing межмодульных данных си

 ,


0

2

приветы. подскажите плз в какую сторону начать думать по следующему вопросу.

допустим, есть приложение на си, которое на вход получает некое сообщение состоящее из набора параметров a, b , c. Приложение модульное, сообщение прогоняется через несколько модулей и генерирует некоторый результат.

Возникла задача - как допустим принтэфить входные и выходные данные для каждого модуля для входного сообщения с определенным значением параметра а = A1. К примеру у приложения есть консоль, я подключаюсь к консоли и задаю режим trace и указываю параметр a = A1 и жду в консоли межмодульный трейс коррелирующий с A1

Вариант с постоянным if в коде как то не устраивает, думаю есть что то изящное и уже устоявшееся в мире.

в dbg ерланга такое из кообки даже для релиза

 с постоянным if

Используй декоратор;)

anonymous ()

Что значит постоянный if? Ты не хочешь что бы такая возможность оставалась в релизной версии программы? Тогда используй макросы

SR_team ★★★★ ()

Обычно в Си делают что-то типа такого

#ifdef DEBUG
void debuglog(...) {
    ...
    printf(...);
    ...
}
#else
void debuglog(...) {}
#endif
И если тебе нужны логи, то компилишь с флагом DEBUG. Но в рантайме переключать не выйдет, если тебе нужен рантайм.

Aswed ★★★★★ ()
Последнее исправление: Aswed (всего исправлений: 1)
Ответ на: комментарий от SR_team

постоянный if - это примерно если в каждом модуле сравнивать параметр а c величиной А1 и писать лог при a == A1. То есть этот if всегда должен быть, но так не хочется, хочется динамически включать этот if как бы включая DEBUG моде в рантайме.

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

А ты что, хотел магии?

Тебе уже сказали: спрячь if в макрос. Причем там не только сравнение с величиной будет, но и с флагом!

anonymous ()

uftrace умеет парсить параметры, можно либо её попробовать использовать, либо по аналогии сделать. Хотя имён параметров там нет (может в отладочной информации отсутствуют в принципе). Тут более старая версия, которая попроще (меньше кода и функциональности).

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

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

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

Очевидное решение для автора (полон тред инженеров): не нужно постоянно сравнивать параметры, достаточно сделать это один раз в нужной функции:

void log(...) { if not debug return else ... }
anonymous ()
Ответ на: комментарий от anonymous

Понятное дело — он выставит некий глобальный флаг на стадии анализа аргументов командной строки или терминала, но все равно внутри любой функции ему придется вызывать

…
if(fucking_flag) do_something;
…

anonymous ()

Как тебе изврат, вызывать необходимые функции через указатель.
При установке опции заменять указатель с функции на декоратор или на функцию с дебагом. :)

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

а потом avidemux пишет в .xsession-errors гигабайты данных и останавливается на out of space.

Только не останавливается, а зависает в ожидании, ставя колом всю систему в параллель.

dzidzitop ★★ ()
Последнее исправление: dzidzitop (всего исправлений: 1)
Ответ на: комментарий от kirk_johnson

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

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

Разумеетс, не нужно его писать всегда. Сделать флаг -d не так сложно.

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

Интересней инкрементальный флаг ввести. Моя надстройка над getopt умеет это делать. Скажем, ввел -v — получил первый уровень отладочных сообщений; -vv — второй и т.д.

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

Надстройка над getopt? В смысле

int verbose = 0;

...

switch (opt) {

...

case 'v':
        verbose += 1;
        break;

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

я не автор avidemux

а автор следует заветам ильича писать дебаг логи.

dzidzitop ★★ ()
Последнее исправление: dzidzitop (всего исправлений: 1)
Ответ на: комментарий от dzidzitop

Ну, автор делает это неправильно. Не стоит из-за этого советовать всем делать неправильно по-другому.

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

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

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

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

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

Не, в релизе этого говна не должно быть

Кто тебе сказал?

и отладочных символов

Ты не поверишь, но dwarf'ы стрипают и пихают в отдельный пакет почти во всех дистрибутивах.

А особенно говнеца которое багрепорты отправляет.

Понятия не имею, о чем ты.

kirk_johnson ★☆ ()

я подключаюсь к консоли и задаю режим trace и указываю параметр a = A1

Вариант с постоянным if в коде как то не устраивает

При этом приложение как-то должно распознать работает ли оно в режиме trace или без него и работать в соответствующем режиме (косвенные вызовы - тот же if по накладным расходам). Задача уровня «хочу изобрести вечный двигатель» (на самом деле можно патчить код работающего приложения, но, думаю, тебе такой вариант не подходит).

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

Хотя имён параметров там нет (может в отладочной информации отсутствуют в принципе).

Если отладочная инфа есть в принципе, то и имена там должны бы быть.

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

Очевидное решение для автора (полон тред инженеров): не нужно постоянно сравнивать параметры, достаточно сделать это один раз в нужной функции:

void log(...) { if not debug return else ... }

Причём чтобы уменьшить предполагаемые/возможные потери производительности, можно добавить подсказку unlikely():

void log(...) { if unlikely(debug_enabled) {...} else return;

gag ★★★★★ ()
if (opts.debug && msg.а == A1) {
  log_debug(...);
}

Опционально завернуть в #ifdef DEBUG, как выше писали.

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