From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27156 invoked by alias); 8 Nov 2016 11:14:08 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 27141 invoked by uid 89); 8 Nov 2016 11:14:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=protocol, =e5=b0=a7, our?= X-HELO: mail-qk0-f179.google.com Received: from mail-qk0-f179.google.com (HELO mail-qk0-f179.google.com) (209.85.220.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 08 Nov 2016 11:13:57 +0000 Received: by mail-qk0-f179.google.com with SMTP id q130so212066095qke.1 for ; Tue, 08 Nov 2016 03:13:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ffcjf/+/+eMwmdwFsFos+pJu+ZCoJnwIkKEQjgymxFQ=; b=fgggFreT+7kK6EMp82LRf1SNCPmtkZmDV8/Ev47iU4Q3H4LsMKmvYgL9iCTZlFoj0M bKiU6horSzp+NRd4a89JPvDjTBv/kucK4bAhTJXMk6j0U5qY8z0ZzBnO+fOCX93boUP3 bsYVkAQCIMiftbjFq33A7KqBxxn7PJ2dxRNvCFVaM7hYodNEiTyeUolX8pycjuibz7Yv jXJ1D2pvlEEGhNRHiqelhBhi2syXgB2L4gk1YB6SszgBi0ZkiaQ7HJoAB5RDyWu3VHBf 0k0j4emIiSIEoyXzYrh6m4evOhEGmg6d84keb7O580eOFq88gPxi8RcfdXxRHVeqnIfX W+xQ== X-Gm-Message-State: ABUngvcWQAGEN6nRWkTUJ0RFYsH0OgGUG0WjX7o3GqP6weBvFougdUo3yEKgGva9h0Q2Vr6gJS+PolsnGsKvrA== X-Received: by 10.55.26.156 with SMTP id l28mr12170532qkh.164.1478603635661; Tue, 08 Nov 2016 03:13:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.149.55 with HTTP; Tue, 8 Nov 2016 03:13:55 -0800 (PST) In-Reply-To: <5821A95F.2060408@marco.de> References: <5821A95F.2060408@marco.de> From: Yao Qi Date: Tue, 08 Nov 2016 11:14:00 -0000 Message-ID: Subject: Re: embedded system and "target remote" To: Matthias Pfaller Cc: GDB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-11/txt/msg00009.txt.bz2 On Tue, Nov 8, 2016 at 10:30 AM, Matthias Pfaller wrote: > Hi, > > 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, https://sourceware.org/gdb/download/onlinedocs/gdb/Convenience-Vars.html > > 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, https://sourceware.org/gdb/download/onlinedocs/gdb/Remote-Non_002dStop.html IIUC, GDB thinks async is on in remote (if the serial device is async). > > 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? --=20 Yao (=E9=BD=90=E5=B0=A7)