GDB не может. Как ему помочь?

Команда ″file″ что говорит про ваш /home/user/Development/playground/test ?

$ file _playground/test
_playground/test: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /nix/store/lmn7lwydprqibdkghw7wgcn21yhllz13-glibc-2.40-66/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.10.0, with debug_info, not stripped

Это просто бинарник, без особой магии. Если запускать напрямую без GDB, всё корректно отрабатывает.

А что за система, ядро, опции?

Если система с какими-то нестандартными защитами от хакеров, типа запрета записи в память с кодом процесса, то понятно, что работать не будет, потому что GDB меняет код вставляя инструкцию (точно не помню, кажется, какое-то прерывание), чтобы реализовать остановку в нужном месте.

А что за система, ядро, опции?

NixOS. Ничего необычного.

Если система с какими-то нестандартными защитами от хакеров, типа запрета записи в память с кодом процесса, то понятно, что работать не будет, потому что GDB меняет код вставляя инструкцию (точно не помню, кажется, какое-то прерывание), чтобы реализовать остановку в нужном месте.

LLDB-то работает. Другие бинарники GDB пережёвывает с различным успехом, хотя ругань про «Cannot access memory at address» остаётся.

См: https://wiki.gentoo.org/wiki/Hardened/Debugging

У меня не используется PaX. И, повторю, LLDB работает. Проблема есть только с GDB.

Да, мне по каким-то причинам (скор?) нельзя часто отправлять или редактировать сообщения, это было вдогонку к предыдущему, до того, как увидел ответ.

В общем, оказывается, сейчас помимо software breakpoints (замена инструкции на int 0x3) есть hardware breakpoints через регистры процессора.

Попробуй в GDB вместо break hbreak. Если сработает - значит проблема точно в защите памяти процесса от записи.

оказывается, сейчас помимо software breakpoints (замена инструкции на int 0x3) есть hardware breakpoints через регистры процессора.

Ты пишешь к нам из 1980-ого года? Когда услышишь про битки - закупайся!

Если сработает - значит проблема точно в защите памяти

Ровно наоборот.

меня глючит или playground/test и _playground/test вообще говоря разные файлы ?

не знаю какая там каша заварена в NiX`os, это могут быть их проблемы. С файловыми системами там нахреноверчено

меня глючит или playground/test и _playground/test вообще говоря разные файлы ?

Сорри, криво скопипастил. Это один и тот же файл.

не знаю какая там каша заварена в NiX`os, это могут быть их проблемы. С файловыми системами там нахреноверчено

Как это проверить?

NixOS

Почему я не удивлен

Как это проверить?

собирать нетленку в стейбл-Debian..для old-фагов в Слаке..

и там собственно билдить/отлаживать

Nix`os и прочая экзотика это уже порты, когда всё готово и точно работает.

собирать нетленку в стейбл-Debian..для old-фагов в Слаке..

Что? Это моя рабочая система, я пытаюсь отладить прогу, над которой работаю. Ты предлагаешь мне дистрибутив менять? Нет уж, спасибо.

Nix`os и прочая экзотика это уже порты, когда всё готово и точно работает.

Ну вот GDB похоже не очень работает и не готов для десктопа. Придётся переходить на LLDB, который смог.

Я тоже уверен, что тут как-то причастен NixOS. Набросал сейчас простую программу на C, запустил под GDB, breakpoint отработал без проблем.

Я бы посоветовал искать ответ где-нибудь в NixOS community.

Я тоже уверен, что тут как-то причастен NixOS

Возможно. Вопрос только в том, как именно он может быть причастен-то? Куда это вообще копать, кроме как в сторону «уже третий год слышу непонятный стук»?

Вангую там по дефолту какое-то защищенного ядро стоит, которое gdb мешает

Я думаю, что для начала стоило бы привести: версию ядра, версию gcc, версию gdb, содержимое /proc/config.gz.

LLDB работает. GDB тоже работает на некоторых бинарниках. А на некоторых не работает. А на некоторых работает, но с кучей ошибок. Вот пример с тупым сишным hello world:

(gdb) b main
Breakpoint 1 at 0x401135: file helloworld.c, line 5.
(gdb) run
Starting program: /home/void/Development/C/helloworld 
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
[New LWP 167390]
[LWP 167390 exited]
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
Cannot access memory at address 0x1c
Cannot access memory at address 0x14
Cannot access memory at address 0x14
[New LWP 167391]
[New LWP 167392]
[New LWP 167393]
[LWP 167393 exited]
[LWP 167392 exited]
[LWP 167391 exited]
process 167387 is executing new program: /home/void/Development/C/helloworld
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/nix/store/lmn7lwydprqibdkghw7wgcn21yhllz13-glibc-2.40-66/lib/libthread_db.so.1".

