summaryrefslogtreecommitdiff
path: root/include
Commit message (Collapse)AuthorAgeFilesLines
* PR29961, plugin-api.h: "Could not detect architecture endianess"Alan Modra2023-05-171-22/+23
| | | | | | | | | | | | Found when attempting to build binutils on sparc sunos-5.8 where sys/byteorder.h defines _BIG_ENDIAN but not any of the BYTE_ORDER variants. This patch adds the extra tests to cope with the old machine, and tidies the header a little. PR 29961 plugin-api.h: When handling non-gcc or gcc < 4.6.0 include necessary header files before testing macros. Make more use of #elif. Test _LITTLE_ENDIAN and _BIG_ENDIAN in final tests.
* gcc-4.5 build fixesAlan Modra2023-05-171-2/+0
| | | | | | | | | | | | | | | | | | | | Trying to build binutils with an older gcc currently fails. Working around these gcc bugs is not onerous so let's fix them. bfd/ * elf32-csky.c (csky_elf_size_dynamic_sections): Don't type-pun pointer. * elf32-rl78.c (rl78_compute_complex_reloc): Rename "stat" variable to "status". gas/ * compress-debug.c (compress_finish): Supply all fields in ZSTD_inBuffer initialisation. include/ * xtensa-dynconfig.h (xtensa_isa_internal): Delete unnecessary forward declaration. opcodes/ * loongarch-opc.c: Supply all fields of zero struct initialisation in various opcode tables.
* Add LDPT_REGISTER_CLAIM_FILE_HOOK_V2 linker plugin hook [GCC PR109128]Joseph Myers2023-05-111-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is one part of the fix for GCC PR109128, along with a corresponding GCC change. Without this patch, what happens in the linker, when an unused object in a .a file has offload data, is that elf_link_is_defined_archive_symbol calls bfd_link_plugin_object_p, which ends up calling the plugin's claim_file_handler, which then records the object as one with offload data. That is, the linker never decides to use the object in the first place, but use of this _p interface (called as part of trying to decide whether to use the object) results in the plugin deciding to use its offload data (and a consequent mismatch in the offload data present at runtime). The new hook allows the linker plugin to distinguish calls to claim_file_handler that know the object is being used by the linker (from ldmain.c:add_archive_element), from calls that don't know it's being used by the linker (from elf_link_is_defined_archive_symbol); in the latter case, the plugin should avoid recording the object as one with offload data. bfd/ * plugin.c (struct plugin_list_entry): Add claim_file_v2. (register_claim_file_v2): New. (try_load_plugin): Use LDPT_REGISTER_CLAIM_FILE_HOOK_V2. (ld_plugin_object_p): Take second argument. (bfd_link_plugin_object_p): Update call to ld_plugin_object_p. (register_ld_plugin_object_p): Update argument prototype. (bfd_plugin_object_p): Update call to ld_plugin_object_p. * plugin.h (register_ld_plugin_object_p): Update argument prototype. include/ * plugin.api.h (ld_plugin_claim_file_handler_v2) (ld_plugin_register_claim_file_v2) (LDPT_REGISTER_CLAIM_FILE_HOOK_V2): New. (struct ld_plugin_tv): Add tv_register_claim_file_v2. ld/ * plugin.c (struct plugin): Add claim_file_handler_v2. (LDPT_REGISTER_CLAIM_FILE_HOOK_V2): New. (plugin_object_p): Add second argument. Update call to plugin_call_claim_file. (register_claim_file_v2): New. (set_tv_header): Handle LDPT_REGISTER_CLAIM_FILE_HOOK_V2. (plugin_call_claim_file): Add argument known_used. (plugin_maybe_claim): Update call to plugin_object_p. * testplug.c, testplug2.c, testplug3.c, testplug4.c: Handle LDPT_REGISTER_CLAIM_FILE_HOOK_V2. * testsuite/ld-plugin/plugin-1.d, testsuite/ld-plugin/plugin-10.d, testsuite/ld-plugin/plugin-11.d, testsuite/ld-plugin/plugin-13.d, testsuite/ld-plugin/plugin-14.d, testsuite/ld-plugin/plugin-15.d, testsuite/ld-plugin/plugin-16.d, testsuite/ld-plugin/plugin-17.d, testsuite/ld-plugin/plugin-18.d, testsuite/ld-plugin/plugin-19.d, testsuite/ld-plugin/plugin-2.d, testsuite/ld-plugin/plugin-26.d, testsuite/ld-plugin/plugin-3.d, testsuite/ld-plugin/plugin-30.d, testsuite/ld-plugin/plugin-4.d, testsuite/ld-plugin/plugin-5.d, testsuite/ld-plugin/plugin-6.d, testsuite/ld-plugin/plugin-7.d, testsuite/ld-plugin/plugin-8.d, testsuite/ld-plugin/plugin-9.d: Update test expectations.
* Re: Keeping track of rs6000-coff archive element pointersAlan Modra2023-04-281-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | Commit de7b90610e9e left a hole in the element checking, explained by the comment added to _bfd_xcoff_openr_next_archived_file. While fixing this, tidy some types used to hold unsigned values so that casts are not needed to avoid signed/unsigned comparison warnings. Also tidy a few things in xcoff.h. bfd/ * coff-rs6000.c (_bfd_xcoff_openr_next_archived_file): Check that we aren't pointing back at the last element. Make filestart a ufile_ptr. Update for xcoff_artdata change. (_bfd_strntol, _bfd_strntoll): Return unsigned values. (_bfd_xcoff_slurp_armap): Make off a ufile_ptr. (add_ranges): Update for xcoff_artdata change. * libbfd-in.h (struct artdata): Make first_file_filepos a ufile_ptr. * libbfd.h: Regenerate. include/ * coff/xcoff.h (struct xcoff_artdata): Replace min_elt with ar_hdr_size. (xcoff_big_format_p): In the !SMALL_ARCHIVE case return true for anything but a small archive.
* RISC-V: Support XVentanaCondOps extensionPhilipp Tomsich2023-04-262-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ventana Micro has published the specification for their XVentanaCondOps ("conditional ops") extension at https://github.com/ventanamicro/ventana-custom-extensions/releases/download/v1.0.0/ventana-custom-extensions-v1.0.0.pdf which contains two new instructions - vt.maskc - vt.maskcn that can be used in constructing branchless sequences for various conditional-arithmetic, conditional-logical, and conditional-select operations. To support such vendor-defined instructions in the mainline binutils, this change also adds a riscv_supported_vendor_x_ext secondary dispatch table (but also keeps the behaviour of allowing any unknow X-extension to be specified in addition to the known ones from this table). As discussed, this change already includes the planned/agreed future requirements for X-extensions (which are likely to be captured in the riscv-toolchain-conventions repository): - a public specification document is available (see above) and is referenced from the gas-documentation - the naming follows chapter 27 of the RISC-V ISA specification - instructions are prefixed by a vendor-prefix (vt for Ventana) to ensure that they neither conflict with future standard extensions nor clash with other vendors bfd/ChangeLog: * elfxx-riscv.c (riscv_get_default_ext_version): Add riscv_supported_vendor_x_ext. (riscv_multi_subset_supports): Recognize INSN_CLASS_XVENTANACONDOPS. gas/ChangeLog: * doc/c-riscv.texi: Add section to list custom extensions and their documentation URLs. * testsuite/gas/riscv/x-ventana-condops.d: New test. * testsuite/gas/riscv/x-ventana-condops.s: New test. include/ChangeLog: * opcode/riscv-opc.h Add vt.maskc and vt.maskcn. * opcode/riscv.h (enum riscv_insn_class): Add INSN_CLASS_XVENTANACONDOPS. opcodes/ChangeLog: * riscv-opc.c: Add vt.maskc and vt.maskcn. Series-version: 1 Series-to: binutils@sourceware.org Series-cc: Kito Cheng <kito.cheng@sifive.com> Series-cc: Nelson Chu <nelson.chu@sifive.com> Series-cc: Greg Favor <gfavor@ventanamicro.com> Series-cc: Christoph Muellner <cmuellner@gcc.gnu.org>
* Keeping track of rs6000-coff archive element pointersAlan Modra2023-04-211-22/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | rs6000-coff archives use a linked list of file offsets, where each element points to the next element. The idea is to allow updating of large archives quickly without rewriting the whole archive. (binutils ar does not do this.) Unfortunately this is an easy target for fuzzers to create an archive that will cause ar or any other tool processing archives to hang. I'd implemented guards against pointing back to the previous element, but of course that didn't last long. So this patch implements a scheme to keep track of file offset ranges used by elements as _bfd_read_ar_hdr is called for each element. See the add_range function comment. I needed a place to stash the list, so chose the obvious artdata.tdata backend extension to archive's tdata, already used by xcoff. That involved a little cleanup, because while it would be possible to continue using different artdata.tdata for the big and small archives, it's nicer to use a union. If anyone is concerned this list of element ranges might grow large and thus significantly slow down the tools, adjacent ranges are merged. In fact something like "ar t" will only ever have one range on xcoff archives generated by binutils/ar. I agree there might still be a problem with ld random element access via the armap. include/ * coff/xcoff.h (SIZEOF_AR_FILE_HDR): Use sizeof. (SIZEOF_AR_FILE_HDR_BIG, SIZEOF_AR_HDR, SIZEOF_AR_HDR_BIG): Likewise. (struct ar_ranges, struct xcoff_artdata): New. (x_artdata): Define. (xcoff_big_format_p): Rewrite. (xcoff_ardata, xcoff_ardata_big): Delete. bfd/ * coff-rs6000.c: Replace uses of xcoff_ardata and xcoff_ardata_big throughout file. (_bfd_xcoff_archive_p): Adjust artdata.tdata allocation. (add_range): New function. (_bfd_xcoff_read_ar_hdr): Use it here. Fix memory leak. (_bfd_xcoff_openr_next_archived_file): Remove old sanity checks. Set up range for header. (xcoff_write_archive_contents_old): Make the temporary artdata.tdata used here to pass info down to _bfd_compute_and_write_armap a struct xcoff_artdata. (xcoff_write_archive_contents_big): Likewise. * coff64-rs6000.c: Replace uses of xcoff_ardata and xcoff_ardata_big throughout file. (xcoff64_archive_p): Adjust artdata.tdata allocation.
* sframe: correct some typosIndu Bhagat2023-04-191-2/+2
| | | | | | | | include/ * sframe.h: Correct a typo. libsframe/ * sframe.c: Likewise.
* aarch64: Remove stray reglist variableRichard Sandiford2023-03-301-1/+1
| | | | | Sorry for not catching this during testing. I was using a host compiler that predated the switch to -fno-common.
* aarch64: Add the RPRFM instructionRichard Sandiford2023-03-301-0/+2
| | | | | | | | | | This patch adds the RPRFM (range prefetch) instruction. It was introduced as part of SME2, but it belongs to the prefetch hint space and so doesn't require any specific ISA flags. The aarch64_rprfmop_array initialiser (deliberately) only fills in the leading non-null elements.
* aarch64: Add new SVE dot-product instructionsRichard Sandiford2023-03-301-1/+2
| | | | | | | This patch adds the SVE FDOT, SDOT and UDOT instructions, which are available when FEAT_SME2 is implemented. The patch also reorders the existing SVE_Zm3_22_INDEX to keep the operands numerically sorted.
* aarch64: Add the SME2 shift instructionsRichard Sandiford2023-03-301-0/+3
| | | | | | | | | | | | | | | There are two instruction formats here: - SQRSHR, SQRSHRU and UQRSHR, which operate on lists of two or four registers. - SQRSHRN, SQRSHRUN and UQRSHRN, which operate on lists of four registers. These are the first SME2 instructions to have immediate operands. The patch makes sure that, when parsing SME2 instructions with immediate operands, the new predicate-as-counter registers are parsed as registers rather than as #-less immediates.
* aarch64: Add the SME2 saturating conversion instructionsRichard Sandiford2023-03-301-0/+1
| | | | | | | | | | There are two instruction formats here: - SQCVT, SQCVTU and UQCVT, which operate on lists of two or four registers. - SQCVTN, SQCVTUN and UQCVTN, which operate on lists of four registers.
* aarch64: Add the SME2 MLALL and MLSLL instructionsRichard Sandiford2023-03-301-0/+5
| | | | | | | SMLALL, SMLSLL, UMLALL and UMLSLL have the same format. USMLALL and SUMLALL allow the same operand types as those instructions, except that SUMLALL does not have the multi-vector x multi-vector forms (which would be redundant with USMLALL).
* aarch64: Add the SME2 MLAL and MLSL instructionsRichard Sandiford2023-03-301-0/+4
| | | | | | | The {BF,F,S,U}MLAL and {BF,F,S,U}MLSL instructions share the same encoding. They are the first instance of a ZA (as opposed to ZA tile) operand having a range of offsets. As with ZA tiles, the expected range size is encoded in the operand-specific data field.
* aarch64: Add the SME2 FMLA and FMLS instructionsRichard Sandiford2023-03-301-0/+2
|
* aarch64: Add the SME2 maximum/minimum instructionsRichard Sandiford2023-03-301-0/+1
| | | | | | This patch adds the SME2 multi-register forms of F{MAX,MIN}{,NM} and {S,U}{MAX,MIN}. SQDMULH, SRSHL and URSHL have the same form as SMAX etc., so the patch adds them too.
* aarch64: Add the SME2 ADD and SUB instructionsRichard Sandiford2023-03-301-0/+3
| | | | | | | | | | | | | | | | | | | | | | Add support for the SME2 ADD. SUB, FADD and FSUB instructions. SUB and FSUB have the same form as ADD and FADD, except that ADD also has a 2-operand accumulating form. The 64-bit ADD/SUB instructions require FEAT_SME_I16I64 and the 64-bit FADD/FSUB instructions require FEAT_SME_F64F64. These are the first instructions to have tied register list operands, as opposed to tied single registers. The parse_operands change prevents unsuffixed Z registers (width==-1) from being treated as though they had an Advanced SIMD-style suffix (.4s etc.). It means that: Error: expected element type rather than vector type at operand 2 -- `add za\.s\[w8,0\],{z0-z1}' becomes: Error: missing type suffix at operand 2 -- `add za\.s\[w8,0\],{z0-z1}'
* aarch64: Add the SME2 ZT0 instructionsRichard Sandiford2023-03-301-0/+11
| | | | | | | | SME2 adds lookup table instructions for quantisation. They use a new lookup table register called ZT0. LUTI2 takes an unsuffixed SVE vector index of the form Zn[<imm>], which is the first time that this syntax has been used.
* aarch64: Add the SME2 predicate-related instructionsRichard Sandiford2023-03-301-0/+11
| | | | | | | | | | | | | | | | | Implementation-wise, the main things to note here are: - the WHILE* instructions have forms that return a pair of predicate registers. This is the first time that we've had lists of predicate registers, and they wrap around after register 15 rather than after register 31. - the predicate-as-counter WHILE* instructions have a fourth operand that specifies the vector length. We can treat this as an enumeration, except that immediate values aren't allowed. - PEXT takes an unsuffixed predicate index of the form PN<n>[<imm>]. This is the first instance of a vector/predicate index having no suffix.
* aarch64: Add the SME2 multivector LD1 and ST1 instructionsRichard Sandiford2023-03-301-0/+3
| | | | | | | | | | | | | | | SME2 adds LD1 and ST1 variants for lists of 2 and 4 registers. The registers can be consecutive or strided. In the strided case, 2-register lists have a stride of 8, starting at register x0xxx. 4-register lists have a stride of 4, starting at register x00xx. The instructions are predicated on a predicate-as-counter register in the range pn8-pn15. Although we already had register fields with upper bounds of 7 and 15, this is the first plain register operand to have a nonzero lower bound. The patch uses the operand-specific data field to record the minimum value, rather than having separate inserters and extractors for each lower bound. This in turn required adding an extra bit to the field.
* aarch64: Add the SME2 MOVA instructionsRichard Sandiford2023-03-301-0/+10
| | | | | | | | | | | | | | SME2 defines new MOVA instructions for moving multiple registers to and from ZA. As with SME, the instructions are also available through MOV aliases. One notable feature of these instructions (and many other SME2 instructions) is that some register lists must start at a multiple of the list's size. The patch uses the general error "start register out of range" when this constraint isn't met, rather than an error specifically about multiples. This ensures that the error is consistent between these simple consecutive lists and later strided lists, for which the requirements aren't a simple multiple.
* aarch64: Add support for predicate-as-counter registersRichard Sandiford2023-03-301-0/+5
| | | | | | | | | | | | SME2 adds a new format for the existing SVE predicate registers: predicates as counters rather than predicates as masks. In assembly code, operands that interpret predicates as counters are written pn<N> rather than p<N>. This patch adds support for these registers and extends some existing instructions to support them. Since the new forms are just a programmer convenience, there's no need to make them more restrictive than the earlier predicate-as-mask forms.
* aarch64; Add support for vector offset rangesRichard Sandiford2023-03-301-4/+19
| | | | | | | | | | | Some SME2 instructions operate on a range of consecutive ZA vectors. This is indicated by syntax such as: za[<Wv>, <imml>:<immh>] Like with the earlier vgx2 and vgx4 support, we get better error messages if the parser allows all ZA indices to have a range. We can then reject invalid cases during constraint checking.
* aarch64: Add support for vgx2 and vgx4Richard Sandiford2023-03-301-0/+13
| | | | | | | | | | | | | | | | | | | | | | | Many SME2 instructions operate on groups of 2 or 4 ZA vectors. This is indicated by adding a "vgx2" or "vgx4" group size to the ZA index. The group size is optional in assembly but preferred for disassembly. There is not a binary distinction between mnemonics that have group sizes and mnemonics that don't, nor between mnemonics that take vgx2 and mnemonics that take vgx4. We therefore get better error messages if we allow any ZA index to have a group size during parsing, and wait until constraint checking to reject invalid sizes. A quirk of the way errors are reported means that if an instruction is wrong both in its qualifiers and its use of a group size, we'll print suggested alternative instructions that also have an incorrect group size. But that's a general property that also applies to things like out-of-range immediates. It's also not obviously the wrong thing to do. We need to be relatively confident that we're looking at the right opcode before reporting detailed operand-specific errors, so doing qualifier checking first seems resonable.
* aarch64: Add _off4 suffix to AARCH64_OPND_SME_ZA_arrayRichard Sandiford2023-03-301-3/+3
| | | | | | | SME2 adds various new fields that are similar to AARCH64_OPND_SME_ZA_array, but are distinguished by the size of their offset fields. This patch adds _off4 to the name of the field that we already have.
* aarch64: Add +sme2Richard Sandiford2023-03-301-0/+1
| | | | | This patch adds bare-bones support for +sme2. Later patches fill in the rest.
* aarch64: Add support for strided register listsRichard Sandiford2023-03-301-12/+26
| | | | | | | | | | | | | | | | | SME2 has instructions that accept strided register lists, such as { z0.s, z4.s, z8.s, z12.s }. The purpose of this patch is to extend binutils to support such lists. The parsing code already had (unused) support for strides of 2. The idea here is instead to accept all strides during parsing and reject invalid strides during constraint checking. The SME2 instructions that accept strided operands also have non-strided forms. The errors about invalid strides therefore take a bitmask of acceptable strides, which allows multiple possibilities to be summed up in a single message. I've tried to update all code that handles register lists.
* aarch64: Add a aarch64_cpu_supports_inst_p helperRichard Sandiford2023-03-301-0/+3
| | | | | | | | | | | | | | Quite a lot of SME2 instructions have an opcode bit that selects between 32-bit and 64-bit forms of an instruction, with the 32-bit forms being part of base SME2 and with the 64-bit forms being part of an optional extension. It's nevertheless useful to have a single opcode entry for both forms since (a) that matches the ISA definition and (b) it tends to improve error reporting. This patch therefore adds a libopcodes function called aarch64_cpu_supports_inst_p that tests whether the target supports a particular instruction. In future it will depend on internal libopcodes routines.
* aarch64: Add an operand class for SVE register listsRichard Sandiford2023-03-301-0/+1
| | | | | | | | | | | | SVE register lists were classified as SVE_REG, since there had been no particular reason to separate them out. However, some SME2 instructions have tied register list operands, and so we need to distinguish registers and register lists when checking whether two operands match. Also, the register list operands used a general error message, even though we already have a dedicated error code for register lists that are the wrong length.
* aarch64: Add an error code for out-of-range registersRichard Sandiford2023-03-301-1/+9
| | | | | | | | libopcodes currently reports out-of-range registers as a general AARCH64_OPDE_OTHER_ERROR. However, this means that each register range needs its own hard-coded string, which is a bit cumbersome if the range is determined programmatically. This patch therefore adds a dedicated error type for out-of-range errors.
* aarch64: Deprioritise AARCH64_OPDE_REG_LISTRichard Sandiford2023-03-301-5/+9
| | | | | | | | | | | | | | | | | | SME2 has many instructions that take a list of SVE registers. There are often multiple forms, with different forms taking different numbers of registers. This means that if, after a successful parse and qualifier match, we find that the number of registers does not match the opcode entry, the associated error should have a lower priority/severity than other errors reported at the same stage. For example, if there are 2-register and 4-register forms of an instruction, and if the assembly code uses the 2-register form with an out-of-range value, the out-of-range value error against the 2-register instruction should have a higher priority than the "wrong number of registers" error against the 4-register instruction. This is tested by the main SME2 patches, but seemed worth splitting out.
* aarch64: Update operand_mismatch_kind_namesRichard Sandiford2023-03-301-1/+4
| | | | | The contents of operand_mismatch_kind_names were out of sync with the enum.
* aarch64: Move ZA range checks to aarch64-opc.cRichard Sandiford2023-03-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | This patch moves the range checks on ZA vector select offsets from gas to libopcodes. Doing the checks there means that the error messages contain the expected range. It also fits in better with the error severity scheme, which becomes important later. (This is because out-of-range indices are treated as more severe than syntax errors, on the basis that parsing must have succeeded if we get to the point of checking the completed opcode.) The patch also adds a new check_za_access function for checking ZA accesses. That's a bit over the top for one offset check, but the function becomes more complex with later patches. sme-9-illegal.s checked for an invalid .q suffix using: psel p1, p15, p3.q[w15] but this is doubly invalid because it misses the immediate part of the index. The patch keeps that test but adds another with a zero index, so that .q is the only thing wrong. The aarch64-tbl.h change includes neatening up the backslash positions.
* aarch64: Make indexed_za use 64-bit immediatesRichard Sandiford2023-03-301-1/+1
| | | | | | | | | A later patch moves the range checking for ZA vector select offsets from gas to libopcodes. That in turn requires the immediate field to be big enough to support all parsed values. This shouldn't be a particularly size-sensitive structure, so there should be no memory problems with doing this.
* aarch64: Rename za_tile_vector to za_indexRichard Sandiford2023-03-301-10/+13
| | | | | | | | | za_tile_vector is also used for indexing ZA as a whole, rather than just for indexing tiles. The former is more common than the latter in SME2, so this patch generalises the name to "indexed_za". The patch also names the associated structure, so that later patches can reuse it during parsing.
* aarch64: Make SME instructions use F_STRICTRichard Sandiford2023-03-301-0/+2
| | | | | | | | | | This patch makes all SME instructions use F_STRICT, so that qualifiers have to be provided explicitly rather than being inferred from other operands. The main change is to move the qualifier setting from the operand-level decoders to the opcode level. This is one step towards consolidating the ZA parsing code and extending it to handle SME2.
* aarch64: Add sme-i16i64 and sme-f64f64 aliasesRichard Sandiford2023-03-301-2/+2
| | | | | | | Most extension flags are named after the associated architectural FEAT_* flags, but sme-i64 and sme-f64 were exceptions. This patch adds sme-i16i64 and sme-f64f64 aliases, but keeps the old names too for compatibility.
* Use stdint types in coff internal_auxentAlan Modra2023-03-271-40/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | long is a poor choice of type to store 32-bit values read from objects files by H_GET_32. H_GET_32 doesn't sign extend so tests like that in gdb/coffread.c for "negative" values won't work if long is larger than 32 bits. If long is 32-bit then code needs to be careful to not accidentally index negative array elements. (I'd rather see a segfault on an unmapped 4G array index than silently reading bogus data.) long is also a poor choice for x_sect.s_scnlen, which might have 64-bit values. It's better to use unsigned exact width types to avoid surprises. I decided to change the field names too, which makes most of this patch simply renaming. Besides that there are a few places where casts are no longer needed, and where printf format strings or tests need adjusting. include/ * coff/internal.h (union internal_auxent): Use unsigned stdint types. Rename l fields to u32 and u64 as appropriate. bfd/ * coff-bfd.c, * coff-rs6000.c, * coff64-rs6000.c, * coffcode.h, * coffgen.c, * cofflink.c, * coffswap.h, * peXXigen.c, * xcofflink.c: Adjust to suit internal_auxent changes. binutils/ * rdcoff.c: Adjust to suit internal_auxent changes. gas/ * config/obj-coff.h, * config/tc-ppc.c: Adjust to suit internal_auxent changes. gdb/ * coffread.c, * xcoffread.c: Adjust to suit internal_auxent changes. ld/ * pe-dll.c: Adjust to suit internal_auxent changes.
* Add support to readelf for the PT_OPENBSD_MUTABLE segment type.Frederic Cambus2023-03-232-0/+5
| | | | | binutils * readelf.c (get_segment_type): Handle PT_OPENBSD_MUTABLE segment type. include * elf/common.h (PT_OPENBSD_MUTABLE): Define.
* readelf: add support for QNT_STACK note subsectionsClément Chigot2023-03-161-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QNX provides some .note subsections. QNT_STACK is the one controling the stack allocation. bfd/ChangeLog: * elf.c (BFD_QNT_CORE_INFO): Delete. (BFD_QNT_CORE_STATUS): Likewise. (BFD_QNT_CORE_GREG): Likewise. (BFD_QNT_CORE_FPREG): Likewise. (elfcore_grok_nto_note): Replace BFD_QNT_* by QNT_*. binutils/ChangeLog: * readelf.c (get_qnx_elfcore_note_type): New function. (print_qnx_note): New function. (process_note): Add support for QNX support. include/ChangeLog: * elf/common.h (QNT_DEBUG_FULLPATH): New define. (QNT_DEBUG_RELOC): New define. (QNT_STACK): New define. (QNT_GENERATOR): New define. (QNT_DEFAULT_LIB): New define. (QNT_CORE_SYSINFO): New define. (QNT_CORE_INFO): New define. (QNT_CORE_STATUS): New define. (QNT_CORE_GREG): New define. (QNT_CORE_FPREG): New define. (QNT_LINK_MAP): New define.
* BPF relocations review / refactoringCupertino Miranda2023-03-161-14/+8
| | | | | | | | | | | | | | | | | | | | | - Removed not needed relocations. - Renamed relocations to match llvm and linux kernel. Relocation changes: R_BPF_INSN_64 => R_BPF_64_64 R_BPF_INSN_DISP32 => R_BPF_64_32 R_BPF_DATA_32 => R_BPF_64_ABS32 R_BPF_DATA_64 => R_BPF_64_ABS64 ChangeLog: * bfd/bpf-reloc.def: Created file with BPF_HOWTO macro entries. * bfd/reloc.c: Removed non needed relocations. * bfd/bfd-in2.h: regenerated. * bfd/libbfd.h: regenerated. * bfd/elf64-bpf.c: Changed relocations. * include/elf/bpf.h: Adapted relocation values/names. * gas/config/tc-bpf.c: Changed relocation mapping.
* gdbsupport: ignore -Wenum-constexpr-conversion in enum-flags.hSimon Marchi2023-03-061-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When building with clang 16, we get: CXX gdb.o In file included from /home/smarchi/src/binutils-gdb/gdb/gdb.c:19: In file included from /home/smarchi/src/binutils-gdb/gdb/defs.h:65: /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/enum-flags.h:95:52: error: integer value -1 is outside the valid range of values [0, 15] for this enumeration type [-Wenum-constexpr-conversion] integer_for_size<sizeof (T), static_cast<bool>(T (-1) < T (0))>::type ^ The error message does not make it clear in the context of which enum flag this fails (i.e. what is T in this context), but it doesn't really matter, we have similar warning/errors for many of them, if we let the build go through. clang is right that the value -1 is invalid for the enum type we cast -1 to. However, we do need this expression in order to select an integer type with the appropriate signedness. That is, with the same signedness as the underlying type of the enum. I first wondered if that was really needed, if we couldn't use std::underlying_type for that. It turns out that the comment just above says: /* Note that std::underlying_type<enum_type> is not what we want here, since that returns unsigned int even when the enum decays to signed int. */ I was surprised, because std::is_signed<std::underlying_type<enum_type>> returns the right thing. So I tried replacing all this with std::underlying_type, see if that would work. Doing so causes some build failures in unittests/enum-flags-selftests.c: CXX unittests/enum-flags-selftests.o /home/smarchi/src/binutils-gdb/gdb/unittests/enum-flags-selftests.c:254:1: error: static assertion failed due to requirement 'gdb::is_same<selftests::enum_flags_tests::check_valid_expr254::archetype<enum_flags<s elftests::enum_flags_tests::RE>, selftests::enum_flags_tests::RE, enum_flags<selftests::enum_flags_tests::RE2>, selftests::enum_flags_tests::RE2, enum_flags<selftests::enum_flags_tests::URE>, selftests::enum_fla gs_tests::URE, int>, selftests::enum_flags_tests::check_valid_expr254::archetype<enum_flags<selftests::enum_flags_tests::RE>, selftests::enum_flags_tests::RE, enum_flags<selftests::enum_flags_tests::RE2>, selfte sts::enum_flags_tests::RE2, enum_flags<selftests::enum_flags_tests::URE>, selftests::enum_flags_tests::URE, unsigned int>>::value == true': CHECK_VALID (true, int, true ? EF () : EF2 ()) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/smarchi/src/binutils-gdb/gdb/unittests/enum-flags-selftests.c:91:3: note: expanded from macro 'CHECK_VALID' CHECK_VALID_EXPR_6 (EF, RE, EF2, RE2, UEF, URE, VALID, EXPR_TYPE, EXPR) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/valid-expr.h:105:3: note: expanded from macro 'CHECK_VALID_EXPR_6' CHECK_VALID_EXPR_INT (ESC_PARENS (typename T1, typename T2, \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/valid-expr.h:66:3: note: expanded from macro 'CHECK_VALID_EXPR_INT' static_assert (gdb::is_detected_exact<archetype<TYPES, EXPR_TYPE>, \ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This is a bit hard to decode, but basically enumerations have the following funny property that they decay into a signed int, even if their implicit underlying type is unsigned. This code: enum A {}; enum B {}; int main() { std::cout << std::is_signed<std::underlying_type<A>::type>::value << std::endl; std::cout << std::is_signed<std::underlying_type<B>::type>::value << std::endl; auto result = true ? A() : B(); std::cout << std::is_signed<decltype(result)>::value << std::endl; } produces: 0 0 1 So, the "CHECK_VALID" above checks that this property works for enum flags the same way as it would if you were using their underlying enum types. And somehow, changing integer_for_size to use std::underlying_type breaks that. Since the current code does what we want, and I don't see any way of doing it differently, ignore -Wenum-constexpr-conversion around it. Change-Id: Ibc82ae7bbdb812102ae3f1dd099fc859dc6f3cc2
* Delete PROGRESS macrosAlan Modra2023-02-161-38/+0
| | | | | | | | | | | | | | | | | | | | | I don't see much point in cluttering the source with the PROGRESS macros, which of course do nothing at all with the definitions in progress.h. progress.h is unchanged apart from the copyright comment since commit d4d4c53c68f0 in 1994. binutils/ * ar.c: Don't include progress.h, or invoke PROGRESS macros. * nm.c: Likewise. * objcopy.c: Likewise. * objdump.c: Likewise. gas/ * as.h: Don't include progress.h. * as.c: Don't invoke PROGRESS macros. * write.c: Likewise. include/ * progress.h: Delete. ld/ * ldmain.c: Don't include progress.h, or invoke PROGRESS macros.
* ppc32 and "LOAD segment with RWX permissions"Alan Modra2023-02-061-0/+3
| | | | | | | | | | | | | | | | | | | | | When using a bss-plt we'll always trigger the RWX warning, which disturbs gcc test results. On the other hand, there may be reason to want the warning when gcc is configured with --enable-secureplt. So turning off the warning entirely for powerpc might not be the best solution. Instead, we'll turn off the warning whenever a bss-plt is generated, unless the user explicitly asked for the warning. bfd/ * elf32-ppc.c (ppc_elf_select_plt_layout): Set no_warn_rwx_segments on generating a bss plt, unless explicity enabled by the user. Also show the bss-plt warning when --warn-rwx-segments is given without --bss-plt. include/ * bfdlink.h (struct bfd_link_info): Add user_warn_rwx_segments. ld/ * lexsup.c (parse_args): Set user_warn_rwx_segments. * testsuite/ld-elf/elf.exp: Pass --secure-plt for powerpc to the rwx tests.
* bpf: fix error conversion from long unsigned int to unsigned int ↵Guillermo E. Martinez2023-02-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | [-Werror=overflow] Regenerating BPF target using the maintainer mode emits: .../opcodes/bpf-opc.c:57:11: error: conversion from ‘long unsigned int’ to ‘unsigned int’ changes value from ‘18446744073709486335’ to ‘4294902015’ [-Werror=overflow] 57 | 64, 64, 0xffffffffffff00ff, { { F (F_IMM32) }, { F (F_OFFSET16) }, { F (F_SRCLE) }, { F (F_OP_CODE) }, { F (F_DSTLE) }, { F (F_OP_SRC) }, { F (F_OP_CLASS) }, { 0 } } The use of a narrow size to handle the mask CGEN in instruction format is causing this error. Additionally eBPF `call' instructions constructed by expressions using symbols (BPF_PSEUDO_CALL) emits annotations in `src' field of the instruction, used to identify BPF target endianness. cpu/ * bpf.cpu (define-call-insn): Remove `src' field from instruction mask. include/ *opcode/cge.h (CGEN_IFMT): Adjust mask bit width. opcodes/ * bpf-opc.c: Regenerate.
* bfd: use "stack trace" instead of "unwind" for SFrameIndu Bhagat2023-02-021-1/+1
| | | | | | | | | | | | | SFrame format is meant for generating stack traces only. bfd/ * elf-bfd.h: Replace the use of "unwind" with "stack trace". * elf-sframe.c: Likewise. * elf64-x86-64.c: Likewise. * elfxx-x86.c: Likewise. include/ * elf/common.h: Likewise.
* sframe: use "stack trace" instead of "unwind" for SFrameIndu Bhagat2023-02-021-14/+14
| | | | | | | SFrame format is meant for generating stack traces only. include/ * sframe.h: Fix comments in the header file.
* sim: info: convert verbose field to a boolMike Frysinger2023-01-181-2/+3
| | | | | | | The verbose argument has always been an int treated as a bool, so convert it to an explicit bool. Further, update the API docs to match the reality that the verbose value is actually used by some of the internal modules.
* ctf: fix various dreadful typos in the ctf_archive format commentsNick Alcock2023-01-121-4/+4
| | | | | | | | | | | | | | | | | | | When defining a format it helps to a) get the endianness right when you explicitly state what it is and b) define things in terms of fields that exist rather than fields that don't. (A bunch of changes of names during implementation were not reflected in these comments...) Thanks to Jose "Eye of the Eagle" Marchesi for spotting these. include/ * ctf.h (struct ctf_archive) [ctfa_ctfs]: The size element of this is in little-endian byte order, not network byte order. (struct ctf_archive_modent): This is positioned right after the end fo the struct ctf_archive, not at the offset of a nonexistent field. The number of elements in the array depends on ctfa_ndicts, not another nonexistent field.
* Fix size of external_reloc for pe-aarch64Mark Harmstone2023-01-101-2/+1
| | | | | | | | | | | | | | | This patch series finishes off the work by Jedidiah Thompson, and adds support for creating aarch64 PE images. This should be essentially complete: I've used this to create a "hello world" Windows program in asm, and (with GCC patches) a UEFI program in C. I think the only things missing are the .secidx relocation, which is needed for PDBs, and the SEH pseudos used for C++ exceptions. This first patch fixes the size of RELSZ; I'm not sure why it was 14 in the first place. This is the size of the "Base Relocation Block" in https://learn.microsoft.com/en-us/windows/win32/debug/pe-format, and AFAIK should be 10 for everything.
View Lorry Controller Status