From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id LBgQBDPP5GC7TQAAWB0awg (envelope-from ) for ; Tue, 06 Jul 2021 17:46:27 -0400 Received: by simark.ca (Postfix, from userid 112) id F08171F1F4; Tue, 6 Jul 2021 17:46:26 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 547EC1E54D for ; Tue, 6 Jul 2021 17:46:26 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 05933389F4FA for ; Tue, 6 Jul 2021 21:46:26 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 05933389F4FA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1625607986; bh=mwKNqxuSQJawI+4OTpuyPtN/poLIk1gqIiE5MW3YTvY=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=nE6GXulTyizXmvBr8VGj5QACO8fj0U3Z4WpUs60NQA/mdpUXKUXlpDrq37cMf5ctr C1i8uze/1T7XvQy/4OzX0FCuMxc4Jq193GP6PD6Gfo8oukaDiU8eswB4MejnBvykOz T60ttobnNqIYjpLuuRFqRAqtsq8fbg/fHJxxynfk= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 09A44393A40D for ; Tue, 6 Jul 2021 21:45:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 09A44393A40D Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 166LjBHD016066 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 6 Jul 2021 17:45:15 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 166LjBHD016066 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 161231E54D; Tue, 6 Jul 2021 17:45:11 -0400 (EDT) Subject: Re: [PATCH 02/11] gdb: introduce intrusive_list, make thread_info use it To: Pedro Alves , gdb-patches@sourceware.org References: <20210622165704.2404007-1-simon.marchi@polymtl.ca> <20210622165704.2404007-3-simon.marchi@polymtl.ca> <2466c5e0-36f4-ce47-f05f-022cda04bb04@palves.net> Message-ID: <3707d3e0-3166-cee1-dabd-cb101807c01e@polymtl.ca> Date: Tue, 6 Jul 2021 17:45:10 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Tue, 6 Jul 2021 21:45:11 +0000 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: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Cc: Simon Marchi Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 2021-07-06 5:02 p.m., Pedro Alves wrote: > On 2021-07-06 8:38 p.m., Simon Marchi wrote: >> On 2021-07-05 11:44 a.m., Pedro Alves wrote: >>>>> $1 = intrusive list of thread_info = { >>> {id = 1.1, ptid = 1000.1000.0, state = THREAD_RUNNING}, >>> {id = 1.3, ptid = 1000.1002.0, state = THREAD_STOPPED}, >>> {id = 1.5, ptid = 1000.3672.0, state = THREAD_STOPPED} >>> } >> >> How would you accomplish this, with a struct thread_info >> pretty-printer? This means that printing a single thread like this: >> >> (gdb) print *tp >> >> would also produce the short output, I don't think we want that. When >> we print a single thread_info structure, I think it's good to have all >> the fields shown. > > I don't have a great answer. It feels to me like the pretty printer code > should ask the container if it has a custom printer for the element, and only > if it doesn't would it look up the printer for the element's type. That would be a new feature that doesn't exist today, I think: a different printer for a type when it's printed as a container element than when it's printed standalone. > Maybe having a printer for thread_info all the time isn't that bad. printing > thread_info structures does dump a lot of stuff and isn't that easy to parse. > If you want to see the whole thing, there's always "print /r" to disable the > printer. > >> >> Perhaps by defining a more specialized pretty-printer for >> intrusive_list? But then I'm not sure what kind of value >> the children method would return. > > I guess it could return a typedef for "thread_info *" like e.g., "thread_info_p" instead > of the raw pointer, and then we'd register a printer for only the typedef. I > think that means that indexing via thread_list[1] etc. would also return the typedef, > and thus give you the short print.. I think these are all good ideas for improvements, but I'd rather keep them for later (if someone wants to implement them, I'm not sure I will). We could bike-shed for a while on how to display a thread_info, what to include / what to exclude, etc. I think that my original proposal is strictly better than what we have today, in the sense that today you just can't print the whole list of threads, so we don't lose anything. Simon