P.S. gdb наверное всё-таки не для восьмибиток, тем более виртуальных
Недосимулятр 8080 со встроенными asm/disasm/debugger
Moderator: Shaos
-
Lavr
- Supreme God
- Posts: 16803
- Joined: 21 Oct 2009 08:08
- Location: Россия
-
bar
- Senior
- Posts: 185
- Joined: 07 Aug 2006 10:18
Как это выглядит в протоколе remote-target я не скажу, потому что мне никогда в голову не приходило попробовать приконнектится telnet'ом к удалённому gdb. Но в command-line можно использовать команду info registers или что-нибудь вида "print $rax". А когда мне надо посмотреть дамп памяти, я обычно делаю это командой print с приведениями типов, примерно так: "p/x (*(unsigned*)$rsp)@256". p -- это сокращение команды print, /x говорит о том, что я хочу видеть числа в hex'е, в скобочках стоит чисто C'шное выражение, преобразующее число из $rsp к типу unsigned*, и затем разадресовывающее получившийся адрес, а @256 говорит о том, сколько элементов надо вывести.Shaos wrote:а как же смотреть регистры и дампить память?...
Ко всему этому в gdb есть команды stepi и nexti позволяющие трейсить программу по одной инструкции. И, наконец, gdb'шная команда break принимает в качестве аргумента адрес. Чуть не забыл, есть ещё команда disassemble, которая может кусок памяти перевести в ассемблерные мнемоники. То есть в gdb есть всё, чтобы отлаживать голый бинарь без какой-либо отладочной информации.
Не скрою, что gdb весьма неудобен для отладки при отсутствии отладочной информации, если при source-level отладке gdb вполне можно использовать через командную строку, то при "бинарной" отладке уже всё становится существенно хуже.
Но это же нам не очень важно: планов приделывать отладчик с command-line интерфейсом никто не строит. Нужен фронтенд, и есть у меня подозрение, что написать фронтенд к gdb не сильно-то и сложнее, чем непосредственно к симулятору. Но в случае с сорц-левел отладкой, этот фронтенд будет иметь массу вкусностей, типа вывода думпа памяти не в хексах, а примерно в таком виде:
Code: Select all
(struct my_string*){
{.len = 10, str = "hello"},
{.len = -1, str = "world"},
{.len = 1234, str = NULL},
}C восьмибитным AVR он справляется. С виртуальным. С simulavr.P.S. gdb наверное всё-таки не для восьмибиток, тем более виртуальных
-
Lavr
- Supreme God
- Posts: 16803
- Joined: 21 Oct 2009 08:08
- Location: Россия
Ну тогда - чур я поддерживаю ДОС-версию...Shaos wrote:Так что чтобы иметь поддержанными и линух, и дос, и твою винду номер 98, придётся всё городить самостоятельно...Lavr wrote:Ну это как-то уж слишком... слишком колхозно ещё и интерфейсы рисовать...Shaos wrote:Ввиду того, что я не большой любитель винды, а также в связи с тем, что я устал от постоянных гонок разных производителей юзерских интерфейсов для линуха, предлагаю весь юзер-интерфейс делать самостоятельно - на уровне пикселей.
Только в чём тогда смысл совместимости? У меня этот Вендоподобный интерфейс
"на уровне пикслей" вообще под QBasic был написан...
iLavr
-
bar
- Senior
- Posts: 185
- Joined: 07 Aug 2006 10:18
Только сейчас обратил внимание. По-ходу дела gtk забросил поддержку win9x в версии 2.6. Почему-то думал что они сделали это с переходом на 3.x, и искренне верил, что можно собрать всё на gtk+-2.24, который вероятно повторит историю gtk+-1.2, то есть будет поддерживаться майнтейнерами дистрибутивов долгие годы.Shaos wrote:Есть вроде достаточно стабильный порт GTK+ под винду (см. GIMP, который им пользуется и который кстати и подарил миру GTK+), однако:Так что чтобы иметь поддержанными и линух, и дос, и твою винду номер 98, придётся всё городить самостоятельно...You will need the GLib, cairo, Pango, ATK, gdk-pixbuf and GTK+ developer packages to build software against GTK+. To run GTK+ programs you will also need the gettext-runtime, fontconfig, freetype, expat, libpng and zlib packages.
....
The current GTK+ stack uses APIs that are available only on Windows 2000 or later. Long obsolete versions of GTK+ did run on Win9x and NT 4, too.
Экая факамаза...
