diff options
| author | Nick Alcock <nick.alcock@oracle.com> | 2021-03-18 12:37:52 +0000 |
|---|---|---|
| committer | Nick Alcock <nick.alcock@oracle.com> | 2021-03-18 12:40:41 +0000 |
| commit | 69a284867c7c92960653cbeab6f79cd815f1342f (patch) | |
| tree | b48c8b256ea735b8fe62da5019c550bc1357667b /ld/testsuite/ld-scripts/assign-loc.d | |
| parent | e4c78f303df55b3dfc5746c8d1817cc0df1b76c3 (diff) | |
| download | gdb-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-scripts/assign-loc.d')
0 files changed, 0 insertions, 0 deletions