ptype output for multi-dimensional arrays using CTF

ptype output for multi-dimensional arrays using CTF

[Indu Bhagat]

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]

Re: ptype output for multi-dimensional arrays using CTF

[Indu Bhagat]

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

Re: ptype output for multi-dimensional arrays using CTF

[Weimin Pan]

On 9/3/2021 7:13 AM, Indu Bhagat wrote:
> 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
>
Hi Indu,

Thank you for the report. Reversing ranges of a multi-dimensional array 
fixes
the first problem. The second problem was caused by a function argument
having a forward reference and is also fixed.