From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id pR+TI/vE5GA2TAAAWB0awg (envelope-from ) for ; Tue, 06 Jul 2021 17:02:51 -0400 Received: by simark.ca (Postfix, from userid 112) id 7F4FC1F1F4; Tue, 6 Jul 2021 17:02:51 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=MAILING_LIST_MULTI, RDNS_DYNAMIC autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.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 A14541E54D for ; Tue, 6 Jul 2021 17:02:50 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5DE5A3898011 for ; Tue, 6 Jul 2021 21:02:50 +0000 (GMT) Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) by sourceware.org (Postfix) with ESMTPS id EC1243861035 for ; Tue, 6 Jul 2021 21:02:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EC1243861035 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f46.google.com with SMTP id j34so400702wms.5 for ; Tue, 06 Jul 2021 14:02:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ktDbiYzL4IRaromXaVm3JH+Dm8H9j4Gz2lWJqwlp8Mw=; b=i0EYL1Ri9K6Mm/+FxqQnv5jM+iVEYkhxxx6iM2HTl7mMamZZZWqowSglBfARSfbfm/ 7ROKmsTEUpuCWygFfm9AFqB41Cv1dWckgj8q3Pi1YtnyC6dVif2Sc6uV825IXKIRRQox MH0YYDrZmDXRfKheI9qSVEOx4ATo889YdK4cbhh26Bekt2tyIPxs1Q9wAZU7yGAQ6bEU eaadldy7/qGllU1zmjA1FAWbzLby8IE3NVMdSB45DZIDnXQTa3Di8OwPa3erhsPHcHTR ANQTMgn6Fx8mjsLsu1Lt+ssmoLf+veH+4BFNVlUvfiF416dgJuEbtl5ncBSINv5UOZx4 gUzw== X-Gm-Message-State: AOAM530kXxkGjSj8atyL0yyCmFYdregrvA+7e1s2SOk4ZBJNs6XG5pJb wS/cO1DanLp1dqwLg7n336E= X-Google-Smtp-Source: ABdhPJwVshMmkiprM4gpka6aG4DcufHMeGtgHyn4TGBpoNjmuZh3Oe8U/VoCV5taQugRYp3w9EmApQ== X-Received: by 2002:a1c:c90c:: with SMTP id f12mr2900459wmb.80.1625605357035; Tue, 06 Jul 2021 14:02:37 -0700 (PDT) Received: from ?IPv6:2001:8a0:f932:6a00:46bc:d03b:7b3a:2227? ([2001:8a0:f932:6a00:46bc:d03b:7b3a:2227]) by smtp.gmail.com with ESMTPSA id s8sm16745059wmh.36.2021.07.06.14.02.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jul 2021 14:02:36 -0700 (PDT) Subject: Re: [PATCH 02/11] gdb: introduce intrusive_list, make thread_info use it From: Pedro Alves To: Simon Marchi , 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: Date: Tue, 6 Jul 2021 22:02:34 +0100 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-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: , Cc: Simon Marchi Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" 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. 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..