LINUX.ORG.RU

когда нужен gdb ?


0

0

Вопрос который давно меня интересует. занимаюсь разработкой под linux, создано не одно приложение: такие как сервера, встроенные системы, драйвера устройств (вобщем далеко не баловство). и ни разу не приходилось пользоваться gdb. Все с помощью fprintf/printk как то обходиться. может я что то интересное пропускаю ? почему вы используете gdb, для чего, если используете ?

anonymous

Если нужно быстро найти глюк в чужом коде.

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

> если вы даавно пиите такие вещи и у вас ни разу ничего не падало - значит , вы крутой профессионал

Это мне ответ?

Я пользуюсь gdb регулярно, ибо развратил он меня. Раньше старался его избегать, но после того, как пришлось развивать большой чужой проект, вошло в привычку.

Die-Hard ★★★★★
()
Ответ на: комментарий от kto_tama

вот мне и интересно: "аристократ или дегенерат" :)

Ну и для чужого кода (старшно какого глючного) print использовал. Конечно может быть с gdb быстрее получилось - ну здесь ничего не могу сказать не пробовал.

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

А ещё можно использовать, чтобы понять, как же всё-таки работает алгоритм... :-)

yz
()

В однопоточном user-space гораздо удобнее printf, особенно когда пишется базовая часть системы, на следующих уровнях абстракци отладчик не нужен. Если думать по 100 раз перед каждой строкой исходника, отладчик не нужен. Ещё можно с самого начала писать printf/логи для любой теоретически возможной ошибочной ситуации, и тогда отладчик не нужен, но это неоправданная трата времени. По большому счёту gdb нужен тому, кто плохо знает систему и C или ленится. Во всех случаях, когда я находил ошибку под gdb, её можно было не делать с самого начала :)

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

>В однопоточном user-space гораздо удобнее printf

В однопоточном user-space gdb гораздо удобнее printf

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

> В однопоточном user-space гораздо удобнее printf, особенно когда пишется базовая часть системы, на следующих уровнях абстракци отладчик не нужен

Сразу видно бывалого профессионала :)

> Если думать по 100 раз перед каждой строкой исходника, отладчик не нужен.

А если думать 100000 раз перед каждой строчкой, программа уже не нужна.

> Во всех случаях, когда я находил ошибку под gdb, её можно было не делать с самого начала :)

Это да. Ну а ошибки, которые ты находил с помощью printf - их нужно было делать, да? 8)

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

>> Во всех случаях, когда я находил ошибку под gdb, её можно было не делать с самого начала :)

>Это да. Ну а ошибки, которые ты находил с помощью printf - их нужно было делать, да? 8)

ошибки были глупые

anonymous
()

Для получения бэктрейса/анализа коры. Поиска глупостей в чужих либах при глюках.

vasily_pupkin ★★★★★
()

Какая нахрен разница что юзать? Если ты используешь printf для отладки, значит таки допускаешь ошибки. И никуда ты от них получается не денешься. А как их искать это уже дело каждого.

Dudraug ★★★★★
()

Посмотри заголовок следующей темы - такие вещи сразу видны в отладчике :)

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

>> Во всех случаях, когда я находил ошибку под gdb, её можно было не делать с самого начала :)

>Это да. Ну а ошибки, которые ты находил с помощью printf - их нужно было делать, да? 8)

Гы! Достойная отповедь... Развеселил!

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

согласен с сейкеном и его классической точкой зрения на дебаг
правильное проектирование решает почти все вопросы отладки

kto_tama ★★★★★
()

Вестимо для чтения core (процессов и ядра).
А вы, OP, неужели сразу без ошибок свои драйвера пишите?

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

Куда же без ошибок, но printk хватает. Ну плюс еще ядро дает при ошибках back trace функций. В user приложениях система логов. Например приложение: маленькая базка данных, ну и к ней делаю функции dump_memory(), dump_tables(), ..... . Потом когда начинаем ее мучать и видим что падает в подозрительных местах используем эти функции. Еще один способ при падении чужого кода - коментируем половину подозрительного логически целого куска кода или расставляем fprintf (stderr - обязательно, stdout буферируется). Потом половину упавшей половины и т.д. - всегда так делаю пока помогает, особено в многопоточных приложениях.

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