Thread 1 "helloworld" hit Breakpoint 1, main (argc=1, argv=0x7fffffff08d8)
    at helloworld.c:5
5           printf("Hello, %s\n", "LOR");
(gdb) c
Continuing.
Hello, LOR
[Inferior 1 (process 167387) exited normally]

Ядро: 6.5.10, конфиг: https://b.opnxng.com/?69aaf7f9bb71b544#DwVVTvXUaiDwAkERqNkMuwap6hFrvuYrDGQ1WyVNEK8e

GCC: 15.1.0

GDB: 16.3

С файловыми системами там нахреноверчено

А не может ли такого быть, что библиотеки из одной версии чего-нибудь, а gdb из другой? И gdb тупо не туда пытается прицепится из-за этого.

Я в nix не силён.

и вот этот /home/user/Development/playground/test был собран вот только что на этой же машине и gdb не работает ?

у мне бывали ошибки типа «Cannot access memory» если бинарь «не родной», возможно у тебя другое, просто предположил

(gdb) b main
Breakpoint 1 at 0x406873

Cannot access memory at address 0x40686f

Странно, правда, что адреса разные? А что скажет p main? А x /10i 0x406873 и x /10i 0x40686f? А аналогичные команды на том же бинарнике в LLDB?

Пожалуйста, покажите, как Вы собираете этот бинарник.

Файл gdbinit большой? Если без него попробовать (опция -n)?

И меняется ли что-то, если вместо ″b main; run″ делать ″start″ или ″starti", а потом «run»?

Файл gdbinit большой? Если без него попробовать (опция -n)?

Пробовал с пустым. Ничего не меняется.

И меняется ли что-то, если вместо ″b main; run″ делать ″start″ или ″starti", а потом «run»?

start так же валится. starti успешно ставит breakpoint в самом начале в _start, но если сделать n, программа прорабатывает полностью и завершается корректно. Новые breakpoint ставить не выходит из-за той же ошибки.

А что скажет p main? А x /10i 0x406873 и x /10i 0x40686f?

(gdb) p main
$1 = {<text variable, no debug info>} 0x40686f <main>
(gdb) x /10i 0x406873
   0x406873 <main+4>:   push   %rbx
   0x406874 <main+5>:   sub    $0x88,%rsp
   0x40687b <main+12>:  mov    %edi,-0x84(%rbp)
   0x406881 <main+18>:  mov    %rsi,-0x90(%rbp)
   0x406888 <main+25>:  mov    0x4389d1(%rip),%rax        # 0x83f260 <defaultRtsConfig>
   0x40688f <main+32>:  mov    0x4389d2(%rip),%rdx        # 0x83f268 <defaultRtsConfig+8>
   0x406896 <main+39>:  mov    %rax,-0x80(%rbp)
   0x40689a <main+43>:  mov    %rdx,-0x78(%rbp)
   0x40689e <main+47>:  mov    0x4389cb(%rip),%rax        # 0x83f270 <defaultRtsConfig+16>
   0x4068a5 <main+54>:  mov    0x4389cc(%rip),%rdx        # 0x83f278 <defaultRtsConfig+24>
(gdb) x /10i 0x40686f
   0x40686f <main>:     push   %rbp
   0x406870 <main+1>:   mov    %rsp,%rbp
   0x406873 <main+4>:   push   %rbx
   0x406874 <main+5>:   sub    $0x88,%rsp
   0x40687b <main+12>:  mov    %edi,-0x84(%rbp)
   0x406881 <main+18>:  mov    %rsi,-0x90(%rbp)
   0x406888 <main+25>:  mov    0x4389d1(%rip),%rax        # 0x83f260 <defaultRtsConfig>
   0x40688f <main+32>:  mov    0x4389d2(%rip),%rdx        # 0x83f268 <defaultRtsConfig+8>
   0x406896 <main+39>:  mov    %rax,-0x80(%rbp)
   0x40689a <main+43>:  mov    %rdx,-0x78(%rbp)

А аналогичные команды на том же бинарнике в LLDB?

