Additional missing byte code frobs for Apple Clang 17.0.0

[sauclovian-g]

With this clang, and with the draft fix for #292,

Apple clang version 17.0.0 (clang-1700.0.13.3)
Target: arm64-apple-darwin24.5.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

and this honk.c:

int foo(int x) {
   return x + 1;
}

compiling with clang -g -O0 -c -emit-llvm honk.c -o honk.bc and loading in SAW gives:

[21:26:03.890] Stack trace:
"llvm_load_module" (honk.saw:1:6-1:22)
instruction code 62 is unknown
from:
	@foo
	FUNCTION_BLOCK
	FUNCTION_BLOCK_ID
	value symbol table
	MODULE_BLOCK
	Bitstream

and then with this gronk.c:

#include <stdio.h>

void foo(void) {
   puts("hi");
}

the same steps give

[21:24:27.152] Encountered the following warnings during parsing:
    Invalid record size: 8
    Expected one of: [6, 7]
    from:
    	METADATA_BASIC_TYPE
    	METADATA_BLOCK
    	METADATA_BLOCK_ID
    	value symbol table
    	MODULE_BLOCK
    	Bitstream
    
    Invalid record size: 24
    Expected size between 16 and 22
    from:
    	METADATA_COMPOSITE_TYPE
    	METADATA_BLOCK
    	METADATA_BLOCK_ID
    	value symbol table
    	MODULE_BLOCK
    	Bitstream
    
Are you sure you're using a supported version of LLVM/Clang?

which might or might not be the same problem.

Both behaviors disappear if you don't build with -g, so that'll serve as a workaround.

[RyanGlScott]

From what I can see, all of these features are actually things that were added upstream to the main LLVM project in later releases:

• The FUNC_CODE_DEBUG_RECORD_DECLARE error is due a function code that was added in LLVM 19.0 and is described in Support debug records (introduced in LLVM 19) #277.
• The METADATA_BASIC_TYPE and METADATA_COMPOSITE_TYPE warnings are most likely due to num_extra_inhabitants, a feature added in LLVM 20.0 and is described in Support num_extra_inhabitants (introduced in LLVM 20.0) #299.

(This perhaps makes sense, since Apple Clang likely develops a lot of experimental features that eventually get added to the mainline.)

[sauclovian-g]

In that case, we can close this issue, no?

[RyanGlScott]

Yes, let's close this in favor of #277 and #299.