From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) by sourceware.org (Postfix) with ESMTPS id 9769E388F011 for ; Wed, 12 May 2021 08:52:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9769E388F011 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=andrew.burgess@embecosm.com Received: by mail-wm1-x334.google.com with SMTP id u133so1079675wmg.1 for ; Wed, 12 May 2021 01:52:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=lGmsz+luVFfYtPLpcJ42DrAHQiPEfsW88ch0piuL+XQ=; b=A5Z9ko2X7NmsqgsVCqo+wCsEwT09Hrd/Hvsm4OQeBIU8xRf7Sjlm8t1tggd5Md8Sm3 v5HJYHktM2N+i9awVTf5Lf5A0tNiAdKrK8b9Li2ialviMHhdmLvFz7lohQRD0e5rWiuL f7NEYOdTY/q68y3fD1peLJtUpLVTXLqKIuyOVLjWppL0w1R1ZusEdbMtD4QDfU2s7PUS JCWMiRs9fHpCbtbshM4L416lZvJYH5VblByd44m5/b091CuV2H+aTTrmdK1JPsh7OptG SjdV/+yIDOSCXABJcPqZP+fJQqkJbc4Z7jccJoGnjbU6WDivYO2Ek7PSr5CV5p02dpvd Ev9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=lGmsz+luVFfYtPLpcJ42DrAHQiPEfsW88ch0piuL+XQ=; b=NHlS5CfNswKMT4z6rhigmtUDBeotTXNS9tdWlfKcEfCHu77giS3McMSkBAxcZzRbM1 E+3slkQNnw6cSU94hhl60xB4dc3GN+LCP2BVwA+K7eeBDqytKG4ra8PNIFm5Rcpkw/E2 ehKo6iC0tn+jKqdhYxL+lbN934bwtuCO7o8x2hK/NbuHNa/1ZRWGGE+BSglLO4coDo+K nboltFXfVj7zHLb3FuzLpKSLy9zcbWgPRtgmwM1ghll00yml9DYVxls4KNsTCOMm+DNQ qlXLxNxGlqrywV8+dS3L69a6FBghoJEozS10aWDkVZIzMn3prRxYkIP+jkL2f64wcXSv uAEg== X-Gm-Message-State: AOAM533Qjzqow06h12B2qAxvoBfxGJkYGazt32fOcHH5yqvitIcK9+K3 z82v4SXRYuylNq/RlFBERRm/ukw8FWYyYw== X-Google-Smtp-Source: ABdhPJxSe6fj6J3q3/bDb1igndh9YIJWcMTvd3HJ1gtm2awkV6kiSg8GHIGAz3Sdz1K+lr0i9/75Qw== X-Received: by 2002:a05:600c:19c8:: with SMTP id u8mr10278416wmq.25.1620809577641; Wed, 12 May 2021 01:52:57 -0700 (PDT) Received: from localhost (host109-151-46-70.range109-151.btcentralplus.com. [109.151.46.70]) by smtp.gmail.com with ESMTPSA id v15sm5634455wmj.39.2021.05.12.01.52.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 May 2021 01:52:57 -0700 (PDT) Date: Wed, 12 May 2021 09:52:56 +0100 From: Andrew Burgess To: "Jose E. Marchesi" Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 1/1] Integrate GNU poke in GDB Message-ID: <20210512085256.GV6612@embecosm.com> References: <20210510151044.20829-1-jose.marchesi@oracle.com> <20210510151044.20829-2-jose.marchesi@oracle.com> <20210511073331.GU6612@embecosm.com> <875yzps9k1.fsf@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <875yzps9k1.fsf@oracle.com> X-Operating-System: Linux/5.8.18-100.fc31.x86_64 (x86_64) X-Uptime: 09:51:11 up 8 days, 21:45, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2021 08:53:16 -0000 * Jose E. Marchesi [2021-05-11 15:07:42 +0200]: > > Hi Andrew. > > Thanks for the feedback. > > > I have no objections to merging this functionality, especially as it > > is so self-contained, however, I do have a question, or feedback. > > > > As someone who doesn't know poke, after reading the manual, it's still > > not clear to me what significant value poke adds to GDB. A lot of the > > examples seem to cover things that GDB already does, mostly examining > > data and variables in target memory (though there were a couple of > > neat features which aren't so easy to achieve in GDB). > > > > I guess my question, or feedback, would be, what's the killer feature > > that adding poke brings to GDB? > > The most obvious example that quickly comes to mind is to check/debug > the integrity of data in an application's memory. > > Suppose you have a program or driver that processes USB packets, and > buffers them in some memory buffer. The program is malfunctioning and > you suspect (but you don't know for sure) the culprit is some corrupted > USB packet. > > So you want to examine the integrity of the USB packets that the program > has buffered at certain point in the program execution. This is where > poke gets handy: a pickle for USB packets (let's say usb.pk) will > provide types/methods/functions describing the format of USB packets, > including integrity. It will also likely provide utility functions for > diagnostics, and even fixing invalid packets. > > GDB gives you access to the C/whatever-language types, and that is very > good, but: > > - C/whatever language types do not include integrity checks. Poke types > almost always do. > > - Poke types are designed to be used/interpreted/read by persons, > whereas C/whatever types are designed to be interpreted by programs. > As such, Poke types tend to "adapt" their form to their contents in > order to be intelligible and to increase the odds of detecting > integrity problems. > > - If the protocol/format/structure of the data being examined is > bit-oriented (consider for example data compressed with deflate) the > C/whatever types usually provide a byte-sized view of the structure > instead of a meaningful structure that the person using GDB can easily > understand/manipulate. Instead, poke can _really_ operate at the bit > level. See the following section in the poke manual: > http://www.jemarch.net/poke-1.2-manual/html_node/Weird-Integers.html#Weird-Integers > > For example, consider the following Poke type describing a type in BTF > (the debugging format for BTF types): > > type BTF_Type = > struct > { > offset,B> name; > > struct uint<32> > { > uint<1> kind_flag; > uint<3>; > uint<4> kind; > uint<8>; > uint<16> vlen; > > method _print = void: > { > printf ("#<%s,kind_flag:%u32d,vlen:%v>", > btf_kind_names[kind], kind_flag, vlen); > } > } info; > > union > { > offset,B> size : (info.kind in [BTF_KIND_INT, > BTF_KIND_ENUM, > BTF_KIND_STRUCT, > BTF_KIND_UNION]); > BTF_Type_Id type_id; > } attrs; > > type BTF_Member = > struct > { > offset,B> name; > BTF_Type_Id type_id; > union > { > offset,b> member_offset : !info.kind_flag; > struct uint<32> > { > offset,b> bitfield_size; > offset,b> bit_offset; > } bitfield; > } offset; > }; > > type BTF_Func_Proto = > struct > { > BTF_Param[info.vlen] params; > }; > > union > { > BTF_Int integer : info.kind == BTF_KIND_INT; > BTF_Array array : info.kind == BTF_KIND_ARRAY; > BTF_Enum[info.vlen] enum : info.kind == BTF_KIND_ENUM; > BTF_Func_Proto func_proto : info.kind == BTF_KIND_FUNC_PROTO; > BTF_Variable variable : info.kind == BTF_KIND_VAR; > BTF_Member[info.vlen] members : (info.kind == BTF_KIND_UNION > || info.kind == BTF_KIND_STRUCT); > BTF_Var_SecInfo[info.vlen] datasec : info.kind == BTF_KIND_DATASEC; > > struct {} nothing; > } data; > > method vararg_p = int: > { > var last_param = data.func_proto.params[info.vlen - 1]; > return (last_param.name == 0#B && last_param.param_type == 0); > } > > method get_kind_name = string: > { > return btf_kind_names[info.kind]; > } > }; > > If you map a BTF_Type from GDB, it will check the integrity (poke also > support mapping in non-strict mode) and also will build the structure > based on the very contents. GDB simply can't do the same thing based on > the "equivalent" collection of decoupled C types, which are really not > equivalent at all. Thanks for this explanation. For me, personally, I think the manual entry would be much more powerful if something like the above was included. I feel it really gives an idea for the sort of thing that can be achieved with poke. Thanks for the great work, Andrew > > So, back to the debugging of the USB processing program, sure, you could > dump the buffer to some file using GDB commands and then use poke on the > side to poke on it. But having poke in GDB allows you to inspect the > buffer directly and the integrity of its contents, and also provides > access to the rest of the program memory, which could be also handy to > diagnose the problem. > > Now suppose you find something fishy in a USB packet, and what you want > to do is to _fix_ it (or modify it somehow) and then continue the > program to see if that fixes the crash. Again sure, you could use GDB > commands to load the modified dump. But having poke in GDB allows you > to just continue. > > This as for "what can poke do for GDB". But there is another aspect to > consider as well: "what can GDB do for poke". > > You see, mainly for the sake of completion, we _do_ support a "proc" IO > device in GNU poke (the command-line editor) that provides access to the > memory of a running process. However, this support is intended only for > the very basics, and: > > - It is not portable (only works on GNU/Linux). > - It doesn't know how to recognize stack frames. > - It doesn't know how to unwind. > - It doesn't have a disassembler. > - etc > > When people ask me to add features like that to poke (and they do ask) I > always think: why bothering implementing them? GDB does all these > things very well, and more, and it is portable, and it knows about a > shitload of architectures, and... . > > So, in my mind, the right platform to use for poking at the memory of > live (or even dead) processes is GDB. That's why we took pains to make > it very easy to integrate poke (libpoke) in other applications, and > therefore this proposed patch :) > > Another example of integration (which is work in progress) is with the > assembler (GAS). > > Instead of writing this: > > .section .text > .set softfloat > .ascii "PS-X EXE" > .byte 0, 0, 0, 0, 0, 0, 0, 0 > .word main > .word 0 > .word 0x80010000 > .word image_size > .word 0,0,0,0 > .word 0x8001FFF0 > .word 0,0,0,0,0,0 > .ascii "Sony Computer Entertainment Inc. for zid" > > You will be able to write something like: > > .poke load psxexe > .poke var s = "Sony Computer" > .poke PS_X_EXE { start = $main, size = $image_size, vendor = s } > > (A nice side effect will be that .poke will be a _really portable_ data > directive, unlike the regular ones, and therefore we will be able to > write, say, the GDB and linker tests for CTF the right way, > i.e. without relying on a compiler or copy-pased inintelligible > .word/.byte blocks.) > > I could go on and on but I don't want to pester you people so I better > stop :)