aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-10-21gdb, gdbserver: make target_waitstatus safeSimon Marchi44-705/+826
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
2021-10-21gdbserver: initialize the members of lwp_info in-classSimon Marchi2-29/+31
Add a constructor to initialize the waitstatus members. Initialize the others in the class directly. Change-Id: I10f885eb33adfae86e3c97b1e135335b540d7442
2021-10-21gdbserver: make thread_info non-PODSimon Marchi2-14/+18
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
2021-10-21Fix ARMv8.4 for hw watchpoint and breakpointAndrew Pinski2-0/+3
Just like my previoius patch for ARMv8.1 and v8.2 (49ecef2a7da2ee9df4), this adds ARMv8.4 debug arch as being compatible for hw watchpoint and breakpoints.
2021-10-21Refactor code slightly in nat/aarch64-linux-hw-point.c ↵Andrew Pinski1-6/+18
(aarch64_linux_get_debug_reg_capacity) 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.
2021-10-21Fixes for gdb.mi/mi-break.expCarl Love1-4/+4
Update the expected pattern for two of the tests. Matching pattern \" doesn't work. Use .* to match the \* pattern.
2021-10-21[gdb/tui] Fix breakpoint display functionalityTom de Vries2-2/+38
In commit 81e6b8eb208 "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 240edef62f0 "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
2021-10-21Fix test step-and-next-inline.ccCarl Love2-2/+4
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.
2021-10-21Fix latent Ada bug when accessing field offsetsTom Tromey3-43/+75
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.
2021-10-21-Waddress warning in ldelf.cAlan Modra1-1/+0
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.
2021-10-21Avoid -Waddress warnings in readelfAlan Modra1-86/+123
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.
2021-10-21Automatic date update in version.inGDB Administrator1-1/+1
2021-10-21PR28417, std::string no longer allows accepting nullptr_tAlan Modra2-2/+2
PR 28417 * incremental.cc (Sized_relobj_incr::do_section_name): Avoid std:string undefined behaviour. * options.h (Search_directory::Search_directory): Likewise.
2021-10-21Re: PR27625, powerpc64 gold __tls_get_addr callsAlan Modra1-156/+36
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 0af4fcc25dd5, 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.
2021-10-20Use std::string in print_one_catch_syscallTom Tromey1-13/+9
This changes print_one_catch_syscall to use std::string, removing a bit of manual memory management.
2021-10-20Use unique_xmalloc_ptr in breakpointTom Tromey6-63/+60
This changes struct breakpoint to use unique_xmalloc_ptr in a couple of spots, removing a bit of manual memory management.
2021-10-20Use unique_xmalloc_ptr in bp_locationTom Tromey2-10/+6
This changes struct bp_location to use a unique_xmalloc_ptr, removing a bit of manual memory management.
2021-10-20Use unique_xmalloc_ptr in watchpointTom Tromey4-25/+18
This changes struct watchpoint to use unique_xmalloc_ptr in a couple of places, removing a bit of manual memory management.
2021-10-20Use unique_xmalloc_ptr in exec_catchpointTom Tromey1-14/+5
This changes struct exec_catchpoint to use a unique_xmalloc_ptr, removing a bit of manual memory management.
2021-10-20Use unique_xmalloc_ptr in solib_catchpointTom Tromey1-12/+7
This changes struct solib_catchpoint to use a unique_xmalloc_ptr, removing a bit of manual memory management.
2021-10-20Make c-exp.y work with Bison 3.8+Christian Biesinger1-2/+3
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
2021-10-20Automatic date update in version.inGDB Administrator1-1/+1
2021-10-19[gdb/testsuite] Reimplement gdb.gdb/python-interrupts.exp as unittestTom de Vries4-50/+57
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.
2021-10-19Check index in type::fieldTom Tromey3-2/+3
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.
2021-10-19Fix Rust lex selftest when using libiconvTom Tromey1-3/+10
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.
2021-10-19Fix format_pieces selftest on WindowsTom Tromey6-72/+127
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.
2021-10-19Fix bug in dynamic type resolutionTom Tromey3-3/+35
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.
2021-10-19Always use std::function for self-testsTom Tromey2-45/+6
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.
2021-10-19Fix PR gdb/17917 Lookup build-id in remote binariesDaniel Black1-9/+12
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
2021-10-19Fix a potential illegal memory access when testing for a special LTO symbol ↵Nick Clifton6-3/+19
name. 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.
2021-10-19Automatic date update in version.inGDB Administrator1-1/+1
2021-10-18CTF: incorrect underlying type setting for enumeration typesWeimin Pan6-36/+42
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.
2021-10-18Automatic date update in version.inGDB Administrator1-1/+1
2021-10-17PR28459, readelf issues bogus warningAlan Modra1-1/+0
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.
2021-10-17Automatic date update in version.inGDB Administrator1-1/+1
2021-10-16ld: Adjust pr28158.rd for glibc 2.34H.J. Lu1-1/+1
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.
2021-10-16Automatic date update in version.inGDB Administrator1-1/+1
2021-10-15Automatic date update in version.inGDB Administrator1-1/+1
2021-10-14Powerpc: Add support for openat and fstatat syscallsCarl Love1-2/+11
[gdb] update ppc-linux-tdep.c Add argument to ppc_canonicalize_syscall for the wordsize. Add syscall entries for the openat and fstatat system calls.
2021-10-14[gdb/testsuite] Add .debug_loc support in dwarf assemblerTom de Vries3-0/+257
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.
2021-10-14[GOLD] Re: PowerPC64: Don't pretend to support multi-tocAlan Modra1-4/+2
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.
2021-10-14[GOLD] Two GOT sections for PowerPC64Alan Modra5-128/+244
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.
2021-10-14[GOLD] PowerPC64: Don't pretend to support multi-tocAlan Modra1-114/+67
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.
2021-10-14Re: s12z/disassembler: call memory_error_func when appropriateAlan Modra1-1/+2
Adjust for commit ba7c18a48457. * testsuite/gas/s12z/truncated.d: Update expected output.
2021-10-14Automatic date update in version.inGDB Administrator1-1/+1
2021-10-13[gdb/exp] Improve <error reading variable> messageTom de Vries3-1/+75
When printing a variable x in a subroutine foo: ... subroutine foo (x) integer(4) :: x (*) x(3) = 1 end subroutine foo ... where x is an array with unknown bounds, we get: ... $ gdb -q -batch outputs/gdb.fortran/array-no-bounds/array-no-bounds \ -ex "break foo" \ -ex run \ -ex "print x" Breakpoint 1 at 0x4005cf: file array-no-bounds.f90, line 18. Breakpoint 1, foo (x=...) at array-no-bounds.f90:18 18 x(3) = 1 $1 = <error reading variable> ... Improve the error message by printing the details of the error, such that we have instead: ... $1 = <error reading variable: failed to get range bounds> ... This is a change in gdb/valprint.c, and grepping through the sources reveals that this is a common pattern. Tested on x86_64-linux.
2021-10-13PPC fix for stfiwx instruction (and additional stores with primary opcode of 31)Carl Love1-4/+4
[gdb] Fix address being recorded in rs6000-tdep.c, ppc_process_record_op31. The GDB record function was recording the variable addr that was passed in rather than the calculated effective address (ea) by the ppc_process_record_op31 function.
2021-10-13gdb: improve error reporting from the disassemblerAndrew Burgess2-6/+15
If the libopcodes disassembler returns a negative value then this indicates that the disassembly failed for some reason. In disas.c, in the function gdb_disassembler::print_insn we can see how this is handled; when we get a negative value back, we call the memory_error function, which throws an exception. The problem here is that the address used in the memory_error call is gdb_disassembler::m_err_memaddr, which is set in gdb_disassembler::dis_asm_memory_error, which is called from within the libopcodes disassembler through the disassembler_info::memory_error_func callback. However, for this to work correctly, every time the libopcodes disassembler returns a negative value, the libopcodes disassembler must have first called the memory_error_func callback. My first plan was to make m_err_memaddr a gdb::optional, and assert that it always had a value prior to calling memory_error, however, a quick look in opcodes/*-dis.c shows that there _are_ cases where a negative value is returned without first calling the memory_error_func callback, for example in arc-dis.c and cris-dis.c. Now, I think that a good argument can be made that these disassemblers must therefore be broken, except for the case where we can't read memory, we should always be able to disassemble the memory contents to _something_, even if it's just '.word 0x....'. However, I certainly don't plan to go and fix all of the disassemblers. What I do propose to do then, is make m_err_memaddr a gdb::optional, but now, instead of always calling memory_error, I add a new path which just calls error complaining about an unknown error. This new path is only used if m_err_memaddr doesn't have a value (indicating that the memory_error_func callback was not called). To test this I just augmented one of the disassemblers to always return -1, before this patch I see this: Dump of assembler code for function main: 0x000101aa <+0>: Cannot access memory at address 0x0 And after this commit I now see: Dump of assembler code for function main: 0x000101aa <+0>: unknown disassembler error (error = -1) This doesn't really help much, but that's because there's no way to report non memory errors out of the disasembler, because, it was not expected that the disassembler would ever report non memory errors.
2021-10-13[gdb/testsuite] Fix gdb.fortran/call-no-debug.exp with native-gdbserverTom de Vries1-1/+3
When running test-case gdb.fortran/call-no-debug.exp with target board native-gdbserver, I run into: ... (gdb) PASS: gdb.fortran/call-no-debug.exp: print string_func_ (&'abcdefg', 3) call (integer) string_func_ (&'abcdefg', 3)^M $2 = 0^M (gdb) FAIL: gdb.fortran/call-no-debug.exp: call (integer) string_func_ (&'abcdefg', 3) ... The problem is that gdb_test is used to match inferior output. Fix this by using gdb_test_stdio. Tested on x86_64-linux.
2021-10-13[gdb/testsuite] Require use_gdb_stub == 0 where appropriateTom de Vries6-17/+35
When running with target board native-gdbserver, we run into a number of FAILs due to use of the start command (and similar), which is not supported when use_gdb_stub == 1. Fix this by: - requiring use_gdb_stub == 0 for the entire test-case, or - guarding some tests in the test-case with use_gdb_stub == 0. Tested on x86_64-linux.
generated by cgit v1.1 at 2025-01-21 18:00:16 +0000