gprofng/ChangeLog
2024-10-03 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>.
* common/hwc_cpus.h: New constant for Neoverse-N1 and Ampere-1.
* common/hwctable.c: Add the hwc table for Neoverse-N1 and Ampere-1.
* src/hwc_arm_ampere_1.h: New file with hwc table for Ampere-1.
* src/hwc_arm_neoverse_n1.h: New file with hwc table for Neoverse-N1.
opcodes/
* m68k-dis.c (m68k_opcode_to_insn_type): Define.
(match_insn_m68k): Call it to set insn_type.
(print_insn_arg) [case 'B']: Set branch target address.
(print_insn_m68k): Set insn_info_valid.
With a gdb build with -fsanitize=thread, and test-case
gdb.python/py-inferior.exp I run into:
...
(gdb) python gdb.selected_inferior().read_memory (0, 0xffffffffffffffff)^M
ERROR: ThreadSanitizer: requested allocation size 0xffffffffffffffff exceeds \
maximum supported size of 0x10000000000^M
...
There's already a workaround for this using ASAN_OPTIONS, and apparently the
same is needed for TSAN_OPTIONS.
Add the allocator_may_return_null=1 workaround also in TSAN_OPTIONS.
Likewise in gdb.dap/memory.exp.
Tested on x86_64-linux.
This patch introduces ADR to the Modula-2 language interface.
It return the address of the parameter supplied.
The patch also contains a dejagnu test for ADR.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
I came across a table containing common misspellings [1], and wrote a script to
detect and correct these misspellings.
The table also contains entries that have alternatives, like this:
...
addres->address, adders
...
and for those the script prints a TODO instead.
The script downloads the webpage containing the table, extracts the table and
caches it in .git/wikipedia-common-misspellings.txt to prevent downloading it
over and over again.
Example usage:
...
$ gdb/contrib/spellcheck.sh gdb*
...
ChangeLog files are silently skipped.
Checked with shellcheck.
Tested on x86_64-linux, by running it on the gdb* dirs on doing a build and
test run.
The results of running it are in the two following patches.
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://en.wikipedia.org/wiki/Wikipedia:Lists_of_common_misspellings/For_machines
Plus some tidies to swap_out_syms.
* elf.c (swap_out_syms): Handle NULL sym name. Use correct type
for return of _bfd_elf_strtab_add. Simplify.
* elflink.c (bfd_elf_match_symbols_in_sections): Handle NULL
sym name.
After commit 68bbe11833, ELF symbols read via bfd_canonicalize_symtab
and similar functions which have bad st_name fields will have NULL in
the name rather than "(null)". gdb.base/bfd-errors.exp deliberately
creates a faulty shared library with st_name pointing outside of
.dynsym for some symbols, and thus now results in NULL symbol names.
This triggers a segv on string_buffer.assign(name). Fix that.
For some reason, dlltool supports mcore-elf input files.
* dlltool.c (filter_symbols): Drop symbols with NULL names.
(identify_member_contains_symname): Don't consider symbols
with NULL names.
Given that relocation symbol name can now be NULL for ELF, adjust
various get_synthetic_symtab routines so they don't segfault.
* elf.c (_bfd_elf_get_synthetic_symtab): Cope with sym->name
possibly being NULL.
* elf32-arm.c (elf32_arm_get_synthetic_symtab): Likewise.
* elf32-ppc.c (ppc_elf_get_synthetic_symtab): Likewise.
* elf64-ppc.c (ppc64_elf_get_synthetic_symtab): Likewise.
* elfxx-mips.c (_bfd_mips_elf_get_synthetic_symtab): Likewise.
* elfxx-x86.c (_bfd_x86_elf_get_synthetic_symtab): Likewise.
Many uses of bfd_elf_sym_name report errors. They ought to not return
a NULL, as was the case prior to commit 68bbe11833. Introduce a new
function for cases where we'd like to know there is a problem with a
symbol st_name.
* elf-bfd.h (bfd_elf_sym_name_raw): Declare.
* elf.c (bfd_elf_sym_name_raw): New function.
(bfd_elf_sym_name): Revert to behaviour prior to 68bbe11833,
but returning "<null>" rather than "(null)" for st_name errors.
(group_signature): Use bfd_elf_sym_name_raw.
* elfcode.h (elf_slurp_symbol_table): Likewise.
* elf32-i386.c (elf_i386_scan_relocs): Whitespace.
With the removal of emulations, OBJ_MAYBE_... can no longer be defined.
Tidy code wherever they're used, which also includes the dropping of
most IS_ELF and uses and checks of OUTPUT_FLAVOR.
Where touching such constructs anyway, also drop TE_PEP checks when used
together with TE_PE ones (the former implies the latter).
Both ELF and COFF have various sub-flavors, each of which would then
require its own emulation: Right now when configuring a COFF/PE
secondary target (with perhaps an ELF primary one), one gets plain COFF
emulation rather than COFF/PE one.
As such a multitude of emulations would be unwieldy (and likely fragile)
drop gas emulations altogether instead.
While originally this was in preparation of a subsequent change making
SUPPORT_FRAME_LINKONCE potentially dependent on a global variable, the
construct appears unlikely to have been correct in the first place: The
variable would have been passed reliably uninitialized when
SUPPORT_FRAME_LINKONCE is build-time true.
While there correct indentation of the parameters passed to
get_cfi_seg().
The individual struct emulation instances shouldn't be declared in a .c
file; it and the producers of the symbols want to both see the
declarations, so declarations and definitions don't go out of sync. Move
these declarations to emul.h.
While there also adjust the conditional around this_format: That symbol
is never #define-d anywhere, and it's needed only when USE_EMULATIONS is
defined. (Really, when obj-multi isn't in use, it also is effectively
only ever written to.)
He/she cannot be reached at the given address anymore, and the name is
apparently too common to identify the person to attempt to establish
another contact. Sadly this orphans the CR16 and CRx ports.
when I disable a breakpoint in VS Code the breakpoint is removed
instead. I compared the behavior to lldb-dap and disabled events when
removing a breakpoint. Now it is possible to disable and enable
breakpoints in VS Code.
When building from an unmodified release tarball, a REGEN_TEXI
invocation is supposed to create a symlink to the .texi file
in the source directory and discard the newly generated .tmp file.
However, after commit bd32be01c9 ("bfd: merge doc subdir up a level")
it creates the symlink at the wrong level, and then a .texi with
a fresh timestamp, which in turn forces bfd.info regeneration.
This breaks builds in environments without makeinfo program.
Fix this by creating the symlink at the level of the target stamp.
Fixes: bd32be01c9 ("bfd: merge doc subdir up a level")
Signed-off-by: Alexey Izbyshev <izbyshev@ispras.ru>
This also makes the dlltool tests run more PE targets, finding that
sh-pe dlltool reports "Machine 'sh' not supported". I guess no one
cares about that.
PR19459
* dlltool.c (asm_prefix): Remove "mach" parameter. Return
leading_underscore independent of machine.
(ASM_PREFIX): Adjust.
* testsuite/binutils-all/dlltool.exp: Run on any target
satisfying is_pecoff_format for which dlltool is built.
Revert commit 0398b8d6c8. Remove target_xfail.
This patch tidies dlltool code dealing with adding a leading
underscore to generated symbol names. There should be no functional
change here, but there could be if we ever have a bfd target with
symbol_leading_char something other than '_' or 0.
* dlltool.c (leading_underscore): Change from an int to a
char*. Update all uses. If neither --leading-underscore or
--no=leading-underscore is given, set leading_underscore to a
string with first char returned by bfd_get_target_info as the
target's symbol underscoring.
It doesn't make much sense trying to print line numbers for what are
usually broken symbols, and there is a possibility of a segfault if
we pass strcmp a NULL.
A NULL return from bfd_elf_string_from_elf_section indicates an error.
That shouldn't be masked by bfd_elf_sym_name but rather passed up to
callers such as group_signature. If we want to print "(null)" then
that should be done at a higher level. That's what this patch does,
except that I chose to print "<null>" instead, like readelf. If we
see "(null)" we're probably passing a NULL to printf. I haven't
changed aoutx.h or pdp11.c print_symbol functions because they already
handle NULL names by omitting the name. I also haven't changed
mach-o.c, mmo.c, som.c, srec.c, tekhex.c, vms-alpha.c and
wasm-module.c print_symbol function because it looks like they will
never have NULL symbol names.
bfd/
* elf.c (bfd_elf_sym_name): Don't turn a NULL name into a
pointer to "(null)".
(bfd_elf_print_symbol): Print "<null>" for NULL symbol names.
* coffgen.c (coff_print_symbol): Likewise.
* ecoff.c (_bfd_ecoff_print_symbol): Likewise.
* pef.c (bfd_pef_print_symbol): Likewise.
* syms.c (bfd_symbol_info): Return "<null>" in symbol_info.name
if symbol name is NULL.
ld/
* ldlang.c (ld_is_local_symbol): Don't check for "(null)"
symbol name.
Fix a bug where an experiment with hardware event counter data
causes the source and disassembly files not to be generated.
No longer suppress zero valued metrics and change the name
of the man page in a warning message. Adapt line lengths to
not exceed 79.
gprofng/ChangeLog
2024-09-24 Ruud van der Pas <ruud.vanderpas@oracle.com>
PR 32193
PR 32199
PR 32201
* gp-display-html/gp-display-html.in: Implement all
the above changes.
While looking at the recent line number styling commit I noticed a few
places where we could add more file name styling. So lets do that.
Approved-By: Tom Tromey <tom@tromey.com>
This import name type is formally yet undocumented, but MSVC
produces/supports it, primarily for ARM64EC import libraries.
LLVM/LLD also supports this import name type. Since recently,
llvm-dlltool also uses this type for certain kinds of renamed imports
(that are easy to do in the long style import libraries produced by
GNU dlltool, but require this name type in short import libraries).
This name type contains a third string, in addition to the symbol
name and the DLL name, indicating the actual imported name to
reference in the import tables - which now can be distinct different
from the symbol name on the object file level.
8f23464a5d
and
7b275aa243
show how this import name type was added in LLVM.
Signed-off-by: Martin Storsjö <martin@martin.st>
