aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2020-04-06Implement basic threading support in the NetBSD targetKamil Rytarowski3-0/+185
Use sysctl(3) as the portable interface to prompt NetBSD threads on all supported NetBSD versions. In future newer versions could switch to PT_LWPSTATUS ptrace(2) API that will be supported on NetBSD 10.0 and newer. Implement as part of nbsd_nat_target: - thread_name() - read descriptive thread name - thread_alive() - check whether a thread is alive - post_attach() - updates the list of threads after attach - update_thread_list() - updates the list of threads - pid_to_str() - translates ptid to a descriptive string There are two local static functions: - nbsd_thread_lister() - generic LWP lister for a specified pid - nbsd_add_threads() - utility to update the list of threads Now, GDB on NetBSD can attach to a multithreaded process, spawn a multithreaded process, list threads, print their LWP+PID numbers and descriptive thread names. gdb/ChangeLog: * nbsd-nat.h (struct thread_info): Add forward declaration. (nbsd_nat_target::thread_alive): Add. (nbsd_nat_target::thread_name): Likewise. (nbsd_nat_target::update_thread_list): Likewise. (update_thread_list::post_attach): Likewise. (post_attach::pid_to_str): Likewise. * nbsd-nat.c: Include "gdbthread.h" and "inferior.h". (nbsd_thread_lister): Add. (nbsd_nat_target::thread_alive): Likewise. (nbsd_nat_target::thread_name): Likewise. (nbsd_add_threads): Likewise. (update_thread_list::post_attach): Likewise. (nbsd_nat_target::update_thread_list): Likewise. (post_attach::pid_to_str): Likewise.
2020-04-06Select variant field when printing variantTom Tromey7-2/+146
When I updated the Ada variant-printing code to be value-based, I neglected a couple of issues. First, print_variant_part must first extract the variant field before finding the active component; second, print_field_values should pass in the field value as the outer value when recursing. This patch fixes both of these issues. gdb/ChangeLog 2020-04-06 Tom Tromey <tromey@adacore.com> * ada-valprint.c (print_variant_part): Extract the variant field. (print_field_values): Use the field as the outer value when recursing. gdb/testsuite/ChangeLog 2020-04-06 Tom Tromey <tromey@adacore.com> * gdb.ada/variant-record/proc.adb: New file. * gdb.ada/variant-record/value.adb: New file. * gdb.ada/variant-record/value.s: New file. * gdb.ada/variant-record.exp: New file.
2020-04-06Fix build breakage in NetBSD tdep filesTom Tromey7-2/+15
A recent patch caused some build failures in NetBSD tdep files. I saw this failure in my --enable-target=all build. This patch fixes the problems. Tested by rebuilding. I am going to check this in. gdb/ChangeLog 2020-04-06 Tom Tromey <tromey@adacore.com> * sh-nbsd-tdep.c: Include nbsd-tdep.h. * ppc-nbsd-tdep.c: Include nbsd-tdep.h. * mips-nbsd-tdep.c (mipsnbsd_init_abi): Add missing ";". * arm-nbsd-tdep.c: Include nbsd-tdep.h. * hppa-nbsd-tdep.c: Include nbsd-tdep.h.
2020-04-06Handle complex error type in read_base_typeTom Tromey2-1/+18
It turns out there was one more bug in the earlier complex series: read_base_type could cause an assertion failure on some platforms. I found this running the AdaCore internal test suite, but you can also see it by running gdb's "gdb.cp" tests for x86 (not x86-64). In particular, the DW_ATE_complex_float case calls dwarf2_init_complex_target_type, which calls dwarf2_init_float_type, which can return a type using TYPE_CODE_ERROR. This patch changes the DWARF reader to handle this case, the same way that the f-lang.c patch did. Perhaps init_complex_type really should be changed to allow TYPE_CODE_ERROR? I was not sure. Tested on x86-64 Fedora 30, using an x86 build. I'm checking this in. gdb/ChangeLog 2020-04-06 Tom Tromey <tromey@adacore.com> * dwarf2/read.c (read_base_type) <DW_ATE_complex_float>: Handle TYPE_CODE_ERROR.
2020-04-06Add signal number conversions for NetBSDKamil Rytarowski14-0/+342
gdb/ChangeLog: * nbsd-tdep.c: Include "gdbarch.h". Define enum with NetBSD signal numbers. (nbsd_gdb_signal_from_target, nbsd_gdb_signal_to_target): New. * alpha-nbsd-tdep.c (alphanbsd_init_abi): Call nbsd_init_abi(). * amd64-nbsd-tdep.c (amd64nbsd_init_abi): Likewise. * arm-nbsd-tdep.c (arm_netbsd_elf_init_abi): Likewise. * hppa-nbsd-tdep.c (hppanbsd_init_abi): Likewise. * i386-nbsd-tdep.c (i386nbsd_init_abi): Likewise. * mips-nbsd-tdep.c (nbsd_init_abi): Likewise. * ppc-nbsd-tdep.c (ppcnbsd_init_abi): Likewise. * sh-nbsd-tdep.c (shnbsd_init_abi): Likewise. * sparc-nbsd-tdep.c (sparc32nbsd_init_abi): Likewise. * sparc64-nbsd-tdep.c (sparc64nbsd_init_abi): Likewise. * vax-nbsd-tdep.c (vaxnbsd_elf_init_abi): Likewise.
2020-04-03Fix attributes of typed enums of typedefsHannes Domani5-4/+83
For this enum: typedef unsigned char byte; enum byte_enum : byte { byte_val = 128 }; The unsigned attribute is not set: (gdb) p byte_val $1 = -128 That's because it uses the attributes of the 'byte' typedef for the enum. So this changes it to use the attributes of the underlying 'unsigned char' instead. gdb/ChangeLog: 2020-04-03 Hannes Domani <ssbssa@yahoo.de> PR gdb/25325 * dwarf2/read.c (read_enumeration_type): Fix typed enum attributes. gdb/testsuite/ChangeLog: 2020-04-03 Hannes Domani <ssbssa@yahoo.de> PR gdb/25325 * gdb.cp/typed-enum.cc: New test. * gdb.cp/typed-enum.exp: New file.
2020-04-03Fix DWARF disassembly of DW_OP_const_typeTom Tromey2-0/+11
While debugging another issue, I noticed that disassembling a DWARF expression using DW_OP_const_type did not work. disassemble_dwarf_expression was not properly decoding this operation. This patch fixes the problem. Tested by re-debugging gdb. I didn't write a test case because that seemed like overkill for what's essentially a maintainer's helper. The expression evaluator does decode this properly, so no other change was needed. gdb/ChangeLog 2020-04-03 Tom Tromey <tromey@adacore.com> * dwarf2/loc.c (disassemble_dwarf_expression) <DW_OP_const_type>: Read constant block.
2020-04-02gdb: use bfd_get_section_contents to read section contents in ↵Simon Marchi4-8/+36
is_linked_with_cygwin_dll The function is_linked_with_cygwin_dll currently uses gdb_bfd_map_section to get some section contents. This is not ideal because that memory, which is only used in this function, can't be released. Instead, it was suggested to use bfd_get_full_section_contents. However, bfd_get_full_section_contents returns a newly allocated buffer, which is not very practical to use with C++ automatic memory management constructs. I decided to make gdb_bfd_get_full_section_contents, a small alternative to bfd_get_full_section_contents. It is a small wrapper around bfd_get_section_contents which returns the full contents of the section in a gdb::byte_vector. gdb_bfd_get_full_section_contents could be used at many places that already allocate a vector of the size of the section and then call bfd_get_section_contents. I think these call sites can be updated over time. gdb/ChangeLog: * gdb_bfd.h: Include gdbsupport/byte-vector.h. (gdb_bfd_get_full_section_contents): New declaration. * gdb_bfd.c (gdb_bfd_get_full_section_contents): New function. * windows-tdep.c (is_linked_with_cygwin_dll): Use gdb_bfd_get_full_section_contents.
2020-04-02gdb: replace some calls to internal_error with gdb_assertSimon Marchi5-18/+21
There are a few spots using the pattern: if (condition) internal_error (__FILE__, __LINE__, _("failed internal consistency check")); The message brings no value, since it's pretty the description of a failed assertion. Replace a few of these that are obvious with gdb_assert. gdb/ChangeLog: * exec.c (build_section_table): Replace internal_error with gdb_assert. (section_table_xfer_memory_partial): Likewise. * mdebugread.c (parse_partial_symbols): Likewise. * psymtab.c (lookup_partial_symbol): Likewise. * utils.c (wrap_here): Likewise.
2020-04-02Avoid assertion failure due to complex type changeTom Tromey2-2/+12
Tankut Baris Aktemur pointed out that the recent series to change how complex types are handled introduced a regression. This assert in init_complex_type was firing: gdb_assert (TYPE_CODE (target_type) == TYPE_CODE_INT || TYPE_CODE (target_type) == TYPE_CODE_FLT); The problem was that f-lang.c could call init_complex_type with a type whose code was TYPE_CODE_ERROR. It seemed best to me to fix this in f-lang.c, rather than to change init_complex_type to accept error types. Tested on x86-64 Fedora 30. I'm checking this in. gdb/ChangeLog 2020-04-02 Tom Tromey <tromey@adacore.com> * f-lang.c (build_fortran_types): Use arch_type to initialize builtin_complex_s32 in the TYPE_CODE_ERROR case.
2020-04-02Micro-optimize partial_die_info::readTom Tromey2-4/+8
While profiling the DWARF reader, I noticed that partial_die_info::read creates a vector to store attributes. However, the vector is not needed, as this code only processes a single attribute at a time. This patch removes the vector. On my machine, this improves the time of "./gdb ./gdb" from 2.22 seconds to 1.92 seconds (mean times over 10 runs). Note that the attribute is initialized by read_attribute, so it does not need any special initialization. Avoiding this also improves performance a bit. Tested on x86-64 Fedora 30. I'm checking this in. gdb/ChangeLog 2020-04-02 Tom Tromey <tromey@adacore.com> * dwarf2/read.c (partial_die_info::read): Do not create a vector of attributes.
2020-04-02gdb: Don't remove duplicate entries from the line tableAndrew Burgess10-14/+358
In this commit: commit 8c95582da858ac981f689a6f599acacb8c5c490f Date: Mon Dec 30 21:04:51 2019 +0000 gdb: Add support for tracking the DWARF line table is-stmt field A change was made in buildsym_compunit::record_line to remove duplicate line table entries in some cases. This was an invalid change, as these duplicate line table entries are used in _some_ cases as part of prologue detection (see skip_prologue_using_sal). It might be possible to identify those line table entries that are required by skip_prologue_using_sal and only keep those duplicates around, however, I have not done this here. The original duplicate removal was done because (a) it was easy to implement, and (b) it seemed obviously harmless. As (b) is now known to be false, and implementation would be more complex, and so (a) is also false. As such, it seems better to keep all duplicates until an actual reason presents itself for why we should remove any. The original regression was spotted on RISC-V, which makes use of skip_prologue_using_sal as part of riscv_skip_prologue. Originally I created the test gdb.dwarf2/dw2-inline-small-func.exp, however, this test will not compile on RISC-V as this target doesn't support .uleb128 or .sleb128 assembler directives containing complex expressions. As a result I added the gdb.opt/inline-small-func.exp test, which exposes the bug on RISC-V, but obviously depends on the compiler to produce specific DWARF information in order to expose the bug. Still this test does ensure we always get the desired result, even if the DWARF changes. Originally the gdb.dwarf2/dw2-inline-small-func.exp test passed on x86-64 even with the duplicate line table entries incorrectly removed. The reason for this is that when a compilation unit doesn't have a 'producer' string then skip_prologue_using_sal is not used, instead the prologue is always skipped using analysis of the assembler code. However, for Clang on x86-64 skip_prologue_using_sal is used, so I modified the gdb.dwarf2/dw2-inline-small-func.exp test to include a 'producer' string that names the Clang compiler. With this done the test would fail on x86-64. One thing to note is that the gdb.opt/inline-small-func.exp test might fail on some targets. For example, if we compare sparc to risc-v by looking at sparc32_skip_prologue we see that this function doesn't use skip_prologue_using_sal, but instead uses find_pc_partial_function directly. I don't know the full history behind why the code is like it is, but it feels like sparc32_skip_prologue is an attempt to duplicate some of the functionality of skip_prologue_using_sal, but without all of the special cases. If this is true then the new test could easily fail on this target, this would suggest that sparc should consider switching to use skip_prologue_using_sal like risc-v does. gdb/ChangeLog: * buildsym.c (buildsym_compunit::record_line): Remove deduplication code. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-inline-small-func-lbls.c: New file. * gdb.dwarf2/dw2-inline-small-func.c: New file. * gdb.dwarf2/dw2-inline-small-func.exp: New file. * gdb.dwarf2/dw2-inline-small-func.h: New file. * gdb.opt/inline-small-func.c: New file. * gdb.opt/inline-small-func.exp: New file. * gdb.opt/inline-small-func.h: New file.
2020-04-02gdb/testsuite: Add support for DW_LNS_set_file to DWARF compilerAndrew Burgess2-0/+10
Extend the Dejagnu DWARF compiler to support DW_LNS_set_file opcode. This will be used in a later commit. There should be no change in the testsuite after this commit. gdb/testsuite/ChangeLog: * lib/dwarf.exp (Dwarf::lines::program::DW_LNS_set_file): New function.
2020-04-02gdb/testsuite: Add compiler options parameter to function_range helperAndrew Burgess2-2/+7
When using the Dejagnu DWARF compiler tests will often use the function_range helper function to extract the extents of a function. If the plan is to compiler the file with non-default compiler flags then we must pass those same compiler flags through to the function_range helper function. This will be used in a later commit, there should be no change in the testsuite behaviour after this commit. gdb/testsuite/ChangeLog: * lib/dwarf.exp (function_range): Allow compiler options to be specified.
2020-04-02[gdb/testsuite] Don't use O2 for inlining in break-inline-psymtab.expTom de Vries3-3/+8
In test-case gdb.dwarf2/break-inline-psymtab.exp we use O2 to enable inlining of bar into foo in break-inline-psymtab-2.c. Instead, enforce inlining using __attribute__((always_inline)), to avoid any optimization-related test issues. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-04-02 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/break-inline-psymtab-2.c (bar): Add __attribute__((always_inline)). * gdb.dwarf2/break-inline-psymtab.exp: Don't use -O2.
2020-04-02[gdb/testsuite] Fix silent timeout in gdb.multi/multi-target.expTom de Vries3-15/+59
While running test-case gdb.multi/multi-target.exp, I observed a silent timeout related to "monitor exit". By making the timeout explicit in an expect clause in gdbserver_gdb_exit: ... + timeout { + warning "Timed out waiting for EOF in server after $monitor_exit" + } ... we get in the log: ... monitor exit^M "monitor" command not supported by this target.^M (gdb) WARNING: Timed out waiting for EOF in server after monitor exit ... What happens is the following: - the inferior 5 is selected - a breakpoint is set in inferior 1 - the breakpoint triggers and we switch to inferior 1 - setup is called by test_continue, which calls clean_restart, which calls gdbserver_gdb_exit (due to load_lib gdbserver-support.exp) - gdbserver_gdb_exit issues "monitor exit" - gdb responds with "not supported by this target" because inferior 1 is native Fix this by keeping a list of server_spawn_id, and cleaning those up before calling gdbserver_gdb_exit. This reduces testing time from 1m22s to 32s. gdb/testsuite/ChangeLog: 2020-04-02 Tom de Vries <tdevries@suse.de> * lib/gdbserver-support.exp (gdbserver_exit): Factor out of ... (gdbserver_gdb_exit): ... here. Add timeout warning. * gdb.multi/multi-target.exp (server_spawn_ids): New global var. (connect_target_extended_remote): Append new server_spawn_id to server_spawn_ids. (cleanup): New proc. (setup, <toplevel>): Call cleanup.
2020-04-02[gdb/ada] Fix -readnow FAILsTom de Vries2-3/+34
When running test-case gdb.ada/access_to_packed_array we have: ... (gdb) print pack.a^M $1 = (0 => 1, 2, 3, 4, 5, 6, 7, 8, 9, 10)^M ... but with target board readnow.exp, we have instead: ... (gdb) print pack.a^M 'pack.a' has unknown type; cast it to its declared type^M ... The symbol is normally found by the map_matching_symbols call in ada-lang.c:add_nonlocal_symbols: ... for (objfile *objfile : current_program_space->objfiles ()) { data.objfile = objfile; objfile->sf->qf->map_matching_symbols (objfile, lookup_name, domain, global, callback, (is_wild_match ? NULL : compare_names)); ... which maps onto psym_map_matching_symbols. Function psym_map_matching_symbols iterates over all the partial symtabs, and: - if not expanded, searches in the partial symtab: - if not found, continues to the next - if found, expands into full symtab - searches in the full symtab However, with -readnow the call maps onto dw2_map_matching_symbols instead, which is unimplemented, and consequently no symbol is found. Fix this by detecting -readnow in dw2_map_matching_symbols, and handling that appropriately given that partial symtabs are not present, and full symtabs are: iterate over all the symtabs and search them. Tested on x86_64-linux, with native and target board -readnow. This removes 217 FAILs with board -readnow. gdb/ChangeLog: 2020-04-02 Tom de Vries <tdevries@suse.de> PR ada/24671 * dwarf2/read.c (dw2_map_matching_symbols): Handle -readnow.
2020-04-02[gdb] Use partial symbol table to find language for mainTom de Vries9-10/+137
When language is set to auto, part of loading an executable is to update the language accordingly. This is implemented by set_initial_language. The implementation of set_initial_language works as follows: - check if any objfile in the progspace has name_of_main/language_of_main set, and if so, use the first one found. [ This is what you get f.i. when using dwarf with DW_AT_main_subprogram. ] - otherwise, check for known names in the minimal symbols, and either: - use the associated language if any (f.i. for ada), or - lookup the symbol in the symtab for the name and use the symbol language (f.i. for c/c++). The symbol lookup can be slow though. In the case of the cc1 binary from PR23710 comment 1, getting to the initial prompt takes ~8s: ... $ time.sh gdb cc1 -batch -ex "show language" The current source language is "auto; currently c++". maxmem: 1272260 real: 8.05 user: 7.73 system: 0.38 ... but if we skip guessing the initial language by setting it instead, it takes only ~4s: ... $ time.sh gdb -iex "set language c++" cc1 -batch -ex "show language" The current source language is "c++". maxmem: 498272 real: 3.99 user: 3.90 system: 0.15 ... In both cases, we load the partial symbols for the executable, but in the first case only we also do a lookup of main, which causes the corresponding partial symtab to be expanded into a full symtab. Ideally, we'd like to get the language of the symbol without triggering expansion into a full symtab, and get the speedup without having to set the language manually. There's a related fixme in the header comment of set_initial_language: ... /* Set the initial language. FIXME: A better solution would be to record the language in the psymtab when reading partial symbols, and then use it (if known) to set the language. This would be a win for formats that encode the language in an easily discoverable place, such as DWARF. For stabs, we can jump through hoops looking for specially named symbols or try to intuit the language from the specific type of stabs we find, but we can't do that until later when we read in full symbols. */ void set_initial_language (void) ... Since we're already tracking the language of partial symbols, use this to set the language for the main symbol. Note that this search in partial symbol tables is not guaranteed to yield the same result as the lookup_symbol_in_language call currently done in set_initial_language. Build and reg-tested on x86_64-linux. gdb/ChangeLog: 2020-04-02 Tom de Vries <tdevries@suse.de> * dwarf2/read.c (dwarf2_gdb_index_functions, dwarf2_debug_names_functions): Init lookup_global_symbol_language with NULL. * psymtab.c (psym_lookup_global_symbol_language): New function. (psym_functions): Init psym_lookup_global_symbol_language with psym_lookup_global_symbol_language. * symfile-debug.c (debug_sym_quick_functions): Init lookup_global_symbol_language with NULL. * symfile.c (set_initial_language): Remove fixme comment. * symfile.h (struct quick_symbol_functions): Add lookup_global_symbol_language. * symtab.c (find_quick_global_symbol_language): New function. (find_main_name): Use find_quick_global_symbol_language. gdb/testsuite/ChangeLog: 2020-04-02 Tom de Vries <tdevries@suse.de> * gdb.base/main-psymtab.exp: New file.
2020-04-02[gdb/testsuite] Accept new complex print style in mixed-lang-stack.expTom de Vries2-2/+6
Since commit 981c08ce72 "Change how complex types are printed in C", we see these FAILs: ... FAIL: gdb.fortran/mixed-lang-stack.exp: lang=auto: info args in frame #6 FAIL: gdb.fortran/mixed-lang-stack.exp: lang=c: info args in frame #6 FAIL: gdb.fortran/mixed-lang-stack.exp: lang=c: info args in frame #7 FAIL: gdb.fortran/mixed-lang-stack.exp: lang=c++: info args in frame #6 FAIL: gdb.fortran/mixed-lang-stack.exp: lang=c++: info args in frame #7 ... The problem is that printing of complex types has changed from: ... d = 4 + 5 * I ... to: ... d = 4 + 5i ... but the test-case still checks for the old printing style. Fix this by updating the test-case to check for the new style. gdb/testsuite/ChangeLog: 2020-04-02 Tom de Vries <tdevries@suse.de> * gdb.fortran/mixed-lang-stack.exp: Accept new complex printing style.
2020-04-01gdb: fix style issues in is_linked_with_cygwin_dllSimon Marchi2-4/+8
gdb/ChangeLog: * windows-tdep.c (is_linked_with_cygwin_dll): Fix style.
2020-04-01Fix an undefined behavior in record_lineBernd Edlinger2-16/+23
Additionally do not completely remove symbols at the same PC than the end marker, instead make them non-is-stmt breakpoints. 2020-04-01 Bernd Edlinger <bernd.edlinger@hotmail.de> * buildsym.c (record_line): Fix undefined behavior and preserve lines at eof.
2020-04-01Fix the resizing condition of the line tableBernd Edlinger2-1/+5
That was wasting one element. 2020-04-01 Bernd Edlinger <bernd.edlinger@hotmail.de> * buildsym.c (record_line): Fix the resizing condition.
2020-04-01Fix value_literal_complex commentTom Tromey3-4/+11
Christian pointed out that the value_literal_complex was still a bit weird; this patch rewrites it and moves it to value.h. gdb/ChangeLog 2020-04-01 Tom Tromey <tom@tromey.com> * value.h (value_literal_complex): Add comment. * valops.c (value_literal_complex): Refer to value.h.
2020-04-01Add _Complex type support to C parserTom Tromey4-30/+68
This changes the C parser to add support for complex types in casts. gdb/ChangeLog 2020-04-01 Tom Tromey <tom@tromey.com> * c-exp.y (FLOAT_KEYWORD, COMPLEX): New tokens. (scalar_type): New rule, from typebase. (typebase): Use scalar_type. Recognize complex types. (field_name): Handle FLOAT_KEYWORD. (ident_tokens): Add _Complex and __complex__. gdb/testsuite/ChangeLog 2020-04-01 Tom Tromey <tom@tromey.com> * gdb.base/complex-parts.exp: Add type tests.
2020-04-01Implement complex arithmeticTom Tromey4-21/+215
This adds support for complex arithmetic to gdb. Now something like "print 23 + 7i" will work. Addition, subtraction, multiplication, division, and equality testing are supported binary operations. Unary +, negation, and complement are supported. Following GCC, the ~ operator computes the complex conjugate. gdb/ChangeLog 2020-04-01 Tom Tromey <tom@tromey.com> PR exp/25299: * valarith.c (promotion_type, complex_binop): New functions. (scalar_binop): Handle complex numbers. Use promotion_type. (value_pos, value_neg, value_complement): Handle complex numbers. gdb/testsuite/ChangeLog 2020-04-01 Tom Tromey <tom@tromey.com> * gdb.base/complex-parts.exp: Add arithmetic tests.
2020-04-01Change the C parser to allow complex constantsTom Tromey2-8/+75
This changes the C parser to allow complex constants. Now something like "print 23i" will work. There are no tests in this patch; they come later. gdb/ChangeLog 2020-04-01 Tom Tromey <tom@tromey.com> * c-exp.y (COMPLEX_INT, COMPLEX_FLOAT): New tokens. (exp) <COMPLEX_INT, COMPLEX_FLOAT>: New rules. (parse_number): Handle complex numbers.
2020-04-01Change how complex types are printed in CTom Tromey12-34/+48
GCC accepts the "i" suffix for complex numbers. I think this is nicer to read than the current output, so this patch changes the C code to print complex numbers this way. gdb/ChangeLog 2020-04-01 Tom Tromey <tom@tromey.com> * c-valprint.c (c_decorations): Change complex suffix to "i". gdb/testsuite/ChangeLog 2020-04-01 Tom Tromey <tom@tromey.com> * gdb.compile/compile.exp: Update. * gdb.compile/compile-cplus.exp: Update. * gdb.base/varargs.exp: Update. * gdb.base/floatn.exp: Update. * gdb.base/endianity.exp: Update. * gdb.base/callfuncs.exp (do_function_calls): Update. * gdb.base/funcargs.exp (complex_args, complex_integral_args) (complex_float_integral_args): Update. * gdb.base/complex.exp: Update. * gdb.base/complex-parts.exp: Update.
2020-04-01Add accessors for members of complex numbersTom Tromey5-10/+45
This introduces two new functions that make it simpler to access the components of a complex number. gdb/ChangeLog 2020-04-01 Tom Tromey <tom@tromey.com> * valprint.c (generic_value_print_complex): Use accessors. * value.h (value_real_part, value_imaginary_part): Declare. * valops.c (value_real_part, value_imaginary_part): New functions. * value.c (creal_internal_fn, cimag_internal_fn): Use accessors.
2020-04-01Change how complex types are createdTom Tromey10-57/+71
This patch changes how complex types are created. init_complex_type and arch_complex_type are unified, and complex types are reused, by attaching them to the underlying scalar type. gdb/ChangeLog 2020-04-01 Tom Tromey <tom@tromey.com> * stabsread.c (rs6000_builtin_type, read_sun_floating_type) (read_range_type): Update. * mdebugread.c (basic_type): Update. * go-lang.c (build_go_types): Use init_complex_type. * gdbtypes.h (struct main_type) <complex_type>: New member. (init_complex_type): Update. (arch_complex_type): Don't declare. * gdbtypes.c (init_complex_type): Remove "objfile" parameter. Make name if none given. Use alloc_type_copy. Look for cached complex type. (arch_complex_type): Remove. (gdbtypes_post_init): Use init_complex_type. * f-lang.c (build_fortran_types): Use init_complex_type. * dwarf2/read.c (read_base_type): Update. * d-lang.c (build_d_types): Use init_complex_type. * ctfread.c (read_base_type): Update.
2020-04-01Move Rust union tests to new fileTom Tromey5-25/+88
I wanted to run the gdb.rust tests against older versions of the Rust compiler, to ensure that changes I am making don't break debugging when using older compilers. However, this did not work because simple.rs now uses unchecked unions, which were only added in Rust 1.19. This patch splits the union code into its own file, so that simple.exp can continue to work. I tested this with selected rust versions back to 1.12. gdb/testsuite/ChangeLog 2020-04-01 Tom Tromey <tromey@adacore.com> * gdb.rust/union.rs: New file. * gdb.rust/union.exp: New file. * gdb.rust/simple.rs (Union, Union2): Move to union.rs. (main): Update. * gdb.rust/simple.exp: Move union tests to union.exp.
2020-04-01Remove local variable from simple.rs test caseTom Tromey2-1/+4
This removes the "y0" variable from simple.rs:main. This variable isn't needed by the test case, and it uses a form of initialization that was added in rust 1.17. Removing this makes it simpler to run the gdb.rust tests against older versions of rustc. gdb/testsuite/ChangeLog 2020-04-01 Tom Tromey <tromey@adacore.com> * gdb.rust/simple.rs (main): Remove "y0".
2020-04-01gdb/infrun: stop all threads if there exists a non-stop targetTankut Baris Aktemur5-4/+118
Stop all threads not only if the current target is non-stop, but also if there exists a non-stop target. The multi-target patch (5b6d1e4fa4f "Multi-target support") made the following change to gdb/inf-child.c: void inf_child_target::maybe_unpush_target () { - if (!inf_child_explicitly_opened && !have_inferiors ()) + if (!inf_child_explicitly_opened) unpush_target (this); } If we are in all-stop mode with multiple inferiors, and an exit event is received from an inferior, target_mourn_inferior() gets to this point and without the have_inferiors() check, the target is unpushed. This leads to having exec_ops as the top target. Here is a test scenario. Two executables, ./a.out returns immediately; ./sleepy just sleeps. $ gdb ./sleepy (gdb) start ... (gdb) add-inferior -exec ./a.out ... (gdb) inferior 2 [Switching to inferior 2.. (gdb) start ... (gdb) set schedule-multiple on (gdb) set debug infrun 1 (gdb) continue At this point, the exit event is received from ./a.out. Normally, this would lead to stop_all_threads() to also stop ./sleepy, but this doesn't happen, because target_is_non_stop_p() returns false. And it returns false because the top target is no longer the process target; it is the exec_ops. This patch modifies 'stop_waiting' to call 'stop_all_threads' if there exists a non-stop target, not just when the current top target is non-stop. Tested on X86_64 Linux. gdb/ChangeLog: 2020-04-01 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * infrun.c (stop_all_threads): Update assertion, plus when stopping threads, take into account that we might be trying to stop an all-stop target. (stop_waiting): Call 'stop_all_threads' if there exists a non-stop target. gdb/testsuite/ChangeLog: 2020-04-01 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * gdb.multi/stop-all-on-exit.c: New test. * gdb.multi/stop-all-on-exit.exp: New file.
2020-04-01gdb: define convenience function 'exists_non_stop_target'Tankut Baris Aktemur3-0/+28
Define a predicate function that returns true if there exists an inferior with a non-stop target. gdb/ChangeLog: 2020-04-01 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * target.h (exists_non_stop_target): New function declaration. * target.c (exists_non_stop_target): New function.
2020-04-01Allow pointer arithmetic with integer referencesHannes Domani5-3/+41
Considering these variables: int i = 3; int &iref = i; It's not possible to do any pointer arithmetic with iref: (gdb) p &i+iref Argument to arithmetic operation not a number or boolean. So this adds checks for references to integers in pointer arithmetic. gdb/ChangeLog: 2020-04-01 Hannes Domani <ssbssa@yahoo.de> PR gdb/24789 * eval.c (is_integral_or_integral_reference): New function. (evaluate_subexp_standard): Allow integer references in pointer arithmetic. gdb/testsuite/ChangeLog: 2020-04-01 Hannes Domani <ssbssa@yahoo.de> PR gdb/24789 * gdb.cp/misc.cc: Add integer reference variable. * gdb.cp/misc.exp: Add test.
2020-04-01gdb/remote: do not check for null_ptid in stop replyTankut Baris Aktemur4-7/+30
A gdbserver does not report a ptid in a 'W' or 'X' packet if multi-process extensions are not supported or turned off. See https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html#multiprocess-extensions https://sourceware.org/gdb/current/onlinedocs/gdb/Stop-Reply-Packets.html#Stop-Reply-Packets GDB's remote packet parser checks for whether a stop-reply packet contains a ptid if the target is non-stop, and issues an error if no ptid is included: if (target_is_non_stop_p () && event->ptid == null_ptid) error (_("No process or thread specified in stop reply: %s"), buf); This leads to the following error when the non-stop mode is turned on but multi-process extensions are off: $ gdb (gdb) set non-stop on (gdb) set remote multiprocess-feature-packet off (gdb) target remote | gdbserver - ./foo Remote debugging using | gdbserver - ./foo stdin/stdout redirected Process ./foo created; pid = 3712 ... (gdb) continue Continuing. ... No process or thread specified in stop reply: W2a (gdb) Because the check is done for stop reply packets in general, a similar situation occurs if the 'T' or 'Tthread' packet is disabled in gdbserver (i.e. via --disable-packet=T). E.g: $ gdb (gdb) set non-stop on (gdb) target remote | gdbserver --disable-packet=Tthread - ./foo ... No process or thread specified in stop reply: T0506:0000000000000000;07:10e2ffffff7f0000;10:9060ddf7ff7f0000; or $ gdb (gdb) set non-stop on (gdb) target remote | gdbserver --disable-packet=T - ./foo ... No process or thread specified in stop reply: S05 The commit commit cada5fc921e39a1945c422eea055c8b326d8d353 Date: Wed Mar 11 12:30:13 2020 +0000 gdb: Handle W and X remote packets without giving a warning and its predecessor commit 24ed6739b699f329c2c45aedee5f8c7d2f54e493 Date: Thu Jan 30 14:35:40 2020 +0000 gdb/remote: Restore support for 'S' stop reply packet added warnings for when GDB has to make a guess for a missing ptid in case of multiple threads/inferiors. These warnings should suffice. So, the simple solution is to remove the check completely. Regression-tested on X86_64 Linux. gdb/ChangeLog: 2020-04-01 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * remote.c (remote_target::remote_parse_stop_reply): Remove the check for no ptid in the stop reply when the target is non-stop. gdb/testsuite/ChangeLog: 2020-04-01 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * gdb.server/stop-reply-no-thread.exp: Enhance the test scenario to cover execution until the end and also the case when no packet is disabled when starting gdbserver.
2020-04-01Avoid copying in lookup_name_infoTom Tromey8-41/+95
lookup_name_info always copies the name that is passed in. However, normally a copy is not needed. This patch changes this class to avoid copying. This required changing the "name" method to return something else; I chose a gdb::string_view, to avoid excessive calls to strlen in the code using the lookup_name_info. However, as this class does not allow an arbitrary string_view, I've also added a c_str method that guarantees a \0-terminated result -- a pedantic difference but one that respects the string_view contract, IMO. gdb/ChangeLog 2020-04-01 Tom Tromey <tromey@adacore.com> * symtab.h (class lookup_name_info) <lookup_name_info>: Change "name" parameter to rvalue reference. Initialize m_name_holder. <lookup_name_info>: New overloads. <name>: Return gdb::string_view. <c_str>: New method. <make_ignore_params>: Update. <search_name_hash>: Update. <language_lookup_name>: Return const char *. <m_name>: Change type. * symtab.c (demangle_for_lookup_info::demangle_for_lookup_info) (demangle_for_lookup_info::demangle_for_lookup_info): Update. (lookup_name_info::match_any): Update. * psymtab.c (match_partial_symbol, lookup_partial_symbol): Update. * minsyms.c (linkage_name_str): Update. * language.c (default_symbol_name_matcher): Update. * dwarf2/read.c (mapped_index_base::find_name_components_bounds): Update. * ada-lang.c (ada_fold_name): Change parameter to string_view. (ada_lookup_name_info::ada_lookup_name_info): Update. (literal_symbol_name_matcher): Update.
2020-04-01Avoid some copying in psymtab.cTom Tromey2-42/+25
I noticed that psymtab.c was always copying the search string in psymtab_search_name, even when it wasn't necessary. This patch removes this function in favor of using the make_ignore_params feature of lookup_name_info. Once I had done that, I noticed that lookup_partial_symbol was creating a lookup_name_info. However, this function called in loops, causing even more excess allocation. This patch further fixes this by hosting the creation of the lookup_name_info into the callers. gdb/ChangeLog 2020-04-01 Tom Tromey <tromey@adacore.com> * psymtab.c (psymtab_search_name): Remove function. (psym_lookup_symbol): Create search name and lookup name here. (lookup_partial_symbol): Remove "name" parameter; add lookup_name. (psym_expand_symtabs_for_function): Update.
2020-03-31Fix py-tui.c build problemTom Tromey2-1/+12
py-tui.c can fail to build if the ncurses development headers are not installed, but if Python was built against ncurses. In this case, the Python headers will define HAVE_NCURSES_H, confusing gdb_curses.h. This patch fixes the problem by moving this include inside "#ifdef TUI". gdb/ChangeLog 2020-03-31 Joel Jones <joelkevinjones@gmail.com> PR tui/25597: * python/py-tui.c: Include gdb_curses.h inside of #ifdef TUI.
2020-03-31Don't pass NULL to memcpy in gdbTom Tromey2-2/+8
I compiled gdb with -fsanitize=undefined and ran the test suite. A couple of reports came from passing NULL to memcpy, e.g.: [...]btrace-common.cc:176:13: runtime error: null pointer passed as argument 2, which is declared to never be null While it would be better to fix this in the standard, in the meantime it seems easy to avoid this error. gdb/ChangeLog 2020-03-31 Tom Tromey <tromey@adacore.com> * dwarf2/abbrev.c (abbrev_table::read): Conditionally call memcpy. gdbsupport/ChangeLog 2020-03-31 Tom Tromey <tromey@adacore.com> * btrace-common.cc (btrace_data_append): Conditionally call memcpy.
2020-03-31[gdb/testsuite] Fix c-linkage-name.exp with -fltoTom de Vries2-7/+18
When running test-case gdb.base/c-linkage-name.exp with target board unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects, I run into: ... PASS: gdb.base/c-linkage-name.exp: maint info psymtab: c-linkage-name-2.c: no FAIL: gdb.base/c-linkage-name.exp: print symada__cS before partial symtab \ expansion ... The test-case tries to print a symbol before and after symtab expansion. And it tries to ensure (since commit 13c3a74afb) that the symtab containing the symbol is not yet expanded when doing the 'before' print, by placing the symbol in a different CU (c-linkage-name-2.c) from the one containing main (c-linkage-name.c), such that when we load the exec and expand the symtab containing main, the symtab containing the symbol isn't. The generated debug info for the test-case when using mentioned target board however is structured like this: ... <0><d2>: Abbrev Number: 1 (DW_TAG_compile_unit) <d8> DW_AT_name : <artificial> <1><f4>: Abbrev Number: 2 (DW_TAG_imported_unit) <f5> DW_AT_import : <0x16b> [Abbrev Number: 1] <1><f9>: Abbrev Number: 2 (DW_TAG_imported_unit) <fa> DW_AT_import : <0x19c> [Abbrev Number: 1] <1><fe>: Abbrev Number: 3 (DW_TAG_subprogram) <ff> DW_AT_abstract_origin: <0x17d> <1><115>: Abbrev Number: 4 (DW_TAG_variable) <116> DW_AT_abstract_origin: <0x1ce> <0><16b>: Abbrev Number: 1 (DW_TAG_compile_unit) <171> DW_AT_name : c-linkage-name.c <1><17d>: Abbrev Number: 2 (DW_TAG_subprogram) <17e> DW_AT_name : main <0><19c>: Abbrev Number: 1 (DW_TAG_compile_unit) <1a2> DW_AT_name : c-linkage-name-2.c <1><1ce>: Abbrev Number: 5 (DW_TAG_variable) <1cf> DW_AT_name : mundane <1d6> DW_AT_linkage_name: symada__cS ... So, the CU named <artificial> contains both the concrete main and the concrete symbol, which explains the FAIL. The first test should fail, but passes for two reasons. First of all, due to PR symtab/25700, we have two regular partial symtabs c-linkage-name-2.c instead of one, and one of them is expanded, the other one not: ... { psymtab c-linkage-name-2.c ((struct partial_symtab *) 0x38d6f60) readin yes { psymtab c-linkage-name-2.c ((struct partial_symtab *) 0x38d6fe0) readin no ... And then there's the include symtab, which is also not expanded: ... { psymtab c-linkage-name-2.c ((struct partial_symtab *) 0x38143e0) readin no ... Fix the FAIL by explicitly setting the language before load, changing the language setting from auto/c to manual/c, such that the symtab containing main is no longer expanded. And make the symtab expansion testing more robust by using the output of "maint info symtabs" instead of "maint info psymtabs". Tested on x86_64-linux, using native and target boards cc-with-gdb-index.exp, cc-with-debug-names.exp, readnow.exp and unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects. gdb/testsuite/ChangeLog: 2020-03-31 Tom de Vries <tdevries@suse.de> * gdb.base/c-linkage-name.exp: Fix test-case comment. Set language to c. Use "maint info symtabs" to check symtab expansion.
2020-03-30RISC-V: Update CSR to privileged spec 1.11.Nelson Chu3-4/+11
gas/ * testsuite/gas/riscv/alias-csr.d: Move this to priv-reg-pseudo. * testsuite/gas/riscv/alias-csr.s: Likewise. * testsuite/gas/riscv/no-aliases-csr.d: Move this to priv-reg-pseudo-noalias. * testsuite/gas/riscv/bad-csr.d: Rename to priv-reg-fail-nonexistent. * testsuite/gas/riscv/bad-csr.l: Likewise. * testsuite/gas/riscv/bad-csr.s: Likewise. * testsuite/gas/riscv/satp.d: Removed. Already included in priv-reg. * testsuite/gas/riscv/satp.s: Likewise. * testsuite/gas/riscv/priv-reg-pseudo.d: New testcase for all pseudo csr instruction, including alias-csr testcase. * testsuite/gas/riscv/priv-reg-pseudo.s: Likewise. * testsuite/gas/riscv/priv-reg-pseudo-noalias.d: New testcase for all pseudo instruction with objdump -Mno-aliases. * testsuite/gas/riscv/priv-reg-fail-nonexistent.d: New testcase. * testsuite/gas/riscv/priv-reg-fail-nonexistent.l: Likewise. * testsuite/gas/riscv/priv-reg-fail-nonexistent.s: Likewise. * testsuite/gas/riscv/priv-reg.d: Update CSR to 1.11. * testsuite/gas/riscv/priv-reg.s: Likewise. * testsuite/gas/riscv/priv-reg-fail-rv32-only.l: Likewise. * testsuite/gas/riscv/csr-dw-regnums.d: Likewise. * testsuite/gas/riscv/csr-dw-regnums.s: Likewise. include/ * opcode/riscv-opc.h: Update CSR to 1.11. gdb/ * features/riscv/32bit-csr.xml: Regenerated. * features/riscv/64bit-csr.xml: Regenerated.
2020-03-30Change ada_which_variant_applies to value APITom Tromey4-15/+13
While debugging an Ada regression, I noticed that all the callers of ada_which_variant_applies desconstruct a value, only to have it be reconstructed by this function. This patch removes this inefficiency in favor of simply passing in the value directly. Tested on x86-64 Fedora 30. gdb/ChangeLog 2020-03-30 Tom Tromey <tromey@adacore.com> * ada-valprint.c (print_variant_part): Update. * ada-lang.h (ada_which_variant_applies): Update. * ada-lang.c (ada_which_variant_applies): Remove outer_type and outer_valaddr parameters; replace with "outer" value parameter. (to_fixed_variant_branch_type): Update.
2020-03-30[PowerPC] Fix debug register issues in ppc-linux-natPedro Franco de Carvalho2-396/+1020
This patch fixes some issues with debug register handling for the powerpc linux native target. Currently, the target methods for installing and removing hardware breakpoints and watchpoints in ppc-linux-nat.c affect all threads known to linux-nat, including threads of different processes. This patch changes ppc-linux-nat.c so that only the process of inferior_ptid is affected by these target methods, as GDB expects. This is done in the same way as various other architectures. The install/remove target methods only register a hardware breakpoint or watchpoint, and then send a stop signal to the threads. The debug registers are only changed with ptrace right before each thread is next resumed, using low_prepare_to_resume. There are two interfaces to modify debug registers for linux running on powerpc, with different sets of ptrace requests: - PPC_PTRACE_GETHWDBGINFO, PPC_PTRACE_SETHWDEBUG, and PPC_PTRACE_DELHWDEBUG. Or - PTRACE_SET_DEBUGREG and PTRACE_GET_DEBUGREG The first set (HWDEBUG) is the more flexible one and allows setting watchpoints with a variable watched region length and, for certain embedded processors, multiple types of debug registers (e.g. hardware breakpoints and hardware-assisted conditions for watchpoints). Currently, server processors only provide one watchpoint. The second one (DEBUGREG) only allows setting one debug register, a watchpoint, so we only use it if the first one is not available. The HWDEBUG interface handles debug registers with slot numbers. Once a hardware watchpoint or breakpoint is installed (with PPC_PTRACE_SETHWDEBUG), ptrace returns a slot number. This slot number can then be used to remove the watchpoint or breakpoint from the inferior (with PPC_PTRACE_DELHWDEBUG). The first interface also provides a bitmask of available debug register features, which can be obtained with PPC_PTRACE_GETHWDBGINFO. When GDB first tries to use debug registers, we try the first interface with a ptrace call, and if it isn't available, we fall back to the second one, if available. We use EIO as an indicator that an interface is not available in the kernel. For simplicity, with any other error we immediately assume no interface is available. Unfortunately this means that if a process is killed by a signal right before we try to detect the interface, we might get an ESRCH, which would prevent debug registers to be used in the GDB session. However, it isn't clear that we can safely raise an exception and try again in the future in all the contexts where we try to detect the interface. If the HWDEBUG interface works but provides no feature bits, the target falls back to the DEBUGREG interface. When the kernel is configured without CONFIG_HW_BREAKPOINTS (selected by CONFIG_PERF_EVENTS), there is a bug that causes watchpoints installed with the HWDEBUG interface not to trigger. When this is the case, the feature bits will be zero, which is used as the indicator to fall back to the DEBUGREG interface. This isn't ideal, but has always been the behavior of GDB before this patch, so I decided not to change it. A flag indicates for each thread if its debug registers need to be updated the next time it is resumed. The flag is set whenever the upper layers request or remove a hardware watchpoint or breakpoint, or when a new thread is detected. Because some kernel configurations disable watchpoints after they are hit, we also use the last stop reason of the LWP to determine whether we should update the debug registers. It isn't clear that this is also true of BookE hardware breakpoints, but we also check their stop reason to be on the safe side, since it doesn't hurt. A map from process numbers to hardware watchpoint or breakpoint objects keeps track of what has been requested by the upper layers of GDB, since for GDB installing a hardware watchpoint or breakpoint means doing so for the whole process. When using the HWDEBUG interface we also have to keep track of which slots were last installed in each thread with a map from threads to the slots, so that they can be removed when needed. When resuming a thread, we remove all the slots using this map, then we install all the hardware watchpoints and breakpoints from the per-process map of requests, and then update the per-thread map accordingly. This per-thread state is also used for copying the debug register state after a fork or a clone is detected. The kernel might do this depending on the configuration. Recent kernels running on server processors that were configured with CONFIG_PERF_EVENTS (and therefore CONFIG_HW_BREAKPOINTS) don't copy debug registers across forks and clones. Recent kernels without CONFIG_HW_BREAKPOINTS copy this state. I believe that on embedded processors (e.g. a ppc440) the debug register state is copied, but I haven't been able to test this. To handle both cases, the per-thread state is always copied when forks and clones are detected, and when we resume the thread and delete the debug register slots before updating them, we ignore ENOENT errors. We don't need to handle this when using the DEBUGREG interface since it only allows one hardware watchpoint and doesn't return slot numbers, we just set or clear this watchpoint when needed. Since we signal running threads to stop after a request is processed, so that we can update their debug registers when they are next resumed, there will be a time between signalling the threads and their stop during which the debug registers haven't been updated, even if the target methods completed. The tests in gdb.threads/watchpoint-fork.exp no longer fail with this patch. gdb/ChangeLog: 2020-03-30 Pedro Franco de Carvalho <pedromfc@linux.ibm.com> * ppc-linux-nat.c: Include <algorithm>, <unordered_map>, and <list>. Remove inclusion of observable.h. (PPC_DEBUG_CURRENT_VERSION): Move up define. (struct arch_lwp_info): New struct. (class ppc_linux_dreg_interface): New class. (struct ppc_linux_process_info): New struct. (struct ppc_linux_nat_target) <low_delete_thread, low_new_fork> <low_new_clone, low_forget_process, low_prepare_to_resume> <copy_thread_dreg_state, mark_thread_stale> <mark_debug_registers_changed, register_hw_breakpoint> <clear_hw_breakpoint, register_wp, clear_wp> <can_use_watchpoint_cond_accel, calculate_dvc, check_condition> <num_memory_accesses, get_trigger_type> <create_watchpoint_request, hwdebug_point_cmp> <init_arch_lwp_info, get_arch_lwp_info> <low_stopped_by_watchpoint, low_stopped_data_address>: Declare as methods. <struct ptid_hash>: New inner struct. <m_dreg_interface, m_process_info, m_installed_hw_bps>: Declare members. (saved_dabr_value, hwdebug_info, max_slots_number) (struct hw_break_tuple, struct thread_points, ppc_threads) (have_ptrace_hwdebug_interface) (hwdebug_find_thread_points_by_tid) (hwdebug_insert_point, hwdebug_remove_point): Remove. (ppc_linux_nat_target::can_use_hw_breakpoint): Use m_dreg_interface, remove call to PTRACE_SET_DEBUGREG. (ppc_linux_nat_target::region_ok_for_hw_watchpoint): Add comment, use m_dreg_interface. (hwdebug_point_cmp): Change to... (ppc_linux_nat_target::hwdebug_point_cmp): ...this method. Use reference arguments instead of pointers. (ppc_linux_nat_target::ranged_break_num_registers): Use m_dreg_interface. (ppc_linux_nat_target::insert_hw_breakpoint): Add comment, use m_dreg_interface. Call register_hw_breakpoint. (ppc_linux_nat_target::remove_hw_breakpoint): Add comment, use m_dreg_interface. Call clear_hw_breakpoint. (get_trigger_type): Change to... (ppc_linux_nat_target::get_trigger_type): ...this method. Add comment. (ppc_linux_nat_target::insert_mask_watchpoint): Update comment, use m_dreg_interface. Call register_hw_breakpoint. (ppc_linux_nat_target::remove_mask_watchpoint): Update comment, use m_dreg_interface. Call clear_hw_breakpoint. (can_use_watchpoint_cond_accel): Change to... (ppc_linux_nat_target::can_use_watchpoint_cond_accel): ...this method. Update comment, use m_dreg_interface and m_process_info. (calculate_dvc): Change to... (ppc_linux_nat_target::calculate_dvc): ...this method. Use m_dreg_interface. (num_memory_accesses): Change to... (ppc_linux_nat_target::num_memory_accesses): ...this method. (check_condition): Change to... (ppc_linux_nat_target::check_condition): ...this method. (ppc_linux_nat_target::can_accel_watchpoint_condition): Update comment, use m_dreg_interface. (create_watchpoint_request): Change to... (ppc_linux_nat_target::create_watchpoint_request): ...this method. Use m_dreg_interface. (ppc_linux_nat_target::insert_watchpoint): Add comment, use m_dreg_interface. Call register_hw_breakpoint or register_wp. (ppc_linux_nat_target::remove_watchpoint): Add comment, use m_dreg_interface. Call clear_hw_breakpoint or clear_wp. (ppc_linux_nat_target::low_forget_process) (ppc_linux_nat_target::low_new_fork) (ppc_linux_nat_target::low_new_clone) (ppc_linux_nat_target::low_delete_thread) (ppc_linux_nat_target::low_prepare_to_resume): New methods. (ppc_linux_nat_target::low_new_thread): Remove previous logic, only call mark_thread_stale. (ppc_linux_thread_exit): Remove. (ppc_linux_nat_target::stopped_data_address): Change to... (ppc_linux_nat_target::low_stopped_data_address): This. Add comment, use m_dreg_interface and m_thread_hw_breakpoints. (ppc_linux_nat_target::stopped_by_watchpoint): Change to... (ppc_linux_nat_target::stopped_by_watchpoint): This. Add comment. Call low_stopped_data_address. (ppc_linux_nat_target::watchpoint_addr_within_range): Use m_dreg_interface. (ppc_linux_nat_target::masked_watch_num_registers): Use m_dreg_interface. (ppc_linux_nat_target::copy_thread_dreg_state) (ppc_linux_nat_target::mark_thread_stale) (ppc_linux_nat_target::mark_debug_registers_changed) (ppc_linux_nat_target::register_hw_breakpoint) (ppc_linux_nat_target::clear_hw_breakpoint) (ppc_linux_nat_target::register_wp) (ppc_linux_nat_target::clear_wp) (ppc_linux_nat_target::init_arch_lwp_info) (ppc_linux_nat_target::get_arch_lwp_info): New methods. (_initialize_ppc_linux_nat): Remove observer callback.
2020-03-30[PowerPC] Move up some register access routinesPedro Franco de Carvalho2-164/+172
Keep the routines related to register access grouped together. gdb/ChangeLog: 2020-03-30 Pedro Franco de Carvalho <pedromfc@linux.ibm.com> * ppc-linux-nat.c (ppc_linux_nat_target::store_registers) (ppc_linux_nat_target::auxv_parse) (ppc_linux_nat_target::read_description) (supply_gregset, fill_gregset, supply_fpregset, fill_fpregset): Move up.
2020-03-30Add low_new_clone method to linux_nat_target.Pedro Franco de Carvalho3-0/+13
This patch adds a low_new_clone method to linux_nat_target, called after a PTRACE_EVENT_CLONE is detected, similar to how low_new_fork is called after PTRACE_EVENT_(V)FORK. This is useful for targets that need to copy state associated with a thread that is inherited across clones. gdb/ChangeLog: 2020-03-30 Pedro Franco de Carvalho <pedromfc@linux.ibm.com> * linux-nat.h (low_new_clone): New method. * linux-nat.c (linux_handle_extended_wait): Call low_new_clone.
2020-03-30[gdb/testsuite] Fix c-linkage-name.exp with {cc-with-gdb-index,readnow}.expTom de Vries3-17/+57
When running test-case gdb.base/c-linkage-name.exp with target board cc-with-gdb-index.exp, I see: ... FAIL: gdb.base/c-linkage-name.exp: maint info psymtab: c-linkage-name-2.c: no FAIL: gdb.base/c-linkage-name.exp: maint info psymtab: c-linkage-name-2.c: yes ... The FAILs are due to the fact that partial symbol tables are not generated for indexed executables. When running the same test-case with target board readnow.exp, I see: ... FAIL: gdb.base/c-linkage-name.exp: maint info psymtab: c-linkage-name-2.c: no FAIL: gdb.base/c-linkage-name.exp: print symada__cS before partial symtab \ expansion FAIL: gdb.base/c-linkage-name.exp: maint info psymtab: c-linkage-name-2.c: yes ... The "maint info psymtab" FAILs are also due to fact that the partial symbol tables not generated, but in this case it's because the symtabs are fully expanded upon load due to using -readnow. The "print symada__cS before partial symtab expansion" test intends to test the state before symbol table expansion, and with -readnow that's not possible. Mark these FAILs as UNSUPPORTED. Tested on x86_64-linux, with native, and target boards cc-with-gdb-index.exp, cc-with-debug-names.exp and readnow.exp. gdb/testsuite/ChangeLog: 2020-03-30 Tom de Vries <tdevries@suse.de> * gdb.base/c-linkage-name.exp: Use readnow call to mark a test unsupported. (verify_psymtab_expanded): Move ... * lib/gdb.exp (verify_psymtab_expanded): ... here. Add unsupported test. (readnow): New proc.
2020-03-29gdb: rename partial symtab expand functions of debug info readers using ↵Simon Marchi4-10/+23
legacy_psymtab As I am trying to understand the dynamic of partial_symtab::read_symtab and partial_symtab::expand_psymtab, I think that renaming these functions helps make it clear that they are effectively implementations of the partial_symtab::expand_psymtab method. gdb/ChangeLog: * dbxread.c (dbx_psymtab_to_symtab_1): Rename to... (dbx_expand_psymtab): ... this. (start_psymtab): Update. * mdebugread.c (psymtab_to_symtab_1): Rename to... (mdebug_expand_psymtab): ... this. (parse_partial_symbols): Update. (new_psymtab): Update. * xcoffread.c (xcoff_psymtab_to_symtab_1): Rename to... (xcoff_expand_psymtab): ... this. (xcoff_start_psymtab): Update.
2020-03-29gdb: rename partial_symtab::read_dependencies to expand_dependenciesSimon Marchi7-7/+20
This method calls partial_symtab::expand_psymtab on all dependencies of a psymtab. Given that there is also a partial_symtab::read_symtab method, I think it would be clearer to name this function expand_dependencies, rather than read_dependencies. gdb/ChangeLog: * psympriv.h (partial_symtab) <read_dependencies>: Rename to... <expand_dependencies>: ... this. * psymtab.c (partial_symtab::read_dependencies): Rename to... (partial_symtab::expand_dependencies): ... this. * dwarf2/read.c (dwarf2_include_psymtab) <expand_psymtab>: Update. (dwarf2_psymtab::expand_psymtab): Update. * dbxread.c (dbx_psymtab_to_symtab_1): Update. * mdebugread.c (psymtab_to_symtab_1): Update. * xcoffread.c (xcoff_psymtab_to_symtab_1): Update.
2020-03-29gdb: remove discard_psymtab functionSimon Marchi4-8/+8
This function does not add much value, compared to calling the method on the psymtab_storage object directly. gdb/ChangeLog: * psympriv.h (discard_psymtab): Remove. * dbxread.c (dbx_end_psymtab): Update. * xcoffread.c (xcoff_end_psymtab): Update.
2020-03-28Fix comment in dwarf2/attribute.hTom Tromey2-3/+8
I noticed that a comment in dwarf2/attribute.h still referred to dwarf2_get_attr_constant_value. However, this is now a method on struct attribute. gdb/ChangeLog 2020-03-28 Tom Tromey <tom@tromey.com> * dwarf2/attribute.h (struct attribute) <form_is_constant>: Update comment.