SYMBOL_REFERENCES_LOCAL can return true for undefined symbols. This
can result in a segfault when running sparc64 ld/testsuite/ld-vsb
tests that expect a failure.
* elfxx-sparc.c (_bfd_sparc_elf_finish_dynamic_symbol): Don't
access u.def.section on non-default visibility undefined symbol.
v850_elf_set_note is declared using an unsigned int note param in
elf32-v850.h but defined with enum c850_notes note in elf32-v850.c.
Current mainline gcc is warning about this. Huh.
* elf32-v850.c (v850_elf_set_note): Make "note" param an
unsigned int.
This fixes -Wpedantic warnings in chew.c. Conversion between function
and object pointers is not guaranteed. They can even be different
sizes, not that we're likely to encounter build machines like that
nowadays.
PR 29194
* doc/chew.c (pcu): New union typedef.
(dict_type, pc): Use it here. Adjust uses of pc.
(add_to_definition): Make "word" param a pcu. Adjust all uses
of function.
(stinst_type): Delete.
Catch out of memory.
* doc/chew.c: Include libibery.h.
(init_string_with_size, nextword): Replace malloc with xmalloc.
(newentry, add_to_definition): Likewise.
(catchar, catbuf): Replace realloc with xrealloc.
(add_intrinsic): Replace strdup with xstrdup.
* doc/local.mk (LIBIBERTY): Define.
(chew): Link against libiberty.
* Makefile.in: Regenerate.
This also removes some unused variables, and deletes support for the
"var" keyword which isn't used and was broken. (No means to set
variables, and add_var used push_number inconsistent with its use
elsewhere.)
* doc/chew.c: Move typedefs before variables, variables before
functions.
(die): Move earlier.
(word_type, sstack, ssp): Delete.
(dict_type): Delete var field.
(add_var): Delete.
(compile): Remove "var" support.
The zhinx extension is a sub-extension in zfinx, corresponding to
zfh extension but use GPRs instead of FPRs.
This patch expanded the zfh insn class define, since zfh and zhinx
use the same opcodes, thanks for Nelson's works.
changelog in V2: Add missing classes of 'zfh' and 'zhinx' in
"riscv_multi_subset_supports_ext".
bfd/ChangeLog:
* elfxx-riscv.c (riscv_multi_subset_supports): New extensions.
(riscv_multi_subset_supports_ext): New extensions.
gas/ChangeLog:
* testsuite/gas/riscv/fp-zhinx-insns.d: New test.
* testsuite/gas/riscv/fp-zhinx-insns.s: New test.
include/ChangeLog:
* opcode/riscv.h (enum riscv_insn_class): New INSN classes.
opcodes/ChangeLog:
* riscv-opc.c: Modify INSN_CLASS.
bfd_hostptr_t is defined as a type large enough to hold either a long
or a pointer. It mostly appears in the coff backend code in casts.
include/coff/internal.h struct internal_syment and union
internal_auxent have the only uses in data structures, where
comparison with include/coff/external.h and other code reveals that
the type only needs to be large enough for a 32-bit integer or a
pointer. That should mean replacing with uintptr_t is OK.
Requiring C99 means that uses of bfd_uint64_t can be replaced with
uint64_t, and similarly for bfd_int64_t, BFD_HOST_U_64_BIT, and
BFD_HOST_64_BIT. This patch does that, removes #ifdef BFD_HOST_*
and tidies a few places that print 64-bit values.
In the now-historical CRIS glibc port, the default stack permission
was no-exec as in "#define DEFAULT_STACK_PERMS (PF_R|PF_W)", and the
gcc port only emits the executable-stack marker when needed; when
emitting code needing it. In other words, the binutils setting
mismatches. It doesn't matter much, except being confusing and
defaulting to "off" is more sane.
ld:
* testsuite/ld-elf/elf.exp (target_defaults_to_execstack): Switch to 0
for cris*-*-*.
bfd:
* elf32-cris.c (elf_backend_default_execstack): Define to 0.
Change-Id: I52f37598f119b19111c7a6546c00a627fca0f396
Generate a .note.package FDO package metadata ELF note, following
the spec: https://systemd.io/ELF_PACKAGE_METADATA/
If the jansson library is available at build time (and it is explicitly
enabled), link ld to it, and use it to validate that the input is
correct JSON, to avoid writing garbage to the file. The
configure option --enable-jansson has to be used to explicitly enable
it (error out when not found). This allows bootstrappers (or others who
are not interested) to seamlessly skip it without issues.
This commit makes RV32 + 'Q' extension (version 2.2 or later) not
conflicting since this combination is no longer prohibited by the
specification.
bfd/ChangeLog:
* elfxx-riscv.c (riscv_parse_check_conflicts): Remove conflict
detection that prohibits RV32Q on 'Q' version 2.2 or later.
gas/ChangeLog:
* testsuite/gas/riscv/march-fail-rv32iq.d: Removed.
* testsuite/gas/riscv/march-fail-rv32iq.l: Likewise.
* testsuite/gas/riscv/march-fail-rv32iq2p0.d: New test
showing RV32IQ fails on 'Q' extension version 2.0.
* testsuite/gas/riscv/march-fail-rv32iq2p0.l: Likewise.
* testsuite/gas/riscv/march-fail-rv32iq2.d: Likewise.
* testsuite/gas/riscv/march-fail-rv32iq-isa-2p2.d: New test
showing RV32IQ fails on ISA specification version 2.2.
* testsuite/gas/riscv/march-ok-rv32iq2p2.d: New test
showing RV32IQ succesds on 'Q' extension version 2.2.
* testsuite/gas/riscv/march-ok-rv32iq-isa-20190608.d: New test
showing RV32IQ succesds on ISA specification 20190608.
When using perf to profile large binaries, _bfd_dwarf2_find_nearest_line()
becomes a hotspot, as perf wants to get line number information
(for inline-detection purposes) for each and every sample. In Chromium
in particular (the content_shell binary), this entails going through
475k address ranges, which takes a long time when done repeatedly.
Add a radix-256 trie over the address space to quickly map address to
compilation unit spaces; for content_shell, which is 1.6 GB when some
(but not full) debug information turned is on, we go from 6 ms to
0.006 ms (6 µs) for each lookup from address to compilation unit, a 1000x
speedup.
There is a modest RAM increase of 180 MB in this binary (the existing
linked list over ranges uses about 10 MB, and the entire perf job uses
between 2–3 GB for a medium-size profile); for smaller binaries with few
ranges, there should be hardly any extra RAM usage at all.
Make ld and bfd values consistent by swapping values 0 and 2 in
link_info.warn_execstack. This has the benefit of making the value an
"extended" boolean, with 0 meaning no warning, 1 meaning warn, other
values a conditional warning.
Yes, this patch introduces fails on arm/aarch64. Not a problem with
this patch but an arm/aarch64 before_parse problem.
bfd/
* elflink.c (bfd_elf_size_dynamic_sections): Adjust
warn_execstack test.
include/
* bfdlink.h (warn_execstack): Swap 0 and 2 meaning.
ld/
* configure.ac (DEFAULT_LD_WARN_EXECSTACK): Use values of 0,
1, 2 consistent with link_info.warn_execstack.
* ld.texi: Typo fixes.
* lexsup.c (parse_args): Adjust setting of link_info.warn_execstack.
(elf_static_list_options): Adjust help message conditions.
* configure: Regenerate.
Otherwise the string table may grow and hence e.g. change a final binary
(observed with PE/COFF ones) even if really there's no change. Doing so
in fact reduces the overall amount of code, and in particular the number
of places which need to remain in sync.
Afaics there's no real equivalent to the "traditional_format" field used
when linking, so hashing is always enabled when copying / stripping.
Neither of the tools is really a linker, so whatever was originally
recorded should be retained rather than being overwritten by these
tools' versions.
So far this option had no effect when used together with e.g.
--strip-debug. Set BSF_FILE on these symbols to change that.
While altering this also join two adjacent blocks of case labeled
statements with identical code.
When a sufficiently small alignment was specified via --file-alignment,
individual section alignment shouldn't affect placement within the file.
This involves first of all clearing D_PAGED for images when section and
file alignment together don't permit paging of the image. The involved
comparison against COFF_PAGE_SIZE in turn helped point out (through a
compiler warning) that 'page_size' should be of unsigned type (as in
particular FileAlignment is). This yet in turn pointed out a dubious
error condition (which is being deleted).
For the D_PAGED case I think the enforced file alignment may still be
too high, but I'm wary of changing that logic without knowing of
possible corner cases.
Furthermore file positions in PE should be independent of the alignment
recorded in section headers anyway. Otherwise there are e.g. anomalies
following commit 6f8f6017a0 ("PR27567, Linking PE files adds alignment
section flags to executables") in that linking would use information a
subsequent processing step (e.g. stripping) wouldn't have available
anymore, and hence a binary could change in that 2nd step for no actual
reason. (Similarly stripping a binary linked with a linker pre-dating
that commit would change the binary again when stripping it a 2nd time.)
This commit fixes canonical extension order to follow the RISC-V ISA
Manual draft-20210402-1271737 or later.
bfd/ChangeLog:
* elfxx-riscv.c (riscv_recognized_prefixed_ext): Fix "K" extension
prefix to be placed before "J".
If you load a core file into GDB with the --write option, or "set
write on" (equivalent), and then poke memory expecting it to patch the
core binary, you'll notice something odd -- the write seems to
succeed, but in reality, it doesn't. The value you wrote doesn't
persist. Like so:
$ gdb -q --write -c testsuite/outputs/gdb.base/patch/gcore.test
[New LWP 615986]
Core was generated by `/home/pedro/gdb/build/gdb/testsuite/outputs/gdb.base/patch/patch'.
Program terminated with signal SIGTRAP, Trace/breakpoint trap.
#0 0x0000555555555131 in ?? ()
(gdb) p *(unsigned char *)0x0000555555555131 = 1
$1 = 1 '\001'
(gdb) p *(unsigned char *)0x0000555555555131
$2 = 185 '\271'
(gdb)
Diffing hexdumps of before/after patching, reveals that a "0x1" was
actually written somewhere in the file. The problem is that the "0x1"
was written at the wrong offset in the file...
That happens because _bfd_elf_set_section_contents does this to seek
to the section's offset:
pos = hdr->sh_offset + offset;
if (bfd_seek (abfd, pos, SEEK_SET) != 0
|| bfd_bwrite (location, count, abfd) != count)
return false;
... and 'hdr->sh_offset' is zero, so we seek to just OFFSET, which is
incorrect. The reason 'hdr->sh_offset' is zero is that
kernel-generated core files normally don't even have a section header
table (gdb-generated ones do, but that's more an accident than a
feature), and indeed elf_core_file_p doesn't even try to read sections
at all:
/* Core files are simply standard ELF formatted files that partition
the file using the execution view of the file (program header table)
rather than the linking view. In fact, there is no section header
table in a core file.
The process status information (including the contents of the general
register set) and the floating point register set are stored in a
segment of type PT_NOTE. We handcraft a couple of extra bfd sections
that allow standard bfd access to the general registers (.reg) and the
floating point registers (.reg2). */
bfd_cleanup
elf_core_file_p (bfd *abfd)
Changing _bfd_elf_set_section_contents from:
pos = hdr->sh_offset + offset;
to:
pos = section->filepos + offset;
fixes it. If we do that however, the tail end of
_bfd_elf_set_section_contents ends up as a copy of
_bfd_generic_set_section_contents, so just call the latter, thus
eliminating some duplicate code.
New GDB testcase included, which exercises both patching an executable
and patching a core file. Patching an executable already works
without this fix, because in that case BFD reads in the sections
table. Still, we had no testcase for that yet. In fact, we have no
"set write on" testcases at all, this is the first one.
Tested on x86-64 GNU/Linux, gdb, ld, binutils, and gas.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18227
Change-Id: I0f49f58b48aabab2e269f2959b8fd8a7fe36fdce
