This is the mail archive of the
mailing list for the GDB project.
Re: embedded system and "target remote"
- From: Yao Qi <qiyaoltc at gmail dot com>
- To: Matthias Pfaller <leo at marco dot de>
- Cc: GDB <gdb at sourceware dot org>
- Date: Tue, 8 Nov 2016 11:13:55 +0000
- Subject: Re: embedded system and "target remote"
- Authentication-results: sourceware.org; auth=none
- References: <5821A95F.firstname.lastname@example.org>
On Tue, Nov 8, 2016 at 10:30 AM, Matthias Pfaller <email@example.com> wrote:
> I'm currently implementing gdb server support for our cortex-m3/m4 based
> embedded systems.
Out of curiosity, is it like openocd?
> At the moment I'm implementing break points using the FPB unit.
I don't know much about FPB unit.
> I would like to setup the FPB unit at context switch time for thread
> specific break points. Is there a way to pass the referenced thread id
> with the 'Z' commands?
The remote protocol is not aware of thread specific breakpoint.
Thread specific breakpoint just works, "b foo if thread 1", but it is not
efficient. What do you want to achieve?
> Is there a way to modify the behaviour of the break point commands to
> always reference the currently selected thread? Gobal breakpoints do not
> make sense in my usage case.
What do you mean by "always reference the currently selected thread"?
Always set thread specific breakpoint for current selected thread?
You can get current thread via $_thread and $_gthread,
> Another thing I'd really like to do is to enforce non-stop and
> target-async from the target side. Is there a way to do this?
See the first paragraph in GDB manual below,
IIUC, GDB thinks async is on in remote (if the serial device is
> regards, Matthias
> PS: How does gdb recoginze the initial stack frame? At the moment stack
> trace backs of stopped threads will not stop at correct frame.
Do you have an example?