libctf: minor error-handling fixes

A transient bug in the preceding change (fixed before commit) exposed a
new failure, of ld/testsuite/ld-ctf/diag-parname.d.  This attempts to
ensure that if we link a dict with child type IDs but no attached
parent, we get a suitable ECTF_NOPARENT error.  This was happening
before this commit, but only by chance, because ctf_variable_iter and
ctf_variable_next check to see if the dict they're passed is a child
dict without an associated parent.  We forgot error-checking on the
ctf_variable_next call, and as a result this was concealed -- and
looking for the problem exposed a new bug.

If any of the lookups beneath ctf_dedup_hash_type fail, the CTF link
does *not* fail, but acts quite bizarrely, skipping the type but
emitting an error to the CTF error/warning log -- so the linker will
report an error, emit a partial CTF dict missing some types, and exit
with exitcode 0 as if nothing went wrong.  Since ctf_dedup_hash_type is
never expected to fail in normal operation, this is surely wrong:
failures at emission time do not emit partial CTF dicts, so failures
at hashing time should not either.

So propagate the error back up.

Also fix a couple of smaller bugs where we fail to properly free things
and/or propagate error codes on various rare link-time errors and
out-of-memory conditions.

libctf/ChangeLog
2021-03-02  Nick Alcock  <nick.alcock@oracle.com>

	* ctf-dedup.c (ctf_dedup): Pass on errors from ctf_dedup_hash_type.
	Call ctf_dedup_fini properly on other errors.
	(ctf_dedup_emit_type): Set the errno on dynhash insertion failure.
	* ctf-link.c (ctf_link_deduplicating_per_cu): Close outputs beyond
	output 0 when asserting because >1 output is found.
	(ctf_link_deduplicating): Likewise, when asserting because the
	shared output is not the same as the passed-in fp.

0 files changed, 0 insertions, 0 deletions