After GCC PR 121411 is fixed, large structures (with offsets > 512MiB)
are written correctly... but libctf cannot query them properly unless
they are even bigger (> 4GiB), because it checks to see if the ctt_size
is CTF_LSIZE_SENT to decide whether to use a ctf_lmember_t or a
ctf_member_t to encode the structure members.  But the structure member
offsets are in *bits*, not bytes: the right value to check is
CTF_LSTRUCT_THRESH, which is 1/8th the size.

(Thanks to Martin Pirker <[email protected]> for the diagnosis
and fix.)

Testing this is a bit fun, because we don't want to emit an error if the
compiler is broken: but we cannot tell whether the compiler is broken
using the existing lookup harness, because its input is passed through
the linker (and thus the broken ld).  So add another sort of link mode,
"objects", which keeps the constituent object files around and passes
both the final linker output and the object files that make it up to the
lookup program.  Our testcase can then check the linker input to see if
the compiler is buggy, and only if it isn't check the linker output and
fail if things aren't right.

libctf/
	PR libctf/33339
	* ctf-types.c (ctf_struct_member): Check CTF_LSTRUCT_THRESH, not
	CTF_LSIZE_SENT.
	* testsuite/lib/ctf-lib.exp (run_lookup_test): New 'objects'
	link option.
	* testsuite/libctf-lookup/big-struct-corruption.*: New test.
	* testsuite/libctf-lookup/big-struct-ctf.c: New test input.

Before GCC PR114186, all looked good in the land of
multidimensional arrays: you wrote

int a[5][10];

and ctf_type_aname() et al would print it as

int [5][10]

Unfortunately this was two bugs in one. GCC was emitting the array as if
it were int a[10][5], i.e. as this:

a -> [10] -> [5] -> int

rather than

a -> [5] -> [10] -> int

as it should be. libctf was hiding this by printing them in the wrong
order, concealing the bug from anyone using objdump --ctf or anything
but actual type graph traversal. Once this was fixed for GCC, the bug
was visible in libctf: multidimensional arrays were printed backwards!
(But this is just a print-time bug: the underlying bug, that something
traversing the type graph would see the array in backwards order, was
fixed by the fix to GCC.)

Fix this libctf bug, printing the arrays the right way round. In a
possibly futile attempt to retain some vestige of backwards
compatibility, introduce a new bug-compat flag CTF_F_ARRNELEMS, which,
if on, indicates that PR114186 is fixed and GCC is emitting array
elements the right way round. (Unfortunately, the fix went in without
this flag, so some GCCs will still emit CTF that will cause libctf to
print them wrong, even with this fix -- but it's no wronger than it was
before, and new GCC and new binutils, as well as GCC older than any fix
for PR114186 and new binutils, will print things properly. Someone
traversing the type graph will see things right after the GCC fix, wrong
before it, and there isn't really any reliable way to tell which you
have, though if CTF_F_ARRNELEMS is set, you definitely have a fixed GCC.
The test checks for this, but it's not something we expect actual users
to ever do -- CTF dict flags are an internal implementation detail with
no user-visible API for a reason.)

[nca: log message, test compat with older compilers]

include/
	* ctf.h (CTF_F_ARRNELEMS): New bug-compat flag.
	(CTF_F_MAX): Adjust.

libctf/
	PR libctf/32161
	* ctf-decl.c (ctf_decl_push): Prepend if this is an array and
	the bug-compat flag is set.
	* ctf-dump.c (ctf_dump_header): Dump the new bug-compat flag.
	* testsuite/libctf-lookup/multidim-array*: New test.