All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <dan@debian.org>
To: Yoni Rabinovitch <Yoni.Rabinovich@Teledata-Networks.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Problems debugging multithreaded program wirh gdbserver via serial port
Date: Mon, 8 Nov 2004 09:40:01 -0500	[thread overview]
Message-ID: <20041108144001.GA23783@nevyn.them.org> (raw)
In-Reply-To: <D6FAAE89E48C5B488B41BEBBDCD746CD09E7CE@tndcmail.Teledata.Local>

On Mon, Nov 08, 2004 at 04:11:32PM +0200, Yoni Rabinovitch wrote:
> Hi,
> 
>   I am trying to debug a multithreaded program running on an embedded MIPS 5Kc using gdb and gdbserver, connected via
> a serial port.
> 
>   My environment is as follows:
> 
>   MIPS kernel based on 2.4.18
>   gdb :  6.2.1, configured with --host=i686-pc-linux-gnu --target=mips-hardhat-linux --disable-sim --disable-tcl --enable-threads --enable-shared
>   gdbserver: 6.2.1, configured with --target=mips-linux --enable-threads --enable-shared
>   gcc : 3.2.3,     }
>   binutils : 2.13  }   Built using crosstool
>   glibc: 2.2.5      }
> 
>   My problems are as follows:
> 
> 1)  If I try to run the program from gdbserver (i.e. gdbserver /dev/ttyS0 wlsd), I get "readchar: Input/output error" messages,
> and nothing works. See attached file gdb_fail.
> What is going on here ?

It sounds like your serial port is messed up.

> 2) If I first run the program, and then attach gdbserver to it (i.e. gdbserver /dev/ttyS0 --attach 80), I can debug it. 
> However, debugging is amazingly slow !! 
> For example, it can take 10 minutes for the "backtrace" (bt) command to complete !!! 
> Also, I get messages saying "Cannot access memory at address 0x2c" whnever I try to look at the stack.
> See attached file gdb_trace.
> Why is it going so slow ?
> What is the cause of the "Cannot access memory at address 0x2c"  messages ?

GDB is confused by glibc's syscall stubs.  In general, don't worry
about errors at the end of backtraces.

> 3) If I repeat the scenario described in 2), but with "set debug remote 1", it seems to work somewhat faster
> (e.g. bt takes about 1 minute to complete).
> I am seeing alot of "Packet instead of Ack, ignoring it" messages.
> See attached file gdb_trace_debug.
> What do these messages mean ? 

Try "set debug serial 1" in addition - it's very verbose but maybe it
will tell you what the "packet" is.

-- 
Daniel Jacobowitz

  reply	other threads:[~2004-11-08 14:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-08 14:11 Problems debugging multithreaded program wirh gdbserver via serial port Yoni Rabinovitch
2004-11-08 14:11 ` Yoni Rabinovitch
2004-11-08 14:40 ` Daniel Jacobowitz [this message]
2004-11-08 16:36 ` David Daney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20041108144001.GA23783@nevyn.them.org \
    --to=dan@debian.org \
    --cc=Yoni.Rabinovich@Teledata-Networks.com \
    --cc=linux-mips@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.