Emacs в качестве GUI для GDB, или небинарная совместимость

Всем здравствуйте.

На снимке – эксперименты, являющиеся продолжением вот этой темы.

Как уже не в первый раз убеждаюсь, утилита strace с ключом -k (печатать stack trace каждого вызова) – прекрасный инструмент для первичного (грубого) поиска проблемы. Собственно, именно таким способом было выяснено, что на Debian 9 и Debian 10+ поведение java начинает различаться, начиная с инструкции <open64_w+22> из libhpi.so. В результате последовательность

b main
r
b open64_w
cont

позволяет вплотную подобраться к проблеме, но уже ~~пер-ректально~~ «изнутри».

На снимке – сравнение консольного интерфейса GDB (слева) и Emacs (справа). Если честно, Emacs’ом для отладки пользовался в первый раз в жизни – и он мне понравился. Понравился даже больше, чем старик DDD, который умные люди используют для полноценной визуализации данных в памяти, но вот мне самому как-то не доводилось.

В чём ценность cgdb как обёртки над gdb, особенно в отсутствие исходного кода, – я так и не понял. Если у вас есть успешный ~~успех~~ опыт использования cgdb – поделитесь, пожалуйста. Аналогично, xxgdb, наверное, хорош – но для того, чтобы он завёлся в 2023 году, мне надо выкинуть из ~/.gdbinit буквально всё.

За каким рожном нужен убогий и деревянный как Буратино Nemiver, по недосмотру появившийся в пакетах Debian и заявляющий в качестве ключевых особенностей совместимость с GNOME 3 и умение скопировать значение переменной в буфер обмена (я не шучу: «Ability to copy the content of a variable into the GTK clipboard») – я тоже не понял. Зачем, если есть прекрасный Emacs?

В сухом остатке: насколько я понял, ebp + 0x8, ebp + 0xc и ebp + 0x10 – это адреса параметров функции. По первому адресу лежит строка, и строка эта на Debian 9 и Debian 10 разная: