Re: Nemiver fails assertion when remote debugging AVR target

[Dodji Seketeli <dodji seketeli org>]

Inductiveload <inductiveload gmail com> a écrit:

> Hi,

Hello,

Wow, I am amazed at how long it took me to follow-up on this message.  I
sincerely apologize for this embarrassing delay.

> I am trying to use Nemiver to debug an AVR program written in C and
> running on an XMEGA chip, which I know is not exactly a standard
> use-case, but it should still work, as it's basically just gdb as
> far as the debugger cares. I compile with avr-gcc and run AVaRICE as
> a gdb server. I can debug it with avr-gdb on the console, and in
> DDD. However, I'd quite like to use Nemiver for this. I start
> Nemiver with the following arugments:
>
> > nemiver --remote=localhost:4242 --gdb-binary=/usr/bin/avr-gdb program.elf
>
> I get the following error pop up:
>
> > Assertion failed: addr_range.min () != 0 && addr_range.max () != 0

I see.

> This assertion comes from
> src/persp/dbgperspective/nmv-dbg-perspective.cc:7762
>
> This problem occurs in Nemiver 0.93 and a fresh git build.
>
> The behaviour of avr-gdb and DDD is to break at "0x00000000 in
> __vectors ()" on startup. This zero address is presumably what
> triggers the assert failure here. Commenting the assertion out (c.f.
> patch) allows Nemiver to start normally. I'm not sure what you could
> use to say if a zero address is a sign of a problem or is normal
> behaviour like here?

Usually, low addresses, including zero, are not used, so that when you
see someone trying to do something with the address zero it's the sign
of a use of a non properly set variable or something like that.

That is why I put that assertion there, and until your message, nobody
complained :-)

But your case argues for Nemiver to support this, so I am committing the
patch below to the master branch.

Please note that it would have been nice to know your real name, to
refer to it in the patch.  The code snippet is really small so I don't
think there can be any significant copyright-related issue there.  But
still I think it's a good practice to give credit to people for their
work.

Thank you for your time and contribution.

> From aeaf16f1c412b0bb7015fb219b8ec147933ecedb Mon Sep 17 00:00:00 2001
From: Dodji Seketeli <dodji seketeli org>
Date: Sun, 14 Apr 2013 15:13:08 +0200
Subject: [PATCH] Allow disassembling from address 0

        * src/persp/dbgperspective/nmv-dbg-perspective.cc
        (DBGPerspective::disassemble_around_address_and_do): Allow
        Debugging at address 0 as some targets let meaningful stuff be
        placed there.  This is in response to a message started on the
        mailing list by an unnamed person which email address is
        Inductiveload <inductiveload gmail com>:
        https://mail.gnome.org/archives/nemiver-list/2013-March/msg00000.html.
---
 src/persp/dbgperspective/nmv-dbg-perspective.cc | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/persp/dbgperspective/nmv-dbg-perspective.cc b/src/persp/dbgperspective/nmv-dbg-perspective.cc
index d9760a9..6547439 100644
--- a/src/persp/dbgperspective/nmv-dbg-perspective.cc
+++ b/src/persp/dbgperspective/nmv-dbg-perspective.cc
@@ -7780,8 +7780,6 @@ DBGPerspective::disassemble_around_address_and_do
         return;
 
     Range addr_range (a_address, a_address);
-    THROW_IF_FAIL (addr_range.min () != 0
-                   && addr_range.max () != 0);
     // Increase the address range of instruction to disassemble by a
     // number N that is equal to m_priv->num_instr_to_disassemble.
     // 17 is the max size (in bytes) of an instruction on intel
-- 
                Dodji