libctf: impose an ordering on conflicting types
When two types conflict and they are not types which can have forwards
(say, two arrays of different sizes with the same name in two different
TUs) the CTF deduplicator uses a popularity contest to decide what to
do: the type cited by the most other types ends up put into the shared
dict, while the others are relegated to per-CU child dicts.
This works well as long as one type *is* most popular -- but what if
there is a tie? If several types have the same popularity count,
we end up picking the first we run across and promoting it, and
unfortunately since we are working over a dynhash in essentially
arbitrary order, this means we promote a random one. So multiple
runs of ld with the same inputs can produce different outputs!
All the outputs are valid, but this is still undesirable.
Adjust things to use the same strategy used to sort types on the output:
when there is a tie, always put the type that appears in a CU that
appeared earlier on the link line (and if there is somehow still a tie,
which should be impossible, pick the type with the lowest type ID).
Add a testcase -- and since this emerged when trying out extern arrays,
check that those work as well (this requires a newer GCC, but since all
GCCs that can emit CTF at all are unreleased this is probably OK as
well).
Fix up one testcase that has slight type ordering changes as a result
of this change.
libctf/ChangeLog:
* ctf-dedup.c (ctf_dedup_detect_name_ambiguity): Use
cd_output_first_gid to break ties.
ld/ChangeLog:
* testsuite/ld-ctf/array-conflicted-ordering.d: New test, using...
* testsuite/ld-ctf/array-char-conflicting-1.c: ... this...
* testsuite/ld-ctf/array-char-conflicting-2.c: ... and this.
* testsuite/ld-ctf/array-extern.d: New test, using...
* testsuite/ld-ctf/array-extern.c: ... this.
* testsuite/ld-ctf/conflicting-typedefs.d: Adjust for ordering
changes.
libctf: impose an ordering on conflicting types
When two types conflict and they are not types which can have forwards
(say, two arrays of different sizes with the same name in two different
TUs) the CTF deduplicator uses a popularity contest to decide what to
do: the type cited by the most other types ends up put into the shared
dict, while the others are relegated to per-CU child dicts.
This works well as long as one type *is* most popular -- but what if
there is a tie? If several types have the same popularity count,
we end up picking the first we run across and promoting it, and
unfortunately since we are working over a dynhash in essentially
arbitrary order, this means we promote a random one. So multiple
runs of ld with the same inputs can produce different outputs!
All the outputs are valid, but this is still undesirable.
Adjust things to use the same strategy used to sort types on the output:
when there is a tie, always put the type that appears in a CU that
appeared earlier on the link line (and if there is somehow still a tie,
which should be impossible, pick the type with the lowest type ID).
Add a testcase -- and since this emerged when trying out extern arrays,
check that those work as well (this requires a newer GCC, but since all
GCCs that can emit CTF at all are unreleased this is probably OK as
well).
Fix up one testcase that has slight type ordering changes as a result
of this change.
libctf/ChangeLog:
* ctf-dedup.c (ctf_dedup_detect_name_ambiguity): Use
cd_output_first_gid to break ties.
ld/ChangeLog:
* testsuite/ld-ctf/array-conflicted-ordering.d: New test, using...
* testsuite/ld-ctf/array-char-conflicting-1.c: ... this...
* testsuite/ld-ctf/array-char-conflicting-2.c: ... and this.
* testsuite/ld-ctf/array-extern.d: New test, using...
* testsuite/ld-ctf/array-extern.c: ... this.
* testsuite/ld-ctf/conflicting-typedefs.d: Adjust for ordering
changes.
libctf: impose an ordering on conflicting types
When two types conflict and they are not types which can have forwards
(say, two arrays of different sizes with the same name in two different
TUs) the CTF deduplicator uses a popularity contest to decide what to
do: the type cited by the most other types ends up put into the shared
dict, while the others are relegated to per-CU child dicts.
This works well as long as one type *is* most popular -- but what if
there is a tie? If several types have the same popularity count,
we end up picking the first we run across and promoting it, and
unfortunately since we are working over a dynhash in essentially
arbitrary order, this means we promote a random one. So multiple
runs of ld with the same inputs can produce different outputs!
All the outputs are valid, but this is still undesirable.
Adjust things to use the same strategy used to sort types on the output:
when there is a tie, always put the type that appears in a CU that
appeared earlier on the link line (and if there is somehow still a tie,
which should be impossible, pick the type with the lowest type ID).
Add a testcase -- and since this emerged when trying out extern arrays,
check that those work as well (this requires a newer GCC, but since all
GCCs that can emit CTF at all are unreleased this is probably OK as
well).
Fix up one testcase that has slight type ordering changes as a result
of this change.
libctf/ChangeLog:
* ctf-dedup.c (ctf_dedup_detect_name_ambiguity): Use
cd_output_first_gid to break ties.
ld/ChangeLog:
* testsuite/ld-ctf/array-conflicted-ordering.d: New test, using...
* testsuite/ld-ctf/array-char-conflicting-1.c: ... this...
* testsuite/ld-ctf/array-char-conflicting-2.c: ... and this.
* testsuite/ld-ctf/array-extern.d: New test, using...
* testsuite/ld-ctf/array-extern.c: ... this.
* testsuite/ld-ctf/conflicting-typedefs.d: Adjust for ordering
changes.
libctf: impose an ordering on conflicting types
When two types conflict and they are not types which can have forwards
(say, two arrays of different sizes with the same name in two different
TUs) the CTF deduplicator uses a popularity contest to decide what to
do: the type cited by the most other types ends up put into the shared
dict, while the others are relegated to per-CU child dicts.
This works well as long as one type *is* most popular -- but what if
there is a tie? If several types have the same popularity count,
we end up picking the first we run across and promoting it, and
unfortunately since we are working over a dynhash in essentially
arbitrary order, this means we promote a random one. So multiple
runs of ld with the same inputs can produce different outputs!
All the outputs are valid, but this is still undesirable.
Adjust things to use the same strategy used to sort types on the output:
when there is a tie, always put the type that appears in a CU that
appeared earlier on the link line (and if there is somehow still a tie,
which should be impossible, pick the type with the lowest type ID).
Add a testcase -- and since this emerged when trying out extern arrays,
check that those work as well (this requires a newer GCC, but since all
GCCs that can emit CTF at all are unreleased this is probably OK as
well).
Fix up one testcase that has slight type ordering changes as a result
of this change.
libctf/ChangeLog:
* ctf-dedup.c (ctf_dedup_detect_name_ambiguity): Use
cd_output_first_gid to break ties.
ld/ChangeLog:
* testsuite/ld-ctf/array-conflicted-ordering.d: New test, using...
* testsuite/ld-ctf/array-char-conflicting-1.c: ... this...
* testsuite/ld-ctf/array-char-conflicting-2.c: ... and this.
* testsuite/ld-ctf/array-extern.d: New test, using...
* testsuite/ld-ctf/array-extern.c: ... this.
* testsuite/ld-ctf/conflicting-typedefs.d: Adjust for ordering
changes.
libctf: impose an ordering on conflicting types
When two types conflict and they are not types which can have forwards
(say, two arrays of different sizes with the same name in two different
TUs) the CTF deduplicator uses a popularity contest to decide what to
do: the type cited by the most other types ends up put into the shared
dict, while the others are relegated to per-CU child dicts.
This works well as long as one type *is* most popular -- but what if
there is a tie? If several types have the same popularity count,
we end up picking the first we run across and promoting it, and
unfortunately since we are working over a dynhash in essentially
arbitrary order, this means we promote a random one. So multiple
runs of ld with the same inputs can produce different outputs!
All the outputs are valid, but this is still undesirable.
Adjust things to use the same strategy used to sort types on the output:
when there is a tie, always put the type that appears in a CU that
appeared earlier on the link line (and if there is somehow still a tie,
which should be impossible, pick the type with the lowest type ID).
Add a testcase -- and since this emerged when trying out extern arrays,
check that those work as well (this requires a newer GCC, but since all
GCCs that can emit CTF at all are unreleased this is probably OK as
well).
Fix up one testcase that has slight type ordering changes as a result
of this change.
libctf/ChangeLog:
* ctf-dedup.c (ctf_dedup_detect_name_ambiguity): Use
cd_output_first_gid to break ties.
ld/ChangeLog:
* testsuite/ld-ctf/array-conflicted-ordering.d: New test, using...
* testsuite/ld-ctf/array-char-conflicting-1.c: ... this...
* testsuite/ld-ctf/array-char-conflicting-2.c: ... and this.
* testsuite/ld-ctf/array-extern.d: New test, using...
* testsuite/ld-ctf/array-extern.c: ... this.
* testsuite/ld-ctf/conflicting-typedefs.d: Adjust for ordering
changes.
libctf: impose an ordering on conflicting types
When two types conflict and they are not types which can have forwards
(say, two arrays of different sizes with the same name in two different
TUs) the CTF deduplicator uses a popularity contest to decide what to
do: the type cited by the most other types ends up put into the shared
dict, while the others are relegated to per-CU child dicts.
This works well as long as one type *is* most popular -- but what if
there is a tie? If several types have the same popularity count,
we end up picking the first we run across and promoting it, and
unfortunately since we are working over a dynhash in essentially
arbitrary order, this means we promote a random one. So multiple
runs of ld with the same inputs can produce different outputs!
All the outputs are valid, but this is still undesirable.
Adjust things to use the same strategy used to sort types on the output:
when there is a tie, always put the type that appears in a CU that
appeared earlier on the link line (and if there is somehow still a tie,
which should be impossible, pick the type with the lowest type ID).
Add a testcase -- and since this emerged when trying out extern arrays,
check that those work as well (this requires a newer GCC, but since all
GCCs that can emit CTF at all are unreleased this is probably OK as
well).
Fix up one testcase that has slight type ordering changes as a result
of this change.
libctf/ChangeLog:
* ctf-dedup.c (ctf_dedup_detect_name_ambiguity): Use
cd_output_first_gid to break ties.
ld/ChangeLog:
* testsuite/ld-ctf/array-conflicted-ordering.d: New test, using...
* testsuite/ld-ctf/array-char-conflicting-1.c: ... this...
* testsuite/ld-ctf/array-char-conflicting-2.c: ... and this.
* testsuite/ld-ctf/array-extern.d: New test, using...
* testsuite/ld-ctf/array-extern.c: ... this.
* testsuite/ld-ctf/conflicting-typedefs.d: Adjust for ordering
changes.
libctf, ld: diagnose corrupted CTF header cth_strlen
The last section in a CTF dict is the string table, at an offset
represented by the cth_stroff header field. Its length is recorded in
the next field, cth_strlen, and the two added together are taken as the
size of the CTF dict. Upon opening a dict, we check that none of the
header offsets exceed this size, and we check when uncompressing a
compressed dict that the result of the uncompression is the same length:
but CTF dicts need not be compressed, and short ones are not.
Uncompressed dicts just use the ctf_size without checking it. This
field is thankfully almost unused: it is mostly used when reserializing
a dict, which can't be done to dicts read off disk since they're
read-only.
However, when opening an uncompressed foreign-endian dict we have to
copy it out of the mmaped region it is stored in so we can endian-
swap it, and we use ctf_size when doing that. When the cth_strlen is
corrupt, this can overrun.
Fix this by checking the ctf_size in all uncompressed cases, just as we
already do in the compressed case. Add a new test.
This came to light because various corrupted-CTF raw-asm tests had an
incorrect cth_strlen: fix all of them so they produce the expected
error again.
libctf/
PR libctf/28933
* ctf-open.c (ctf_bufopen_internal): Always check uncompressed
CTF dict sizes against the section size in case the cth_strlen is
corrupt.
ld/
PR libctf/28933
* testsuite/ld-ctf/diag-strlen-invalid.*: New test,
derived from diag-cttname-invalid.s.
* testsuite/ld-ctf/diag-cttname-invalid.s: Fix incorrect cth_strlen.
* testsuite/ld-ctf/diag-cttname-null.s: Likewise.
* testsuite/ld-ctf/diag-cuname.s: Likewise.
* testsuite/ld-ctf/diag-parlabel.s: Likewise.
* testsuite/ld-ctf/diag-parname.s: Likewise.
libctf, ld: dump enums: generally improve dump formatting
This commit adds dumping of enumerands in this general form:
0x3: (kind 8) enum eleven_els (size 0x4) (aligned at 0x4)
ELEVEN_ONE: 10
ELEVEN_TWO: 11
ELEVEN_THREE: -256
ELEVEN_FOUR: -255
ELEVEN_FIVE: -254
...
ELEVEN_SEVEN: -252
ELEVEN_EIGHT: -251
ELEVEN_NINE: -250
ELEVEN_TEN: -249
ELEVEN_ELEVEN: -248
The first and last enumerands in the enumerated type are printed so that
you can tell if they've been cut off at one end or the other. (For now,
there is no way to control how many enumerands are printed.)
The dump output in general is improved, from this sort of thing a few
days ago:
4c: char [0x0:0x8] (size 0x1)
[0x0] (ID 0x4c) (kind 1) char:8 (aligned at 0x1, format 0x3, offset:bits 0x0:0x8)
4d: char * (size 0x8) -> 4c: char [0x0:0x8] (size 0x1)
[0x0] (ID 0x4d) (kind 3) char * (aligned at 0x8)
[...]
5a: struct _IO_FILE (size 0xd8)
[0x0] (ID 0x5a) (kind 6) struct _IO_FILE (aligned at 0x4)
[0x0] (ID 0x3) (kind 1) int _flags:32 (aligned at 0x4, format 0x1, offset:bits 0x0:0x20)
[0x40] (ID 0x4d) (kind 3) char * _IO_read_ptr (aligned at 0x8)
[0x80] (ID 0x4d) (kind 3) char * _IO_read_end (aligned at 0x8)
[0xc0] (ID 0x4d) (kind 3) char * _IO_read_base (aligned at 0x8)
5b: __FILE (size 0xd8) -> 5a: struct _IO_FILE (size 0xd8)
[0x0] (ID 0x5b) (kind 10) __FILE (aligned at 0x4)
[0x0] (ID 0x3) (kind 1) int _flags:32 (aligned at 0x4, format 0x1, offset:bits 0x0:0x20)
[0x40] (ID 0x4d) (kind 3) char * _IO_read_ptr (aligned at 0x8)
[0x80] (ID 0x4d) (kind 3) char * _IO_read_end (aligned at 0x8)
[0xc0] (ID 0x4d) (kind 3) char * _IO_read_base (aligned at 0x8)
[...]
406: struct coff_link_hash_entry (size 0x60)
[0x0] (ID 0x406) (kind 6) struct coff_link_hash_entry (aligned at 0x8)
[0x0] (ID 0x2b3) (kind 6) struct bfd_link_hash_entry root (aligned at 0x8)
[0x0] (ID 0x1d6) (kind 6) struct bfd_hash_entry root (aligned at 0x8)
[0x0] (ID 0x1d7) (kind 3) struct bfd_hash_entry * next (aligned at 0x8)
[0x40] (ID 0x61) (kind 3) const char * string (aligned at 0x8)
[0x80] (ID 0x1) (kind 1) long unsigned int hash:64 (aligned at 0x8, format 0x0, offset:bits 0x0:0x40)
[0xc0] (ID 0x397) (kind 8) enum bfd_link_hash_type type:8 (aligned at 0x1, format 0x0, offset:bits 0x0:0x8)
[0xc8] (ID 0x1c7) (kind 1) unsigned int non_ir_ref_regular:1 (aligned at 0x1, format 0x0, offset:bits 0x8:0x1)
[0xc9] (ID 0x1c8) (kind 1) unsigned int non_ir_ref_dynamic:1 (aligned at 0x1, format 0x0, offset:bits 0x9:0x1)
[0xca] (ID 0x1c9) (kind 1) unsigned int linker_def:1 (aligned at 0x1, format 0x0, offset:bits 0xa:0x1)
[0xcb] (ID 0x1ca) (kind 1) unsigned int ldscript_def:1 (aligned at 0x1, format 0x0, offset:bits 0xb:0x1)
[0xcc] (ID 0x1cb) (kind 1) unsigned int rel_from_abs:1 (aligned at 0x1, format 0x0, offset:bits 0xc:0x1)
... to this:
0x4c: (kind 1) char (format 0x3) (size 0x1) (aligned at 0x1)
0x4d: (kind 3) char * (size 0x8) (aligned at 0x8) -> 0x4c: (kind 1) char (format 0x3) (size 0x1) (aligned at 0x1)
0x5a: (kind 6) struct _IO_FILE (size 0xd8) (aligned at 0x4)
[0x0] _flags: ID 0x3: (kind 1) int (format 0x1) (size 0x4) (aligned at 0x4)
[0x40] _IO_read_ptr: ID 0x4d: (kind 3) char * (size 0x8) (aligned at 0x8)
[0x80] _IO_read_end: ID 0x4d: (kind 3) char * (size 0x8) (aligned at 0x8)
[0xc0] _IO_read_base: ID 0x4d: (kind 3) char * (size 0x8) (aligned at 0x8)
[0x100] _IO_write_base: ID 0x4d: (kind 3) char * (size 0x8) (aligned at 0x8)
0x5b: (kind 10) __FILE (size 0xd8) (aligned at 0x4) -> 0x5a: (kind 6) struct _IO_FILE (size 0xd8) (aligned at 0x4)
[...]
0x406: (kind 6) struct coff_link_hash_entry (size 0x60) (aligned at 0x8)
[0x0] root: ID 0x2b3: (kind 6) struct bfd_link_hash_entry (size 0x38) (aligned at 0x8)
[0x0] root: ID 0x1d6: (kind 6) struct bfd_hash_entry (size 0x18) (aligned at 0x8)
[0x0] next: ID 0x1d7: (kind 3) struct bfd_hash_entry * (size 0x8) (aligned at 0x8)
[0x40] string: ID 0x61: (kind 3) const char * (size 0x8) (aligned at 0x8)
[0x80] hash: ID 0x1: (kind 1) long unsigned int (format 0x0) (size 0x8) (aligned at 0x8)
[0xc0] type: ID 0x397: (kind 8) enum bfd_link_hash_type (format 0x7f2e) (size 0x1) (aligned at 0x1)
[0xc8] non_ir_ref_regular: ID 0x1c7: (kind 1) unsigned int:1 [slice 0x8:0x1] (format 0x0) (size 0x1) (aligned at 0x1)
[0xc9] non_ir_ref_dynamic: ID 0x1c8: (kind 1) unsigned int:1 [slice 0x9:0x1] (format 0x0) (size 0x1) (aligned at 0x1)
[0xca] linker_def: ID 0x1c9: (kind 1) unsigned int:1 [slice 0xa:0x1] (format 0x0) (size 0x1) (aligned at 0x1)
[0xcb] ldscript_def: ID 0x1ca: (kind 1) unsigned int:1 [slice 0xb:0x1] (format 0x0) (size 0x1) (aligned at 0x1)
[0xcc] rel_from_abs: ID 0x1cb: (kind 1) unsigned int:1 [slice 0xc:0x1] (format 0x0) (size 0x1) (aligned at 0x1)
[...]
In particular, indented subsections are only present for actual structs
and unions, not forwards to them, and the structure itself doesn't add a
spurious level of indentation; structure field names are easier to spot
(at the cost of not making them look so much like C field declarations
any more, but they weren't always shown in valid decl syntax even before
this change) the size, type kind, and alignment are shown for all types
for which they are meaningful; bitfield info is only shown for actual
bitfields within structures and not ordinary integral fields; and type
IDs are never omitted. Type printing is in general much more consistent
and there is much less duplicated code in the type dumper.
There is one user-visible effect outside the dumper: ctf_type_(a)name
was erroneously emitting a trailing space on the name of slice types,
even though a slice of an int and an int with the corresponding encoding
represent the same type and should have the same print form. This
trailing space is now gone.
ld/ChangeLog
2021-01-05 Nick Alcock <nick.alcock@oracle.com>
* testsuite/ld-ctf/array.d: Adjust for dumper changes.
* testsuite/ld-ctf/conflicting-cycle-1.B-1.d: Likewise.
* testsuite/ld-ctf/conflicting-cycle-1.B-2.d: Likewise.
* testsuite/ld-ctf/conflicting-cycle-1.parent.d: Likewise.
* testsuite/ld-ctf/conflicting-cycle-2.A-1.d: Likewise.
* testsuite/ld-ctf/conflicting-cycle-2.A-2.d: Likewise.
* testsuite/ld-ctf/conflicting-cycle-2.parent.d: Likewise.
* testsuite/ld-ctf/conflicting-cycle-3.C-1.d: Likewise.
* testsuite/ld-ctf/conflicting-cycle-3.C-2.d: Likewise.
* testsuite/ld-ctf/conflicting-cycle-3.parent.d: Likewise.
* testsuite/ld-ctf/conflicting-enums.d: Likewise.
* testsuite/ld-ctf/conflicting-typedefs.d: Likewise.
* testsuite/ld-ctf/cross-tu-cyclic-conflicting.d: Likewise.
* testsuite/ld-ctf/cross-tu-cyclic-nonconflicting.d: Likewise.
* testsuite/ld-ctf/cross-tu-into-cycle.d: Likewise.
* testsuite/ld-ctf/cross-tu-noncyclic.d: Likewise.
* testsuite/ld-ctf/cycle-1.d: Likewise.
* testsuite/ld-ctf/cycle-2.A.d: Likewise.
* testsuite/ld-ctf/cycle-2.B.d: Likewise.
* testsuite/ld-ctf/cycle-2.C.d: Likewise.
* testsuite/ld-ctf/data-func-conflicted.d: Likewise.
* testsuite/ld-ctf/diag-cttname-null.d: Likewise.
* testsuite/ld-ctf/diag-cuname.d: Likewise.
* testsuite/ld-ctf/diag-parlabel.d: Likewise.
* testsuite/ld-ctf/diag-wrong-magic-number-mixed.d: Likewise.
* testsuite/ld-ctf/forward.d: Likewise.
* testsuite/ld-ctf/function.d: Likewise.
* testsuite/ld-ctf/slice.d: Likewise.
* testsuite/ld-ctf/super-sub-cycles.d: Likewise.
* testsuite/ld-ctf/enums.c: New test.
* testsuite/ld-ctf/enums.d: New test.
libctf/ChangeLog
2021-01-05 Nick Alcock <nick.alcock@oracle.com>
* ctf-decl.c (ctf_decl_push): Exclude slices from the decl stack.
* ctf-types.c (ctf_type_aname): No longer deal with slices here.
* ctf-dump.c (ctf_dump_membstate_t) <cdm_toplevel_indent>: Constify.
(CTF_FT_REFS): New.
(CTF_FT_BITFIELD): Likewise.
(CTF_FT_ID): Likewise.
(ctf_dump_member): Do not do indentation here. Migrate the
type-printing parts of this into...
(ctf_dump_format_type): ... here, to be shared by all type printers.
Get the errno value for non-representable types right. Do not print
bitfield info for non-bitfields. Improve the format and indentation
of other type output. Shuffle spacing around to make all indentation
either 'width of column' or 4 chars.
(ctf_dump_label): Pass CTF_FT_REFS to ctf_dump_format_type.
(ctf_dump_objts): Likewise. Spacing shuffle.
(ctf_dump_var): Likewise.
(type_hex_digits): Migrate down in the file, to above its new user.
(ctf_dump_type): Indent here instead. Pass CTF_FT_REFS to
ctf_dump_format_type. Don't trim off excess linefeeds now we no
longer generate them. Dump enumerated types.
libctf: dedup: enums with overlapping enumerators are conflicting
The CTF deduplicator was not considering enumerators inside enum types to be
things that caused type conflicts, so if the following two TUs were linked
together, you would end up with the following in the resulting dict:
1.c:
enum foo { A, B };
2.c:
enum bar { A, B };
linked:
enum foo { A, B };
enum bar { A, B };
This does work -- but it's not something that's valid C, and the general
point of the shared dict is that it is something that you could potentially
get from any valid C TU.
So consider such types to be conflicting, but obviously don't consider
actually identical enums to be conflicting, even though they too have (all)
their identifiers in common. This involves surprisingly little code. The
deduplicator detects conflicting types by counting types in a hash table of
hash tables:
decorated identifier -> (type hash -> count)
where the COUNT is the number of times a given hash has been observed: any
name with more than one hash associated with it is considered conflicting
(the count is used to identify the most common such name for promotion to
the shared dict).
Before now, those identifiers were all the identifiers of types (possibly
decorated with their namespace on the front for enumerator identifiers), but
we can equally well put *enumeration constant names* in there, undecorated
like the identifiers of types in the global namespace, with the type hash
being the hash of each enum containing that enumerator. The existing
conflicting-type-detection code will then accurately identify distinct enums
with enumeration constants in common. The enum that contains the most
commonly-appearing enumerators will be promoted to the shared dict.
libctf/
* ctf-impl.h (ctf_dedup_t) <cd_name_counts>: Extend comment.
* ctf-dedup.c (ctf_dedup_count_name): New, split out of...
(ctf_dedup_populate_mappings): ... here. Call it for all
* enumeration constants in an enum as well as types.
ld/
* testsuite/ld-ctf/enum-3.c: New test CTF.
* testsuite/ld-ctf/enum-4.c: Likewise.
* testsuite/ld-ctf/overlapping-enums.d: New test.
* testsuite/ld-ctf/overlapping-enums-2.d: Likewise.
libctf: dedup: enums with overlapping enumerators are conflicting
The CTF deduplicator was not considering enumerators inside enum types to be
things that caused type conflicts, so if the following two TUs were linked
together, you would end up with the following in the resulting dict:
1.c:
enum foo { A, B };
2.c:
enum bar { A, B };
linked:
enum foo { A, B };
enum bar { A, B };
This does work -- but it's not something that's valid C, and the general
point of the shared dict is that it is something that you could potentially
get from any valid C TU.
So consider such types to be conflicting, but obviously don't consider
actually identical enums to be conflicting, even though they too have (all)
their identifiers in common. This involves surprisingly little code. The
deduplicator detects conflicting types by counting types in a hash table of
hash tables:
decorated identifier -> (type hash -> count)
where the COUNT is the number of times a given hash has been observed: any
name with more than one hash associated with it is considered conflicting
(the count is used to identify the most common such name for promotion to
the shared dict).
Before now, those identifiers were all the identifiers of types (possibly
decorated with their namespace on the front for enumerator identifiers), but
we can equally well put *enumeration constant names* in there, undecorated
like the identifiers of types in the global namespace, with the type hash
being the hash of each enum containing that enumerator. The existing
conflicting-type-detection code will then accurately identify distinct enums
with enumeration constants in common. The enum that contains the most
commonly-appearing enumerators will be promoted to the shared dict.
libctf/
* ctf-impl.h (ctf_dedup_t) <cd_name_counts>: Extend comment.
* ctf-dedup.c (ctf_dedup_count_name): New, split out of...
(ctf_dedup_populate_mappings): ... here. Call it for all
* enumeration constants in an enum as well as types.
ld/
* testsuite/ld-ctf/enum-3.c: New test CTF.
* testsuite/ld-ctf/enum-4.c: Likewise.
* testsuite/ld-ctf/overlapping-enums.d: New test.
* testsuite/ld-ctf/overlapping-enums-2.d: Likewise.
libctf, ld: dump enums: generally improve dump formatting
This commit adds dumping of enumerands in this general form:
0x3: (kind 8) enum eleven_els (size 0x4) (aligned at 0x4)
ELEVEN_ONE: 10
ELEVEN_TWO: 11
ELEVEN_THREE: -256
ELEVEN_FOUR: -255
ELEVEN_FIVE: -254
...
ELEVEN_SEVEN: -252
ELEVEN_EIGHT: -251
ELEVEN_NINE: -250
ELEVEN_TEN: -249
ELEVEN_ELEVEN: -248
The first and last enumerands in the enumerated type are printed so that
you can tell if they've been cut off at one end or the other. (For now,
there is no way to control how many enumerands are printed.)
The dump output in general is improved, from this sort of thing a few
days ago:
4c: char [0x0:0x8] (size 0x1)
[0x0] (ID 0x4c) (kind 1) char:8 (aligned at 0x1, format 0x3, offset:bits 0x0:0x8)
4d: char * (size 0x8) -> 4c: char [0x0:0x8] (size 0x1)
[0x0] (ID 0x4d) (kind 3) char * (aligned at 0x8)
[...]
5a: struct _IO_FILE (size 0xd8)
[0x0] (ID 0x5a) (kind 6) struct _IO_FILE (aligned at 0x4)
[0x0] (ID 0x3) (kind 1) int _flags:32 (aligned at 0x4, format 0x1, offset:bits 0x0:0x20)
[0x40] (ID 0x4d) (kind 3) char * _IO_read_ptr (aligned at 0x8)
[0x80] (ID 0x4d) (kind 3) char * _IO_read_end (aligned at 0x8)
[0xc0] (ID 0x4d) (kind 3) char * _IO_read_base (aligned at 0x8)
5b: __FILE (size 0xd8) -> 5a: struct _IO_FILE (size 0xd8)
[0x0] (ID 0x5b) (kind 10) __FILE (aligned at 0x4)
[0x0] (ID 0x3) (kind 1) int _flags:32 (aligned at 0x4, format 0x1, offset:bits 0x0:0x20)
[0x40] (ID 0x4d) (kind 3) char * _IO_read_ptr (aligned at 0x8)
[0x80] (ID 0x4d) (kind 3) char * _IO_read_end (aligned at 0x8)
[0xc0] (ID 0x4d) (kind 3) char * _IO_read_base (aligned at 0x8)
[...]
406: struct coff_link_hash_entry (size 0x60)
[0x0] (ID 0x406) (kind 6) struct coff_link_hash_entry (aligned at 0x8)
[0x0] (ID 0x2b3) (kind 6) struct bfd_link_hash_entry root (aligned at 0x8)
[0x0] (ID 0x1d6) (kind 6) struct bfd_hash_entry root (aligned at 0x8)
[0x0] (ID 0x1d7) (kind 3) struct bfd_hash_entry * next (aligned at 0x8)
[0x40] (ID 0x61) (kind 3) const char * string (aligned at 0x8)
[0x80] (ID 0x1) (kind 1) long unsigned int hash:64 (aligned at 0x8, format 0x0, offset:bits 0x0:0x40)
[0xc0] (ID 0x397) (kind 8) enum bfd_link_hash_type type:8 (aligned at 0x1, format 0x0, offset:bits 0x0:0x8)
[0xc8] (ID 0x1c7) (kind 1) unsigned int non_ir_ref_regular:1 (aligned at 0x1, format 0x0, offset:bits 0x8:0x1)
[0xc9] (ID 0x1c8) (kind 1) unsigned int non_ir_ref_dynamic:1 (aligned at 0x1, format 0x0, offset:bits 0x9:0x1)
[0xca] (ID 0x1c9) (kind 1) unsigned int linker_def:1 (aligned at 0x1, format 0x0, offset:bits 0xa:0x1)
[0xcb] (ID 0x1ca) (kind 1) unsigned int ldscript_def:1 (aligned at 0x1, format 0x0, offset:bits 0xb:0x1)
[0xcc] (ID 0x1cb) (kind 1) unsigned int rel_from_abs:1 (aligned at 0x1, format 0x0, offset:bits 0xc:0x1)
... to this:
0x4c: (kind 1) char (format 0x3) (size 0x1) (aligned at 0x1)
0x4d: (kind 3) char * (size 0x8) (aligned at 0x8) -> 0x4c: (kind 1) char (format 0x3) (size 0x1) (aligned at 0x1)
0x5a: (kind 6) struct _IO_FILE (size 0xd8) (aligned at 0x4)
[0x0] _flags: ID 0x3: (kind 1) int (format 0x1) (size 0x4) (aligned at 0x4)
[0x40] _IO_read_ptr: ID 0x4d: (kind 3) char * (size 0x8) (aligned at 0x8)
[0x80] _IO_read_end: ID 0x4d: (kind 3) char * (size 0x8) (aligned at 0x8)
[0xc0] _IO_read_base: ID 0x4d: (kind 3) char * (size 0x8) (aligned at 0x8)
[0x100] _IO_write_base: ID 0x4d: (kind 3) char * (size 0x8) (aligned at 0x8)
0x5b: (kind 10) __FILE (size 0xd8) (aligned at 0x4) -> 0x5a: (kind 6) struct _IO_FILE (size 0xd8) (aligned at 0x4)
[...]
0x406: (kind 6) struct coff_link_hash_entry (size 0x60) (aligned at 0x8)
[0x0] root: ID 0x2b3: (kind 6) struct bfd_link_hash_entry (size 0x38) (aligned at 0x8)
[0x0] root: ID 0x1d6: (kind 6) struct bfd_hash_entry (size 0x18) (aligned at 0x8)
[0x0] next: ID 0x1d7: (kind 3) struct bfd_hash_entry * (size 0x8) (aligned at 0x8)
[0x40] string: ID 0x61: (kind 3) const char * (size 0x8) (aligned at 0x8)
[0x80] hash: ID 0x1: (kind 1) long unsigned int (format 0x0) (size 0x8) (aligned at 0x8)
[0xc0] type: ID 0x397: (kind 8) enum bfd_link_hash_type (format 0x7f2e) (size 0x1) (aligned at 0x1)
[0xc8] non_ir_ref_regular: ID 0x1c7: (kind 1) unsigned int:1 [slice 0x8:0x1] (format 0x0) (size 0x1) (aligned at 0x1)
[0xc9] non_ir_ref_dynamic: ID 0x1c8: (kind 1) unsigned int:1 [slice 0x9:0x1] (format 0x0) (size 0x1) (aligned at 0x1)
[0xca] linker_def: ID 0x1c9: (kind 1) unsigned int:1 [slice 0xa:0x1] (format 0x0) (size 0x1) (aligned at 0x1)
[0xcb] ldscript_def: ID 0x1ca: (kind 1) unsigned int:1 [slice 0xb:0x1] (format 0x0) (size 0x1) (aligned at 0x1)
[0xcc] rel_from_abs: ID 0x1cb: (kind 1) unsigned int:1 [slice 0xc:0x1] (format 0x0) (size 0x1) (aligned at 0x1)
[...]
In particular, indented subsections are only present for actual structs
and unions, not forwards to them, and the structure itself doesn't add a
spurious level of indentation; structure field names are easier to spot
(at the cost of not making them look so much like C field declarations
any more, but they weren't always shown in valid decl syntax even before
this change) the size, type kind, and alignment are shown for all types
for which they are meaningful; bitfield info is only shown for actual
bitfields within structures and not ordinary integral fields; and type
IDs are never omitted. Type printing is in general much more consistent
and there is much less duplicated code in the type dumper.
There is one user-visible effect outside the dumper: ctf_type_(a)name
was erroneously emitting a trailing space on the name of slice types,
even though a slice of an int and an int with the corresponding encoding
represent the same type and should have the same print form. This
trailing space is now gone.
ld/ChangeLog
2021-01-05 Nick Alcock <nick.alcock@oracle.com>
* testsuite/ld-ctf/array.d: Adjust for dumper changes.
* testsuite/ld-ctf/conflicting-cycle-1.B-1.d: Likewise.
* testsuite/ld-ctf/conflicting-cycle-1.B-2.d: Likewise.
* testsuite/ld-ctf/conflicting-cycle-1.parent.d: Likewise.
* testsuite/ld-ctf/conflicting-cycle-2.A-1.d: Likewise.
* testsuite/ld-ctf/conflicting-cycle-2.A-2.d: Likewise.
* testsuite/ld-ctf/conflicting-cycle-2.parent.d: Likewise.
* testsuite/ld-ctf/conflicting-cycle-3.C-1.d: Likewise.
* testsuite/ld-ctf/conflicting-cycle-3.C-2.d: Likewise.
* testsuite/ld-ctf/conflicting-cycle-3.parent.d: Likewise.
* testsuite/ld-ctf/conflicting-enums.d: Likewise.
* testsuite/ld-ctf/conflicting-typedefs.d: Likewise.
* testsuite/ld-ctf/cross-tu-cyclic-conflicting.d: Likewise.
* testsuite/ld-ctf/cross-tu-cyclic-nonconflicting.d: Likewise.
* testsuite/ld-ctf/cross-tu-into-cycle.d: Likewise.
* testsuite/ld-ctf/cross-tu-noncyclic.d: Likewise.
* testsuite/ld-ctf/cycle-1.d: Likewise.
* testsuite/ld-ctf/cycle-2.A.d: Likewise.
* testsuite/ld-ctf/cycle-2.B.d: Likewise.
* testsuite/ld-ctf/cycle-2.C.d: Likewise.
* testsuite/ld-ctf/data-func-conflicted.d: Likewise.
* testsuite/ld-ctf/diag-cttname-null.d: Likewise.
* testsuite/ld-ctf/diag-cuname.d: Likewise.
* testsuite/ld-ctf/diag-parlabel.d: Likewise.
* testsuite/ld-ctf/diag-wrong-magic-number-mixed.d: Likewise.
* testsuite/ld-ctf/forward.d: Likewise.
* testsuite/ld-ctf/function.d: Likewise.
* testsuite/ld-ctf/slice.d: Likewise.
* testsuite/ld-ctf/super-sub-cycles.d: Likewise.
* testsuite/ld-ctf/enums.c: New test.
* testsuite/ld-ctf/enums.d: New test.
libctf/ChangeLog
2021-01-05 Nick Alcock <nick.alcock@oracle.com>
* ctf-decl.c (ctf_decl_push): Exclude slices from the decl stack.
* ctf-types.c (ctf_type_aname): No longer deal with slices here.
* ctf-dump.c (ctf_dump_membstate_t) <cdm_toplevel_indent>: Constify.
(CTF_FT_REFS): New.
(CTF_FT_BITFIELD): Likewise.
(CTF_FT_ID): Likewise.
(ctf_dump_member): Do not do indentation here. Migrate the
type-printing parts of this into...
(ctf_dump_format_type): ... here, to be shared by all type printers.
Get the errno value for non-representable types right. Do not print
bitfield info for non-bitfields. Improve the format and indentation
of other type output. Shuffle spacing around to make all indentation
either 'width of column' or 4 chars.
(ctf_dump_label): Pass CTF_FT_REFS to ctf_dump_format_type.
(ctf_dump_objts): Likewise. Spacing shuffle.
(ctf_dump_var): Likewise.
(type_hex_digits): Migrate down in the file, to above its new user.
(ctf_dump_type): Indent here instead. Pass CTF_FT_REFS to
ctf_dump_format_type. Don't trim off excess linefeeds now we no
longer generate them. Dump enumerated types.
libctf, ld: prohibit getting the size or alignment of forwards
C allows you to do only a very few things with entities of incomplete
type (as opposed to pointers to them): make pointers to them and give
them cv-quals, roughly. In particular you can't sizeof them and you
can't get their alignment.
We cannot impose all the requirements the standard imposes on CTF users,
because the deduplicator can transform any structure type into a forward
for the purposes of breaking cycles: so CTF type graphs can easily
contain things like arrays of forward type (if you want to figure out
their size or alignment, you need to chase down the types this forward
might be a forward to in child TU dicts: we will soon add API functions
to make doing this much easier).
Nonetheless, it is still meaningless to ask for the size or alignment of
forwards: but libctf didn't prohibit this and returned nonsense from
internal implementation details when you asked (it returned the kind of
the pointed-to type as both the size and alignment, because forwards
reuse ctt_type as a type kind, and ctt_type and ctt_size overlap). So
introduce a new error, ECTF_INCOMPLETE, which is returned when you try
to get the size or alignment of forwards: we also return it when you try
to do things that require libctf itself to get the size or alignment of
a forward, notably using a forward as an array index type (which C
should never do in any case) or adding forwards to structures without
specifying their offset explicitly.
The dumper will not emit size or alignment info for forwards any more.
(This should not be an API break since ctf_type_size and ctf_type_align
could both return errors before now: any code that isn't expecting error
returns is already potentially broken.)
include/ChangeLog
2021-01-05 Nick Alcock <nick.alcock@oracle.com>
* ctf-api.h (ECTF_INCOMPLETE): New.
(ECTF_NERR): Adjust.
ld/ChangeLog
2021-01-05 Nick Alcock <nick.alcock@oracle.com>
* testsuite/ld-ctf/conflicting-cycle-1.parent.d: Adjust for dumper
changes.
* testsuite/ld-ctf/cross-tu-cyclic-conflicting.d: Likewise.
* testsuite/ld-ctf/forward.c: New test...
* testsuite/ld-ctf/forward.d: ... and results.
libctf/ChangeLog
2021-01-05 Nick Alcock <nick.alcock@oracle.com>
* ctf-types.c (ctf_type_resolve): Improve comment.
(ctf_type_size): Yield ECTF_INCOMPLETE when applied to forwards.
Emit errors into the right dict.
(ctf_type_align): Likewise.
* ctf-create.c (ctf_add_member_offset): Yield ECTF_INCOMPLETE
when adding a member without explicit offset when this member, or
the previous member, is incomplete.
* ctf-dump.c (ctf_dump_format_type): Do not try to print the size of
forwards.
(ctf_dump_member): Do not try to print their alignment.
libctf, ld: fix test results for upstream GCC
The tests currently in binutils are aimed at the original GCC-based
implementation of CTF, which emitted CTF directly from GCC's internal
representation. The approach now under review emits CTF from DWARF,
with an eye to eventually doing this for all non-DWARF debuginfo-like
formats GCC supports. It also uses a different flag to enable
CTF emission (-gctf rather than -gt).
Adjust the testsuite accordingly.
Given that the ld testsuite results are dependent on type ordering,
which we do not guarantee at all, it's amazing how little changes. We
see a few type ordering differences, slices change because the old GCC
was buggy (slices were emitted "backwards", from the wrong end of the
machine word) and its expected results were wrong, and GCC now emits the
underlying integral type for enumerated types, though CTF has no way to
record this yet (coming in v4).
GCC also now emits even hidden symbols into the symtab (and thus
symtypetab), so one symtypetab test changes its expected results
slightly to compensate.
Also add tests for the CTF_K_UNKNOWN nonrepresentable type: this
couldn't be done before now since the only GCC that emits CTF_K_UNKNOWN
for nonrepresentable types is the new one.
ld/ChangeLog
2021-05-06 Nick Alcock <nick.alcock@oracle.com>
* testsuite/ld-ctf/ctf.exp: Use -gctf, not -gt.
* testsuite/lib/ld-lib.exp: Likewise.
* testsuite/ld-ctf/nonrepresentable-1.c: New test for nonrepresentable types.
* testsuite/ld-ctf/nonrepresentable-2.c: Likewise.
* testsuite/ld-ctf/nonrepresentable.d: Likewise.
* testsuite/ld-ctf/array.d: Larger type section.
* testsuite/ld-ctf/data-func-conflicted.d: Likewise.
* testsuite/ld-ctf/enums.d: Likewise.
* testsuite/ld-ctf/conflicting-enums.d: Don't compare types.
* testsuite/ld-ctf/cross-tu-cyclic-conflicting.d: Changed type order.
* testsuite/ld-ctf/cross-tu-noncyclic.d: Likewise.
* testsuite/ld-ctf/slice.d: Adjust for improved slice emission.
libctf/ChangeLog
2021-05-06 Nick Alcock <nick.alcock@oracle.com>
* testsuite/lib/ctf-lib.exp: Use -gctf, not -gt.
* testsuite/libctf-regression/nonstatic-var-section-ld-r.lk:
Hidden symbols now get into the symtypetab anyway.
libctf, ld: fix test results for upstream GCC
The tests currently in binutils are aimed at the original GCC-based
implementation of CTF, which emitted CTF directly from GCC's internal
representation. The approach now under review emits CTF from DWARF,
with an eye to eventually doing this for all non-DWARF debuginfo-like
formats GCC supports. It also uses a different flag to enable
CTF emission (-gctf rather than -gt).
Adjust the testsuite accordingly.
Given that the ld testsuite results are dependent on type ordering,
which we do not guarantee at all, it's amazing how little changes. We
see a few type ordering differences, slices change because the old GCC
was buggy (slices were emitted "backwards", from the wrong end of the
machine word) and its expected results were wrong, and GCC now emits the
underlying integral type for enumerated types, though CTF has no way to
record this yet (coming in v4).
GCC also now emits even hidden symbols into the symtab (and thus
symtypetab), so one symtypetab test changes its expected results
slightly to compensate.
Also add tests for the CTF_K_UNKNOWN nonrepresentable type: this
couldn't be done before now since the only GCC that emits CTF_K_UNKNOWN
for nonrepresentable types is the new one.
ld/ChangeLog
2021-05-06 Nick Alcock <nick.alcock@oracle.com>
* testsuite/ld-ctf/ctf.exp: Use -gctf, not -gt.
* testsuite/lib/ld-lib.exp: Likewise.
* testsuite/ld-ctf/nonrepresentable-1.c: New test for nonrepresentable types.
* testsuite/ld-ctf/nonrepresentable-2.c: Likewise.
* testsuite/ld-ctf/nonrepresentable.d: Likewise.
* testsuite/ld-ctf/array.d: Larger type section.
* testsuite/ld-ctf/data-func-conflicted.d: Likewise.
* testsuite/ld-ctf/enums.d: Likewise.
* testsuite/ld-ctf/conflicting-enums.d: Don't compare types.
* testsuite/ld-ctf/cross-tu-cyclic-conflicting.d: Changed type order.
* testsuite/ld-ctf/cross-tu-noncyclic.d: Likewise.
* testsuite/ld-ctf/slice.d: Adjust for improved slice emission.
libctf/ChangeLog
2021-05-06 Nick Alcock <nick.alcock@oracle.com>
* testsuite/lib/ctf-lib.exp: Use -gctf, not -gt.
* testsuite/libctf-regression/nonstatic-var-section-ld-r.lk:
Hidden symbols now get into the symtypetab anyway.
libctf: dedup: enums with overlapping enumerators are conflicting
The CTF deduplicator was not considering enumerators inside enum types to be
things that caused type conflicts, so if the following two TUs were linked
together, you would end up with the following in the resulting dict:
1.c:
enum foo { A, B };
2.c:
enum bar { A, B };
linked:
enum foo { A, B };
enum bar { A, B };
This does work -- but it's not something that's valid C, and the general
point of the shared dict is that it is something that you could potentially
get from any valid C TU.
So consider such types to be conflicting, but obviously don't consider
actually identical enums to be conflicting, even though they too have (all)
their identifiers in common. This involves surprisingly little code. The
deduplicator detects conflicting types by counting types in a hash table of
hash tables:
decorated identifier -> (type hash -> count)
where the COUNT is the number of times a given hash has been observed: any
name with more than one hash associated with it is considered conflicting
(the count is used to identify the most common such name for promotion to
the shared dict).
Before now, those identifiers were all the identifiers of types (possibly
decorated with their namespace on the front for enumerator identifiers), but
we can equally well put *enumeration constant names* in there, undecorated
like the identifiers of types in the global namespace, with the type hash
being the hash of each enum containing that enumerator. The existing
conflicting-type-detection code will then accurately identify distinct enums
with enumeration constants in common. The enum that contains the most
commonly-appearing enumerators will be promoted to the shared dict.
libctf/
* ctf-impl.h (ctf_dedup_t) <cd_name_counts>: Extend comment.
* ctf-dedup.c (ctf_dedup_count_name): New, split out of...
(ctf_dedup_populate_mappings): ... here. Call it for all
* enumeration constants in an enum as well as types.
ld/
* testsuite/ld-ctf/enum-3.c: New test CTF.
* testsuite/ld-ctf/enum-4.c: Likewise.
* testsuite/ld-ctf/overlapping-enums.d: New test.
* testsuite/ld-ctf/overlapping-enums-2.d: Likewise.
libctf: dedup: enums with overlapping enumerators are conflicting
The CTF deduplicator was not considering enumerators inside enum types to be
things that caused type conflicts, so if the following two TUs were linked
together, you would end up with the following in the resulting dict:
1.c:
enum foo { A, B };
2.c:
enum bar { A, B };
linked:
enum foo { A, B };
enum bar { A, B };
This does work -- but it's not something that's valid C, and the general
point of the shared dict is that it is something that you could potentially
get from any valid C TU.
So consider such types to be conflicting, but obviously don't consider
actually identical enums to be conflicting, even though they too have (all)
their identifiers in common. This involves surprisingly little code. The
deduplicator detects conflicting types by counting types in a hash table of
hash tables:
decorated identifier -> (type hash -> count)
where the COUNT is the number of times a given hash has been observed: any
name with more than one hash associated with it is considered conflicting
(the count is used to identify the most common such name for promotion to
the shared dict).
Before now, those identifiers were all the identifiers of types (possibly
decorated with their namespace on the front for enumerator identifiers), but
we can equally well put *enumeration constant names* in there, undecorated
like the identifiers of types in the global namespace, with the type hash
being the hash of each enum containing that enumerator. The existing
conflicting-type-detection code will then accurately identify distinct enums
with enumeration constants in common. The enum that contains the most
commonly-appearing enumerators will be promoted to the shared dict.
libctf/
* ctf-impl.h (ctf_dedup_t) <cd_name_counts>: Extend comment.
* ctf-dedup.c (ctf_dedup_count_name): New, split out of...
(ctf_dedup_populate_mappings): ... here. Call it for all
* enumeration constants in an enum as well as types.
ld/
* testsuite/ld-ctf/enum-3.c: New test CTF.
* testsuite/ld-ctf/enum-4.c: Likewise.
* testsuite/ld-ctf/overlapping-enums.d: New test.
* testsuite/ld-ctf/overlapping-enums-2.d: Likewise.