From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: antony.king@st.com (Antony KING)
Cc: gdb@sourceware.org
Subject: Re: Spurious SIGTRAP reported by GDB 6.8 when debugging embedded RTOS application
Date: Sat, 16 Aug 2008 15:33:00 -0000 [thread overview]
Message-ID: <200808152315.m7FNFeMU025871@d12av02.megacenter.de.ibm.com> (raw)
In-Reply-To: <48A5E69D.9050901@st.com> from "Antony KING" at Aug 15, 2008 09:27:09 PM
Antony KING wrote:
> you can see that GDB is reporting a "SIGTRAP" message after switching
> threads from "Thread 3" (the active thread) to "Thread 7" and then
> performing the step. GDB is expecting that on completion of the step the
> stopped thread reported by the target will be same as was selected by
> GDB before the step (e.g. "Thread 7"). This will not generally happen
> with our RTOS since it is not possible to change the currently running
> thread (as exhibited above).
Here's my understanding of this issue: GDB does not actually care about
the "currently running" thread -- this is up the OS scheduler which GDB
cannot and does not attempt to influence.
GDB does cares about the following two properties of threads:
- Which threads are *runnable* (i.e. not stopped)
GDB may -depending on the situation- want to tell the target to mark
all threads runnable, no thread runnable, or just a single thread
runnable. (If it marks all threads runnable, it is of course up to
the OS which threads it schedules in which order to actually *run*
on any of the physical processors.)
- Which thread to run in hardware single-step mode
On targets that support hardware single-step, GDB will want to decide
*which* of the threads the single-step mode should be applied to.
(GDB will only ever mark one thread for single-stepping.)
It seems that you're running into problems with the second point:
GDB has asked the target to hardware single-step thread 7, but your OS
actually enabled hardware single-stepping for thread 3.
If possible, you should fix this in your target implementation. If
this is not possible for your RTOS, one simple way to solve the issue
might be to tell the GDB core that your target does not support hardware
single-stepping. Then, GDB will fall back to software single-stepping,
where it cares for stepping the correct thread by itself.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
next prev parent reply other threads:[~2008-08-15 23:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-16 15:12 Antony KING
2008-08-16 15:33 ` Ulrich Weigand [this message]
2008-08-18 18:16 ` Antony KING
2008-08-18 18:30 ` Daniel Jacobowitz
2008-08-18 18:36 ` Pedro Alves
2008-08-20 1:31 ` Antony KING
2008-08-18 18:47 ` Antony KING
2008-08-19 0:33 ` Ulrich Weigand
2008-08-20 14:30 ` Antony KING
2008-08-20 14:37 ` Pedro Alves
2008-08-21 3:24 ` Antony KING
2008-08-22 14:58 ` Ulrich Weigand
2008-08-27 21:38 ` Antony KING
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=200808152315.m7FNFeMU025871@d12av02.megacenter.de.ibm.com \
--to=uweigand@de.ibm.com \
--cc=antony.king@st.com \
--cc=gdb@sourceware.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox