ctf*: exit with error upon terminate()

[emaste]

Summary

The initial port of the CTF tools had a FreeBSD-specific patch to print
the termination message but exit with a 0 status, with a goal of getting
as much to build as possible and silently ignoring any issues.

We're now past the point where silently ignoring failures makes sense;
we need to find and address any remaining issues.

PR:             276826

[markj]

I'm ok with this, but please be sure to try a make tinderbox. I can run it and fix fallout if that helps.

This will break the gcc build, due to missing DWARF 5 support. I'd gotten that partially working last year but there's more to do. I think I saw somewhere that kaiw@ is working on DWARF 5 support. Is that right? We could force the use of DWARF 4 in the meantime.

[jrtc27]

This is long overdue! Though terminate_cleanup needs unifdef'ing (introduced in the import itself in https://cgit.freebsd.org/src/tree/cddl/contrib/opensolaris/tools/ctf/cvt/ctfconvert.c?id=4cc75139b96639698b4e96da3b60cd3d81e9a959). Note this code itself came into the tree in https://cgit.freebsd.org/src/commit/?id=c01977ed3b6d325bae5de5025eb0c6357ee73be5, which is similarly undocumented in the commit message.

[jrtc27]

(and please also note in the commit message that #ifdef __FreeBSD__ for behavioural changes like this in bootstrap tools is incorrect now that we have cross-building from non-FreeBSD, i.e. that cross-building from macOS and Linux can currently fail when FreeBSD ignores the error)

[imp]

In D43743#997652, @jrtc27 wrote:

(and please also note in the commit message that #ifdef __FreeBSD__ for behavioural changes like this in bootstrap tools is incorrect now that we have cross-building from non-FreeBSD, i.e. that cross-building from macOS and Linux can currently fail when FreeBSD ignores the error)

In the past we've used this construct for FreeBSD additions. I'd be surprised if the intent was for cross builds...

[emaste]

PR276930 for an exp-run, tinderbox going now.

[emaste]

Tinderbox looks good. I will push once the exp-run is complete.

[markj]

In D43743#999750, @emaste wrote:

Tinderbox looks good. I will push once the exp-run is complete.

Well, but that's going to break the gcc12 and 13 builds. Do you have a separate patch to force gcc to emit DWARF 4?

[emaste]

Well, but that's going to break the gcc12 and 13 builds.

The issue is that GCC defaults to DWARF 5 now, and ctfconvert/ctfmerge cannot handle it?

Oh, I found PR269928 now.

[markj]

In D43743#999911, @emaste wrote:

Well, but that's going to break the gcc12 and 13 builds.

The issue is that GCC defaults to DWARF 5 now, and ctfconvert/ctfmerge cannot handle it?

Right. I posted D43837 to mitigate this. I see a few other ctfconvert warnings in the gcc12 build, presumably we'll have to address them as part of this effort.

[emaste]

The error I encountered when trying to build with gcc:

ctfconvert -L VERSION -g elf-vdso32.so.o
ERROR: ctfconvert: elf-vdso32.so.o doesn't have type data to convert
*** [elf-vdso32.so.o] Error code 1
make[2]: stopped in /usr/obj/tmp/cirrus-ci-build/amd64.amd64/sys/GENERIC
--- elf-vdso.so.o ---
ctfconvert -L VERSION -g elf-vdso.so.o
ERROR: ctfconvert: elf-vdso.so.o doesn't have type data to convert
*** [elf-vdso.so.o] Error code 1
make[2]: stopped in /usr/obj/tmp/cirrus-ci-build/amd64.amd64/sys/GENERIC
2 errors

[markj]

In D43743#1000889, @emaste wrote:

The error I encountered when trying to build with gcc:

ctfconvert -L VERSION -g elf-vdso32.so.o
ERROR: ctfconvert: elf-vdso32.so.o doesn't have type data to convert
*** [elf-vdso32.so.o] Error code 1
make[2]: stopped in /usr/obj/tmp/cirrus-ci-build/amd64.amd64/sys/GENERIC
--- elf-vdso.so.o ---
ctfconvert -L VERSION -g elf-vdso.so.o
ERROR: ctfconvert: elf-vdso.so.o doesn't have type data to convert
*** [elf-vdso.so.o] Error code 1
make[2]: stopped in /usr/obj/tmp/cirrus-ci-build/amd64.amd64/sys/GENERIC
2 errors

I'm not sure why a clang build doesn't have the same problem. Is it sufficient to add a no-ctfconvert annotation to the corresponding sys/conf/files* entries? I don't see any reason to run ctfconvert on them.

[emaste]

With D43873 applied my next failure is

--- intel_sha1.o ---
ctfconvert -L VERSION -g intel_sha1.o
ERROR: ctfconvert: die 348: unrecognized real type size 2

as an aside while looking at that there are some #ifdef __sparc blocks that might need revisiting (in cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c)