From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailsec118.isp.belgacom.be (mailsec118.isp.belgacom.be [195.238.20.114]) by sourceware.org (Postfix) with ESMTPS id 1D620384F00E for ; Mon, 14 Nov 2022 20:05:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1D620384F00E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=skynet.be Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=skynet.be DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=skynet.be; i=@skynet.be; q=dns/txt; s=rmail; t=1668456338; x=1699992338; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=TueCq/Lf5LtdOk933x5DyOVtgDIbhzPVHhExc2ltmAM=; b=QyDy2Kjwy32ZmP9MnTHKwAIdL5pYya23XlYCcVX60zFpcuXaSy20hESN PKFJiBcSC+bJHIBnm6yRQvdcJm2PBIi9SVFIBaTkUk50nw3eyGzepUNZS TGCMWmp2ptE+akxezuyjQM5EkQIp82hm1EE1ZubPv3DUpuX+YmKL0mVRP w=; X-ExtLoop: 1 X-IPAS-Result: =?us-ascii?q?A2A3AQA4n3Jj/1uGgG0NTYEJCYFGhQeETpEdkVuNUw8BA?= =?us-ascii?q?QEBAQEBAQEJRAQBAYUAAwIChHwmNwYOAQIEAQEBAQMCAwEBAQEBAQMBAQYBA?= =?us-ascii?q?QEBAQEGBAGBG4UvgnspAYN1AQEBAyMPAUYQCw0LAgImAgJXBhOyJXqBMhpnh?= =?us-ascii?q?HGaZYFngRQtgWWHGogQN4FVRIQ/PogbgmcEl0EcOAMZKx1AAws7Mg1KG1gOC?= =?us-ascii?q?R8cDhcNBQYSAyBsBQo3DygvZyscGweBDCooFQMEBAMCBhMDIgINKTEUBCkTD?= =?us-ascii?q?SsnbwkCAyJlBQMDBCgsAwkhHwcWESQ8B1Y6AQQDAhAgOAYDCQMCIlR1LhEVB?= =?us-ascii?q?QMLFSUIBUoECDkFBlMSAgoRAxIPBiZFDkg+ORYGJ0IBMQ4OFANegWkENaBEg?= =?us-ascii?q?TLCBDQHg2uBRwYMnnsylxgDkXuXNKJzhQWBeIF/bYM6Up0ZdDsCBwEKAQEDC?= =?us-ascii?q?YpmAQE?= IronPort-PHdr: A9a23:yHXh6xzwv5IJfFrXCzLpzVBlVkEcU1XcAAcZ59Idhq5Udez7ptK+Z hCZua8m1QeUFcWDsrQY0bGQ6/ihEUU7or+5+EgYd5JNUxJXwe43pCcHRPC/NEvgMfTxZDY7F skRHHVs/nW8LFQHUJ2mPw6arXK99yMdFQviPgRpOOv1BpTSj8Oq3Oyu5pHfeQpFiCSybL9oI xi6swrdutQKjYZiN609zgfFrmZSd+lZ229lK0ifkwrg6su14ZVu7zlet/U9+sBaTK70Zb44T btWDDQnN2A6+sjmvgTdQAWM+3URTHwYngJHDAbZ4h76WIzxsjbhuepmxCaaJ8z2QqsqVjmk8 qxmVQXniCYDNz4+7WHXlsl9h79VrR69uxByxZPfbZqLP/RiYKzSYdIaRXJAXslPUSxBHpi8Z JYLA+YYIOpUs5Xxq14IoBCjBwejGfnvxydLiHHr3aM0zfosHw/E0wwuA90BvnvbotruOacOU u241rXEwSnZYv5U3zr29YjGcgomofGJRb9+a8rRyUgrFwPEllWQsZLqNC6V2esXqWib6PNgV f+ui2E5sQFxuSWky8A0ionJh4IVzlHE9T1hwIkrP9G5RlR0YcSjEJtJqiGaNpV5Qtk5Q2xzo yY6yb0HuZilcygW0pgo3ADQZuWBfoOV7R3tSPyfLi1khHJ5Zr2/nRCy/FCkx+HgVse5zFdHo ytKnNXSuX0D1xje58eFR/Z//Uqv2SuD2hzO5uxFP005la7WJoI8zrMtmZQdv1nPEyHolEjyi qKda0Yq+vCw5uj6frnrooWQO5Jqhgz9KKgih8KyDOsiPgUKQmSW//m32qf58k3jWrpKi+U7k qzesJ/HO8sWvrW5AwpJ0oY77Ba/Eium3MwYnXYZKFJFfwqKgIz0N1zKPvz0F+qzjlWvnTtx2 vzKJKDtD5HLIXTbkbfhe6hy61JExQYu0dxS44hYBqwfLP/wQEP9qdLVAxAjPwGw3urrENB92 ZkfWWKLDK+ZKqTSsVqQ6+I3I+mMZYsVuDflK/g9+fHil3E4lkUHfamuxJsXdXG4Eep8I0WCe nfsmdQBEGcMvgUgUOzmkkaNXiBLa3a0RK0z/is7B56+DYffWoCth6SM0SmjEp1Mem9GEkyME Wvvd4icR/cMciWSIsp/nT0ETrWuUZIu2guyuw/90bpoMPDY9TEftZLmzNR1/fHclQku9TxoC MSQy2KNQH91nmMURz82x7tyoVZjxVie0ah3meBYGcZP6PNOVwc2LYTcwPBiC9DuRgLBec+ES Fm7Tdq9GD0xVsg+w8MSbEZ9BdqilQvO3zGtA78IjbyEGII786zG0HjrOclx0XHG1LMujwpuf swaCWqjzpJl8A3eFsadj1+ekqu7Xa0Q1SXK7mrFxm2L6hJ2Sgl1BJ3FXHQeflPb5evw/ETbU r6jE69vZhNByMqDMrNHLMLgl1JfWfbuIs/2eGGgnWqsQxyFkODfJLH2cnkQiX2OQHMPlBoeq DPfbVBWOw== IronPort-Data: A9a23:maUJdaqX9bdrYf2Wo7lKI5OMKDVeBmJCZBIvgKrLsJaIsI4StFCzt garIBmPOPuCZ2eneNF+Pdi19U0GvMXVzNJiGVQ4/HtnEisS8uPIVI+TRqvS04N+DSFioGZPt Zh2hgzodZhsJpPkjk7xdOKn9BGQ7InQLpLkEunIJyttcgFtTSYlmHpLlvUw6mJSqYHR7zil5 JWj/aUzBHf/g2QuaztNt/rZwP9SlK2aVA0w7wRWic9j4Qe2e0k9VPo3Oay3Jn3kdYhYdsbSq zHrlezREsvxpn/BO/v9+lrJWhRiro36YWBivkFrt52K2XCukMCdPpETb5LwYW8P49mAcksYJ N9l7fRcQi9xVkHAdXh0vxRwS0lD0aN6FLDvGVaBm+C/lHz6Xjj26vpCXQYMF48T07MiaY1O3 aRwxDElXUnS3aTvnuL9E6811/FLwMvDZdtO/Cg6nXeAVqpgEMmrr6bivLe02B8ohsFKHO7Ga owGYCBodQnBbgdUEkwUGZQzgKGiixETdhUB8wrO9fFmvji7IApZj4rrEcfKc9W2QZsJz1yDt j/Z72LwDURPXDCY4X/fmp62vcfThyT+VZM6HbGx/flwjRuYwWl7IB4bVEe7utGjh0K+Us4ZI EsRkgIhoaJ37EW3RdnwRDWjp2OetRMDUsBdVeog52mwJrH8ul7IQDFeHngYM4Bg5ZZeqSEW6 2JlVujBXVRH2IB5g1rEr994cRva1eMpwaPuqMPKocbpIzUunW3rsi/ycw== IronPort-HdrOrdr: A9a23:03x7R6OHlLKersBcTsqjsMiBIKoaSvp037Dk7S9MoHtuA6ilfq GV7ZcmPHDP5gr5NEtMpTnEAsi9qBDnhPtICOsqVotKNTOO0FdAbrsD0WKI+Vfd8kPFmtK1mZ 0QEZRDNA== X-IronPort-Anti-Spam-Filtered: true X-ProximusIPWarmup: true Received: from unknown (HELO [192.168.1.19]) ([109.128.134.91]) by relay.proximus.be with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Nov 2022 21:05:15 +0100 Message-ID: <3b90f6cdce3f8d4c3ca348e24cfa75fb645fbaf3.camel@skynet.be> Subject: Re: [PATCH] Allow 'ptype/o' for assembly From: Philippe Waroquiers To: Tom Tromey Cc: Keith Seitz , gdb-patches@sourceware.org Date: Mon, 14 Nov 2022 21:05:15 +0100 In-Reply-To: <874jv1y83v.fsf@tromey.com> References: <20221108201452.1255047-1-tromey@adacore.com> <87tu382llr.fsf@tromey.com> <9767e2c450d88795f0a2c47e3c4b78681447bfd9.camel@skynet.be> <874jv1y83v.fsf@tromey.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, 2022-11-14 at 06:32 -0700, Tom Tromey wrote: > > > > > > "Philippe" == Philippe Waroquiers writes: > > Philippe> At work, I relatively often use ptype/o for Ada types. > Philippe> As it only works in C mode, as part of our zillions of site aliases, > Philippe> we have added: > Philippe> alias Wc = with language c -- with annotate 0 -- > Philippe> (where annotate 0 avoids spurious language switch messages in the output). > > Philippe> So, waiting for Adacore to implement ptype/o for Ada (hint hint :)), > Philippe> we use e.g.   > Philippe> (gdb) Wc ptype/o sometype > > I've considered it, and maybe the basics aren't too hard to do, but I > didn't really know what to do with types that have a dynamic layout. > Here the offsets would maybe have to be symbolic (which I'd suppose is a > pain to implement) and holes couldn't really be determined. Effectively, Ada types can have a very rich/sophisticated layout. When I really need to have a in depth look at a complex type representation, the compiler option -gnatR3 produces this (including the symbolic offsets where needed, and "formulas" to compute offsets). > > Maybe gdb could just print a warning in this scenario and drop the '/o' > modifier. That might be easier to do. Currently, ptype /o an_ada_type just prints the type, without the offsets. I have no problem with this behaviour, but producing a warning that /o is ignored in Ada mode will not harm). Thanks Philippe