libctf: teach ctf_add_type how forwards work

This machinery has been broken for as long as Solaris has existed.
Forwards are meant to encode "struct foo;", "enum foo;" or "union
foo;".  Obviously these all exist in distinct namespaces, so forwards
store the type kind they forward to in their ctt_type member
(which makes conceptual sense if you squint at it).  The addition
machinery uses this to promote forwards to the appropriate type as
needed.

Unfortunately ctf_add_type does not: it checks the global namespace
(which is always wrong), and so fails with a spurious conflict if you
have, say, a typedef and then a forward comes along with the same name,
even if it's a forward to something like a struct.  (This was observed
with <libio.h>, which has "struct _IO_FILE;" and also
"typedef struct _IO_FILE _IO_FILE").  We should look at the recorded
type kind and look in the appropriate namespace.   We should also,
when creating the forward in the new container, use that type kind,
rather than just defaulting to CTF_K_STRUCT and hoping that what
eventually comes along is a struct.

This bug is as old as the first implementation of ctf_add_type in
Solaris.  But we also want a new feature for the linker, closely-related
and touching the same code so we add it here: not only do we want a
forward followed by a struct/union/enum to promote the forward, but
we want want a struct/union/enum followed by a forward to act as a NOP
and return the existing type, because when we're adding many files
in succession to a target link, there will often be already-promoted
forwards (in the shape of a struct/union/enum) that want to unify
with duplicate forwards coming from other object files.

v5: fix tabdamage.

libctf/
	* ctf-create.c (ctf_add_type): Look up and use the forwarded-to
	type kind.  Allow forwards to unify with pre-existing structs/
	unions/enums.

0 files changed, 0 insertions, 0 deletions