aboutsummaryrefslogtreecommitdiff
path: root/ld/testsuite/ld-elf/pr14156a.d
diff options
context:
space:
mode:
authorNick Alcock <nick.alcock@oracle.com>2021-03-18 12:37:52 +0000
committerNick Alcock <nick.alcock@oracle.com>2021-03-18 12:40:41 +0000
commit69a284867c7c92960653cbeab6f79cd815f1342f (patch)
treeb48c8b256ea735b8fe62da5019c550bc1357667b /ld/testsuite/ld-elf/pr14156a.d
parente4c78f303df55b3dfc5746c8d1817cc0df1b76c3 (diff)
downloadgdb-69a284867c7c92960653cbeab6f79cd815f1342f.zip
gdb-69a284867c7c92960653cbeab6f79cd815f1342f.tar.gz
gdb-69a284867c7c92960653cbeab6f79cd815f1342f.tar.bz2
libctf: support encodings for enums
The previous commit started to error-check the lookup of ctf_type_encoding for the underlying type that is internally done when carrying out a ctf_type_encoding on a slice. Unfortunately, enums have no encoding, so this has historically been returning an error (which is ignored) and then populating the cte_format with uninitialized data. Now the error is not ignored, this is returning an error, which breaks linking of CTF containing bitfields of enumerated type. CTF format v3 does not record the actual underlying type of a enum, but we can mock up something that is not *too* wrong, and that is at any rate better than uninitialized data. ld/ChangeLog 2021-03-18 Nick Alcock <nick.alcock@oracle.com> * testsuite/ld-ctf/slice.c: Check slices of enums too. * testsuite/ld-ctf/slice.d: Results adjusted. libctf/ChangeLog 2021-03-18 Nick Alcock <nick.alcock@oracle.com> * ctf-types.c (ctf_type_encoding): Support, after a fashion, for enums. * ctf-dump.c (ctf_dump_format_type): Do not report enums' degenerate encoding.
Diffstat (limited to 'ld/testsuite/ld-elf/pr14156a.d')
0 files changed, 0 insertions, 0 deletions