From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) by sourceware.org (Postfix) with ESMTPS id 2B99F385840F for ; Fri, 3 Sep 2021 14:13:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2B99F385840F Received: by mail-pf1-x42a.google.com with SMTP id 2so4383085pfo.8 for ; Fri, 03 Sep 2021 07:13:54 -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=aTseLz80VRa8QmW7CznsClugL2EznRvBfeYY6u2bkpw=; b=OoPuZY6lT8ggihcYlBDaOgyOICMPOr15Mjnr8fGs5NoWOvWJZ5uowMekEPiWm7Bvpj 2TjEjFuF5XuQUdQHg1qYygKpW8PKU2Y6meegVOw8Wn8mJLGln5puPm8Q+ObXdBPsMCof zEDC6XjeuoCFF+ktD4XFXSap6GU4VJ+d4+cIjDdpP/nDyWjPNd4Bs/55EjLH974qC60N c5gwmQHjTL141zx+V733wEfHykaVevitS8RTkHXP7TAR6FdYRZJtJUFSAxQKd5ugcdPt 0WKwGQap3te6zCndW7fas4b1c1x5yrC8hhnoQC8IfBU3PhR+gc+I+VJqdz6sSblE4CfM w2pw== X-Gm-Message-State: AOAM532qKrBiA+ZZsnNakmq7MhcnRCi5xkh1h2VKuK3qfpLv+8nLpeTR 4J99qHDPiCykbdunVUuJXSoX3VLn1F3R7cUWeXg= X-Google-Smtp-Source: ABdhPJzW8jM+srPfELmsUq8/kEFsgLpZ0Kz4pi89luTu9pYqaK5HXPO7+1DHF+QBdL/dRLLt5LchiA== X-Received: by 2002:a63:1656:: with SMTP id 22mr3807952pgw.20.1630678433292; Fri, 03 Sep 2021 07:13:53 -0700 (PDT) Received: from [192.168.0.16] (S0106a84e3f65a213.vc.shawcable.net. [24.80.24.133]) by smtp.gmail.com with ESMTPSA id 143sm5436551pfx.1.2021.09.03.07.13.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Sep 2021 07:13:52 -0700 (PDT) Subject: Re: ptype output for multi-dimensional arrays using CTF From: Indu Bhagat To: Weimin Pan Cc: gdb-patches@sourceware.org, Nick Alcock References: <5bc9ca87-004a-5ada-50b5-87be52baa1a7@gmail.com> Message-ID: Date: Fri, 3 Sep 2021 07:13:52 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <5bc9ca87-004a-5ada-50b5-87be52baa1a7@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Fri, 03 Sep 2021 14:13:56 -0000 On 9/3/21 7:00 AM, Indu Bhagat wrote: > Hello Weimin, > > I ran into the following behavior with GDB. It seems like a GDB/CTF issue. > > Using gcc/trunk and binutils-gdb/trunk'ish :) > > Thanks > Indu > > ------------------------- > > $ cat typedef-array.c > typedef int A[2][3]; > A a = {{4, 5, 6}, {7, 8, 9}}; > $ gcc -gctf -c typedef-array.c > $ gdb typedef-array.o > ... > (gdb) ptype A > type = int [3][2] > (gdb) ptype a > type = int [3][2] > > $ objdump --ctf=.ctf typedef-array.o >  ... >   Variables: >     a -> 0x5: (kind 10) A (size 0x18) (aligned at 0x4) -> 0x4: (kind 4) > int [2][3] (size 0x18) (aligned at 0x4) -> 0x3: (kind 4) int [2] (size > 0x8) (aligned at 0x4) -> 0x1: (kind 1) int (format 0x1) (size 0x4) > (aligned at 0x4) > >   Types: >   ... >     0x5: (kind 10) A (size 0x18) (aligned at 0x4) -> 0x4: (kind 4) int > [2][3] (size 0x18) (aligned at 0x4) -> 0x3: (kind 4) int [2] (size 0x8) > (aligned at 0x4) -> 0x1: (kind 1) int (format 0x1) (size 0x4) (aligned > at 0x4) > > As you see, objdump reports the type correctly. > > For reference, here's what DWARF gives: > > $ gcc -g -c typedef-array.c > $ gdb typedef-array.o > > (gdb) ptype A > type = int [2][3] > (gdb) ptype a > type = int [2][3] This could be related (or not). But here is another testcase where the GDB results are not correct. $ cat func-array-arg.c int foo (int a, int b[a][a]) { return b[a-1][a-3]; } $ gcc -gctf -c func-array-arg.c $ objdump --ctf=.ctf func-array-arg.o ... Function objects: foo -> 0x2: (kind 5) int (*) (int, int (*)[0]) (aligned at 0x8) Types: 0x2: (kind 5) int (*) (int, int (*)[0]) (aligned at 0x8) ... 0x5: (kind 3) int (*)[0] (size 0x8) (aligned at 0x8) -> 0x4: (kind 4) int [0] (size 0x0) (aligned at 0x4) -> 0x1: (kind 1) int (format 0x1) (size 0x4) (aligned at 0x4) We are aware of this representation limit of CTF, but at present, using 0 is the best we can do. What I think is not correct is the behavior of GDB around this. $ gdb func-array-arg.o ... (gdb) ptype foo type = int (int, void) For reference, here is the output with DWARF: $ gcc -g -c func-array-arg.c $ gdb func-array-arg.o ... (gdb) ptype foo type = int (int, int (*)[variable length]) Thanks Indu