The disassemble_info structure has four callbacks, we have three of
them as static member functions within gdb_disassembler, the fourth is
just a global static function.
However, this fourth callback, is still only used from the
disassemble_info struct, so there's no real reason for its special
handling.
This commit makes fprintf_disasm a static method within
gdb_disassembler.
There should be no user visible changes after this commit.
Consider the the pcgp-relax-02 testcase,
.text
.globl _start
_start:
.L1: auipc a0, %pcrel_hi(data_a)
.L2: auipc a1, %pcrel_hi(data_b)
addi a0, a0, %pcrel_lo(.L1)
addi a1, a1, %pcrel_lo(.L2)
.data
.word 0x0
.globl data_a
data_a:
.word 0x1
.section .rodata
.globl data_b
data_b:
.word 0x2
If the first auipc is deleted, but we are still building the pcgp
table (connect the high and low pcrel relocations), then there is
an aliasing issue that we need some way to disambiguate which of
the two symbols we are targeting. Therefore, Palmer thought of a
way to use R_RISCV_DELETE to split this into two phases, so we
could resolve the addresses before creating the ambiguities.
This patch just add the ld testcase for the above case, in case we
have changed something but break this.
ld/
* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Renamed pcgp-relax
to pcgp-relax-01, and added pcgp-relax-02.
* testsuite/ld-riscv-elf/pcgp-relax-01.d: Renmaed from pcgp-relax.
* testsuite/ld-riscv-elf/pcgp-relax-01.s: Likewise.
* testsuite/ld-riscv-elf/pcgp-relax-02.d: New testcase.
* testsuite/ld-riscv-elf/pcgp-relax-02.s: Likewise.
Commit abd20cb637 and
ebdcad3fdd introduced additional
complexity into the paths run by the RISC-V relaxation pass in order to
resolve the issue of accurately keeping track of pcrel_hi and pcrel_lo
pairs. The first commit split up relaxation of these relocs into a pass
which occurred after other relaxations in order to prevent the situation
where bytes were deleted in between a pcrel_lo/pcrel_hi pair, inhibiting
our ability to find the corresponding pcrel_hi relocation from the
address attached to the pcrel_lo.
Since the relaxation was split into two passes the 'again' parameter
could not be used to perform the entire relaxation process again and so
the second commit added a way to restart ldelf_map_segments, thus
starting the whole process again.
Unfortunately this process could not account for the fact that we were
not finished with the relaxation process so in some cases - such as the
case where code would not fit in a memory region before the
R_RISCV_ALIGN relocation was relaxed - sanity checks in generic code
would fail.
This patch fixes all three of these concerns by reverting back to a
system of having only one target relax pass but updating entries in the
table of pcrel_hi/pcrel_lo relocs every time any bytes are deleted. Thus
we can keep track of the pairs accurately, and we can use the 'again'
parameter to restart the entire target relax pass, behaving in the way
that generic code expects. Unfortunately we must still have an
additional pass to delay deleting AUIPC bytes to avoid ambiguity between
pcrel_hi relocs stored in the table after deletion. This pass can only
be run once so we may potentially miss out on relaxation opportunities
but this is likely to be rare.
https://sourceware.org/bugzilla/show_bug.cgi?id=28410
bfd/
* elfnn-riscv.c (riscv_elf_link_hash_table): Removed restart_relax.
(riscv_elf_link_hash_table_create): Updated.
(riscv_relax_delete_bytes): Moved after the riscv_update_pcgp_relocs.
Update the pcgp_relocs table whenever bytes are deleted.
(riscv_update_pcgp_relocs): Add function to update the section
offset of pcrel_hi and pcrel_lo, and also update the symbol value
of pcrel_hi.
(_bfd_riscv_relax_call): Need to update the pcgp_relocs table
when deleting codes.
(_bfd_riscv_relax_lui): Likewise.
(_bfd_riscv_relax_tls_le): Likewise.
(_bfd_riscv_relax_align): Once we've handled an R_RISCV_ALIGN,
we can't relax anything else, so set the sec->sec_flg0 to true.
Besides, we don't need to update the pcgp_relocs table at this
stage, so just pass NULL pointer as the pcgp_relocs table for
riscv_relax_delete_bytes.
(_bfd_riscv_relax_section): Use only one pass for all target
relaxations.
(_bfd_riscv_relax_delete): Likewise, we don't need to update
the pcgp_relocs table at this stage, and don't need to set
the `again' since restart_relax mechanism is abandoned.
(bfd_elfNN_riscv_restart_relax_sections): Removed.
(_bfd_riscv_relax_section): Updated.
* elfxx-riscv.h (bfd_elf32_riscv_restart_relax_sections): Removed.
(bfd_elf64_riscv_restart_relax_sections): Likewise.
ld/
* emultempl/riscvelf.em: Revert restart_relax changes and set
relax_pass to 3.
* testsuite/ld-riscv-elf/align-small-region.d: New testcase.
* testsuite/ld-riscv-elf/align-small-region.ld: Likewise.
* testsuite/ld-riscv-elf/align-small-region.s: Likewise.
* testsuite/ld-riscv-elf/restart-relax.d: Removed sine the
restart_relax mechanism is abandoned.
* testsuite/ld-riscv-elf/restart-relax.s: Likewise.
* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
Commit 183be22290 ("gdb, gdbserver: make target_waitstatus safe")
broke the remote-sim.c build. In fact, it does some wrong changes,
result of a bad sed invocation.
Fix it by adjusting the code to the new target_waitstatus API.
Change-Id: I3236ff7ef7681fc29215f68be210ff4263760e91
I stumbled on a bug caused by the fact that a code path read
target_waitstatus::value::sig (expecting it to contain a gdb_signal
value) while target_waitstatus::kind was TARGET_WAITKIND_FORKED. This
meant that the active union field was in fact
target_waitstatus::value::related_pid, and contained a ptid. The read
signal value was therefore garbage, and that caused GDB to crash soon
after. Or, since that GDB was built with ubsan, this nice error
message:
/home/simark/src/binutils-gdb/gdb/linux-nat.c:1271:12: runtime error: load of value 2686365, which is not a valid value for type 'gdb_signal'
Despite being a large-ish change, I think it would be nice to make
target_waitstatus safe against that kind of bug. As already done
elsewhere (e.g. dynamic_prop), validate that the type of value read from
the union matches what is supposed to be the active field.
- Make the kind and value of target_waitstatus private.
- Make the kind initialized to TARGET_WAITKIND_IGNORE on
target_waitstatus construction. This is what most users appear to do
explicitly.
- Add setters, one for each kind. Each setter takes as a parameter the
data associated to that kind, if any. This makes it impossible to
forget to attach the associated data.
- Add getters, one for each associated data type. Each getter
validates that the data type fetched by the user matches the wait
status kind.
- Change "integer" to "exit_status", "related_pid" to "child_ptid",
just because that's more precise terminology.
- Fix all users.
That last point is semi-mechanical. There are a lot of obvious changes,
but some less obvious ones. For example, it's not possible to set the
kind at some point and the associated data later, as some users did.
But in any case, the intent of the code should not change in this patch.
This was tested on x86-64 Linux (unix, native-gdbserver and
native-extended-gdbserver boards). It was built-tested on x86-64
FreeBSD, NetBSD, MinGW and macOS. The rest of the changes to native
files was done as a best effort. If I forgot any place to update in
these files, it should be easy to fix (unless the change happens to
reveal an actual bug).
Change-Id: I0ae967df1ff6e28de78abbe3ac9b4b2ff4ad03b7
Add a constructor to initialize the waitstatus members. Initialize the
others in the class directly.
Change-Id: I10f885eb33adfae86e3c97b1e135335b540d7442
Add a constructor and a destructor. The constructor takes care of the
initialization that happened in add_thread, while the destructor takes
care of the freeing that happened in free_one_thread. This is needed to
make target_waitstatus non-POD, as thread_info contains a member of that
type.
Change-Id: I1db321b4de9dd233ede0d5c101950f1d6f1d13b7
Since the two locations which check the debug arch are the same code currently, it is
a good idea to factor it out to a new function and just use that function from
aarch64_linux_get_debug_reg_capacity. This is also the first step to support
ARMv8.4 debug arch.
In commit 81e6b8eb20 "Make tui-winsource not use breakpoint_chain", a loop
body was transformed into a lambda function body:
...
- for (bp = breakpoint_chain;
- bp != NULL;
- bp = bp->next)
+ iterate_over_breakpoints ([&] (breakpoint *bp) -> bool
...
and consequently:
- a continue was replaced by a return, and
- a final return was added.
Then in commit 240edef62f "gdb: remove iterate_over_breakpoints function", we
transformed back to a loop body:
...
- iterate_over_breakpoints ([&] (breakpoint *bp) -> bool
+ for (breakpoint *bp : all_breakpoints ())
...
but without reverting the changes that introduced the two returns.
Consequently, breakpoints no longer show up in the tui source window.
Fix this by reverting the changes that introduced the two returns.
Build on x86_64-linux, tested with all .exp test-cases that contain
tuiterm_env.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28483
The test expect the runto_main to stop at the first line of the function.
Depending on the optimization level, gdb may stop in the prolog or after
the prolog at the first line. To ensure the test stops at the first line
of main, have it explicitly stop at a break point on the first line of the
function.
On PowerPC, the test passes when compiled with no optimization but fails
with all levels of optimization due to gdb stopping in the prolog.
The "add accessors for field (and call site) location" patch caused a
gdb crash when running the internal AdaCore testsuite. This turned
out to be a latent bug in ada-lang.c.
The immediate cause of the bug is that find_struct_field
unconditionally uses TYPE_FIELD_BITPOS. This causes an assert for a
dynamic type.
This patch fixes the problem by doing two things. First, it changes
find_struct_field to use a dummy value for the field offset in the
situation where the offset is not actually needed by the caller. This
works because the offset isn't used in any other way -- only as a
result.
Second, this patch assures that calls to find_struct_field use a
resolved type when the offset is needed. For
value_tag_from_contents_and_address, this is done by resolving the
type explicitly. In ada_value_struct_elt, this is done by passing
nullptr for the out parameters when they are not needed (the second
call in this function already uses a resolved type).
Note that, while we believe the parent field probably can't occur at a
variable offset, the patch still updates this code path, just in case.
I've updated an existing test case to reproduce the crash.
I'm checking this in.
ldelf.c: In function 'ldelf_after_open':
ldelf.c:1049:43: warning: the comparison will always evaluate as 'true' for the address of 'elf_header' will never be NULL [-Waddress]
1049 | && elf_tdata (abfd)->elf_header != NULL
| ^~
In file included from ldelf.c:37:
../bfd/elf-bfd.h:1957:21: note: 'elf_header' declared here
1957 | Elf_Internal_Ehdr elf_header[1]; /* Actual data, but ref like ptr */
* ldelf.c (ldelf_after_open): Remove useless elf_header test.
Mainline gcc:
readelf.c: In function 'find_section':
readelf.c:349:8: error: the comparison will always evaluate as 'true' for the pointer operand in 'filedata->section_headers + (sizetype)((long unsigned int)i * 80)' must not be NULL [-Werror=address]
349 | ((X) != NULL \
| ^~
readelf.c:761:9: note: in expansion of macro 'SECTION_NAME_VALID'
761 | if (SECTION_NAME_VALID (filedata->section_headers + i)
| ^~~~~~~~~~~~~~~~~~
This will likely be fixed in gcc, but inline functions are nicer than
macros.
* readelf.c (SECTION_NAME, SECTION_NAME_VALID),
(SECTION_NAME_PRINT, VALID_SYMBOL_NAME, VALID_DYNAMIC_NAME),
(GET_DYNAMIC_NAME): Delete. Replace with..
(section_name, section_name_valid, section_name_print),
(valid_symbol_name, valid_dynamic_name, get_dynamic_name): ..these
new inline functions. Update use throughout file.
My previous PR27625 patch had a problem or two. For one, the error
"__tls_get_addr call lacks marker reloc" on processing some calls
before hitting a call without markers typically isn't seen. Instead a
gold assertion fails. Either way it would be a hard error, which
triggers on a file contained in libphobos.a when running the gcc
testsuite. A warning isn't even appropriate since the call involved
is one built by hand without any of the arg setup relocations that
might result in linker optimisation.
So this patch reverts most of commit 0af4fcc25d, instead entirely
ignoring the problem of mis-optimising old-style __tls_get_addr calls
without marker relocs. We can't handle them gracefully without
another pass over relocations before decisions are made about GOT
entries in Scan::global or Scan::local. That seems too costly, just
to link object files from 2009. What's more, there doesn't seem to be
any way to allow the libphobos explicit __tls_get_addr call, but not
old TLS sequences without marker relocs. Examining instructions
before the __tls_get_addr call is out of the question: program flow
might reach the call via a branch. Putting an R_PPC64_TLSGD marker
with zero sym on the call might be a solution, but current linkers
will then merrily optimise away the call!
PR gold/27625
* powerpc.cc (Powerpc_relobj): Delete no_tls_marker_, tls_marker_,
and tls_opt_error_ variables and accessors. Remove all uses.
When using Bison 3.8, we get this error:
../../gdb/c-exp.y:3455:1: error: 'void c_print_token(FILE*, int, YYSTYPE)' defined but not used [-Werror=unused-function]
That's because bison 3.8 removed YYPRINT support:
https://savannah.gnu.org/forum/forum.php?forum_id=10047
Accordingly, this patch only defines that function for Bison < 3.8.
Change-Id: I3cbf2f317630bb72810b00f2d9b2c4b99fa812ad
The test-case gdb.gdb/python-interrupts.exp:
- runs to captured_command_loop
- sets a breakpoint at set_active_ext_lang
- calls a python command
- verifies the command triggers the breakpoint
- sends a signal and verifies the result
The test-case is fragile, because (f.i. with -flto) it cannot be guaranteed
that captured_command_loop and set_active_ext_lang are available for setting
breakpoints.
Reimplement the test-case as unittest, using:
- execute_command_to_string to capture the output
- try/catch to catch the "Error while executing Python code" exception
- a new hook selftests::hook_set_active_ext_lang to raise the signal
Tested on x86_64-linux.
This changes gdb to check the index that is passed to type::field.
This caught one bug in the Ada code when running the test suite
(actually I found the bug first, then realized that the check would
have helped), so this patch fixes that as well.
Regression tested on x86-64 Fedora 34.
The Rust lex selftest fails on our Windows build. I tracked this down
to a use of UTF-32 as a parameter to convert_between_encodings. Here,
iconv_open succeeds, but the actual conversion of a tab character
fails with EILSEQ. I suspect that "UTF-32" is being interpreted as
big-endian, as changing the call to use "UTF-32LE" makes it work.
This patch implements this fix.
The format_pieces selftest currently fails on Windows hosts.
The selftest doesn't handle the "%ll" -> "%I64" rewrite that the
formatter may perform, but also gdbsupport was missing a configure
check for PRINTF_HAS_LONG_LONG. This patch fixes both issues.
A customer-reported problem led us to a bug in dynamic type
resolution. resolve_dynamic_struct will recursively call
resolve_dynamic_type_internal, passing it the sub-object for the
particular field being resolved. While it offsets the address here,
it does not also offset the "valaddr" -- the array of bytes describing
the memory.
This patch fixes the bug, by offsetting both. A test case is included
that can be used to reproduce the bug.
Now that there is a register_test variant that accepts std::function,
it seems to me that the 'selftest' struct and accompanying code is
obsolete -- simply always using std::function is simpler. This patch
implements this idea.
GDB doesn't support loading debug files using build-id from remote
target filesystems.
This is the case when gdbserver attached to a process and a gdb target
remote occurs over tcp.
With this change we make build-id lookups possible:
(gdb) show debug-file-directory
The directory where separate debug symbols are searched for is "/usr/local/lib/debug".
(gdb) set debug-file-directory /usr/lib/debug
(gdb) show sysroot
The current system root is "target:".
(gdb) target extended-remote :46615
Remote debugging using :46615
warning: Can not parse XML target description; XML support was disabled at compile time
Reading /usr/sbin/mariadbd from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading /usr/sbin/mariadbd from remote target...
Reading symbols from target:/usr/sbin/mariadbd...
Reading /usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
Reading /usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
Reading symbols from target:/usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug...
Reading /lib/x86_64-linux-gnu/libpcre2-8.so.0 from remote target...
...
Before this change, the lookups would have been (GNU gdb (GDB) Fedora 10.2-3.fc34):
(gdb) target extended-remote :46615
Remote debugging using :46615
Reading /usr/sbin/mariadbd from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading /usr/sbin/mariadbd from remote target...
Reading symbols from target:/usr/sbin/mariadbd...
Reading /usr/sbin/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
Reading /usr/sbin/.debug/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
Reading /usr/lib/debug//usr/sbin/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
Reading /usr/lib/debug/usr/sbin//0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
Reading target:/usr/lib/debug/usr/sbin//0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
Missing separate debuginfo for target:/usr/sbin/mariadbd
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug
(No debugging symbols found in target:/usr/sbin/mariadbd)
Observe it didn't look for
/usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug
on the remote target (where it is) and expected them to be installed
locally.
As a minor optimization, this also changes the build-id lookup such that
if sysroot is empty, no second lookup of the same location is performed.
Change-Id: I5181696d271c325a25a0805a8defb8ab7f9b3f55
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17917
bfd * linker.c (_bfd_generic_link_add_one_symbol): Test for a NULL
name before checking to see if the symbol is __gnu_lto_slim.
* archive.c (_bfd_compute_and_write_armap): Likewise.
binutils
* nm.c (filter_symbols): Test for a NULL name before checking to
see if the symbol is __gnu_lto_slim.
* objcopy.c (filter_symbols): Likewise.
A bug was filed against the incorrect underlying type setting for
an enumeration type, which was caused by a copy and paste error.
This patch fixes the problem by setting it by calling objfile_int_type,
which was originally dwarf2_per_objfile::int_type, with ctf_type_size bits.
Also add error checking on ctf_func_type_info call.
I'd missed the fact that the .debug_rnglists dump doesn't exactly
display the contents of the section. Instead readelf rummages through
.debug_info looking for DW_AT_ranges entries, then displays the
entries in .debug_rnglists pointed at, sorted. A simpler dump of the
actual section contents might be more useful and robust, but it was
likely done that way to detect overlap and holes.
Anyway, the headers in .debug_rnglists besides the first are ignored,
and limiting to the unit length of the first header fails if there is
more than one unit.
PR 28459
* dwarf.c (display_debug_ranges): Don't constrain data to length
in header.
Adjust pr28158.rd for glibc 2.34:
$ readelf -W --dyn-syms tmpdir/pr28158
Symbol table '.dynsym' contains 4 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __libc_start_main@GLIBC_2.34 (2)
2: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
3: 000000000040401c 4 OBJECT GLOBAL DEFAULT 23 foo@VERS_2.0 (3)
$
vs older glibc:
$ readelf -W --dyn-syms tmpdir/pr28158
Symbol table '.dynsym' contains 4 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __libc_start_main@GLIBC_2.2.5 (3)
2: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
3: 000000000040401c 4 OBJECT GLOBAL DEFAULT 23 foo@VERS_2.0 (2)
$
* testsuite/ld-elf/pr28158.rd: Adjusted for glibc 2.34.
Add .debug_loc support in the dwarf assembler, and use it in new test-case
gdb.dwarf2/loc-sec-offset.exp (which is based on
gdb.dwarf2/loclists-sec-offset.exp).
Tested on x86_64-linux.
We can't get at section->address() until everything is laid out, so
trying to generalise the offset calculation rather than using a value
of 0x8000 (the old object->toc_base_offset()) was bound to fail.
got->g_o_t() is a little better than a hard-coded 0x8000.
* powerpc.cc (Target_powerpc::Scan::local, global): Don't use
toc_pointer() here.
Split .got into two piece, one with the header and entries for small
model got entries, the other with entries for medium/large model got
entries. The idea is to better support mixed pcrel/non-pcrel code
where non-pcrel small-model .toc entries need to be within 32k of the
toc pointer.
* target.h (Target::tls_offset_for_local): Add got param.
(Target::tls_offset_for_global): Likewise.
(Target::do_tls_offset_for_local, do_tls_offset_for_global): Likewise.
* output.h (Output_data_got::Got_entry::write): Add got param.
* output.cc (Output_data_got::Got_entry::write): Likewise, pass to
tls_offset_for_local/global calls.
(Output_data_got::do_write): Adjust to suit.
* s390.cc (Target_s390::do_tls_offset_for_local): Likewise.
(Target_s390::do_tls_offset_for_global): Likewise.
* powerpc.cc (enum Got_type): Extend with small types, move from
class Target_powerpc.
(Target_powerpc::biggot_): New.
(Traget_powerpc::do_tls_offset_for_local, do_tls_offset_for_global,
got_size, got_section, got_base_offset): Handle biggot_.
(Target_powerpc::do_define_standard_symbols): Adjust.
(Target_powerpc::make_plt_section, do_finalize_sections): Likewise.
(Output_data_got_powerpc::Output_data_got_powerpc): Only make
64-bit header for small got section.
(Output_data_got_powerpc::g_o_t): Only return a result for small
got section.
(Output_data_got_powerpc::write): Only write small got section
header.
(Target_powerpc::Scan::local, global): Select small/big Got_type
and section to suit reloc.
(Target_powerpc::Relocate::relocate): Similarly.
(Sort_toc_sections): Rewrite.
Code in powerpc.cc is pretending to support a per-object toc pointer
value, but powerpc gold has no real support for multi-toc. This patch
removes the pretense, tidying quite a lot in preparation for a
followup patch. If multi-toc is ever to be supported, don't revert
this patch but start by adding object parameter to toc_pointer() and
an object to Branch_stub_key.
* powerpc.cc (Powerpc_relobj::toc_base_offset): Delete.
(Target_powerpc::toc_pointer): New function. Use throughout.
(Target_powerpc::got_base_offset): New function. Use throughout..
(Output_data_got_powerpc::got_base_offset): ..in place of
this. Delete.
(Output_data_got_powerpc::Output_data_got_powerpc): Init
header_index_ to -1u for 64-bit, and make header here.
(Output_data_got_powerpc::set_final_data_size, reserve_ent): Don't
make 64-bit header here.
(Output_data_got_powerpc::g_o_t): Return toc pointer offset in
section for 64-bit. Use throughout.
(Stub_table): Remove toc_base_off_ from Branch_stub_key, and
object param on add_long_branch_entry and find_long_branch_entry.
Adjust all uses.
