Nick Clifton [Mon, 27 Jun 2022 10:39:27 +0000 (11:39 +0100)]
Disable execstack and rwx segments warnings for MIPS targets.
PR 29263
* configure.ac: Move HPPA specific code from here...
* configure.tgt: ... to here. Add similar code for MIPS.
Move code for CRIS, MIPS and HPPA to block at start of file.
* configure: Regenerate.
Jan Beulich [Mon, 27 Jun 2022 09:12:57 +0000 (11:12 +0200)]
bfd: prune config.bfd's setting of targ_archs
The final "match all" case can take care of a few explicit entries:
Purge those. Also move s12z* into proper position (the table is
otherwise sorted, after all).
Jan Beulich [Mon, 27 Jun 2022 09:11:46 +0000 (11:11 +0200)]
drop XC16x bits
Commit 04f096fb9e25 ("Move the xc16x target to the obsolete list") moved
the architecture from the "obsolete but still available" to the
"obsolete / support removed" list in config.bfd, making the architecture
impossible to enable (except maybe via "enable everything" options").
Note that I didn't touch */po/*.po{,t} on the assumption that these
would be updated by some (half)automatic means.
Fix location list offset address dump under DW_AT_location (dwarf-5)
For clang compiled objects with dwarf-5, location list offset address dump
under DW_AT_location is corrected, where DW_FORM_loclistx is used. While
dumping the location list offset, the address dumped is wrong where it was
refering to .debug_addr instead of .debug_loclists
* dwarf.c (fetch_indexed_value): Add base_address as parameter and
use it to access the section offset.
(read_and_display_attr_value): Handle DW_FORM_loclistx form separately.
Pass loclists_base to fetch_indexed_value().
Alan Modra [Sat, 25 Jun 2022 02:27:22 +0000 (11:57 +0930)]
PowerPC64 .branch_lt address
.branch_lt is really an extension of .plt, as is .iplt. We'd like all
of the PLT sections to be fixed relative to .TOC. after stub sizing,
because changes in offset to PLT entries might mean a change in stub
sizes. When -z relro, the relro layout does this by laying out
sections from the end of the relro segment. So for example, a change
in .eh_frame (which happens after stub sizing) will keep the same GOT
to PLT offset when -z relro. Not so when -z norelro, because then the
usual forward layout of section is done and .got is more aligned than
.branch_lt.
* emulparams/elf64ppc.sh: Set .branch_lt address fixed relative
to .got.
* testsuite/ld-powerpc/elfv2exe.d: Adjust to suit.
Alan Modra [Fri, 24 Jun 2022 03:55:45 +0000 (13:25 +0930)]
-z relro relaxation and ld script SIZEOF
A number of targets use assignments like:
. = DATA_SEGMENT_RELRO_END (SIZEOF (.got.plt) >= 12 ? 12 : 0, .);
(from i386) in linker scripts to put the end of the relro segment past
the header in .got.plt. Examination of testcases like those edited by
this patch instead sees the end of the relro segment being placed at
the start of .got.plt. For the i386 pie1 test:
The DATA_SEGMENT_RELRO_END value in the map file is weird too. All of
this is triggered by SIZEOF (.got.plt) being evaluated wrongly as
zero. Fix it by taking into account the action of
lang_reset_memory_regions during relaxation.
* ldexp.c (fold_name <SIZEOF>): Use rawsize if size has been reset.
* ldlang.c (lang_size_sections_1): Don't reset processed_vma here.
* testsuite/ld-i386/pie1.d: Adjust to suit.
* testsuite/ld-x86-64/pr20830a.d: Likewise.
* testsuite/ld-x86-64/pr20830b.d: Likewise.
* testsuite/ld-x86-64/pr21038a.d: Likewise.
* testsuite/ld-x86-64/pr21038b.d: Likewise.
* testsuite/ld-x86-64/pr21038c.d: Likewise.
Commit b68a20d6675f1360ea4db50a9835c073675b9889 changed ld to produce
R_ARM_GLOB_DAT but that defeated the purpose of protected visibility
as an optimization. Restore the previous behavior (which matches
ld.lld) by defining elf_backend_extern_protected_data to 0.
...points to a "sibling" DIE that is at a different child depth.
Because this test case doesn't really require sibling attributes, this
patch fixes the problem by removing them from the test.
Note that gdb is not generally robust against malformed DWARF.
Detecting and compensating for this problem would probably be
expensive and, IMO, is better left to some (still hypothetical) DWARF
linter.
Tom Tromey [Thu, 9 Jun 2022 13:21:24 +0000 (07:21 -0600)]
Fix end of CU calculation in cooked_indexer::index_dies
cooked_indexer::index_dies incorrect computes the end of the current
CU in the .debug_info. This isn't readily testable without writing
intentionally corrupt DWARF, but it's apparent through observation: it
is currently based on 'info_ptr', which does not always point to the
start of the CU. This patch fixes the expression. Tested on x86-64
Fedora 34.
Tiezhu Yang [Sat, 25 Jun 2022 01:20:00 +0000 (09:20 +0800)]
gdb: LoongArch: Define register numbers and clean up code
This commit defines register numbers of various important registers,
we can use them directly in the related code, and also clean up some
code to make them more clear and readable.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Since interp_ui_out() is a virtual method that also works for the CLI
interpreter, and, both the CLI and the TUI interpreters inherit from
the same base class (cli_interp_base), we can convert the CLI
observers to cast to cli_interp_base instead and use interp_ui_out()
too. With that, the CLI observers will work for the TUI interpreter
as well. This lets us completely eliminate the TUI observers. That's
what this commit does.
Pedro Alves [Fri, 24 Jun 2022 16:20:16 +0000 (17:20 +0100)]
Revert "Delete delete_thread_silent"
Turns out we'll be gaining a new use of this function very soon, the
incoming AMDGPU port needs it. Let's add it back, as it isn't really
hurting anything.
Yvan Roux [Fri, 24 Jun 2022 15:16:54 +0000 (17:16 +0200)]
gdb/arm: Update the value of active sp when base sp changes
For Arm Cortex-M33 with security extensions, there are 4 different
stacks pointers (msp_s, msp_ns, psp_s, psp_ns).
When plain "sp" is updated during unwinding of the stack, the active
stack pointer of the 4 stack pointers needs to be kept in sync.
Andrew Burgess [Thu, 9 Jun 2022 15:45:48 +0000 (16:45 +0100)]
gdb/testsuite: remove unneeded calls to get_compiler_info
It is not necessary to call get_compiler_info before calling
test_compiler_info, and, after recent commits that removed setting up
the gcc_compiled, true, and false globals from get_compiler_info,
there is now no longer any need for any test script to call
get_compiler_info directly.
As a result every call to get_compiler_info outside of lib/gdb.exp is
redundant, and this commit removes them all.
There should be no change in what is tested after this commit.
Andrew Burgess [Thu, 9 Jun 2022 14:21:37 +0000 (15:21 +0100)]
gdb/testsuite: remove global gcc_compiled from gdb.exp
After this commit the gcc_compiled global is no longer exported from
lib/gdb.exp. In theory we could switch over all uses of gcc_compiled
to instead call test_compiler_info directly, however, I have instead
added a new proc to gdb.exp: 'is_c_compiler_gcc'. I've then updated
the testsuite to call this proc instead of using the global.
Having a new proc specifically for this task means that we have a
single consistent pattern for detecting gcc. By wrapping this logic
within a proc that calls test_compiler_info, rather than using the
global, means that test scripts don't need to call get_compiler_info
before they read the global, simply calling the new proc does
everything in one go.
As a result I've been able to remove the get_compiler_info calls from
all the test scripts that I've touched in this commit.
In some of the tests e.g. gdb.dwarf2/*.exp, the $gcc_compiled flag was
being checked at the top of the script to decide if the whole script
should be skipped or not. In these cases I've called the new proc
directly and removed all uses of gcc_compiled.
In other cases, e.g. most of the gdb.base scripts, there were many
uses of gcc_compiled. In these cases I set a new global gcc_compiled
near the top of the script, and leave the rest of the script
unchanged.
There should be no changes in what is tested after this commit.
Pedro Alves [Wed, 22 Jun 2022 19:33:01 +0000 (20:33 +0100)]
Include count of unexpected core files in gdb.sum summary
If GDB, GDBserver, a testcase program, Valgrind, etc. unexpectedly
crash while running the GDB testsuite, and you've setup your machine
such that core files are dumped in the current directory instead of
being shoved somewhere by abrt, apport, or similar (as you should for
proper GDB testing), you'll end up with an unexpected core file in the
$build/gdb/testsuite/ directory.
It can happen that GDB, GDBserver, etc. even crashes _after_ gdb_exit,
during teardown, and thus such a crash won't be noticed by looking at
the gdb.sum file at all. This commit aims at improving that, by
including a new "unexpected core files" line in the testrun summary.
For example, here's what I get on x86-64 Ubuntu 20.04, with this
patch:
=== gdb Summary ===
# of unexpected core files 12 << new info
# of expected passes 107557
# of unexpected failures 35
# of expected failures 77
# of unknown successes 2
# of known failures 114
# of untested testcases 31
# of unsupported tests 139
where we can see that GDB crashed a number of times, but also
Valgrind's vgdb, and a couple testcase programs. Neither of which is
good.
If your core_pattern is just "core" (but why??), then I guess that you
may end up with just a single core file in testsuite/. Still, that is
one core file too many.
Above, we see a couple cores for "connect-with-no", which are the
result of gdb.server/connect-with-no-symbol-file.exp. This is a case
mentioned above -- while the program crashed, that happens during
testcase teardown, and it goes unnoticed (without this commit) by
gdb.sum results. Vis:
$ make check TESTS="gdb.server/connect-with-no-symbol-file.exp"
...
=== gdb Summary ===
# of unexpected core files 2
# of expected passes 8
...
$
The tests fully passed, but still the testcase program crashed
somehow:
$ ls -1 testsuite/core.*
testsuite/core.connect-with-no.941561.nelson.1656003317
testsuite/core.connect-with-no.941682.nelson.1656003317
Against --target_board=native-extended-gdbserver it's even worse. I
get:
# of unexpected core files 26
and note that when GDBserver hits an assertion failure, it exits with
error, instead of crashing with SIGABRT. I think that should be
changed, at least on development builds, but that would be for another
patch. After such patch, I suspect the number of unexpected cores
will be higher, as there are likely teardown GDBserver assertions that
we're not noticing.
I decided to put this new info in the "gdb Summary" section, as that's
a place people already are used to looking at, either when looking at
the tail of gdb.sum, or when diffing gdb.sum files, and we've already
extended this section before, to include the count of DUPLICATE and
PATH problems, so there's precedent.
Implementation-wise, the new line is appended after DejaGnu is
finished, with a shell script that is invoked by the Makefile. It is
done this way so that serial and parallel testing work the same way.
My initial cut at an implementation was in TCL, straight in
testsuite/lib/check-test-names.exp, where DUPLICATES and PATH are
handled, like so:
@@ -148,6 +159,10 @@ namespace eval ::CheckTestNames {
$counts(paths,$which)
maybe_show_count "# of duplicate test names\t" \
$counts(duplicates,$which)
+
+ set cores [glob -nocomplain -directory $::objdir core*]
+ maybe_show_count "# of unexpected core files\t" \
+ [llength $cores]
}
But that would only work for serial testing, as in parallel testing,
the final gdb.sum is generated by aggregating the results of all the
individual gdb.sum files, and dg-extract-results.sh doesn't know about
our new summary line. And I don't think that dg-extract-results.sh
should be taught about it, since the count of core files is not
something that we want to count many times, once per testcase, and
then add up the subcounts at the end. Every time we count the core
files, we're already counting the final count.
I considered using the Tcl implementation in serial mode, and the
script approach for parallel testing, but that has the obvious
downside of implementing and maintaining the same thing twice. In the
end, I settled on the script approach for serial mode too, which
requires making the "check-single" rule print the tail end of the
gdb.sum file, with a side effect being that if you look at the
terminal after a run (instead of at the gdb.sum file), you'll see the
"gdb Summary" section twice, once without the unexpected core lines
printed, and then another with. IMO, this isn't an issue; when
testing in parallel mode, if you look at the terminal after "make -jN
check", you'll also see multiple "gdb Summary" sections printed.
%e: executable filename
%p: pid
%h: hostname
%t: UNIX time of dump
so it's easy to tell which program produced the core from the core
file name.
From above, we can tell that the corresponding testcases are
gdb.base/annota1.exp, gdb.base/annota3.exp and
gdb.base/exitsignal.exp.
At least gdb.base/annota1.exp and gdb.base/annota3.exp have code in
them to delete the core file. However, that isn't working for me,
because said code only looks for cores named exactly either "core" or
"core.PID", and my core_pattern doesn't match that.
Another issue I noticed, is that I have not been running
gdb.base/bigcore.exp, for a similar reason. I get:
Program terminated with signal SIGABRT, Aborted.
The program no longer exists.
(gdb) PASS: gdb.base/bigcore.exp: signal SIGABRT
UNTESTED: gdb.base/bigcore.exp: can't generate a core file
But I actually have a core file under the testcase's output dir:
This commit fixes these things, by adding a find_core_file routine
that searches core files in a way that works with my core pattern as
well. This then also adds a convenience remove_core routine as a
wrapper around find_core_file that removes the found core file.
In addition, it changes some testcases that expect to have their
program dump core, to switch the inferior's cwd to the testcase's
output dir, so that the core is dumped there instead of in
build/gdb/testsuite/. Some testcases were already doing that, but not
all. The idea is that any core file dumped in build/gdb/testsuite/ is
an unexpected core file. The next patch will add a count of such
unexpected core files to gdb.sum.
Another change is that the directory changing is now done with "set
cwd" instead of with "cd". "set cwd" only affects the inferior cwd,
while "cd" affects GDB's cwd too. By using "set cwd" instead of "cd",
if GDB dumps core in these testcases, the GDB core dump will still end
up in build/gdb/testsuite/, and can thus be detected as an unexpected
core.
Andrew Burgess [Sat, 14 May 2022 09:35:54 +0000 (10:35 +0100)]
gdb: make use of RAII in run_inferior_call
In passing I noticed that there are three local variables in
run_inferior_call that are used to save, and then restore some state,
I think these could all be replaced with a RAII style scoped_restore
instead.
Of the three locals that I've changed, the only one that I believe is
now restored in a different location is ui::async, before this commit
the async field was restored after a call to either delete_file_handle
or ui_register_input_event_handler, and after this commit, the field
is restored before these calls. However, I don't believe that either
of these functions depend on the value of the async field, so I
believe the commit is fine.
Tested on x86-64/Linux passes with no regressions.
Tom Tromey [Thu, 23 Jun 2022 20:26:13 +0000 (14:26 -0600)]
Don't declare cli_set_logging
cli_set_logging is declared but not defined. It's probably a leftover
from whenever interpreters were changed to use inheritance. This
patch removes the declaration. Tested by grep and rebuilding.
Tom Tromey [Tue, 7 Jun 2022 15:15:24 +0000 (09:15 -0600)]
Use PyBool_FromLong
I noticed a few spots that were explicitly creating new references to
Py_True or Py_False. It's simpler here to use PyBool_FromLong, so
this patch changes all the places I found.
Alan Modra [Thu, 23 Jun 2022 01:51:36 +0000 (11:21 +0930)]
Re: PowerPC64: stub debug dump
Let's show the current stub as well as the previous one. Of interest
is the current offset and a new field, id. Check that the build
hash table traversal is in the same order as sizing traversal too.
* elf64-ppc.c (struct ppc_stub_hash_entry): Add id.
(struct ppc_link_hash_table): Add stub_id.
(stub_hash_newfunc): Init id and symtype.
(dump_stub): New function, extracted from..
(dump_previous_stub): ..here. Deleted.
(ppc_build_one_stub): Sanity check stub id as well as offset.
Show current stub as well as previous.
(ppc_size_one_stub): Set stub id.
(ppc64_elf_size_stubs): Init stub_id before traversal.
(ppc64_elf_build_stubs): Likewise.
gcc -fpic -shared -fuse-ld=bfd fails with the confusing diagnostic:
relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `foo' which may bind externally can not be used when making a shared object; recompile with -fPIC
Call _bfd_elf_symbol_refs_local_p with local_protected==true to suppress
the error. The new behavior matches gold and ld.lld.
Note: if some code tries to use direct access relocations to take the
address of foo (likely due to -fno-pic), the pointer equality will
break, but the error should be reported on the executable link, not on
the innocent shared object link. glibc 2.36 will give a warning at
relocation resolving time.
Commit 32f573bcb3aaa1c9defcad79dbb5851fcc02ae2d changed ld to produce
R_AARCH64_GLOB_DAT but that defeated the purpose of protected visibility
as an optimization. Restore the previous behavior (which matches
ld.lld) by defining elf_backend_extern_protected_data to 0.
Tom Tromey [Fri, 17 Jun 2022 15:38:20 +0000 (09:38 -0600)]
Move mi_interpreter to mi-interp.h
I noticed that touching interps.h caused a lot of recompilation. I
tracked this down to mi-common.h including this file. This patch
moves the MI interpreter to mi-interp.h, which cuts down on
recompilation when modifying interps.h.
Tom Tromey [Fri, 17 Jun 2022 15:31:44 +0000 (09:31 -0600)]
Use unique_xmalloc_ptr in interp
This changes interp::m_name to be a unique_xmalloc_ptr, removing some
manual memory management. It also cleans up the initialization of the
'inited' member, and moves the 'private:' and 'public:' keywords to
their proper spots.
Fangrui Song [Wed, 22 Jun 2022 17:55:12 +0000 (10:55 -0700)]
aarch64: Disallow copy relocations on protected data
If an executable has copy relocations for extern protected data, that
can only work if the shared object containing the definition is built
with assumptions (a) the compiler emits GOT-generating relocations (b)
the linker produces R_*_GLOB_DAT instead of R_*_RELATIVE. Otherwise the
shared object uses its own definition directly and the executable
accesses a stale copy. Note: the GOT relocations defeat the purpose of
protected visibility as an optimization, and it turns out this never
worked perfectly.
glibc 2.36 will warn on copy relocations on protected data. Let's
produce a warning at link time, matching ld.lld which has been used on
many aarch64 OSes.
Note: x86 requires GNU_PROPERTY_NO_COPY_ON_PROTECTED to have the error.
This is to largely due to GCC 5's "x86-64: Optimize access to globals in
PIE with copy reloc" which started to use direct access relocations for
external data symbols in -fpie mode.
GCC's aarch64 port does not have the change. Nowadays with most builds
switching to -fpie/-fpic, aarch64 mostly doesn't need to worry about
copy relocations. So for aarch64 we simply don't check
GNU_PROPERTY_NO_COPY_ON_PROTECTED.
* dwarf.c (fetch_indexed_string): Added new parameter
str_offsets_base to calculate the string offset.
(read_and_display_attr_value): Read DW_AT_str_offsets_base
attribute.
(process_debug_info): While allocating memory and initializing
debug_information, do it for do_debug_info also, if its true.
(load_separate_debug_files): Load .debug_str_offsets if exists.
* dwarf.h (struct debug_info): Add str_offsets_base field.
Nelson Chu [Wed, 22 Jun 2022 09:57:12 +0000 (17:57 +0800)]
RISC-V: Reorder the prefixed extensions which are out of order.
This patch has been pending for almost a year... However, I noticed that
llvm can already re-order the extensions, even if they are out of orders.
Not really sure if they can also re-order the single letter extensions,
but at least we can do this for the multi-letter extensions in binutils.
bfd/
* elfxx-riscv.c (riscv_parse_prefixed_ext): Removed the code which are
used to check the prefixed extension orders.
gas/
* testsuite/gas/riscv/march-fail-order-x-z.d: Removed since we will help
tp reorder the prefixed extensions for now.
* testsuite/gas/riscv/march-fail-order-x-z.l: Likewise.
* testsuite/gas/riscv/march-fail-order-x.d: Likewise.
* testsuite/gas/riscv/march-fail-order-x.l: Likewise.
* testsuite/gas/riscv/march-fail-order-z.d: Likewise.
* testsuite/gas/riscv/march-fail-order-z.l: Likewise.
Nelson Chu [Wed, 22 Jun 2022 09:03:16 +0000 (17:03 +0800)]
RISC-V: Use single h extension to control hypervisor CSRs and instructions.
According to the picture 28.1 in the current ISA spec, h is no larger the
multi-letter extension, it is a single extension after v. Therefore, this
patch fix the implementation, and use the single h to control hypervisor
CSRs and instructions, which we promised to do before.
bfd/
* elfxx-riscv.c (riscv_supported_std_ext): Added h with version 1.0 after v.
(riscv_supported_std_h_ext): Removed.
(riscv_all_supported_ext): Updated since riscv_supported_std_h_ext is removed.
(riscv_prefix_ext_class): Removed RV_ISA_CLASS_H.
(parse_config): Updated since riscv_prefix_ext_class is removed.
(riscv_recognized_prefixed_ext): Likewise.
(riscv_get_default_ext_version): Likewise.
(riscv_multi_subset_supports): Handle INSN_CLASS_H for hypervisor instructions.
(riscv_multi_subset_supports_ext): Likewise.
gas/
* config/tc-riscv.c (riscv_csr_class): Added CSR_CLASS_H and CSR_CLASS_H_32 for
hypervisor CSRs.
(riscv_csr_address): Likewise.
* testsuite/gas/riscv/csr-version-1p10.d: Updated since hypervisor CSRs are
controlled by single h extension for now.
* testsuite/gas/riscv/csr-version-1p10.l: Likewise.
* testsuite/gas/riscv/csr-version-1p11.d: Likewise.
* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
* testsuite/gas/riscv/csr-version-1p12.d: Likewise.
* testsuite/gas/riscv/csr-version-1p12.l: Likewise.
* testsuite/gas/riscv/csr-version-1p9p1.d: Likewise.
* testsuite/gas/riscv/csr-version-1p9p1.l: Likewise.
* testsuite/gas/riscv/h-ext-32.d: Added h to architecture string.
* testsuite/gas/riscv/h-ext-64.d: Likewise.
* testsuite/gas/riscv/march-fail-single-prefix-h: Removed since h is no
longer multi-letter extension.
* testsuite/gas/riscv/march-fail-unknown-h.d: Likewise.
include/
* opcode/riscv-opc.h: Control hypervisor CSRs by h extension, rather than
the privileged spec verisons.
* opcode/riscv.h (riscv_insn_class): Added INSN_CLASS_H.
opcodes/
* riscv-opc.c (riscv_opcodes): Control hypervisor instructions by h extension.
Tsukasa OI [Thu, 2 Jun 2022 14:05:58 +0000 (23:05 +0900)]
RISC-V: Add 'H' to canonical extension ordering
This commit adds 'H' to canonical extension ordering based on current
consensus (not officially ratified as a new ISA specification manual
but discussion for software compatibility is made).
bfd/ChangeLog
* elfxx-riscv.c (riscv_ext_canonical_order): Add 'H' for
canonical extension ordering based on current consensus.
Tsukasa OI [Fri, 10 Jun 2022 09:52:50 +0000 (18:52 +0900)]
RISC-V: Prepare i18n for required ISA extensions
Some strings returned by the riscv_multi_subset_supports_ext function
contain not just extension names but words like "and" and "or".
This commit wraps such strings with the gettext macro (_) for
internationalization in the future.
bfd/ChangeLog:
* elfxx-riscv.c (riscv_multi_subset_supports_ext): Wrap some
strings with the gettext macro to prepare future i18n.
Tsukasa OI [Fri, 10 Jun 2022 10:00:19 +0000 (19:00 +0900)]
RISC-V: Fix inconsistent error message (range)
This commit fixes inconsistent error message format involving compressed
funct<n> fields. In specific, funct6 had an error message with range
0..2^<n> ("0..64") unlike other funct<n> fields with 0..2^<n>-1
(e.g. funct4 with "0..15").
Marcus Nilsson [Wed, 22 Jun 2022 08:36:03 +0000 (10:36 +0200)]
readelf: replace xmalloc with malloc in slurp_relr_relocs
Using xmalloc makes the null check redundant since failing allocation
will exit the program. Instead use malloc and let the error be
conveyed up the call chain.
Alan Modra [Wed, 22 Jun 2022 02:25:02 +0000 (11:55 +0930)]
PowerPC64: stub debug dump
powerpc64le-linux-ld is failing the assertion in ppc_build_one_stub,
again apparently, which means a stub will overwrite the tail of a
previous stub. The difficulty with debugging these issues is that
it's not a problem with the stub that triggers the assertion, but the
previous stub in that section. This patch keeps track of the last
stub and adds a debug dump. Hopefully that will help.
* elf64-ppc.c (enum _ppc64_sec_type): Add sec_stub.
(struct _ppc64_elf_section_data): Add u.last_ent.
(dump_previous_stub): New function.
(ppc_build_one_stub): Keep track of previous stub, and dump it
when finding an overlapping stub.
Nick Alcock [Sat, 11 Jun 2022 12:07:18 +0000 (13:07 +0100)]
libctf: tests: prune warnings from compiler output
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.
Nick Alcock [Fri, 10 Jun 2022 18:06:59 +0000 (19:06 +0100)]
libctf: avoid mingw warning
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.
Nick Alcock [Fri, 10 Jun 2022 16:05:50 +0000 (17:05 +0100)]
libctf: fix linking together multiple objects derived from the same source
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.
Kevin Buettner [Thu, 2 Jun 2022 22:26:38 +0000 (15:26 -0700)]
Document how GDB searches for files when using -s, -e, and -se options
GDB's documentation of the 'file' command says:
If you do not specify a directory and the file is not found in the
GDB working directory, GDB uses the environment variable PATH as a
list of directories to search, just as the shell does when looking
for a program to run.
The same is true for files specified via commandline options -s, -e,
and -se.
This commit adds a cross reference to the file command for these options.
Nick Clifton [Tue, 21 Jun 2022 15:37:27 +0000 (16:37 +0100)]
Binutils support for dwarf-5 (location and range lists related)
* dwarf.h (struct debug_info): Add rnglists_base field.
* dwarf.c (read_and_display_attr_value): Read attribute DW_AT_rnglists_base.
(display_debug_rnglists_list): While handling DW_RLE_base_addressx,
DW_RLE_startx_endx, DW_RLE_startx_length items, pass the proper parameter
value to fetch_indexed_addr(), i.e. fetch the proper entry in .debug_addr section.
(display_debug_ranges): Add rnglists_base to the .debug_rnglists base address.
(load_separate_debug_files): Load .debug_addr section, if exists.
Nick Clifton [Tue, 21 Jun 2022 10:22:38 +0000 (11:22 +0100)]
Default to disabling the linker warnings about execstack and RWX segments if the target is the HPPA architecture.
PR 29263
* configure.ac (ac_default_ld_warn_execstack): Default to 'no' for
HPPA targets.
(ac_default_ld_warn_rwx_segments): Likewise.
* configure: Regenerate.
* testsuite/ld-elf/elf.exp: Add the --warn-execstack command line
option to the command line when running execstack tests for the
HPPA target.
Tom Tromey [Mon, 6 Jun 2022 16:01:40 +0000 (10:01 -0600)]
Move finish_print out of value_print_options
'finish_print' does not really belong in value_print_options -- this
is consulted only when deciding whether or not to print a value, and
never during the course of printing. This patch removes it from the
structure and makes it a static global in infcmd.c instead.
Tom Tromey [Sun, 5 Jun 2022 17:28:10 +0000 (11:28 -0600)]
Fix assertion failure in copy_type
PR exp/20630 points out a simple way to cause an assertion failure in
copy_type -- but this was found in the wild a few times as well.
copy_type only works for objfile-owned types, but there isn't a deep
reason for this. This patch fixes the bug by updating copy_type to
work for any sort of type.
Better would perhaps be to finally implement type GC, but I still
haven't attempted this.
Tomoaki Kawada [Thu, 16 Jun 2022 09:54:30 +0000 (09:54 +0000)]
Fix the sorting algorithm for reloc entries
The optimized insertion sort algorithm in `elf_link_adjust_relocs`
incorrectly assembled "runs" from unsorted entries and inserted them to an
already-sorted prefix, breaking the loop invariants of insertion sort.
This commit updates the run assembly loop to break upon encountering a
non-monotonic change in the sort key.
PR 29259
bfd/
* elflink.c (elf_link_adjust_relocs): Ensure run being inserted
is sorted.
ld/
* testsuite/ld-elf/pr29259.d,
* testsuite/ld-elf/pr29259.s,
* testsuite/ld-elf/pr29259.t: New test.
Enze Li [Sun, 12 Jun 2022 05:22:25 +0000 (13:22 +0800)]
gdb: Add new 'print nibbles' feature
Make an introduction of a new print setting that can be set by 'set
print nibbles [on|off]'. The default value if OFF, which can be changed
by user manually. Of course, 'show print nibbles' is also included in
the patch.
The new feature displays binary values by group, with four bits per
group. The motivation for this work is to enhance the readability of
binary values.
Here's a GDB session before this patch is applied.
(gdb) print var_a
$1 = 1230
(gdb) print/t var_a
$2 = 10011001110
With this patch applied, we can use the new print setting to display the
new form of the binary values.
(gdb) print var_a
$1 = 1230
(gdb) print/t var_a
$2 = 10011001110
(gdb) set print nibbles on
(gdb) print/t var_a
$3 = 0100 1100 1110
Tiezhu Yang [Fri, 17 Jun 2022 08:51:05 +0000 (16:51 +0800)]
gdb: NEWS: Move LoongArch gdbserver to the correct section
commit e5ab6af52d38 ("gdbserver: Add LoongArch/Linux support")
was merged into the master since GDB 12, so we should put the
news in the "Changes since GDB 12" section.
Thanks Tom Tromey for your correction [1], sorry for that.
Alan Modra [Fri, 17 Jun 2022 07:55:53 +0000 (17:25 +0930)]
PR29256, memory leak in obj_elf_section_name
When handling section names in quotes obj_elf_section_name calls
demand_copy_C_string, which puts the name on the gas notes obstack.
Such strings aren't usually freed, since obstack_free frees all more
recently allocated objects as well as its arg. When handling
non-quoted names, obj_elf_section_name mallocs the name. Due to the
mix of allocation strategies it isn't possible for callers to free
names, if that was desirable. Partially fix this by always creating
names on the obstack, which is more efficient anyway. (You still
can't obstack_free on error paths due to the xtensa
tc_canonicalize_section_name.) Also remove a couple of cases where
the name is dup'd for no good reason as far as I know.
PR 29256
* config/obj-elf.c (obj_elf_section_name): Create name on notes
obstack.
(obj_elf_attach_to_group): Don't strdup group name.
(obj_elf_section): Likewise.
(obj_elf_vendor_attribute): Use xmemdup0 rather than xstrndup.
Pedro Alves [Fri, 17 Jun 2022 10:10:40 +0000 (11:10 +0100)]
Fix GDB build with GCC 4.8 & 4.9
With gcc 4.8/4.9, we run into this build failure (and other similar
ones):
/home/palves/gdb/binutils-gdb/src/gdb/location.h:224:59: error: could not convert ‘{0, LINE_OFFSET_UNKNOWN}’ from ‘<brace-enclosed initializer list>’ to ‘line_offset’
struct line_offset line_offset = {0, LINE_OFFSET_UNKNOWN};
^
The issue is that at around the GCC 4.8/4.9 era, a default member
initializer prevented the struct from being an aggregate, so you
cannot use aggregate initialization on them. That rule changed after
GCC 4.9 and GCC 5 & later uses new rules.
Fix this by not using aggregate initialization for struct line_offset.
The default member initization already leaves line_offset as {0,
LINE_OFFSET_UNKNOWN}, so initialization to those values can just go
away. The remaining cases are of the form {0, LINE_OFFSET_NONE}, and
those cases can be better rewritten to delay setting the sign field
until we know we have a valid offset.
Pedro Alves [Fri, 27 May 2022 15:53:49 +0000 (16:53 +0100)]
Convert set_location_spec_string to a method
This converts set_location_spec_string to a method of location_spec,
and makes the location_spec::as_string field protected, renaming it to
m_as_string along the way.
Pedro Alves [Fri, 27 May 2022 15:25:01 +0000 (16:25 +0100)]
Eliminate copy_location_spec
copy_location_spec is just a wrapper around location_spec::clone(), so
remove it and call clone() directly. This simplifies users, as they
no longer have to use std::unique_ptr::get().
This patch eliminates explicit_location and linespec_location,
inlining their members in the corresponding location_spec type.
The location_spec subclasses were the ones currently defined in
location.c, so they are moved to the header. Since the definitions of
the classes are now visible, we no longer need location_spec_deleter.
Some constructors that are used for cloning location_specs, like:
In the process, initialize_explicit_location is eliminated, and some
functions that returned the "data type behind a locspec", like
get_linespec_location are converted to downcast functions, like
as_linespec_location_spec.
Pedro Alves [Mon, 23 May 2022 19:15:18 +0000 (20:15 +0100)]
event_location -> location_spec
Currently, GDB internally uses the term "location" for both the
location specification the user input (linespec, explicit location, or
an address location), and for actual resolved locations, like the
breakpoint locations, or the result of decoding a location spec to
SaLs. This is expecially confusing in the breakpoints module, as
struct breakpoint has these two fields:
breakpoint::location;
breakpoint::loc;
"location" is the location spec, and "loc" is the resolved locations.
And then, we have a method called "locations()", which returns the
resolved locations as range...
The location spec type is presently called event_location:
/* Location we used to set the breakpoint. */
event_location_up location;
and it is described like this:
/* The base class for all an event locations used to set a stop event
in the inferior. */
struct event_location
{
and even that is incorrect... Location specs are used for finding
actual locations in the program in scenarios that have nothing to do
with stop events. E.g., "list" works with location specs.
To clean all this confusion up, this patch renames "event_location" to
"location_spec" throughout, and then all the variables that hold a
location spec, they are renamed to include "spec" in their name, like
e.g., "location" -> "locspec". Similarly, functions that work with
location specs, and currently have just "location" in their name are
renamed to include "spec" in their name too.
Tom de Vries [Thu, 16 Jun 2022 13:11:26 +0000 (15:11 +0200)]
[gdb/testsuite] Fix have_mpx test
When testing on openSUSE Leap 15.4 I ran into this FAIL:
...
FAIL: gdb.arch/i386-mpx-map.exp: NULL address of the pointer
...
and likewise for all the other mpx tests.
The problem is that have_mpx is supposed to return 0, but it doesn't because
it tries to match this output:
...
builtin_spawn -ignore SIGHUP temp/20294/have_mpx-2-20294.x^M
No MPX support^M
No MPX support^M
...
using:
...
&& ![string equal $output "No MPX support\r\n"]]
...
Alan Modra [Thu, 16 Jun 2022 06:50:05 +0000 (16:20 +0930)]
use of uninitialised value in input_file_open
Triggered by a file containing just "#N" or "#A". fgets when hitting
EOF before reading anything returns NULL and does not write to buf.
strchr (buf, '\n') then is reading from uninitialised memory.
* input-file.c (input_file_open): Don't assume buf contains
zero string terminator when fgets returns NULL.
Alan Modra [Thu, 16 Jun 2022 05:18:13 +0000 (14:48 +0930)]
Always free matching vector from bfd_check_format_matches
At least one place calling list_matching_formats failed to free the
"matching" vector from bfd_check_format_matches afterwards. Fix that
by calling free inside list_matching_formats.
Alan Modra [Wed, 15 Jun 2022 13:00:51 +0000 (22:30 +0930)]
PR29250, readelf erases CIE initial register state
PR 29250
binutils/
* dwarf.c (display_debug_frames): Set col_type[reg] on sizing
pass over FDE to cie->col_type[reg] if CIE specifies reg.
Handle DW_CFA_restore and DW_CFA_restore_extended on second
pass using the same logic. Remove unnecessary casts. Don't
call frame_need_space on second pass over FDE.
gas/
* testsuite/gas/i386/ehinterp.d,
* testsuite/gas/i386/ehinterp.s: New test.
* testsuite/gas/i386/i386.exp: Run it.
sim: fix BFD_VMA format arguments on 32-bit hosts [PR gdb/29184]
Noticed format mismatch when attempted to build gdb on i686-linux-gnu
in --enable-64-bit-bfd mode:
sim/../../sim/cris/sim-if.c:576:28:
error: format '%lx' expects argument of type 'long unsigned int',
but argument 4 has type 'bfd_size_type' {aka 'long long unsigned int'} [-Werror=format=]
576 | sim_do_commandf (sd, "memory region 0x%" BFD_VMA_FMT "x,0x%lx",
| ^~~~~~~~~~~~~~~~~~~
577 | interp_load_addr, interpsiz);
| ~~~~~~~~~
| |
| bfd_size_type {aka long long unsigned int}
While at it fixed format string for time-related types.
Tom Tromey [Fri, 3 Jun 2022 16:39:11 +0000 (10:39 -0600)]
Check for listeners in emit_exiting_event
I noticed that emit_exiting_event does not check whether there are any
listeners before creating the event object. All other event emitters
do this, so this patch updates this one as well.
Tom Tromey [Sat, 19 Feb 2022 16:33:12 +0000 (09:33 -0700)]
Add to documentation of Python 'dont_repeat' method
PR python/28533 points out that the Python 'dont_repeat' documentation
is a bit ambiguous about when the method ought to be called. This
patch spells it out.
Yvan Roux [Wed, 15 Jun 2022 14:07:22 +0000 (16:07 +0200)]
gdb/arm: Make sp alias for one of the other stack pointers
For Cortex-M targets, SP register is never detached from msp or
psp, it always has the same value as one of them. Let GDB treat
ARM_SP_REGNUM as an alias similar to what is done in hardware.
Yvan Roux [Wed, 15 Jun 2022 14:01:46 +0000 (16:01 +0200)]
gdb/arm: Track msp and psp
For Arm Cortex-M33 with security extensions, there are 4 different
stack pointers (msp_s, msp_ns, psp_s, psp_ns). To be compatible
with earlier Cortex-M derivates, the msp and psp registers are
aliases for one of the 4 real stack pointer registers.
These are the combinations that exist:
sp -> msp -> msp_s
sp -> msp -> msp_ns
sp -> psp -> psp_s
sp -> psp -> psp_ns
This means that when the GDB client is to show the value of "msp",
the value should always be equal to either "msp_s" or "msp_ns".
Same goes for "psp".
To add a bit more context; GDB does not really use the register msp
(or psp) internally, but they are part of the set of registers which
are provided by the target.xml file. As a result, they will be part
of the set of registers printed by the "info r" command.
Without this particular patch, GDB will hit the assert in the bottom
of arm_cache_get_sp_register function.
Yvan Roux [Wed, 15 Jun 2022 14:00:34 +0000 (16:00 +0200)]
gdb/arm: Fetch initial sp value prior to compare
For Arm Cortex-M33 with security extensions, there are 4 different
stack pointers (msp_s, msp_ns, psp_s, psp_ns). In order to
identify the active one, compare the values of the different
stacks. The value of the initial sp register needs to be fetched to
perform this comparison.
Andrew Burgess [Mon, 4 Apr 2022 21:52:58 +0000 (22:52 +0100)]
gdb: unify two dis_asm_read_memory functions in disasm.c
After the recent restructuring of the disassembler code, GDB has ended
up with two identical class static functions, both called
dis_asm_read_memory, with identical implementations.
My first thought was to move these out of their respective classes,
and just make them global functions, then I'd only need a single
copy.
And maybe that's the right way to go. But I disliked that by doing
that I loose the encapsulation of the method with the corresponding
disassembler class.
So, instead, I placed the static method into its own class, and had
both the gdb_non_printing_memory_disassembler and gdb_disassembler
classes inherit from this new class as an additional base-class.
In terms of code generated, I don't think there's any significant
difference with this approach, but I think this better reflects how
the function is closely tied to the disassembler.
There should be no user visible changes after this commit.
Andrew Burgess [Mon, 4 Apr 2022 14:48:19 +0000 (15:48 +0100)]
gdb: refactor the non-printing disassemblers
This commit started from an observation I made while working on some
other disassembler patches, that is, that the function
gdb_buffered_insn_length, is broken ... sort of.
I noticed that the gdb_buffered_insn_length function doesn't set up
the application data field if the disassemble_info structure.
Further, I noticed that some architectures, for example, ARM, require
that the application_data field be set, see gdb_print_insn_arm in
arm-tdep.c.
And so, if we ever use gdb_buffered_insn_length for ARM, then GDB will
likely crash. Which is why I said only "sort of" broken. Right now
we don't use gdb_buffered_insn_length with ARM, so maybe it isn't
broken yet?
Anyway to prove to myself that there was a problem here I extended the
disassembler self tests in disasm-selftests.c to include a test of
gdb_buffered_insn_length. As I run the test for all architectures, I
do indeed see GDB crash for ARM.
To fix this we need gdb_buffered_insn_length to create a disassembler
that inherits from gdb_disassemble_info, but we also need this new
disassembler to not print anything.
And so, I introduce a new gdb_non_printing_disassembler class, this is
a disassembler that doesn't print anything to the output stream.
I then observed that both ARC and S12Z also create non-printing
disassemblers, but these are slightly different. While the
disassembler in gdb_non_printing_disassembler reads the instruction
from a buffer, the ARC and S12Z disassemblers read from target memory
using target_read_code.
And so, I further split gdb_non_printing_disassembler into two
sub-classes, gdb_non_printing_memory_disassembler and
gdb_non_printing_buffer_disassembler.
The new selftests now pass, but otherwise, there should be no user
visible changes after this commit.
Andrew Burgess [Fri, 17 Sep 2021 17:12:34 +0000 (18:12 +0100)]
gdb/python: implement the print_insn extension language hook
This commit extends the Python API to include disassembler support.
The motivation for this commit was to provide an API by which the user
could write Python scripts that would augment the output of the
disassembler.
To achieve this I have followed the model of the existing libopcodes
disassembler, that is, instructions are disassembled one by one. This
does restrict the type of things that it is possible to do from a
Python script, i.e. all additional output has to fit on a single line,
but this was all I needed, and creating something more complex would,
I think, require greater changes to how GDB's internal disassembler
operates.
The disassembler API is contained in the new gdb.disassembler module,
which defines the following classes:
DisassembleInfo
Similar to libopcodes disassemble_info structure, has read-only
properties: address, architecture, and progspace. And has methods:
__init__, read_memory, and is_valid.
Each time GDB wants an instruction disassembled, an instance of
this class is passed to a user written disassembler function, by
reading the properties, and calling the methods (and other support
methods in the gdb.disassembler module) the user can perform and
return the disassembly.
Disassembler
This is a base-class which user written disassemblers should
inherit from. This base class provides base implementations of
__init__ and __call__ which the user written disassembler should
override.
DisassemblerResult
This class can be used to hold the result of a call to the
disassembler, it's really just a wrapper around a string (the text
of the disassembled instruction) and a length (in bytes). The user
can return an instance of this class from Disassembler.__call__ to
represent the newly disassembled instruction.
The gdb.disassembler module also provides the following functions:
register_disassembler
This function registers an instance of a Disassembler sub-class
as a disassembler, either for one specific architecture, or, as a
global disassembler for all architectures.
builtin_disassemble
This provides access to GDB's builtin disassembler. A common
use case that I see is augmenting the existing disassembler output.
The user code can call this function to have GDB disassemble the
instruction in the normal way. The user gets back a
DisassemblerResult object, which they can then read in order to
augment the disassembler output in any way they wish.
This function also provides a mechanism to intercept the
disassemblers reads of memory, thus the user can adjust what GDB
sees when it is disassembling.
The included documentation provides a more detailed description of the
API.
There is also a new CLI command added:
maint info python-disassemblers
This command is defined in the Python gdb.disassemblers module, and
can be used to list the currently registered Python disassemblers.
Andrew Burgess [Fri, 17 Sep 2021 17:11:40 +0000 (18:11 +0100)]
gdb: add extension language print_insn hook
This commit is setup for the next commit.
In the next commit I will add a Python API to intercept the print_insn
calls within GDB, each print_insn call is responsible for
disassembling, and printing one instruction. After the next commit it
will be possible for a user to write Python code that either wraps
around the existing disassembler, or even, in extreme situations,
entirely replaces the existing disassembler.
This commit does not add any new Python API.
What this commit does is put the extension language framework in place
for a print_insn hook. There's a new callback added to 'struct
extension_language_ops', which is then filled in with nullptr for Python
and Guile.
Finally, in the disassembler, the code is restructured so that the new
extension language function ext_lang_print_insn is called before we
delegate to gdbarch_print_insn.
After this, the next commit can focus entirely on providing a Python
implementation of the new print_insn callback.
There should be no user visible change after this commit.
Andrew Burgess [Wed, 27 Oct 2021 09:07:56 +0000 (10:07 +0100)]
gdb: add new base class to gdb_disassembler
The motivation for this change is an upcoming Python disassembler API
that I would like to add. As part of that change I need to create a
new disassembler like class that contains a disassemble_info and a
gdbarch. The management of these two objects is identical to how we
manage these objects within gdb_disassembler, so it might be tempting
for my new class to inherit from gdb_disassembler.
The problem however, is that gdb_disassembler has a tight connection
between its constructor, and its print_insn method. In the
constructor the ui_file* that is passed in is replaced with a member
variable string_file*, and then in print_insn, the contents of the
member variable string_file are printed to the original ui_file*.
What this means is that the gdb_disassembler class has a tight
coupling between its constructor and print_insn; the class just isn't
intended to be used in a situation where print_insn is not going to be
called, which is how my (upcoming) sub-class would need to operate.
My solution then, is to separate out the management of the
disassemble_info and gdbarch into a new gdb_disassemble_info class,
and make this class a parent of gdb_disassembler.
In arm-tdep.c and mips-tdep.c, where we used to cast the
disassemble_info->application_data to a gdb_disassembler, we can now
cast to a gdb_disassemble_info as we only need to access the gdbarch
information.
Now, my new Python disassembler sub-class will still want to print
things to an output stream, and so we will want access to the
dis_asm_fprintf functionality for printing.
However, rather than move this printing code into the
gdb_disassemble_info base class, I have added yet another level of
hierarchy, a gdb_printing_disassembler, thus the class structure is
now:
struct gdb_disassemble_info {};
struct gdb_printing_disassembler : public gdb_disassemble_info {};
struct gdb_disassembler : public gdb_printing_disassembler {};
In a later commit my new Python disassembler will inherit from
gdb_printing_disassembler.
The reason for adding the additional layer to the class hierarchy is
that in yet another commit I intend to rewrite the function
gdb_buffered_insn_length, and to do this I will be creating yet more
disassembler like classes, however, these will not print anything,
thus I will add a gdb_non_printing_disassembler class that also
inherits from gdb_disassemble_info. Knowing that that change is
coming, I've gone with the above class hierarchy now.
There should be no user visible changes after this commit.
Andrew Burgess [Tue, 24 May 2022 10:54:40 +0000 (11:54 +0100)]
gdb/python: convert gdbpy_err_fetch to use gdbpy_ref
Convert the gdbpy_err_fetch class to make use of gdbpy_ref, this
removes the need for manual reference count management, and allows the
destructor to be removed.
There should be no functional change after this commit.
I think this cleanup is worth doing on its own, however, in a later
commit I will want to copy instances of gdbpy_err_fetch, and switching
to using gdbpy_ref means that I can rely on the default copy
constructor, without having to add one that handles the reference
counts, so this is good preparation for that upcoming change.
Tom de Vries [Wed, 15 Jun 2022 07:03:03 +0000 (09:03 +0200)]
[gdb/build] Fix build for gcc < 11
When building trunk on openSUSE Leap 15.3 with system gcc 7.5.0, I run into:
...
In file included from ../bfd/bfd.h:46:0,
from gdb/defs.h:37,
from gdb/debuginfod-support.c:19:
gdb/debuginfod-support.c: In function ‘bool debuginfod_is_enabled()’:
gdb/../include/diagnostics.h:42:3: error: unknown option after \
‘#pragma GCC diagnostic’ kind [-Werror=pragmas]
_Pragma (DIAGNOSTIC_STRINGIFY (GCC diagnostic ignored option))
^
gdb/../include/diagnostics.h:80:3: note: in expansion of macro \
‘DIAGNOSTIC_IGNORE’
DIAGNOSTIC_IGNORE ("-Wstringop-overread")
^~~~~~~~~~~~~~~~~
gdb/debuginfod-support.c:201:4: note: in expansion of macro \
‘DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD’
DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD
^
...
The problem is that the warning -Wstringop-overread has been introduced for
gcc 11, and we can only tell gcc to ignore if it knows about it.
Fix this by guarding the DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD definition in
diagnostics.c with '#if __GNUC__ >= 11'.
Alan Modra [Tue, 14 Jun 2022 03:16:42 +0000 (12:46 +0930)]
PR29230, segv in lookup_symbol_in_variable_table
The PR23230 testcase uses indexed strings without specifying
SW_AT_str_offsets_base. In this case we left u.str with garbage (from
u.val) which then led to a segfault when attempting to access the
string. Fix that by clearing u.str. The patch also adds missing
sanity checks in the recently committed read_indexed_address and
read_indexed_string functions.
PR 29230
* dwarf2.c (read_indexed_address): Return uint64_t. Sanity check idx.
(read_indexed_string): Use uint64_t for str_offset. Sanity check idx.
(read_attribute_value): Clear u.str for indexed string forms when
DW_AT_str_offsets_base is not yet read or missing.
projects / thirdparty / binutils-gdb.git / log
