Author Topic: avr-gdb debugging and disassembly window  (Read 11935 times)

Offline radi

  • Single posting newcomer
  • *
  • Posts: 3
avr-gdb debugging and disassembly window
« on: April 08, 2017, 09:07:07 pm »
Hello to everyone.

I have a small, but a bit annoying issue with the avr-gdb debugging.

Debugging works as well as it should: I can step the code, see register values, etc. However, when code stops at a breakpoint disassembly window remains empty. If I'll use disassemble command then assembler code appears in the debugger log, but the disassembly window is still empty. Probably it will be simpler to understand the symptoms from the attached screenshot.

Is there a simple workaround to put disassemble code in the disassembly window automatically when the step is done?

I use Code::Blocks 16.01 (wx2.8.12) on Linux 64 bit with avr-gcc, avr-gdb and simulavr

Thank you in advance for help

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: avr-gdb debugging and disassembly window
« Reply #1 on: April 09, 2017, 12:51:29 am »
I doubt it. My guess is that the code understands only x86 assembly and it cannot parse the avr assembly.
I have no jtag cable, so I cannot reproduce this problem. :(
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline radi

  • Single posting newcomer
  • *
  • Posts: 3
Re: avr-gdb debugging and disassembly window
« Reply #2 on: April 09, 2017, 08:44:39 am »
Hi,

thanks for your reply. Do I understand right, that code::blocks debugger code understands only x86 assembly?

I didn't use jtag, I used emulated controller with simulavr. Settings as in this post
http://forums.codeblocks.org/index.php/topic,6819.msg53408.html#msg53408

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: avr-gdb debugging and disassembly window
« Reply #3 on: April 09, 2017, 11:30:32 am »
I don't think understand is the correct word. The debugger is gdb we're only a viewer and we use regular expressions to extract information we need. My guess is that some of the regexes fails because it get unexpected output.

Let me see if I can setup simulavr and try to debug this.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline radi

  • Single posting newcomer
  • *
  • Posts: 3
Re: avr-gdb debugging and disassembly window
« Reply #4 on: April 09, 2017, 12:12:51 pm »
OK, thanks for assistance.

I've browsed a bit the code of debugger plugin and now understand a bit better, what you told me about misunderstanding regexp. It feels that the problem comes (or initiates) from GdbCmd_DisassemblyInit::ParseOutput, because the debugger can not match expression "Stack level "  coming from "info frame" gdb command.

I checked manually this command in avr-gdb, and the output has "Stack level " expression in the beginning. So, the problem is either in parser itself or in getting the avr-gdb output to the parser input.

I don't have enough understanding of the code::blocks debugger plugin code to continue, so it will be great if you'll have some time to check it. Otherwise manual commands will do their work

Offline kenzanin

  • Single posting newcomer
  • *
  • Posts: 5
  • solderen.co.cc/forum
    • Forum electronika indonesia
Re: avr-gdb debugging and disassembly window
« Reply #5 on: May 25, 2018, 10:12:40 am »
Hi
Iam also have the same problem and i have to change this file
gdb_commands.h
-- static wxRegEx reDisassemblyInitFunc(_T("eip = (0x[A-Fa-f0-9]+) in ([^;]*)"));
++ static wxRegEx reDisassemblyInitFunc(_T("PC2 = (0x[A-Fa-f0-9]+) in ([^;]*)"));

            if(hexAddrStr.IsEmpty())
                //****NOTE: If this branch is taken, disassembly may not reflect the program's
                //actual current location.  Other areas of code will change the current (stack) frame
                //which results in $pc reflecting the eip(x86-based) of that frame.  After changing to
                //a non-top frame, a request (gdb 7.2 x86) to print either '$pc' or '$eip' will
                //return the same value.
                //So, there seems to be no way to obtain the actual current address in this (non-MI)
                //interface.  Hence, we can't get the correct disassembly (when the $pc does not
                //reflect actual current address.)  GDB itself does continue to step from the correct address, so
                //there may be some other way to obtain it yet to be found.
                m_Cmd << _T(" $pc");
            -- else if(wxT("0x") == hexAddrStr.Left(2) || wxT("0X") == hexAddrStr.Left(2))
            --  m_Cmd << wxT(" ") << hexAddrStr;
            else
       ++ m_Cmd << _T(" $pc");
            --  m_Cmd << wxT(" 0x") << hexAddrStr;

But this make pc gcc gdb fail to work
If you have other solution please let me know.
Thanks