https://sourceware.org/bugzilla/show_bug.cgi?id=33047
Bug ID: 33047
Summary: libctf linking generates unexpectedly hidden types
when doing cu-mapped links
Product: binutils
Version: 2.45 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: libctf
Assignee: unassigned at sourceware dot org
Reporter: nick.alcock at oracle dot com
Target Milestone: ---
cu-mapped CTF links are a weird variant of linking which, rather than emitting
conflicting types into child dictionaries named by compilation unit, arranges
to smash multiple named compilation units into one with a different name and
uses those as well. Since this stuffs types from several compilation units into
one, some of those types can conflict, and since GNU ld doesn't use this weird
mode it tends to accumulate bugs. Since the largest use case we possess for
this is the Linux kernel, and it has massive diversity of compilers,
configurations, etc, it can be quite hard to reproduce some of these bugs.
This particular bug causes us to observe output looking like (grepping out only
the relevant bits)
{0x6ef: (kind 6) struct foo (size 0x80) (aligned at 0x8)}
0x6f5: (kind 9) struct foo
0x6f6: (kind 3) struct foo * (size 0x8) (aligned at 0x8) -> 0x6f5: ...
That {...} means 'this type is hidden'. Hidden types cannot be looked up by
name. The general rule of the deduplicator is that types should never be hidden
unless they must be for format validity (e.g. if you might otherwise have
several types with the same name). The deduplicator is expected to never emit
hidden types unless it is doing a cu-mapped link and jamming several
identically-named types into the same CU as a result; in this case, you'd
expect the first type to be visible, and the later ones to be hidden.
You never expect to see what we see here, which is a useful type hidden,
followed by a much less useful one (a forward!) unhidden. This should be fixed
because it's breaking real programs (it breaks drgn startup).
--
You are receiving this mail because:
You are on the CC list for the bug.
