diff options
author | Nick Alcock <nick.alcock@oracle.com> | 2021-01-05 13:25:56 +0000 |
---|---|---|
committer | Nick Alcock <nick.alcock@oracle.com> | 2021-01-05 14:53:39 +0000 |
commit | b09ad6eae985c6cf3138775de8e712bc116b4166 (patch) | |
tree | c4340a2974f343d6b6492995ae6309376e5d9316 /ld/ldemul.h | |
parent | 5519536196e670c3c0fb2b138acc44049227e724 (diff) | |
download | gdb-b09ad6eae985c6cf3138775de8e712bc116b4166.zip gdb-b09ad6eae985c6cf3138775de8e712bc116b4166.tar.gz gdb-b09ad6eae985c6cf3138775de8e712bc116b4166.tar.bz2 |
libctf: do not print array declarators backwards
The CTF declarator stack code (used by ctf_type_aname() and thus
ultimately by ctf-dump.c and objdump --ctf etc) contains careful
code to prepend array declarators to the stack it's building up
on the grounds that array declarators are ordered inside out: only
they're not, they're ordered outside in.
This has led to our (non-upstreamed) compiler emitting array declarators
backwards for years, because it looks backwards in the dumper unless
it's actually emitted backwards into the CTF so the dumper can wrongly
reverse it again: but
int[5][6]
should be an array of 6 int[5]s, not an array of 5 int[6]'s, so even if
the dumper gets it right, actual users calling ctf_array_info are going
to see a completely wrong type graph with the wrong bounds in it.
Fix trivial.
libctf/ChangeLog
2021-01-05 Nick Alcock <nick.alcock@oracle.com>
* ctf-decl.c (ctf_decl_push): Don't print array decls backwards.
Diffstat (limited to 'ld/ldemul.h')
0 files changed, 0 insertions, 0 deletions