aboutsummaryrefslogtreecommitdiff
path: root/libctf
AgeCommit message (Collapse)AuthorFilesLines
2023-11-20libctf: adding CU mappings should be idempotentNick Alcock1-2/+16
When CTF finds conflicting types, it usually shoves each definition into a CTF dictionary named after the compilation unit. The intent of the obscure "cu-mapped link" feature is to allow you to implement custom linkers that shove the definitions into other, more coarse-grained units (say, one per kernel module, even if a module consists of more than one compilation unit): conflicting types within one of these larger components are hidden from name lookup so you can only look up (an arbitrary one of) them by name, but can still be found by chasing type graph links and are still fully deduplicated. You do this by calling ctf_link_add_cu_mapping (fp, "CU name", "bigger lump name"), repeatedly, with different "CU name"s: the ctf_link() following that will put all conflicting types found in "CU name"s sharing a "bigger lump name" into a child dict in an archive member named "bigger lump name". So it's clear enough what happens if you call it repeatedly with the same "bigger lump name" more than once, because that's the whole point of it: but what if you call it with the same "CU name" repeatedly? ctf_link_add_cu_mapping (fp, "CU name", "bigger lump name"); ctf_link_add_cu_mapping (fp, "CU name", "other name"); This is meant to be the same as just doing the second of these, as if the first was never called. Alas, this isn't what happens, and what you get is instead a bit of an inconsistent mess: more or less, the first takes precedence, which is the exact opposite of what we wanted. Fix this to work the right way round. (I plan to add support for CU-mapped links to GNU ld, mainly so that we can properly *test* this machinery.) libctf/ChangeLog: * ctf-link.c (ctf_create_per_cu): Note the behaviour of repeatedly adding FROMs. (ctf_link_add_cu_mapping): Implement that behavour.
2023-11-15Finalized intl-update patchesArsen Arsenovi?7-64/+2284
* intl: Remove directory. Replaced with out-of-tree GNU gettext. * .gitignore: Add '/gettext*'. * configure.ac (host_libs): Replace intl with gettext. (hbaseargs, bbaseargs, baseargs): Split baseargs into {h,b}baseargs. (skip_barg): New flag. Skips appending current flag to bbaseargs. <library exemptions>: Exempt --with-libintl-{type,prefix} from target and build machine argument passing. * configure: Regenerate. * Makefile.def (host_modules): Replace intl module with gettext module. (configure-ld): Depend on configure-gettext. * Makefile.in: Regenerate. * src-release.sh: Remove references to the intl/ directory.
2023-10-20libctf: fix creation-time parent/child dict confusionsNick Alcock17-20/+322
The fixes applied a few years ago to resolve confusions between parent and child dicts at lookup time also apply in various forms to creation. In general, if you have a type in a parent dict ctf_imported into a child and you do something to it, and the parent dict is writable (created via ctf_create, not opened via ctf_open*) it should work just the same to make changes to that type via a child dict as it does to make the change to the parent dict directly -- and nothing you're prohibited from doing to the parent dict when done directly should be allowed just because you're doing it via a child. Specifically, the following don't work when doing things from the child, but should: - adding a member of a type in the parent to a struct or union in the parent via ctf_add_member or ctf_add_member_offset: this yields ECTF_BADID - adding a member of a type in the parent to a struct or union in the parent via ctf_add_member_encoded: this dumps core (!). - adding an enumerand to an enumerator in the parent: this yields ECTF_BADID - setting the properties of an array in the parent via ctf_set_array; this yields ECTF_BADID Relatedly, some things work when doing things via a child that should fail, yielding a CTF dictionary with invalid content (readable, but meaningless): in particular, you can add a child type to a struct in the parent via any of the ctf_add_member* family and nothing complains at all, even though you should never be able to add references to children to parents (since any given parent can be associated with many different children). A family of tests is added to check each of these cases independently, since some can result in coredumps and it would be nice to test the other cases even if some dump core. They use a common library to do all the actual work. The set of affected API calls was determined by code inspection (auditing all calls to ctf_dtd_lookup): it's possible that I missed a few, but I doubt it, since other cases use ctf_lookup* functions, which already climb to the parent where appropriate. libctf/ChangeLog: PR libctf/30985 * ctf-create.c (ctf_dtd_lookup): Traverse to parents if necessary. (ctf_set_array): Likewise. Report errors on the child; require both parent and child to be writable. (ctf_add_enumerator): Likewise. (ctf_add_member_offset): Likewise. Prohibit addition of child types to structs in the parent. (ctf_add_member_encoded): Do not dereference a NULL dtd: report ECTF_BADID instead. * ctf-string.c (ctf_str_add_ref_internal): Report ENOMEM on the dict if addition of a string ref fails. * testsuite/libctf-writable/parent-child-dtd-crash-lib.c: New library. * testsuite/libctf-writable/parent-child-dtd-enum.*: New test. * testsuite/libctf-writable/parent-child-dtd-enumerator.*: New test. * testsuite/libctf-writable/parent-child-dtd-member-encoded.*: New test. * testsuite/libctf-writable/parent-child-dtd-member-offset.*: New test. * testsuite/libctf-writable/parent-child-dtd-set-array.*: New test. * testsuite/libctf-writable/parent-child-dtd-struct.*: New test. * testsuite/libctf-writable/parent-child-dtd-union.*: New test.
2023-10-18libctf: check for problems with error returnsNick Alcock2-0/+75
We do this as a writable test because the only known-affected platforms (with ssize_t longer than unsigned long) use PE, and we do not have support for CTF linkage in the PE linker yet. PR libctf/30836 * libctf/testsuite/libctf-writable/libctf-errors.*: New test.
2023-10-18libctf: Return CTF_ERR in ctf_type_resolve_unsliced PR 30836Torbjörn SVENSSON1-1/+1
In commit 998a4f589d68503f79695f180fdf1742eeb0a39d, all but one return statement was updated to return the error proper value. This commit rectifies that missed return statement. libctf/ ctf-types.c (ctf_type_resolve_unsliced): Return CTF_ERR on error. Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
2023-10-17libctf: Sanitize error types for PR 30836Torbjörn SVENSSON8-134/+114
Made sure there is no implicit conversion between signed and unsigned return value for functions setting the ctf_errno value. An example of the problem is that in ctf_member_next, the "offset" value is either 0L or (ctf_id_t)-1L, but it should have been 0L or -1L. The issue was discovered while building a 64 bit ld binary to be executed on the Windows platform. Example object file that demonstrates the issue is attached in the PR. libctf/ Affected functions adjusted. Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com> Co-Authored-By: Yvan ROUX <yvan.roux@foss.st.com>
2023-08-12regen configAlan Modra1-21/+52
This regenerates config files changed by the previous 44 commits. Note that subject lines in these commits mostly match the gcc git originating commit.
2023-07-03Add markers for the 2.41 branchNick Clifton1-0/+4
2023-04-08libctf, link: fix CU-mapped links with CTF_LINK_EMPTY_CU_MAPPINGSNick Alcock1-10/+11
This is a bug in the intersection of two obscure options that cannot even be invoked from ld with a feature added to stop ld of the same input file repeatedly from crashing the linker. The latter fix involved tracking input files (internally to libctf) not just with their input CU name but with a version of their input CU name that was augmented with a numeric prefix if their linker input file name was changed, to prevent distinct CTF dicts with the same cuname from overwriting each other. (We can't use just the linker input file name because one linker input can contain many CU dicts, particularly under ld -r). If these inputs then produced conflicting types, those types were emitted into similarly-named output dicts, so we needed similar machinery to detect clashing output dicts and add a numeric prefix to them as well. This works fine, except that if you used the cu-mapping feature to force double-linking of CTF (so that your CTF can be grouped into output dicts larger than a single translation unit) and then also used CTF_LINK_EMPTY_CU_MAPPINGS to force every possible output dict in the mapping to be created (even if empty), we did the creation of empty dicts first, and then all the actual content got considered to be a clash. So you ended up with a pile of useless empty dicts and then all the content was in full dicts with the same names suffixed with a #0. This seems likely to confuse consumers that use this facility. Fixed by generating all the EMPTY_CU_MAPPINGS empty dicts after linking is complete, not before it runs. No impact on ld, which does not do cu-mapped links or pass CTF_LINK_EMPTY_CU_MAPPINGS to ctf_link(). libctf/ * ctf-link.c (ctf_create_per_cu): Don't create new dicts iff one already exists and we are making one for no input in particular. (ctf_link): Emit empty CTF dicts corresponding to no input in particular only after linkiing is complete.
2023-04-08libctf: propagate errors from parents correctlyNick Alcock5-13/+204
CTF dicts have per-dict errno values: as with other errno values these are set on error and left unchanged on success. This means that all errors *must* set the CTF errno: if a call leaves it unchanged, the caller is apt to find a previous, lingering error and misinterpret it as the real error. There are many places in libctf where we carry out operations on parent dicts as a result of carrying out other user-requested operations on child dicts (e.g. looking up information on a pointer to a type will look up the type as well: the pointer might well be in a child and the type it's a pointer to in the parent). Those operations on the parent might fail; if they do, the error must be correctly reflected on the child that the user-visible operation was carried out on. In many places this was not happening. So, audit and fix all those places. Add tests for as many of those cases as possible so they don't regress. libctf/ * ctf-create.c (ctf_add_slice): Use the original dict. * ctf-lookup.c (ctf_lookup_variable): Propagate errors. (ctf_lookup_symbol_idx): Likewise. * ctf-types.c (ctf_member_next): Likewise. (ctf_type_resolve_unsliced): Likewise. (ctf_type_aname): Likewise. (ctf_member_info): Likewise. (ctf_type_rvisit): Likewise. (ctf_func_type_info): Set the error on the right dict. (ctf_type_encoding): Use the original dict. * testsuite/libctf-writable/error-propagation.*: New test.
2023-04-08libctf, tests: do not assume host and target have identical field offsetsNick Alcock4-3/+24
The newly-introduced libctf-lookup unnamed-field-info test checks C compiler-observed field offsets against libctf-computed ones by #including the testcase in the lookup runner as well as generating CTF for it. This only works if the host, on which the lookup runner is compiled and executed, is the same architecture as the target, for which the CTF is generated: when crossing, the trick may fail. So pass down an indication of whether this is a cross into the testsuite, and add a new no_cross flag to .lk files that is used to suppress test execution when a cross-compiler is being tested. libctf/ * Makefile.am (check_DEJAGNU): Pass down TEST_CROSS. * Makefile.in: Regenerated. * testsuite/lib/ctf-lib.exp (run_lookup_test): Use it to implement the new no_cross option. * testsuite/libctf-lookup/unnamed-field-info.lk: Mark as no_cross.
2023-03-24libctf: get the offsets of fields of unnamed structs/unions rightNick Alcock4-1/+121
We were failing to add the offsets of the containing struct/union in this case, leading to all offsets being relative to the unnamed struct/union itself. libctf/ PR libctf/30264 * ctf-types.c (ctf_member_info): Add the offset of the unnamed member of the current struct as necessary. * testsuite/libctf-lookup/unnamed-field-info*: New test.
2023-03-24libctf: fix a comment typoNick Alcock1-1/+1
ctf_dedup's intern() function does not return a dynamically allocated string, so I just spent ten minutes auditing for obvious memory leaks that couldn't actually happen. Update the comment to note what it actually returns (a pointer into an atoms table: i.e. possibly not a new string, and not so easily leakable). libctf/ * ctf-dedup.c (intern): Update comment.
2023-03-24libctf: work around an uninitialized variable warningNick Alcock1-1/+1
GCC 11+ complains that sym is uninitialized in ctf_symbol_next. It isn't, but it's not quite smart enough to figure that out (it requires domain-specific knowledge of the state of the ctf_next_t iterator over multiple calls). libctf/ * ctf-lookup.c (ctf_symbol_next): Initialize sym to a suitable value for returning if never reset during the function.
2023-03-24libctf: fix assertion failure with no system qsort_rNick Alcock1-0/+4
If no suitable qsort_r is found in libc, we fall back to an implementation in ctf-qsort.c. But this implementation routinely calls the comparison function with two identical arguments. The comparison function that ensures that the order of output types is stable is not ready for this, misinterprets it as a type appearing more that once (a can-never-happen condition) and fails with an assertion failure. Fixed, audited for further instances of the same failure (none found) and added a no-qsort test to my regular testsuite run. libctf/: PR libctf/30013 * ctf-dedup.c (sort_output_mapping): Inputs are always equal to themselves.
2023-03-20libctf: unused variableAlan Modra1-2/+0
* ctf-archive.c (arc_mmap_writeout): Delete unused variable.
2023-03-19ctf segfaultsAlan Modra2-5/+8
PR 30228 PR 30229 * ctf-open.c (ctf_bufopen_internal): Check for NULL cts_data. * ctf-archive.c (ctf_arc_bufpreamble, ctf_arc_bufopen): Likewise.
2023-01-16libctf: update regexp to allow makeinfo to build documentEnze Li2-2/+2
While trying to build gdb on latest openSUSE Tumbleweed, I noticed the following warning, checking for makeinfo... makeinfo --split-size=5000000 configure: WARNING: *** Makeinfo is too old. Info documentation will not be built. then I checked the version of makeinfo, it said, ====== $ makeinfo --version texi2any (GNU texinfo) 7.0.1 Copyright (C) 2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. ====== After digging a little bit, it became quite obvious that a dot is missing in regexp that makes it impossible to match versions higher than 7.0, and here's the solution: - | egrep 'texinfo[^0-9]*(6\.[3-9]|[7-9][0-9])' >/dev/null 2>&1; then + | egrep 'texinfo[^0-9]*(6\.[3-9]|[7-9]\.[0-9])' >/dev/null 2>&1; then However, Eli pointed out that the solution above has another problem: it will stop working when Texinfo 10.1 will be released. Meanwhile, he suggested to solve this problem permanently. That is, we don't care about the minor version for Texinfo > 6.9, we only care about the major version. In this way, the problem will be resolved permanently, thanks to Eli. libctf/ChangeLog: * configure: Regenerated. * configure.ac: Update regexp to match versions higher than 7.0.
2023-01-12libctf: ctf-link outdated input check faultyNick Alcock1-6/+29
This check has a pair of faults which, combined, can lead to memory corruption. Firstly, it assumes that the values of the ctf_link_inputs hash are ctf_dict_t's: they are not, they are ctf_link_input_t's, a much shorter structure. So the flags check which is the core of this is faulty (but happens, by chance, to give the right output on most architectures, since usually we happen to get a 0 here, so the test that checks this usually passes). Worse, the warning that is emitted when the test fails is added to the wrong dict -- it's added to the input dict, whose warning list is never consumed, rendering the whole check useless. But the dict it adds to is still the wrong type, so we end up overwriting something deep in memory (or, much more likely, dereferencing a garbage pointer and crashing). Fixing both reveals another problem: the link input is an *archive* consisting of multiple members, so we have to consider whether to check all of them for the outdated-func-info thing we are checking here. However, no compiler exists that emits a mixture of members with this flag on and members with it off, and the linker always reserializes (and upgrades) such things when it sees them: so all members in a given archive must have the same value of the flag, so we only need to check one member per input archive. libctf/ PR libctf/29983 * ctf-link.c (ctf_link_warn_outdated_inputs): Get the types of members of ctf_link_inputs right, fixing a possible spurious tesst failure / wild pointer deref / overwrite. Emit the warning message into the right dict.
2023-01-12libctf: skip the testsuite from inside dejagnuNick Alcock5-70/+61
The libctf testsuite uses Tcl try/catch to trap run_output errors. This is only supported in reasonably recent Tcls, so we detect the lack of try/catch and suppress the testsuite via an Automake conditional in its absence. But this turns out not to work: Automake produces a check-DEJAGNU target regardless of the value of this conditional and sticks it in an unconditionally-executed part of the makefile, so the testsuite gets executed anyway, and fails with a nasty-looking syntax error. We can't disable it by taking "dejagnu" out of AUTOMAKE_OPTIONS, because if you do that Automake stops you using RUNTEST, RUNTESTFLAGS and other variables users would expect to work. So move to disabling the testsuite from inside the testsuite itself, importing the value of the former Automake conditional as a Tcl variable and exiting very early in default.exp if it's false. * configure.ac (TCL_TRY): No longer an Automake conditional. Rename to... (HAVE_TCL_TRY): ... this. * Makefile.am: Drop TCL_TRY. (development.exp): Set have_tcl_try. * testsuite/config/default.exp: Exit if have_tcl_try is false. * configure: Regenerated. * Makefile.in: Likewise.
2023-01-01Update year range in copyright notice of binutils filesAlan Modra40-41/+41
The newer update-copyright.py fixes file encoding too, removing cr/lf on binutils/bfdtest2.c and ld/testsuite/ld-cygwin/exe-export.exp, and embedded cr in binutils/testsuite/binutils-all/ar.exp string match.
2022-12-31Add markers for 2.40 branchNick Clifton1-0/+4
2022-12-12libctf: remove unnecessary zstd constructsIndu Bhagat5-280/+6
This patch is essentially a revert of commit-id: 8818c80cbd4116ef5af171ec47c61167179e225c (libctf: Add ZSTD_LIBS to LIBS so that ac_cv_libctf_bfd_elf can be true) As the specific configure check now uses libtool, this explicit mention of the dependency $ZSTD_LIBS is not needed anymore. ChangeLog: * libctf/Makefile.in: Regenerated. * libctf/aclocal.m4: Likewise. * libctf/config.h.in: Likewise. * libctf/configure: Likewise. * libctf/configure.ac: Remove ZSTD_LIBS from LIBS. Cleanup unused AC_ZSTD.
2022-12-12libctf: remove AC_CONFIG_MACRO_DIRIndu Bhagat2-8/+2
ACLOCAL_AMFLAGS is being set already. So using AC_CONFIG_MACRO_DIR is unnecessary. ChangeLog: * libctf/configure: Regenerated. * libctf/configure.ac: remove AC_CONFIG_MACRO_DIR usage.
2022-12-12libctf: remove unnecessary zlib constructsIndu Bhagat2-6/+4
This dependency is managed via libtool. So explicit addition to LDFLAGS and LIBS is not necessary anymore. ChangeLog: * libctf/configure: Regenerated. * libctf/configure.ac: remove zlib from LDFLAGS and LIBS.
2022-12-08libctf: avoid potential double freeAlan Modra1-1/+4
* ctf-link.c (ctf_link_add_cu_mapping): Set t NULL after free.
2022-11-11libctf: use libtool for link test in configureIndu Bhagat2-0/+1368
The configure check for ELF support in BFD uses the AC_TRY_LINK. If libbfd's dependencies change, this macro will need to be updated manually with explicit additions to LDFLAGS and LIBS. This patch updates the check to use libtool instead. ChangeLog: * libctf/configure.ac: Use libtool instead. * libctf/configure: Regenerated.
2022-11-07configure: require libzstd >= 1.4.0Christophe Lyon1-10/+10
gas uses ZSTD_compressStream2 which is only available with libzstd >= 1.4.0, leading to build errors when an older version is installed. This patch updates the check libzstd presence to check its version is >= 1.4.0. However, since gas seems to be the only component requiring such a recent version this may imply that we disable ZSTD support for all components although some would still benefit from an older version. I ran 'autoreconf -f' in all directories containing a configure.ac file, using vanilla autoconf-2.69 and automake-1.15.1. I noticed several errors from autoheader in readline, as well as warnings in intl, but they are unrelated to this patch. This should fix some of the buildbots. OK for trunk? Thanks, Christophe
2022-09-26libctf: Add ZSTD_LIBS to LIBS so that ac_cv_libctf_bfd_elf can be trueFangrui Song5-6/+280
2022-08-01libctf: Avoid use of uninitialised variablesAlan Modra1-6/+10
* ctf-link.c (ctf_link_add_ctf_internal): Don't free uninitialised pointers.
2022-07-08Add markers for 2.39 branchNick Clifton1-0/+4
2022-06-21libctf: tests: prune warnings from compiler outputNick Alcock2-6/+6
We were failing to call prune_warnings appropriately, leading to false-positive test failures on some platforms (observed on sparclinux). libctf/ChangeLog: * testsuite/lib/ctf-lib.exp: Prune warnings from compiler and linker output. * testsuite/libctf-regression/libctf-repeat-cu.exp: Likewise, and ar output too.
2022-06-21libctf: avoid mingw warningNick Alcock1-1/+1
A missing paren led to an intended cast to avoid dependence on the size of size_t in one argument of ctf_err_warn applying to the wrong type by mistake. libctf/ChangeLog: * ctf-serialize.c (ctf_write_mem): Fix cast.
2022-06-21libctf: fix linking together multiple objects derived from the same sourceNick Alcock8-33/+280
Right now, if you compile the same .c input repeatedly with CTF enabled and different compilation flags, then arrange to link all of these together, then things misbehave in various ways. libctf may conflate either inputs (if the .o files have the same name, say if they are stored in different .a archives), or per-CU outputs when conflicting types are found: the latter can lead to entirely spurious errors when it tries to produce multiple per-CU outputs with the same name (discarding all but the last, but then looking for types in the earlier ones which have just been thrown away). Fixing this is multi-pronged. Both inputs and outputs need to be differentiated in the hashtables libctf keeps them in: inputs with the same cuname and filename need to be considered distinct as long as they have different associated CTF dicts, and per-CU outputs need to be considered distinct as long as they have different associated input dicts. Right now there is nothing tying the two together other than the CU name: fix this by introducing a new field in the ctf_dict_t named ctf_link_in_out, which (for input dicts) points to the associated per-CU output dict (if any), and for output dicts points to the associated input dict. At creation time the name used is completely arbitrary: it's only important that it be distinct if CTF dicts are distinct. So, when a clash is found, adjust the CU name by sticking the number of elements in the input on the end. At output time, the CU name will appear in the linked object, so it matters a little more that it look slightly less ugly: in conflicting cases, append an incrementing integer, starting at 0. This naming scheme is not very helpful, but it's hard to see what else we can do. The input .o name may be the same. The input .a name is not even visible to ctf_link, and even *that* might be the same, because .a's can contain many members with the same name, all of which participate in the link. All we really know is that the two have distinct dictionaries with distinct types in them, and at least this way they are all represented, any any symbols, variables etc referring to those types are accurately stored. (As a side-effect this also fixes a use-after-free and double-free when errors are found during variable or symbol emission.) Use the opportunity to prevent a couple of sources of problems, to wit changing the active CU mappings when a link has already been done (no effect on ld, which doesn't use CU mappings at all), and causing multiple consecutive ctf_link's to have the same net effect as just doing the last one (no effect on ld, which only ever does one ctf_link) rather than having the links be a sort of half-incremental not-really-intended mess. libctf/ChangeLog: PR libctf/29242 * ctf-impl.h (struct ctf_dict) [ctf_link_in_out]: New. * ctf-dedup.c (ctf_dedup_emit_type): Set it. * ctf-link.c (ctf_link_add_ctf_internal): Set the input CU name uniquely when clashes are found. (ctf_link_add): Document what repeated additions do. (ctf_new_per_cu_name): New, come up with a consistent name for a new per-CU dict. (ctf_link_deduplicating): Use it. (ctf_create_per_cu): Use it, and ctf_link_in_out, and set ctf_link_in_out properly. Don't overwrite per-CU dicts with per-CU dicts relating to different inputs. (ctf_link_add_cu_mapping): Prevent per-CU mappings being set up if we already have per-CU outputs. (ctf_link_one_variable): Adjust ctf_link_per_cu call. (ctf_link_deduplicating_one_symtypetab): Likewise. (ctf_link_empty_outputs): New, delete all the ctf_link_outputs and blank out ctf_link_in_out on the corresponding inputs. (ctf_link): Clarify the effect of multiple ctf_link calls. Empty ctf_link_outputs if it already exists rather than having the old output leak into the new link. Fix a variable name. * testsuite/config/default.exp (AR): Add. (OBJDUMP): Likewise. * testsuite/libctf-regression/libctf-repeat-cu.exp: New test. * testsuite/libctf-regression/libctf-repeat-cu*: Main program, library, and expected results for the test.
2022-04-28libctf: impose an ordering on conflicting typesNick Alcock1-1/+20
When two types conflict and they are not types which can have forwards (say, two arrays of different sizes with the same name in two different TUs) the CTF deduplicator uses a popularity contest to decide what to do: the type cited by the most other types ends up put into the shared dict, while the others are relegated to per-CU child dicts. This works well as long as one type *is* most popular -- but what if there is a tie? If several types have the same popularity count, we end up picking the first we run across and promoting it, and unfortunately since we are working over a dynhash in essentially arbitrary order, this means we promote a random one. So multiple runs of ld with the same inputs can produce different outputs! All the outputs are valid, but this is still undesirable. Adjust things to use the same strategy used to sort types on the output: when there is a tie, always put the type that appears in a CU that appeared earlier on the link line (and if there is somehow still a tie, which should be impossible, pick the type with the lowest type ID). Add a testcase -- and since this emerged when trying out extern arrays, check that those work as well (this requires a newer GCC, but since all GCCs that can emit CTF at all are unreleased this is probably OK as well). Fix up one testcase that has slight type ordering changes as a result of this change. libctf/ChangeLog: * ctf-dedup.c (ctf_dedup_detect_name_ambiguity): Use cd_output_first_gid to break ties. ld/ChangeLog: * testsuite/ld-ctf/array-conflicted-ordering.d: New test, using... * testsuite/ld-ctf/array-char-conflicting-1.c: ... this... * testsuite/ld-ctf/array-char-conflicting-2.c: ... and this. * testsuite/ld-ctf/array-extern.d: New test, using... * testsuite/ld-ctf/array-extern.c: ... this. * testsuite/ld-ctf/conflicting-typedefs.d: Adjust for ordering changes.
2022-03-25libtool.m4: fix the NM="/nm/over/here -B/option/with/path" caseNick Alcock1-7/+13
My previous nm patch handled all cases but one -- if the user set NM in the environment to a path which contained an option, libtool's nm detection tries to run nm against a copy of nm with the options in it: e.g. if NM was set to "nm --blargle", and nm was found in /usr/bin, the test would try to run "/usr/bin/nm --blargle /usr/bin/nm --blargle". This is unlikely to be desirable: in this case we should run "/usr/bin/nm --blargle /usr/bin/nm". Furthermore, as part of this nm has to detect when the passed-in $NM contains a path, and in that case avoid doing a path search itself. This too was thrown off if an option contained something that looked like a path, e.g. NM="nm -B../prev-gcc"; libtool then tries to run "nm -B../prev-gcc nm" which rarely works well (and indeed it looks to see whether that nm exists, finds it doesn't, and wrongly concludes that nm -p or whatever does not work). Fix all of these by clipping all options (defined as everything including and after the first " -") before deciding whether nm contains a path (but not using the clipped value for anything else), and then removing all options from the path-modified nm before looking to see whether that nm existed. NM=my-nm now does a path search and runs e.g. /usr/bin/my-nm -B /usr/bin/my-nm NM=/usr/bin/my-nm now avoids a path search and runs e.g. /usr/bin/my-nm -B /usr/bin/my-nm NM="my-nm -p../wombat" now does a path search and runs e.g. /usr/bin/my-nm -p../wombat -B /usr/bin/my-nm NM="../prev-binutils/new-nm -B../prev-gcc" now avoids a path search: ../prev-binutils/my-nm -B../prev-gcc -B ../prev-binutils/my-nm This seems to be all combinations, including those used by GCC bootstrap (which, before this commit, fails to bootstrap when configured --with-build-config=bootstrap-lto, because the lto plugin is now using --export-symbols-regex, which requires libtool to find a working nm, while also using -B../prev-gcc to point at the lto plugin associated with the GCC just built.) Regenerate all affected configure scripts. * libtool.m4 (LT_PATH_NM): Handle user-specified NM with options, including options containing paths.
2022-03-23libctf: add LIBCTF_WRITE_FOREIGN_ENDIAN debugging optionNick Alcock3-111/+144
libctf has always handled endianness differences by detecting foreign-endian CTF dicts on the input and endian-flipping them: dicts are always written in native endianness. This makes endian-awareness very low overhead, but it means that the foreign-endian code paths almost never get routinely tested, since "make check" usually reads in dicts ld has just written out: only a few corrupted-CTF tests are actually in fixed endianness, and even they only test the foreign- endian code paths when you run make check on a big-endian machine. (And the fix is surely not to add more .s-based tests like that, because they are a nightmare to maintain compared to the C-code-based ones.) To improve on this, add a new environment variable, LIBCTF_WRITE_FOREIGN_ENDIAN, which causes libctf to unconditionally endian-flip at ctf_write time, so the output is always in the wrong endianness. This then tests the foreign-endian read paths properly at open time. Make this easier by restructuring the writeout code in ctf-serialize.c, which duplicates the maybe-gzip-and-write-out code three times (once for ctf_write_mem, with thresholding, and once each for ctf_compress_write and ctf_write just so those can avoid thresholding and/or compression). Instead, have the latter two call the former with thresholds of 0 or (size_t) -1, respectively. The endian-flipping code itself gains a bit of complexity, because one single endian-flipper (flip_types) was assuming the input to be in foreign-endian form and assuming it could pull things out of the input once they had been flipped and make sense of them. At the cost of a few lines of duplicated initializations, teach it to read before flipping if we're flipping to foreign-endianness instead of away from it. libctf/ * ctf-impl.h (ctf_flip_header): No longer static. (ctf_flip): Likewise. * ctf-open.c (flip_header): Rename to... (ctf_flip_header): ... this, now it is not private to one file. (flip_ctf): Rename... (ctf_flip): ... this too. Add FOREIGN_ENDIAN arg. (flip_types): Likewise. Use it. (ctf_bufopen_internal): Adjust calls. * ctf-serialize.c (ctf_write_mem): Add flip_endian path via a newly-allocated bounce buffer. (ctf_compress_write): Move below ctf_write_mem and reimplement in terms of it. (ctf_write): Likewise. (ctf_gzwrite): Note that this obscure writeout function does not support endian-flipping.
2022-03-23libctf, ld: diagnose corrupted CTF header cth_strlenNick Alcock1-16/+29
The last section in a CTF dict is the string table, at an offset represented by the cth_stroff header field. Its length is recorded in the next field, cth_strlen, and the two added together are taken as the size of the CTF dict. Upon opening a dict, we check that none of the header offsets exceed this size, and we check when uncompressing a compressed dict that the result of the uncompression is the same length: but CTF dicts need not be compressed, and short ones are not. Uncompressed dicts just use the ctf_size without checking it. This field is thankfully almost unused: it is mostly used when reserializing a dict, which can't be done to dicts read off disk since they're read-only. However, when opening an uncompressed foreign-endian dict we have to copy it out of the mmaped region it is stored in so we can endian- swap it, and we use ctf_size when doing that. When the cth_strlen is corrupt, this can overrun. Fix this by checking the ctf_size in all uncompressed cases, just as we already do in the compressed case. Add a new test. This came to light because various corrupted-CTF raw-asm tests had an incorrect cth_strlen: fix all of them so they produce the expected error again. libctf/ PR libctf/28933 * ctf-open.c (ctf_bufopen_internal): Always check uncompressed CTF dict sizes against the section size in case the cth_strlen is corrupt. ld/ PR libctf/28933 * testsuite/ld-ctf/diag-strlen-invalid.*: New test, derived from diag-cttname-invalid.s. * testsuite/ld-ctf/diag-cttname-invalid.s: Fix incorrect cth_strlen. * testsuite/ld-ctf/diag-cttname-null.s: Likewise. * testsuite/ld-ctf/diag-cuname.s: Likewise. * testsuite/ld-ctf/diag-parlabel.s: Likewise. * testsuite/ld-ctf/diag-parname.s: Likewise.
2022-03-23include, libctf, ld: extend variable section to contain functions tooNick Alcock3-12/+57
The CTF variable section is an optional (usually-not-present) section in the CTF dict which contains name -> type mappings corresponding to data symbols that are present in the linker input but not in the output symbol table: the idea is that programs that use their own symbol- resolution mechanisms can use this section to look up the types of symbols they have found using their own mechanism. Because these removed symbols (mostly static variables, functions, etc) all have names that are unlikely to appear in the ELF symtab and because very few programs have their own symbol-resolution mechanisms, a special linker flag (--ctf-variables) is needed to emit this section. Historically, we emitted only removed data symbols into the variable section. This seemed to make sense at the time, but in hindsight it really doesn't: functions are symbols too, and a C program can look them up just like any other type. So extend the variable section so that it contains all static function symbols too (if it is emitted at all), with types of kind CTF_K_FUNCTION. This is a little fiddly. We relied on compiler assistance for data symbols: the compiler simply emits all data symbols twice, once into the symtypetab as an indexed symbol and once into the variable section. Rather than wait for a suitably adjusted compiler that does the same for function symbols, we can pluck unreported function symbols out of the symtab and add them to the variable section ourselves. While we're at it, we do the same with data symbols: this is redundant right now because the compiler does it, but it costs very little time and lets the compiler drop this kludge and save a little space in .o files. include/ * ctf.h: Mention the new things we can see in the variable section. ld/ * testsuite/ld-ctf/data-func-conflicted-vars.d: New test. libctf/ * ctf-link.c (ctf_link_deduplicating_variables): Duplicate symbols into the variable section too. * ctf-serialize.c (symtypetab_delete_nonstatic_vars): Rename to... (symtypetab_delete_nonstatics): ... this. Check the funchash when pruning redundant variables. (ctf_symtypetab_sect_sizes): Adjust accordingly. * NEWS: Describe this change.
2022-02-11libctf: delete unused libctf_TEXINFOSMike Frysinger2-2/+0
It's not clear what this was meant for, but it's not used by anything, and the info pages still generate fine without it.
2022-01-22Add markers for 2.38 branchNick Clifton1-0/+4
2022-01-02Update year range in copyright notice of binutils filesAlan Modra39-40/+40
The result of running etc/update-copyright.py --this-year, fixing all the files whose mode is changed by the script, plus a build with --enable-maintainer-mode --enable-cgen-maint=yes, then checking out */po/*.pot which we don't update frequently. The copy of cgen was with commit d1dd5fcc38ead reverted as that commit breaks building of bfp opcodes files.
2021-12-02libctf: workaround automake bug with conditional info pagesMike Frysinger3-20/+32
It looks like automake makes assumptions about its ability to build info pages based on the GNU standard behavior of shipping info pages with the distributions. So even though the info pages were conditionalized, and automake disabled some of the targets, it was still creeping in by way of unconditional INFO_DEPS settings. We can workaround this by adding a stub target for the info page when building info pages are disabled. This tricks automake into disabling its own extended generation target. I'll follow up with the automake folks to see what they think.
2021-12-02libctf: re-generate configureSimon Marchi1-2/+1
When configuring libctf, I get: config.status: error: cannot find input file: `doc/Makefile.in' This is because configure is out-of-date, re-generate it. Change-Id: Ie69acd33012211a4620661582c7d24ad6d2cd169
2021-12-01libctf: merge doc subdir up a levelMike Frysinger5-1014/+410
This avoids a recursive make into the doc subdir and speeds up the build slightly. It also allows for more parallelism.
2021-11-29libctf: enable silent build rulesMike Frysinger3-3/+43
Also add $(AM_V_xxx) to various manual rules in here.
2021-11-09doc/ctf-spec.texi: Remove "@validatemenus off"H.J. Lu1-1/+0
Remove @validatemenus from ctf-spec.texi, which has been removed from texinfo by commit a16dd1a9ece08568a1980b9a65a3a9090717997f Author: Gavin Smith <gavinsmith0123@gmail.com> Date: Mon Oct 12 16:32:37 2020 +0100 * doc/texinfo.texi (Writing a Menu, Customization Variables for @-Commands) (Command List), * doc/refcard/txirefcard.tex Remove @validatemenus. * tp/Texinfo/XS/Makefile.am (command_ids.h): Use gawk instead of awk. Avoid discouraged "$p" usage, using "$(p)" instead. * tp/Texinfo/XS/configure.ac: Check for gawk. commit 128acab3889b51809dc3bd3c6c74b61d13f7f5f4 Author: Gavin Smith <gavinsmith0123@gmail.com> Date: Thu Jan 3 14:51:53 2019 +0000 Update refcard. * doc/refcard/txirefcard.tex: @setfilename is no longer mandatory. Do not mention @validatemenus or explicitly giving @node pointers, as these are not very important features. PR libctf/28567 * doc/ctf-spec.texi: Remove "@validatemenus off".
2021-11-08libctf: add CTF format specificationNick Alcock8-40/+2857
It's been a long time since most of this was written: it's long past time to put it in the binutils source tree. It's believed correct and complete insofar as it goes: it documents format v3 (the current version) but not the libctf API or any earlier versions. (The earlier versions can be read by libctf but not generated by it, and you are highly unlikely ever to see an example of any of them.) libctf/ChangeLog 2021-11-08 Nick Alcock <nick.alcock@oracle.com> * doc/ctf-spec.texi: New file. * configure.ac (MAKEINFO): Add. (BUILD_INFO): Likewise. (AC_CONFIG_FILES) [doc/Makefile]: Add. * Makefile.am [BUILD_INFO] (SUBDIRS): Add doc/. * doc/Makefile.am: New file. * doc/Makefile.in: Likewise. * configure: Regenerated. * Makefile.in: Likewise.
2021-10-25libctf, ld: handle nonrepresentable types betterNick Alcock2-6/+17
ctf_type_visit (used, among other things, by the type dumping code) was aborting when it saw a nonrepresentable type anywhere: even a single structure member with a nonrepresentable type caused an abort with ECTF_NONREPRESENTABLE. This is not useful behaviour, given that the abort comes from a type-resolution we are only doing in order to determine whether the type is a structure or union. We know nonrepresentable types can't be either, so handle that case and pass the nonrepresentable type down. (The added test verifies that the dumper now handles this case and prints nonrepresentable structure members as it already does nonrepresentable top-level types, rather than skipping the whole structure -- or, without the previous commit, skipping the whole types section.) ld/ChangeLog 2021-10-25 Nick Alcock <nick.alcock@oracle.com> * testsuite/ld-ctf/nonrepresentable-member.*: New test. libctf/ChangeLog 2021-10-25 Nick Alcock <nick.alcock@oracle.com> * ctf-types.c (ctf_type_rvisit): Handle nonrepresentable types.
2021-10-25libctf: dump: do not stop dumping types on errorNick Alcock2-4/+14
If dumping of a single type fails, we obviously can't dump it; but just as obviously this doesn't make the other types in the types section invalid or undumpable. So we should not propagate errors seen when type-dumping, but rather ignore them and carry on, so we dump as many types as we can (leaving out the ones we can't grok). libctf/ChangeLog 2021-10-25 Nick Alcock <nick.alcock@oracle.com> * ctf-dump.c (ctf_dump_type): Do not abort on error.