Bug 32161 - CTF array dimensions dumped backwards
Summary: CTF array dimensions dumped backwards
Status: UNCONFIRMED
Alias: None
Product: binutils
Classification: Unclassified
Component: libctf (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-09-10 17:25 UTC by Bruce McCulloch
Modified: 2024-09-10 19:08 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
Patch that fixes backwards multidimensional array dumping, plus tests (1.34 KB, patch)
2024-09-10 17:25 UTC, Bruce McCulloch
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Bruce McCulloch 2024-09-10 17:25:59 UTC
Created attachment 15698 [details]
Patch that fixes backwards multidimensional array dumping, plus tests

$ cat array.c
int a[1][2][3]
$ gcc -gctf -o array.o -c array.c
$ objdump --ctf array.o

array.o:     file format elf64-x86-64

Contents of CTF section .ctf:

  Header:
    Magic number: 0xdff2
    Version: 4 (CTF_VERSION_3)
    Flags: 0x2 (CTF_F_NEWFUNCINFO)
    Compilation unit name: //array.c
    Data object section:	0x0 -- 0x3 (0x4 bytes)
    Object index section:	0x4 -- 0x7 (0x4 bytes)
    Variable section:	0x8 -- 0xf (0x8 bytes)
    Type section:	0x10 -- 0x77 (0x68 bytes)
    String section:	0x78 -- 0x9b (0x24 bytes)

  Labels:

  Data objects:
    a -> 0x5: (kind 4) int [3][2][1] (size 0x18) (aligned at 0x4) -> 0x4: (kind 4) int [3][2] (size 0x18) (aligned at 0x4) -> 0x3: (kind 4) int [3] (size 0xc) (aligned at 0x4) -> 0x1: (kind 1) int (format 0x1) (size 0x4) (aligned at 0x4)

  Function objects:

  Variables:
    a -> 0x5: (kind 4) int [3][2][1] (size 0x18) (aligned at 0x4) -> 0x4: (kind 4) int [3][2] (size 0x18) (aligned at 0x4) -> 0x3: (kind 4) int [3] (size 0xc) (aligned at 0x4) -> 0x1: (kind 1) int (format 0x1) (size 0x4) (aligned at 0x4)

  Types:
    0x1: (kind 1) int (format 0x1) (size 0x4) (aligned at 0x4)
    0x2: (kind 1) long unsigned int (format 0x0) (size 0x8) (aligned at 0x8)
    0x3: (kind 4) int [3] (size 0xc) (aligned at 0x4) -> 0x1: (kind 1) int (format 0x1) (size 0x4) (aligned at 0x4)
    0x4: (kind 4) int [3][2] (size 0x18) (aligned at 0x4) -> 0x3: (kind 4) int [3] (size 0xc) (aligned at 0x4) -> 0x1: (kind 1) int (format 0x1) (size 0x4) (aligned at 0x4)
    0x5: (kind 4) int [3][2][1] (size 0x18) (aligned at 0x4) -> 0x4: (kind 4) int [3][2] (size 0x18) (aligned at 0x4) -> 0x3: (kind 4) int [3] (size 0xc) (aligned at 0x4) -> 0x1: (kind 1) int (format 0x1) (size 0x4) (aligned at 0x4)

  Strings:
    0x0: 
    0x1: int
    0x5: long unsigned int
    0x17: a
    0x19: //array.c

This behavior occurs as a result of the following patch, which was applied in gcc 14.2.0:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114186
This patch solves the issue of reversed multidimensional array nelems in the BTF dumper and in the assembler output, but causes the multidimensional arrays in CTF to be dumped backwards.

This behavior can also be observed in ctf_get_aname() as well as some other functions.

The problem lies in ctf_decl_push, and I have a solution as well as some tests.

The issue with this is that if this patch is applied while compiling with a version of gcc older than 14.2.0, this patch will make the dumper output backwards. 

The solution to this is either to backport the gcc-14.2.0 patch, or to add a flag to objdump and libctf.

Patch is attached.