From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64972 invoked by alias); 5 Oct 2015 18:32:11 -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 64962 invoked by uid 89); 5 Oct 2015 18:32:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_05,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-io0-f170.google.com Received: from mail-io0-f170.google.com (HELO mail-io0-f170.google.com) (209.85.223.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 05 Oct 2015 18:32:09 +0000 Received: by iow1 with SMTP id 1so158992019iow.1 for ; Mon, 05 Oct 2015 11:32:08 -0700 (PDT) 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-type:content-transfer-encoding; bh=EU4e+N8mFpR0+cUxX1GcNpHd0X208drm8VGgj9PkTQw=; b=R7xkuv5Dgxn0SLWZwjEZXfh/d++jILEiDg9YkOu+dJZWakCU/zesOmzGpDlQ5ShDe0 oaD+LJv6O8nCvp8NvAIiYFoHhBiD9iQk69Ox9LQNDbPiPaZyBEgG3zTlwTkInBvoSgWz VCUXSXFcLta9Ri8lAeU1hwCkv97aX37E2TrRucfRoOMAhfUFjInzd3tU+r5uZClnwbv3 4YjR01Aq9SwI3XQkg5vfxC27brQircUkRBa0WGQYXCait2i5v5nadDXYD4oCS+dW9l+c htsaOquws+x+gKoZDnaPHf2WB41bllmQsulr/9sj0/mX4LsBxIaLboBJ9TRtabCVlJJc JPFg== X-Gm-Message-State: ALoCoQmqGUQY4JBXMwAxbjokeOoNFjrzNR2evpDp24vlXkN3nR6DMiNwaK/I+MFBxzaZsgNd2Kh6 X-Received: by 10.107.6.139 with SMTP id f11mr29274482ioi.61.1444069927702; Mon, 05 Oct 2015 11:32:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.134.131 with HTTP; Mon, 5 Oct 2015 11:31:27 -0700 (PDT) In-Reply-To: References: <20150603142858.GA19370@griffinp-ThinkPad-X1-Carbon-2nd> <20150930132729.GB26183@griffinp-ThinkPad-X1-Carbon-2nd> From: Doug Evans Date: Mon, 05 Oct 2015 18:32:00 -0000 Message-ID: Subject: Re: RFC GDB Linux Awareness analysis To: Duane Ellis Cc: Peter Griffin , Andreas Arnez , gdb , Lee Jones Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg00014.txt.bz2 On Wed, Sep 30, 2015 at 9:41 AM, Duane Ellis wrote: > I would offer the following for GDB Kernel Dump analysis - there is *a*lo= t* more that is needed. > ... > 3) GDB - generally as stated in the caldron slide deck is a =E2=80=9Cappl= ication debugger=E2=80=9D it is not a bare metal debugger > I cannot agree with this more - and it is a fundamental limitatio= n for GDB The extent to which gdb is not a bare metal debugger is IMO mostly driven by patches. Application level debugging gets more attention. But if reasonable patches came our way I would certainly approve them. [The devil is, again, in the details of course. One of the harder parts of hacking on gdb is that you can't break, or make harder, any of the other of the myriad of supported use cases, some of which are so old it's a crime that we're still having to put time into them (IMO).] > 4) In the bare metal world - GDB has a really big (fundamental) problem -= GDB thinks an address is a integer This has been an off and on discussion in gdb since at least as far back as Cygnus days. :-) No disagreement here that we have the wrong kind of abstraction for an addr= ess. > 6) Lots of the above needs to be scripted (i.e.: Python is a great solut= ion here, but is not always present) > And - these scripts could be provided by the Linux Kernel build p= rocess > Specifically: The kernel build process should produce an architec= ture/build-specific data file with structure definition > These scripts that I talk about, could read the =E2=80=98build-sp= ecific=E2=80=99 data file > (more about this later) I'd like to see a world where we actually open up gdb innards more, instead of providing an API on top of a closed system. The scripting possibilities would increase by at least an order of magnitude. > 7) A good example of scripting is during postmortem debug > GDB cannot call (execute) a helper function within the target bec= ause the target is not =E2=80=9Clive=E2=80=9D Depends on what the helper function does of course. E.g., it's possible to resurrect a corefile (assuming it hasn't been truncated, etc.) enough to run a pretty-printer contained in the app (as opposed to in pytho= n). > 4) GDB does not currently expose enough via the scripting interface > As I stated above - attitudes need to change about GDB No disagreement here.