(lldb) p (int(*)(int,char**)) main
(int (*)(int, char **)) 0x000000000040686f
(lldb) di -s 0x406873
test`main:
test[0x406873] <+4>:  pushq  %rbx
test[0x406874] <+5>:  subq   $0x88, %rsp
test[0x40687b] <+12>: movl   %edi, -0x84(%rbp)
test[0x406881] <+18>: movq   %rsi, -0x90(%rbp)
test[0x406888] <+25>: movq   0x4389d1(%rip), %rax ; defaultRtsConfig
(lldb) di -s 0x40686f
test`main:
test[0x40686f] <+0>:  pushq  %rbp
test[0x406870] <+1>:  movq   %rsp, %rbp
test[0x406873] <+4>:  pushq  %rbx
test[0x406874] <+5>:  subq   $0x88, %rsp
test[0x40687b] <+12>: movl   %edi, -0x84(%rbp)
test[0x406881] <+18>: movq   %rsi, -0x90(%rbp)
test[0x406888] <+25>: movq   0x4389d1(%rip), %rax ; defaultRtsConfig

Одно и то же показывают.

Пожалуйста, покажите, как Вы собираете этот бинарник.

Это выхлоп кастомной сборки GHC. Я работаю над добавлением пары фич в компилятор. Сам код не то чтобы важен, там вызываются только сишные puts и exit и код сборки мусора. Не очень понимаю, как что-то из этого может мешать работе GDB.

и вот этот /home/user/Development/playground/test был собран вот только что на этой же машине и gdb не работает ?

Да.

у мне бывали ошибки типа «Cannot access memory» если бинарь «не родной», возможно у тебя другое, просто предположил

Нет, это родной бинарь для amd64. Выхлоп file выкладывал выше.

Надо посмотреть, как на это влияет aslr (set disable-randomization), и такие флажки компилятора, как -fpic/-fpie и их антагонисты.

Это выхлоп кастомной сборки GHC.

Проверь на выхлопе обычного сишного компилятора.

Проверил. Аналогичная срань.

Но мне что-то кажется, если GDB не может дебажить просто любой бинарник, то его пора закапывать. Этот проект бесполезен.

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

Клоун, ну работай по своим представлениям дальше.

Если ты мне сейчас хочешь тут начать залечивать, что GDB не умеет с PIE и ASLR работать, то это ещё большее днище а не отладчик.

мне что-то кажется, если GDB не может дебажить просто любой бинарник, то его пора закапывать. Этот проект бесполезен.

Оправдываешь амплуа Ъ-хаскелиста - если у тебя на локалхосте всё через жопу и в говне, то виноват весь мир кругом, а ты - весь в белом.

Оправдываешь амплуа Ъ-хаскелиста - если у тебя на локалхосте всё через жопу и в говне, то виноват весь мир кругом, а ты - весь в белом.

Это было бы так, если бы у меня на локалхосте не было другого популярного отладчика, который бы отлично работал. Серьёзно, если бы LLDB тоже сыпал ошибками, я бы полез копать в сторону проблем с системой. Но LLDB работает вообще без проблем, а GDB не работает.

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

Если есть идеи, что именно может портить GDB карму,

Ломать не строить - полный перечень не влезет в базу лора.

мне тут предложили только сменить дистрибутив

Если бы ты был квалифицированным специалистом по своему дистрибутиву, способным самостоятельно диагностировать и исправлять ошибки в нём, наверное ты бы мог пренебречь этим советом. Возможно так же, что тот факт у всех вокруг на всех «типовых» дистрибутивах от дебьяна до склаквари GDB работает без проблем, тоже может быть как-то с этим связан.

Но я лично так конечно же не считаю - если у тебя всё работает, то где вызов? Где преодоление трудностей? Где укрощение кремниевого чудища, в конце-то концов? Где ощущение себя настоящим линуксоидом? А когда ты просто запускаешь GDB и он работает - это как-то скучно и не интересно. Даже тему на форуме в интернете не создать.

Если есть идеи, что именно может портить GDB карму,

Ломать не строить - полный перечень не влезет в базу лора.

Обожаю ЛОР за это просто потрясающую клоунаду! Скучал по этому месту.

Где ещё в интернете ты найдёшь людей, у которых на компьютере не работает GDB? Только тут, на лоре. Воистину уникальное место.

Где ещё в интернете ты найдёшь людей, у которых на компьютере не работает GDB? Только тут, на лоре.

Что лишний раз доказывает, что ты мало пользовался GDB и только в ограниченном количестве случаев. Заставить его падать с сегфолтом вообще ни разу не сложно, достаточно скормить ему бинарник пожирнее.