linux-mips
[Top] [All Lists]

RE: Problems debugging multithreaded program wirh gdbserver via ser ial

To: "Daniel Jacobowitz" <dan@debian.org>
Subject: RE: Problems debugging multithreaded program wirh gdbserver via ser ial port
From: "Yoni Rabinovitch" <Yoni.Rabinovich@Teledata-Networks.com>
Date: Tue, 9 Nov 2004 18:08:47 +0200
Cc: <linux-mips@linux-mips.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org
Thread-index: AcTF9uhy1PNdWjCyRbSJLlefLizejgAfkIvg
Thread-topic: Problems debugging multithreaded program wirh gdbserver via se r ial port
>> Simultaneously, in the gdbserver session (via minicom) I see:
>> +$OK#9a

>Um.... you're running with a serial port open on the same port you're
>trying to debug on?  That can't work.  Use one for console and the
>other for gdbserver, or come to some other arrangement if your board
>only has one.

OK, thanks. I now have this sorted out. It seems the only way it agrees to work
is if I start gdbserver in a minicom session, and then kill -9 the minicom 
session, and then connect
with gdb.

So, now I have basic (command line) gdb <-> gdbserver working OK over the 
serial connection.

However, I am trying to run gdb from a GUI front end, which is running gdb/mi.
What I am seeing is that the GUI is invoking gdb/mi stack-info-depth, which 
seems to be
causing a memory exception in frame_register_unwind ("Cannot access memory at 
address 0x2c").
Thus, even though gdb is able to decipher the stack, the error at the end of 
the backtrace causes
the gdb/mi GUI to choke.

How can I work around this ?

Thanks !! 

<Prev in Thread] Current Thread [Next in Thread>
  • RE: Problems debugging multithreaded program wirh gdbserver via ser ial port, Yoni Rabinovitch <=