summaryrefslogtreecommitdiff
path: root/gdb
Commit message (Collapse)AuthorAgeFilesLines
* gdb/copyright.py: Remove testsuite/gdb.base/step-line.{c,inp} special handlingJoel Brobecker2018-01-022-3/+6
| | | | | | | | | | | | | | | In the past, these files needed to be handled by hand, because the testcase was sensitive to the length of the header, which was potentially changing when new copyright years were added to the copyright header. Now that we simply maintain and update a range, the length of the copyright header should not change as a consequence of the update performed by this script, so special handling of those files is no longer necessary. gdb/ChangeLog: * copyright.py (BY_HAND): Remove gdb/testsuite/gdb.base/step-line.inp and gdb/testsuite/gdb.base/step-line.c.
* gdb/copyright.py: Do not forget to remind about MULTIPLE_COPYRIGHT_HEADERSJoel Brobecker2018-01-022-1/+16
| | | | | | | | | | | | | | | There is a small logical error in the part of the script that dumps the list of files in BY_HAND + MULTIPLE_COPYRIGHT_HEADERS but only checkis the contents of BY_HAND. The issue becomes apparent as soon as BY_HAND is empty. Prevent this from happening by treating the two lists separately, as this allows us to provide a more informative message in the case of MULTIPLE_COPYRIGHT_HEADERS. gdb/ChangeLog: * copyright.py (main): Dump the contents of MULTIPLE_COPYRIGHT_HEADERS (separately) from BY_HAND, even if BY_HAND is empty.
* Update copyright year in version message of GDB, GDBserver and GDBreplayJoel Brobecker2018-01-025-3/+14
| | | | | | | | | | | | | gdb/ChangeLog: * top.c (print_gdb_version): Update Copyright year in version message. gdb/gdbserver/ChangeLog: * gdbreplay.c (gdbreplay_version): Update copyright year in version message. * server.c (gdbserver_version): Likewise.
* Yearly rotation of the gdb/ChangeLog fileJoel Brobecker2018-01-023-18453/+18467
| | | | | | gdb/ChangeLog * config/djgpp/fnchange.lst: Add entry for gdb/ChangeLog-2017.
* Avoid indexing std::vector past the endRuslan Kabatsayev2017-12-312-4/+9
| | | | | | | | | | | | The code here wants to find address of an element, and often this element is one past the end of std::vector. Dereferencing that element leads to undefined behavior, so it's better to simply use pointer arithmetic instead of taking address of invalid dereference. gdb/ChangeLog: * psymtab.c (recursively_search_psymtabs): Use pointer arithmetic instead of dereferencing std::vector past the end.
* Only ignore -Wenum-compare-switch if it existsSimon Marchi2017-12-302-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | My patch dwarf2read: Silence -Wenum-compare-switch warning 132448f8359a268f34f074b0908b5255b568da06 made some parts of dwarf2read.c ignore warnings about switch using enums of different kinds. What I did not realize was that older Clang versions (prior to 6) did not have that warning, and therefore give this error: /home/emaisin/src/binutils-gdb/gdb/dwarf2read.c:24187:7: error: unknown warning group '-Wenum-compare-switch', ignored [-Werror,-Wunknown-pragmas] DIAGNOSTIC_IGNORE_SWITCH_DIFFERENT_ENUM_TYPES ^ /home/emaisin/src/binutils-gdb/gdb/common/diagnostics.h:42:3: note: expanded from macro 'DIAGNOSTIC_IGNORE_SWITCH_DIFFERENT_ENUM_TYPES' DIAGNOSTIC_IGNORE ("-Wenum-compare-switch") ^ /home/emaisin/src/binutils-gdb/gdb/common/diagnostics.h:27:3: note: expanded from macro 'DIAGNOSTIC_IGNORE' _Pragma (STRINGIFY (GCC diagnostic ignored option)) ^ <scratch space>:10:25: note: expanded from here GCC diagnostic ignored "-Wenum-compare-switch" ^ Clang has a way to test if it knows about a particular warning. This patch uses that feature to only define DIAGNOSTIC_IGNORE_SWITCH_DIFFERENT_ENUM_TYPES to something if the warning is recognized by the Clang version being used. I tested building dwarf2read.c with clang 4, 5, 6, as well as gcc. gdb/ChangeLog: * common/diagnostics.h (DIAGNOSTIC_IGNORE_SWITCH_DIFFERENT_ENUM_TYPES): Only define if the compiler knows about -Wenum-compare-switch.
* dwarf2read: Silence -Wenum-compare-switch warningSimon Marchi2017-12-302-0/+12
| | | | | | | | | | | | | | | | | | | | | Compiling with Clang 6 gives: /home/emaisin/src/binutils-gdb/gdb/dwarf2read.c:24385:14: error: comparison of two values with different enumeration types in switch statement ('enum dwarf_macro_record_type' and 'dwarf_macinfo_record_type') [-Werror,-Wenum-compare-switch] case DW_MACINFO_vendor_ext: ^~~~~~~~~~~~~~~~~~~~~ /home/emaisin/src/binutils-gdb/gdb/dwarf2read.c:24561:7: error: comparison of two values with different enumeration types in switch statement ('enum dwarf_macro_record_type' and 'dwarf_macinfo_record_type') [-Werror,-Wenum-compare-switch] case DW_MACINFO_vendor_ext: ^~~~~~~~~~~~~~~~~~~~~ This code uses the two enum types on purpose, because it handles both .debug_macro and .debug_macinfo sections. Add some pragmas to disable the warning in these specific cases. gdb/ChangeLog: * dwarf2read.c (dwarf_decode_macro_bytes): Ignore -Wenum-compare-switch warning. (dwarf_decode_macros): Likewise.
* C++-ify parser_stateTom Tromey2017-12-309-102/+110
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This mildly C++-ifies parser_state and stap_parse_info -- just enough to remove some cleanups. This version includes the changes implemented by Simon. Regression tested by the buildbot. gdb/ChangeLog 2017-12-30 Tom Tromey <tom@tromey.com> Simon Marchi <simon.marchi@ericsson.com> * stap-probe.h (struct stap_parse_info): Add constructor, destructor. * stap-probe.c (stap_parse_argument): Update. * rust-exp.y (rust_lex_tests): Update. * parser-defs.h (struct parser_state): Add constructor, destructor, release method. <expout>: Change type to expression_up. (null_post_parser): Change type. (initialize_expout, reallocate_expout): Remove. * parse.c (parser_state::parser_state): Rename from initialize_expout. (parser_state::release): Rename from reallocate_expout. (write_exp_elt, parse_exp_in_context_1, increase_expout_size): Update. (null_post_parser): Change type of "exp". * dtrace-probe.c (dtrace_probe::build_arg_exprs): Update. * ada-lang.c (resolve, resolve_subexp) (replace_operator_with_call): Change type of "expp". * language.h (struct language_defn) <la_post_parser>: Change type of "expp".
* Make mapped_debug_names and mapped_index finalSimon Marchi2017-12-302-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | When compiling with Clang 6, I see these warnings: /home/emaisin/src/binutils-gdb/gdb/dwarf2read.c:25421:5: error: destructor called on non-final 'mapped_index' that has virtual functions but non-virtual destructor [-Werror,-Wdelete-non-virtual-dtor] data->index_table->~mapped_index (); ^ In file included from /home/emaisin/src/binutils-gdb/gdb/dwarf2read.c:31: In file included from /home/emaisin/src/binutils-gdb/gdb/defs.h:28: In file included from /home/emaisin/src/binutils-gdb/gdb/common/common-defs.h:92: In file included from /home/emaisin/src/binutils-gdb/gdb/common/gdb_unique_ptr.h:23: In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/memory:81: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/bits/unique_ptr.h:76:2: error: delete called on non-final 'mapped_debug_names' that has virtual functions but non-virtual destructor [-Werror,-Wdelete-non-virtual-dtor] delete __ptr; ^ /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/bits/unique_ptr.h:236:4: note: in instantiation of member function 'std::default_delete<mapped_debug_names>::operator()' requested here get_deleter()(__ptr); ^ /home/emaisin/src/binutils-gdb/gdb/dwarf2read.c:2374:21: note: in instantiation of member function 'std::unique_ptr<mapped_debug_names, std::default_delete<mapped_debug_names> >::~unique_ptr' requested here dwarf2_per_objfile::dwarf2_per_objfile (struct objfile *objfile_, ^ This patch silences these warnings by making the classes final. gdb/ChangeLog: * dwarf2read.c (struct mapped_debug_names): Make final. (struct mapped_index): Make final.
* Ignore warning about using different types of enums in switchSimon Marchi2017-12-293-0/+16
| | | | | | | | | | | | | | | | | | | | | | When compiling with clang 6, I see a bunch of warnings like this: /home/emaisin/src/binutils-gdb/gdb/amd64-linux-tdep.c:1427:8: error: comparison of two values with different enumeration types in switch statement ('enum amd64_syscall' and 'amd 64_x32_syscall') [-Werror,-Wenum-compare-switch] case amd64_x32_sys_move_pages: ^~~~~~~~~~~~~~~~~~~~~~~~ In this switch, we indeed use enumerators of both types amd64_x32_syscall and amd64_syscall. This is done on purpose, and the enum values are chosen so that they are complementary. I think it's still a useful warning, so I chose to ignore just that particular case. gdb/ChangeLog: * common/diagnostics.h (DIAGNOSTIC_IGNORE_SWITCH_DIFFERENT_ENUM_TYPES): New macro. * amd64-linux-tdep.c (amd64_canonicalize_syscall): Use it.
* Remove unnecessary call to get_thread_db_infoSimon Marchi2017-12-292-5/+6
| | | | | | | | | | | | | In thread_db_detach, we call get_thread_db_info to first check if there exists a thread_db_info entry for the pid to detach. If there is, then we call delete_thread_db_info. It's unnecessary to call get_thread_db_info in the first place, since delete_thread_db_info handles the case where no thread_db_info entry exist for the given pid. gdb/ChangeLog: * linux-thread-db.c (thread_db_detach): Remove call to delete_thread_db_info.
* Remove unused HP-UX TARGET_OBJECT_ enumsSimon Marchi2017-12-282-9/+5
| | | | | | | | | These two enumerators are unused, remove them. gdb/ChangeLog: * target.h (enum target_object) <TARGET_OBJECT_HPUX_UREGS, TARGET_OBJECT_HPUX_SOLIB_GOT>: Remove.
* tdesc: handle arbitrary strings in tdesc_register_in_reggroup_pStafford Horne2017-12-278-41/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | tdesc_register_in_reggroup_p in now able to handle arbitrary groups. This is useful when groups are created while the target descriptor file is received from the remote. This can be the case of a soft core target processor where registers/groups can change. gdb/ChangeLog: yyyy-mm-dd Franck Jullien <franck.jullien@gmail.com> Stafford Horne <shorne@gmail.com> * target-descriptions.c (tdesc_register_in_reggroup_p): Support arbitrary strings. (tdesc_use_registers): Add logic to register new reggroups. (tdesc_reg::group): Update comment to indicate we allow arbitrary strings. * NEWS (Changes since GDB 8.0): Announce that GDB supports arbitrary reggroups. gdb/testsuite/ChangeLog: yyyy-mm-dd Stafford Horne <shorne@gmail.com> * gdb.xml/extra-regs.xml: Add example foo reggroup. * gdb.xml/tdesc-regs.exp: Add test to check for foo reggroup. gdb/doc/ChangeLog: yyyy-mm-dd Stafford Horne <shorne@gmail.com> * gdb.texinfo (Target Description Format): Explain that arbitrary strings are now allowed for register groups.
* reggroups: Add reggroup_gdbarch_new, reggroup_find for dynamic reggroupsStafford Horne2017-12-273-0/+44
| | | | | | | | | | | | | | | | | | | | Traditionally reggroups have been created via reggroup_new() during initialization code and never freed. Now, if we want to initialize reggroups dynamically (i.e. in target description) we should be able to free them. Create this function reggroup_gdbarch_new() which will allocate the reggroup memory onto the passed gdbarch obstack. Also creating reggroup_find() as a utility to find a gdbarch registered reggroup object by name. gdb/ChangeLog: yyyy-mm-dd Stafford Horne <shorne@gmail.com> * reggroups.c (reggroup_gdbarch_new): New function. (reggroup_find): New function. * reggroups.h (reggroup_gdbarch_new): New function. (reggroup_find): New function.
* reggroups: Convert reggroups from post_init to pre_initStafford Horne2017-12-272-11/+13
| | | | | | | | | | | | | | | | | | | | | | Currently the reggroups gdbarch_data cannot be manipulated until after the gdbarch is completely initialized. This is usually done when the object init depends on architecture specific fields. In the case of reggroups it only depends on the obstack being available. Coverting this to pre_init allows using reggroups during gdbarch initialization. This is needed to allow registering arbitrary reggroups during gdbarch initializations. gdb/ChangeLog: yyyy-mm-dd Stafford Horne <shorne@gmail.com> * reggroups.c (reggroups_init): Change to depend only on obstack rather than gdbarch. (reggroup_add): Remove logic for forcing premature init. (_initialize_reggroup): Set `reggroups_data` with gdbarch_data_register_pre_init() rather than gdbarch_data_register_post_init().
* reggroups: Add test and docs for `info reg $reggroup` featureStafford Horne2017-12-277-2/+160
| | | | | | | | | | | | | | | | | | | | | | | | | Until now this feature has existed but was not documented. Adding docs and tests. gdb/ChangeLog: yyyy-mm-dd Stafford Horne <shorne@gmail.com> * infcmd.c (_initialize_infcmd): Add help for info reg $reggroup and info all-registers $reggroup feature. gdb/doc/ChangeLog: yyyy-mm-dd Stafford Horne <shorne@gmail.com> * gdb.texinfo (Registers): Document info reg $reggroup feature. gdb/testsuite/ChangeLog: yyyy-mm-dd Stafford Horne <shorne@gmail.com> * gdb.base/reggroups.c: New file. * gdb.base/reggroups.exp: New file.
* Add ATTRIBUTE_PRINTF to printf_field_type_assignmentSimon Marchi2017-12-232-0/+6
| | | | | | | | | | | | | | Get rid of: /home/simark/src/binutils-gdb/gdb/target-descriptions.c:2026:25: error: format string is not a string literal [-Werror,-Wformat-nonliteral] vprintf_unfiltered (fmt, args); when building with clang. gdb/ChangeLog: * target-descriptions.c (print_c_tdesc) <printf_field_type_assignment>: Add ATTRIBUTE_PRINTF.
* Do not emit "field_type" var if not needed on "maint print c-tdesc"Simon Marchi2017-12-2137-51/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While fiddling a bit with -Wunused-variable, Sergio noticed that "maint print c-tdesc" was always generating code for the "tdesc_type *field_type" variable, even when it wasn't used. This is caught by GCC when using -Wunused-variable, of course. This patch changes the print_c_tdesc class to only output the field declaration when we actually need it. It shouldn't be necessary to do the same with the other variable declarations (type_with_fields and element_type), because they are always if they are declared. The C files in features/ are regenerated, some declarations of field_type are removed, as expected, while some others move to where they are used for the first time. gdb/ChangeLog: * target-descriptions.c (print_c_tdesc) <visit>: Don't output field_type declaration, use printf_field_type_assignment instead. <printf_field_type_assignment>: New method. * features/aarch64-core.c, features/aarch64-fpu.c features/arc-arcompact.c, features/arc-v2.c, features/arm/arm-with-iwmmxt.c, features/i386/32bit-core.c, features/i386/32bit-mpx.c, features/i386/32bit-sse.c, features/i386/64bit-avx512.c, features/i386/64bit-core.c, features/i386/64bit-mpx.c, features/i386/64bit-sse.c, features/i386/x32-core.c, features/or1k.c, features/rs6000/powerpc-7400.c, features/rs6000/powerpc-altivec32.c, features/rs6000/powerpc-altivec32l.c, features/rs6000/powerpc-altivec64.c, features/rs6000/powerpc-altivec64l.c, features/rs6000/powerpc-cell32l.c, features/rs6000/powerpc-cell64l.c, features/rs6000/powerpc-isa205-altivec32l.c, features/rs6000/powerpc-isa205-altivec64l.c, features/rs6000/powerpc-isa205-vsx32l.c, features/rs6000/powerpc-isa205-vsx64l.c, features/rs6000/powerpc-vsx32.c, features/rs6000/powerpc-vsx32l.c, features/rs6000/powerpc-vsx64.c, features/rs6000/powerpc-vsx64l.c, features/s390-gs-linux64.c, features/s390-tevx-linux64.c, features/s390-vx-linux64.c, features/s390x-gs-linux64.c, features/s390x-tevx-linux64.c, features/s390x-vx-linux64.c: Re-generate.
* Remove write-only assignment in rs6000-tdep.cUros Bizjak2017-12-202-1/+5
| | | | | | | | | The result of this memory read is never used, so it can be removed. gdb/ChangeLog: * rs6000-tdep.c (ppc_deal_with_atomic_sequence): Remove write-only assignment to "insn" variable.
* [Cell/B.E.] Fix regression due to gdbarch_significant_addr_bitUlrich Weigand2017-12-203-0/+13
| | | | | | | | | | | | | | | | | | | | | On Cell/B.E. multi-architecture debugging we use a "merged" address space that encodes both the main PowerPC address space and the local store address spaces of all active SPUs. This will always occupy 64 bits. However, gdbarch_addr_bit is set to 32 on SPU, and may be set to 32 as well on PowerPC. Since the new gdbarch_significant_addr_bit defaults to the value of gdbarch_addr_bit, this means addresses may be improperly truncated. Work around this problem by explicitly setting gdbarch_significant_addr_bit to 64 both for the SPU target and also for PowerPC target that support Cell/B.E. execution. gdb/ChangeLog: 2017-12-20 Ulrich Weigand <uweigand@de.ibm.com> * spu-tdep.c (spu_gdbarch_init): Set set_gdbarch_significant_addr_bit to 64 bits. (ppc_linux_init_abi): Likewise, if Cell/B.E. is supported.
* Fix ChangeLog formattingSimon Marchi2017-12-192-2/+2
| | | | | Doing some unrelated grepping found that there were some missing spaces, fix it.
* improved error message when getting an exception printing a variableJoel Brobecker2017-12-176-5/+173
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider the following Ada code defining a global variable whose type is an array of static bounds (1 .. 2), but where its elements are a variant record whose size is not statically known: type Ints is array (Natural range <>) of Integer; type Bounded_Ints (Max_Size : Natural) is record Length : Natural := 0; Objs : Ints (1 .. Max_Size); end record; type Ints_Doubled is array (1 .. 2) of Bounded_Ints (Idem (0)); Global : Ints_Doubled; When compiling this program at -O2 using a GCC-6.4-based compiler on x86_64-linux, trying to print the value of that global variable yields: (gdb) p global $1 = Let's look at the debugging info, which starts with the global variable itself... .uleb128 0x19 # (DIE (0x25e) DW_TAG_variable) .long .LASF32 # DW_AT_name: "fd__global" .long 0x273 # DW_AT_type ... its type is a reference to a typedef ... .uleb128 0x14 # (DIE (0x273) DW_TAG_reference_type) .byte 0x8 # DW_AT_byte_size .long 0x202 # DW_AT_type [...] .uleb128 0x15 # (DIE (0x202) DW_TAG_typedef) .long .LASF19 # DW_AT_name: "fd__ints_doubled" .long 0x20d # DW_AT_type ... of an array (1..2) ... .uleb128 0x2 # (DIE (0x20d) DW_TAG_array_type) .long .LASF19 # DW_AT_name: "fd__ints_doubled" .long 0x15b # DW_AT_type .long 0x221 # DW_AT_sibling .uleb128 0x16 # (DIE (0x21a) DW_TAG_subrange_type) .long 0x40 # DW_AT_type .sleb128 2 # DW_AT_upper_bound .byte 0 # end of children of DIE 0x20d ... of a struct whose name is fd__Tints_doubledC: .uleb128 0x10 # (DIE (0x15b) DW_TAG_structure_type) .long .LASF11 # DW_AT_name: "fd__Tints_doubledC" .long 0x1e4 # DW_AT_GNAT_descriptive_type # DW_AT_artificial .long 0x1e4 # DW_AT_sibling .uleb128 0x7 # (DIE (0x16a) DW_TAG_member) .long .LASF4 # DW_AT_name: "max_size" [snip] The error occurs while Ada evaluator is trying to "fix" the element type inside the array, so as to determine its actual size. For that, it searches for a parallel "XVZ" variable, which, when found, contains the object's actual size. Unfortunately in our case, the variable exists but has been optimized out, as seen by the presence of a variable DIE in the debugging info, but with no address attribute: .uleb128 0x18 # (DIE (0x24e) DW_TAG_variable) .long .LASF31 # DW_AT_name: "fd__Tints_doubledC___XVZ" .long 0x257 # DW_AT_type # DW_AT_artificial Discussing this with some members of AdaCore's compiler team, it is expected that the optimizer can get rid of this variable, and we don't want to pessimize the code just to improve debuggability, since -O2 is about performance. So, the idea of this patch is not to make it work, but provide a bit more information to help users understand what kind of error is preventing GDB from being able to print the variable's value. The first hurdle we had to clear was the fact that ada_val_print traps all exceptions (including QUIT ones!), and does so completly silently. So, the fix was to add a trace of the exception being generated. While doing so, we fix an old XXX/FIXME by only catching errors, letting QUIT exceptions go through. Once this is done, we now get an error message, which gives a first clue as to what was happening: (gdb) p fd.global $1 = <error reading variable: value has been optimized out> However, it would be more useful to know which value it was that was optimized out. For that purpose, we enhanced ada-lang.c::ada_to_fixed_type_1 so as to re-throw the error with a message which indicates which variable we failed to read. With those changes, the new output is now: (gdb) p fd.global $1 = <error reading variable: unable to read value of fd__Tints_doubledC___XVZ (value has been optimized out)> gdb/ChangeLog: * ada-lang.c (ada_to_fixed_type_1): Rethrow errors with a more detailed exception message when getting an exception while trying to read the value of an XVZ variable. * ada-valprint.c (ada_val_print): Only catch RETURN_MASK_ERROR exceptions. Print an error message when an exception is caught. gdb/testsuite/ChangeLog: * gdb.dwarf2/ada-valprint-error.c: New file. * gdb.dwarf2/ada-valprint-error.exp: New file. Tested on x86_64-linux
* (Ada) crash assigning to record component which is an arrayJoel Brobecker2017-12-176-3/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider the following code, which declares a variabled called "input" of type "parameter", which is a record with one component called "u2", where the type of that component is a simple 3-element array of floating point values: type Float_Array_3 is array (1 .. 3) of Float; type parameters is record u2 : Float_Array_3; end record; input : parameters; Trying to assign a value to input.u2 causes GDB to crash: (gdb) p input.u2 := (0.25,0.5,0.75) [1] 20228 segmentation fault (core dumped) [...]/gdb The crash occurs because input.u2 is described in the debugging info as a typedef of an array. Indeed, input's type is: <1><ae9>: Abbrev Number: 7 (DW_TAG_structure_type) <aea> DW_AT_name : (indirect string, offset: 0x1045): target_wrapper__parameters [...] <2><af5>: Abbrev Number: 8 (DW_TAG_member) <af6> DW_AT_name : u2 [...] <afb> DW_AT_type : <0xaca> and, looking at DIE 0xaca to get input.u2's type, we see: <1><aca>: Abbrev Number: 4 (DW_TAG_typedef) <acb> DW_AT_name : (indirect string, offset: 0x1060): target_wrapper__float_array_3 [...] <ad1> DW_AT_type : <0xad5> We can also confirm, following the DW_AT_type attribute (0xad5), that it's a typedef of our array: <1><ad5>: Abbrev Number: 5 (DW_TAG_array_type) <ad6> DW_AT_name : (indirect string, offset: 0x1060): target_wrapper__float_array_3 [...] In fact, this scenario uncovered 2 areas where typedef handling is missing, thus causing a crash. The first happens inside assign_aggregate: if (ada_is_direct_array_type (lhs_type)) { lhs = ada_coerce_to_simple_array (lhs); lhs_type = value_type (lhs); low_index = TYPE_ARRAY_LOWER_BOUND_VALUE (lhs_type); high_index = TYPE_ARRAY_UPPER_BOUND_VALUE (lhs_type); } Here, lhs_type is a TYPE_CODE_TYPEDEF. ada_is_direct_array_type knows how to handle it, but TYPE_ARRAY_LOWER_BOUND_VALUE assumes that the given type is a TYPE_CODE_ARRAY. As such, it ends up accessing some fields in lhs_type which it shouldn't, and kaboom. We fixed this issue by making sure that the TYPE_CODE_TYPEDEF layer gets stripped. Once this is done, we hit a different kind of error, also leading to a SEGV, this time in assign_component. The code looks like this: if (TYPE_CODE (value_type (lhs)) == TYPE_CODE_ARRAY) [...] else [...] Because once again lhs is a TYPE_CODE_TYPEDEF, the check fail, and we end up assuming that lhs is a struct, executing the "else" block, which is: else { elt = ada_index_struct_field (index, lhs, 0, value_type (lhs)); elt = ada_to_fixed_value (elt); } Since lhs is not a struct, ada_index_struct_field returns NULL, which ada_to_fixed_value does not handle well, hence another crash. This patch fixes this other issue the same way, by stripping TYPE_CODE_TYPEDEF layers. gdb/ChangeLog: * ada-lang.c (assign_component): Strip any TYPE_CODE_TYPEDEF layer from lhs' type. (assign_aggregate): Likewise. gdb/testsuite: * gdb.ada/assign_arr: New testcase. Tested on x86_64-linux.
* Ada: fix bad handling in ada_convert_actualXavier Roirand2017-12-177-1/+118
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using this small example: procedure Foo is type Integer_Access is access all Integer; procedure P (A : Integer_Access) is begin null; end P; begin P (null); end Foo; and doing this debug session: (gdb) b p Breakpoint 1 at 0x402d67: file foo.adb, line 7. (gdb) print p(null) Breakpoint 1, foo.p (a=0x641010) at foo.adb:10 ... ^^^^^^^^^^ shows that something goes wrong between the initial null value and the received parameter value in the 'f' function. The value for the parameter 'a' we get is the address of the value we would expect instead of the value itself. This can be checked by doing: (gdb) p *a $1 = 0 Before this fix, in ada_convert_value, this function was looking to the actual value (the null value here) to determine if the formal (parameter 'a' in the procedure 'P' in this exemple) requires a pointer or not which is a wrong assumption and leads to push the address of the value to the inferior instead of the value itself. This is fixed by this patch. gdb/ChangeLog: * ada-lang.c (ada_convert_actual): Change the way actual value are passed to the inferior when the inferior expects a pointer type. gdb/testsuite/ChangeLog: * gdb.ada/funcall_ptr: New testcase. Tested on x86_64-linux.
* gdb: Fix function parameter alignments in or1k-tdep.c.Stafford Horne2017-12-172-9/+17
| | | | | | | | | | | | | | As suggested by Joel Brobecker <brobecker@adacore.com> and as per fsf coding standards. Also fix a few more issues with directly printing pointers. gdb/ChangeLog: * gdb/or1k-tdep.c (show_or1k_debug): Fix function parameter alignment. (or1k_analyse_inst): Likewise. (or1k_single_step_through_delay): Likewise. (or1k_frame_cache): Fix parameter alignment and use paddress() instead of %x.
* gdb: Add news entries for new or1k target.Stafford Horne2017-12-172-0/+9
| | | | | | | | | gdb/ChangeLog: yyyy-mm-dd Stafford Horne <shorne@gmail.com> * NEWS (Changes since GDB 8.0): Mention new or1k target and new commands to set/show or1k debug.
* Fix ARI warning on gdb/typeprint.c:whatis_expSergio Durigan Junior2017-12-152-3/+8
| | | | | | | | | | | I forgot to indent the "if" clause properly and put the "&&" at the beginning of the line, so ARI complained. This commit fixed it. gdb/ChangeLog: 2017-12-15 Sergio Durigan Junior <sergiodj@redhat.com> * typeprint.c (whatis_exp): Fix ARI warning and reindent "if" condition.
* Implement pahole-like 'ptype /o' optionSergio Durigan Junior2017-12-1510-66/+1050
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit implements the pahole-like '/o' option for 'ptype', which prints the offsets and sizes of struct fields, reporting whenever there is a hole found. The output is heavily based on pahole(1), with a few modifications here and there to adjust it to our reality. Here's an example: /* offset | size */ type = struct wer : public tuv { public: /* 32 | 24 */ struct tyu { /* 32:31 | 4 */ int a1 : 1; /* 32:28 | 4 */ int a2 : 3; /* 32: 5 | 4 */ int a3 : 23; /* 35: 3 | 1 */ char a4 : 2; /* XXX 3-bit hole */ /* XXX 4-byte hole */ /* 40 | 8 */ int64_t a5; /* 48:27 | 4 */ int a6 : 5; /* 48:56 | 8 */ int64_t a7 : 3; /* total size (bytes): 24 */ } a1; /* total size (bytes): 56 */ } A big part of this patch handles the formatting logic of 'ptype', which is a bit messy. The code to handle bitfield offsets, however, took some time to craft. My thanks to Pedro Alves for figuring things out and pointing me to the right direction, as well as coming up with a way to inspect the layout of structs with bitfields (see testcase for comments). After many discussions both on IRC and at the mailing list, I tried to implement printing vtables and inherited classes. Unfortunately the code grew too complex and there were still a few corner cases failing so I had to drop the attempt. This should be implemented in a future patch. This patch is the start of a long-term work I'll do to flush the local patches we carry for Fedora GDB. In this specific case, I'm aiming at upstreaming the feature implemented by the 'pahole.py' script that is shipped with Fedora GDB: <https://src.fedoraproject.org/rpms/gdb/blob/master/f/gdb-archer.patch#_311> This has been regression-tested on the BuildBot. There's a new testcase for it, along with an update to the documentation. I also thought it was worth mentioning this feature in the NEWS file. gdb/ChangeLog: 2017-12-15 Sergio Durigan Junior <sergiodj@redhat.com> Pedro Alves <palves@redhat.com> PR cli/16224 * NEWS (Changes since GDB 8.0): Mention new '/o' flag. * c-typeprint.c (OFFSET_SPC_LEN): New define. (c_type_print_varspec_prefix): New argument 'struct print_offset_data *'. (c_type_print_base_1): New function and prototype. (c_print_type_1): New function, with code from 'c_print_type'. (c_print_type): Use 'c_print_type_1'. (c_type_print_varspec_prefix): New argument 'struct print_offset_data *'. Use it. Call 'c_type_print_base_1' instead of 'c_print_type_base'. (print_spaces_filtered_with_print_options): New function. (output_access_specifier): Take new argument FLAGS. Modify function to call 'print_spaces_filtered_with_print_options'. (c_print_type_vtable_offset_marker): New function. (c_print_type_union_field_offset): New function. (c_print_type_struct_field_offset): New function. (c_print_type_no_offsets): New function. (c_type_print_base_struct_union): New argument 'struct print_offset_data *'. Print offsets and sizes for struct/union/class fields. * typeprint.c (const struct type_print_options type_print_raw_options): Initialize 'print_offsets'. (static struct type_print_options default_ptype_flags): Likewise. (struct print_offset_data print_offset_default_data): New variable. (whatis_exp): Handle '/o' option. (_initialize_typeprint): Add '/o' flag to ptype's help. * typeprint.h (struct print_offset_data): New struct. (struct type_print_options) <print_offsets>: New field. gdb/testsuite/ChangeLog: 2017-12-15 Sergio Durigan Junior <sergiodj@redhat.com> PR cli/16224 * gdb.base/ptype-offsets.cc: New file. * gdb.base/ptype-offsets.exp: New file. gdb/doc/ChangeLog: 2017-12-15 Sergio Durigan Junior <sergiodj@redhat.com> PR cli/16224 * gdb.texinfo (ptype): Add documentation for new flag '/o'.
* Reorganize code to handle TYPE_CODE_{STRUCT,UNION} on 'c_type_print_base'Sergio Durigan Junior2017-12-152-434/+410
| | | | | | | | | | | | | | | | | | | | While doing the 'ptype /o' work, I noticed that 'c_type_print_base' was very long, with a big amount of code just to handle the case of TYPE_CODE_{STRUCT,UNION}. This made working with the function a bit difficult, specially because of the level of indentation. This commit moves this part of the code to their own functions. Now we have a 'c_type_print_base_struct_union' with most of the code, and also 'need_access_label_p', which is a subset of the code that was also a good candidate for having its own function. gdb/ChangeLog: 2017-12-15 Sergio Durigan Junior <sergiodj@redhat.com> * c-typeprint.c (need_access_label_p): New function. (c_type_print_base_struct_union): New function. (c_type_print_base): Move code to handle TYPE_CODE_{STRUCT,UNION} to the functions mentioned above.
* Fix PR19061, gdb hangs/spins-on-cpu when debugging any program on AlphaRichard Henderson2017-12-153-6/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | This fixes PR19061, where gdb hangs/spins-on-cpu when debugging any program on Alpha. (This patch is Uros' forward port of the patch from comment #5 of the PR [1].) Patch was tested on alphaev68-linux-gnu, also tested with gcc's testsuite, where it fixed all hangs in guality.exp and simulate-thread.exp testcases. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=19061#c5 gdb/ChangeLog: 2017-12-15 Richard Henderson <rth@redhat.com> Uros Bizjak <ubizjak@gmail.com> PR gdb/19061 * alpha-tdep.c (alpha_software_single_step): Call alpha_deal_with_atomic_sequence here. (set_gdbarch_software_single_step): Set to alpha_software_single_step. * nat/linux-ptrace.h [__alpha__]: Define GDB_ARCH_IS_TRAP_BRKPT and GDB_ARCH_IS_TRAP_HWBKPT.
* Skip 'maintenance check xml-descriptions' if XML is disabledYao Qi2017-12-152-1/+8
| | | | | | | | | | | | | | | | | I see the following test failure when gdb is configured without XML support, maintenance check xml-descriptions binutils-gdb/gdb/testsuite/../features warning: Can not parse XML target description; XML support was disabled at compile time^M Tested 29 XML files, 29 failed (gdb) FAIL: gdb.gdb/unittest.exp: maintenance check xml-descriptions ${srcdir}/../features gdb/testsuite: 2017-12-15 Yao Qi <yao.qi@linaro.org> * gdb.gdb/unittest.exp: Skip 'maintenance check xml-descriptions' if XML is disabled.
* Skip parse_memory_map_tests if XML is disabledYao Qi2017-12-152-0/+10
| | | | | | | | | | | | | | | | | I find a fail in gdb unit test when gdb is configured without XML support. warning: Can not parse XML memory map; XML support was disabled at compile time^M Self test failed: self-test failed at ../../binutils-gdb/gdb/unittests/memory-map-selftests.c:65 ... Ran 31 unit tests, 1 failed^M (gdb) FAIL: gdb.gdb/unittest.exp: maintenance selftest gdb: 2017-12-15 Yao Qi <yao.qi@linaro.org> * unittests/memory-map-selftests.c: Wrap test with HAVE_LIBEXPAT.
* (Ada) Handle same component names when searching in tagged typesXavier Roirand2017-12-147-2/+364
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider the following code: type Top_T is tagged record N : Integer := 1; U : Integer := 974; A : Integer := 48; end record; type Middle_T is new Top.Top_T with record N : Character := 'a'; C : Integer := 3; end record; type Bottom_T is new Middle.Middle_T with record N : Float := 4.0; C : Character := '5'; X : Integer := 6; A : Character := 'J'; end record; Tagged records in Ada provide object-oriented features, and what is interesting in the code above is that a child tagged record introduce additional components (fields) which sometimes have the same name as one of the components in the parent. For instance, Bottom_T introduces a component named "C", while at the same time inheriting from Middle_T which also has a component named "C"; so, in essence, type Bottom_T has two components with the same name! And before people start wondering why the language can possibly be allowing that, this can only happen if the parent type has a private definition. In our case, this was brought to our attention when the parent was a generic paramenter. With that in mind... Let's say we now have a variable declared and initialized as follow: TC : Top_A := new Bottom_T; And then we use this variable to call this function procedure Assign (Obj: in out Top_T; TV : Integer); as follow: Assign (Top_T (B), 12); Now, we're in the debugger, and we're inside that procedure (Top.Assign in our gdb testcase), and we want to print the value of obj.c: Usually, the tagged record or one of the parent type owns the component to print and there's no issue but in this particular case, what does it mean to ask for Obj.C ? Since the actual type for object is type Bottom_T, it could mean two things: type component C from the Middle_T view, but also component C from Bottom_T. So in that "undefined" case, when the component is not found in the non-resolved type (which includes all the components of the parent type), then resolve it and see if we get better luck once expanded. In the case of homonyms in the derived tagged type, we don't guaranty anything, and pick the one that's easiest for us to program. This patch fixes the behavior like described above. gdb/ChangeLog: * ada-lang.c (ada_value_primitive_field): Handle field search in case of homonyms. (find_struct_field): Ditto. (ada_search_struct_field): Ditto. (ada_value_struct_elt): Ditto. (ada_lookup_struct_elt_type): Ditto. gdb/testsuite/ChangeLog: * gdb.ada/same_component_name: New testcase. Tested on x86_64-linux.
* py-breakpoint: Don't use the 'p' PyArg_ParseTupleAndKeywords format specifierSimon Marchi2017-12-142-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | In Python 3, the 'p' format specifier can be passed to PyArg_ParseTupleAndKeywords to test the argument for truth and convert it to a boolean value (the p stands for predicate). However, it is not available in Python 2, causing this error: Traceback (most recent call last): File "test.py", line 1, in <module> b1 = gdb.Breakpoint("foo", qualified=False) TypeError: argument 10 (impossible<bad format char>) This patch changes it to the 'O' specifier, which returns the Python object passed in without transformation, and uses PyObject_IsTrue on it. This is what is done for the other boolean parameters of this function (internal and temporary). This fixes the test gdb.python/py-breakpoint.exp for Python 2. gdb/ChangeLog: * python/py-breakpoint.c (bppy_init): Use 'O' format specifier for "qualified" and use PyObject_IsTrue.
* DWARF-5 .debug_names DW_IDX_type_unit fixJan Kratochvil2017-12-142-25/+128
| | | | | | | | | | | | | | | | | | | | | | | The .debug_names completely misses its support as it did not even produce DW_IDX_type_unit. gdb/ChangeLog 2017-12-14 Jan Kratochvil <jan.kratochvil@redhat.com> * dwarf2read.c (dw2_debug_names_iterator::next): Support DW_IDX_type_unit. (debug_names::dwarf5_offset_size, unit_kind): New. (debug_names::insert): Add parameter kind. (debug_names::build): Support DW_IDX_type_unit. (debug_names::recursively_write_psymbols): Update (debug_names::write_psymbols caller. (debug_names::write_one_signatured_type_data) (debug_names::write_one_signatured_type): New. (debug_names::index_key, debug_names::symbol_value) (debug_names::write_psymbols): Add kind. (debug_names::write_one_signatured_type): New. (write_debug_names): Move dwarf5_offset_size to debug_names. Use debug_names::write_one_signatured_type for type units.
* Ada: unable to compare strings (Attempt to compare array with non-array)Joel Brobecker2017-12-147-7/+124
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider the following Ada Code: type Str is new String (1 .. 4); My_str : Str := "ABCD"; This simply declares a 4-character string type. Trying to perform equality tests using it currently yield an error: (gdb) p my_str = my_str Attempt to compare array with non-array (gdb) p my_str = "ABCD" Attempt to compare array with non-array The error occurs because my_str is defined as an object whose type is a typdef to a TYPE_CODE_ARRAY, which ada_value_equal is not expecting at all (yet). This patch fixes this oversight. gdb/ChangeLog: * ada-lang.c (ada_value_equal): Add handling of typedef types when comparing array objects. gdb/testsuite/ChangeLog: * gdb.ada/str_binop_equal: New testcase. Tested on x86_64-linux.
* (Ada) Add support for task switching when debugging core filesJoel Brobecker2017-12-135-29/+148
| | | | | | | | | | | | | | | | | | The reasons for not supporting task switching when debugging core files appear to now mostly be OBE. In particular, on GNU/Linux, the thread layer is now able to retrieve the same thread info as in the live process. So, this patch is mostly about just removing the guard that limited the use of task switching to live processes. gdb/ChangeLog: * ada-tasks.c (read_atcb): Properly set task_info->ptid when !target_has_execution as well. (task_command): Remove error when !target_has_execution. gdb/testsuite/ChangeLog: * gdb.ada/task_switch_in_core: New testcase.
* python: Add qualified parameter to gdb.BreakpointSimon Marchi2017-12-1310-15/+138
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the possibility to pass a qualified=True|False parameter when creating a breakpoint in Python. It is equivalent to using -qualified in a linespec. The parameter actually accepts any Python value, and converts it to boolean using Python's standard rules for that (https://docs.python.org/3/library/stdtypes.html#truth). Unlike the -source/-line/-function/-label parameters, it is possible to use -qualified with a "normal" (non-explicit) linespec. Therefore, it is possible (unlike these other parameters) to use this new parameter along with the spec parameter. I updated the py-breakpoint.exp test. To be able to test multiple locations using a namespace, I had to switch the test case to compile as C++. If we really wanted to, we could run it as both C and C++, but omit the C++-specific parts when running it as C. gdb/ChangeLog: * location.h (string_to_event_location): Add match_type parameter. * location.c (string_to_event_location): Likewise. * python/py-breakpoint.c (bppy_init): Handle qualified parameter. gdb/doc/ChangeLog: * python.texi (Manipulating breakpoints using Python): Document qualified parameter to gdb.Breakpoint. gdb/testsuite/ChangeLog: * gdb.python/py-breakpoint.c (foo_ns::multiply): New function. * gdb.python/py-breakpoint.exp: Compile the test case as c++, call test_bkpt_qualified. (test_bkpt_qualified): New proc.
* Tighten regexp of lib/completion-support.exp:test_gdb_complete_tab_multiplePedro Alves2017-12-132-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While writing the tests included in the previous commit, I noticed that test_gdb_complete_tab_multiple would not FAIL if GDB happens to show more completions than expected before the expected list. E.g., with something like this, expecting "p foo" to complete to "foo2" and "foo3": test_gdb_complete_tab_multiple "p foo" "" { "foo2" "foo3" } and then if foo actually completes to: (gdb) p foo[TAB] foo1 foo2 foo3 ^^^^ we'd still PASS. (Note the spurious "foo1" above.) This tightens the regexp with a beginning anchor thus making the completions above cause a FAIL. Other similar functions in completion-support.exp already do something like this; I had just missed this one originally. Thankfully, this did not expose any problems in the gdb.linespec/ tests. Phew. gdb/testsuite/ChangeLog: 2017-12-13 Pedro Alves <palves@redhat.com> * lib/completion-support.exp (test_gdb_complete_tab_multiple): Tighten regexp by matching with an anchor.
* Fix regression: expression completer and scope operator (PR gdb/22584)Pedro Alves2017-12-138-13/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I noticed this regression in the expression completer: "(gdb) p std::[TAB]" => "(gdb) p std::std::" obviously we should have not completed to "std::std::". The problem is that in the earlier big completer rework, I missed taking into account the fact that with expressions, the completion word point is not always at the start of the symbol name (it is with linespecs). The fix is to run the common prefix / LCD string (what readline uses to expand the input line) through make_completion_match_str too. New testcase included, exercising both TAB completion and the complete command. gdb/ChangeLog: 2017-12-13 Pedro Alves <palves@redhat.com> * completer.c (completion_tracker::maybe_add_completion): New 'text' and 'word' parameters. Use make_completion_match_str. (completion_tracker::add_completion): New 'text' and 'word' parameters. Pass down. (completion_tracker::recompute_lowest_common_denominator): Change parameter type to gdb::unique_xmalloc_ptr rval ref. Adjust. * completer.h (completion_tracker::add_completion): New 'text' and 'word' parameters. (completion_tracker::recompute_lowest_common_denominator): Change parameter type to gdb::unique_xmalloc_ptr rval ref. (completion_tracker::recompute_lowest_common_denominator): Change parameter type to gdb::unique_xmalloc_ptr rval ref. * symtab.c (completion_list_add_name): Pass down 'text' and 'word' as well. gdb/testsuite/ChangeLog: 2017-12-13 Pedro Alves <palves@redhat.com> * gdb.cp/cpcompletion.exp: Load completion-support.exp. ("expression with namespace"): New set of tests. * gdb.cp/pr9594.cc (Test_NS::foo, Test_NS::bar) (Nested::Test_NS::qux): New. * lib/completion-support.exp (test_gdb_complete_cmd_multiple): Add defaults to 'start_quote_char' and 'end_quote_char' parameters.
* Factor out final completion match string buildingPedro Alves2017-12-136-131/+106
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have several places doing essentially the same thing; factor them out to a central place. Some of the places overallocate for no good reason, or use strcat unnecessarily. The centralized version is more precise and to the point. (I considered making the gdb::unique_xmalloc_ptr overload version of make_completer_match_str try to realloc (not xrealloc) probably avoiding an allocation in most cases, but that'd be probably overdoing it, and also, now that I'm writing this I thought I'd try to see how could we ever get to filename_completer with "text != word", but I couldn't figure it out. Running the testsuite with 'gdb_assert (text == word);' never tripped on the assertion either. So post gdb 8.1, I'll probably propose a patch to simplify filename_completer a bit, and the gdb::unique_xmalloc_str overload can be removed then.) gdb/ChangeLog: 2017-12-13 Pedro Alves <palves@redhat.com> * cli/cli-decode.c (complete_on_cmdlist, complete_on_enum): Use make_completion_match_str. * completer.c: Use gdb::unique_xmalloc_ptr and make_completion_match_str. (make_completion_match_str_1): New. (make_completion_match_str(const char *, const char *, const char *)): New. (make_completion_match_str(gdb::unique_xmalloc_ptr<char> &&, const char *, const char *)): New. * completer.h (make_completion_match_str(const char *, const char *, const char *)): New. (make_completion_match_str(gdb::unique_xmalloc_ptr<char> &&, const char *, const char *)): New. * interps.c (interpreter_completer): Use make_completion_match_str. * symtab.c (completion_list_add_name, add_filename_to_list): Use make_completion_match_str.
* python doc: Rework Breakpoint.__init__ docSimon Marchi2017-12-132-24/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | I find the documentation of the gdb.Breakpoint constructor hard to read and not very informative, especially since we have added the new linespec parameters. There are multiple problems (some are subjective): - It's not clear that you should use either the spec string or the explicit arguments, not both. - It's not clear what combination of parameters you can use. - The big block of text describing the arguments is hard to read. - Currently, it seems like the "spec" argument is mandatory, even though it is not (if you use explicit linespec). - The square bracket nesting [arg1 [, arg2[, arg3]]] makes it seems like if you specify arg3, you must specify arg1 and arg2 (it's not the case here). This patch tries to address these problems. gdb/doc/ChangeLog: * python.texi (Manipulating breakpoints using Python): Split doc of Breakpoint.__init__ in two, split text in multiple paragraphs, don't nest parameter square brackets.
* gdb: Fix ARI warnings in or1k-tdep.cStafford Horne2017-12-142-14/+23
| | | | | | | | | | | | | | | | Fix a few issues not using the gettext _() wrapper and issues where we are using %p directly instead of the dedicated host/target functions. gdb/ChangeLog: yyyy-mm-dd Stafford Horne <shorne@gmail.com> * or1k-tdep.c (or1k_analyse_inst): Use _() wrapper for message strings. (or1k_unwind_pc): Use paddress() instead of %p. (or1k_unwind_sp): Likewise. (or1k_frame_cache): Use host_address_to_string()/paddress() instead of %p and use _() wrapper for message strings.
* Fix typo in gdb_ari.shSimon Marchi2017-12-132-1/+5
| | | | | | gdb/ChangeLog: * contrib/ari/gdb_ari.sh: Fix typo in help.
* fix "server" command prefix handling (unexpected confirmation queries)Joel Brobecker2017-12-125-1/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "server" command prefix no longer turns confirmation queries off. We can reproduce this with any program by tring to delete all breakpoints, for instance: (gdb) break main Breakpoint 1 at 0x40049b: file /[...]/break-fun-addr1.c, line 21. (gdb) server delete breakpoints Delete all breakpoints? (y or n) GDB should not be asking "Delete all breakpoints? (y or n)", but instead just delete all breakpoints without asking for confirmation. Looking at utils.c::defaulted_query gives a glimpse of how this feature is expected to work: /* Automatically answer the default value if the user did not want prompts or the command was issued with the server prefix. */ if (!confirm || server_command) return def_value; So, it relies on the server_command global to be set when the "server " command prefix is used, which is no longer the case since the following commit: commit b69d38afdea34e4fecab5ea47ffe1e594e0b6233 Date: Wed Mar 9 18:25:00 2016 +0000 Subject: Command line input handling TLC The patch was simplifying the handling for the command line, and I believe there was just a small oversight of removing the setting of the server_command global. This patch restores that, and adds a testcase to make sure we test that feature. gdb/ChangeLog: * event-top.c (handle_line_of_input): Set server_command. gdb/testsuite/ChangeLog: * gdb.base/server-del-break.c: New file. * gdb.base/server-del-break.exp: New file. Tested on x86_64-linux, no regression.
* gdb: testsuite: Add or1k tdesc-regs.exp test supportStafford Horne2017-12-122-0/+7
| | | | | | | | gdb/testsuite/ChangeLog: 2017-12-12 Stafford Horne <shorne@gmail.com> * gdb.xml/tdesc-regs.exp: Add or1k support.
* gdb: testsuite: Add or1k l.nop instructionStafford Horne2017-12-122-0/+6
| | | | | | | | | | | The test case requires adding a nop instruction. For or1k the instruction is `l.nop`. This change uses the correct operation. gdb/testsuite/ChangeLog: 2017-12-12 Stafford Horne <shorne@gmail.com> * gdb.base/bp-permanent.c: Define nop of or1k.
* gdb: Add OpenRISC or1k and or1knd target supportFranck Jullien2017-12-1210-0/+1580
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch prepares the current GDB port of the OpenRISC processor from https://github.com/openrisc/binutils-gdb for upstream merging. Testing has been done with a cgen sim provided in a separate patch. This has been tested with 2 toolchains. GCC [1] 5.4.0 from the OpenRISC project with Newlib [2] and GCC 5.4.0 with Musl [3] 1.1.4. It supports or1knd (no delay slot target). The default target is or1k (with delay slot). You can change the target arch with: (gdb) set architecture or1knd The target architecture is assumed to be or1knd [1] https://github.com/openrisc/or1k-gcc [2] https://github.com/openrisc/newlib [3] https://github.com/openrisc/musl-cross gdb/doc/ChangeLog: 2017-12-12 Stafford Horne <shorne@gmail.com> Stefan Wallentowitz <stefan@wallentowitz.de> Franck Jullien <franck.jullien@gmail.com> Jeremy Bennett <jeremy.bennett@embecosm.com> * gdb.texinfo: Add OpenRISC documentation. gdb/ChangeLog: 2017-12-12 Stafford Horne <shorne@gmail.com> Stefan Wallentowitz <stefan@wallentowitz.de> Stefan Kristiansson <stefan.kristiansson@saunalahti.fi> Franck Jullien <franck.jullien@gmail.com> Jeremy Bennett <jeremy.bennett@embecosm.com> * configure.tgt: Add targets for or1k and or1knd. * or1k-tdep.c: New file. * or1k-tdep.h: New file. * features/Makefile: Add or1k.xml to build. * features/or1k.xml: New file. * features/or1k-core.xml: New file. * features/or1k.c: Generated.
* PR22576, ppc64_skip_trampoline_code uses wrong r2 for EXEC_REVERSEAlan Modra2017-12-122-58/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The TOC pointer register, r2, on powerpc64 is generally not mentioned in debug info. It is saved and restored by call linkage code, and set to the callee value either by call stub code (ELFv1) or in the callee global entry point code (ELFv2). A call stub uses the caller TOC pointer to access the PLT. So for gdb to read the correct PLT entry in order to determine the destination of the trampoline, gdb needs to know the caller r2. When skipping over trampolines in the normal forward direction, the caller r2 is simply the current value of r2 (at the start of the trampoline). However, when reversing over trampolines the current value of r2 is that for the callee. Using that value results in wild reads of memory rather than the correct PLT entry. This patch corrects the value of r2 by using the value saved on the stack for reverse execution. Note that in reverse execution mode it isn't really necessary for skip_trampoline_code to return the actual destination, so we're doing a little more work than needed here. Any non-zero return value would do (and it would be nicer if the interface was changed to return the start of the stub). PR tdep/22576 * ppc64-tdep.c (ppc64_plt_entry_point): Rewrite to take TOC-relative PLT offset, and retrieve r2 from stack when executing in reverse. (ppc64_standard_linkage1_target): Drop pc param. Calculate offset rather than PLT address. (ppc64_standard_linkage2_target): Likewise. (ppc64_standard_linkage3_target): Likewise. (ppc64_standard_linkage4_target): Likewise. (ppc64_skip_trampoline_code_1): Adjust to suit.
* remote: Return NULL extra_info/name if they are emptySimon Marchi2017-12-112-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit remote: C++ify thread_item and threads_listing_context 21fe1c752e254167d953fa8c846280f63a3a5290 broke the test gdb.threads/names.exp. The problem is that since we now use an std::string to hold the extra_info, an empty string is returned by target_extra_thread_info to print_thread_info_1 when the remote stub didn't send any extra info, instead of NULL before. Because of that, print_thread_info_1 prints the extra info between parentheses, which results in some spurious empty parentheses. Expected: * 1 Thread 22752.22752 "main" all_threads_ready () at ... Actual : * 1 Thread 22752.22752 "main" () all_threads_ready () a ... Since the bug was introduced by a behavior change in the remote target, I chose to fix it on the remote target side by making it return NULL when the extra string is empty. This will avoid possibly changing the behavior of the common code and affecting other targets. The name field has the same problem. If a remote stub returns no thread names, remote_thread_name will return an empty string instead of NULL, so print_thread_info_1 will show empty quotes ("") instead of nothing. gdb/ChangeLog: PR gdb/22556 * remote.c (remote_thread_name): Return NULL if name is empty. (remote_threads_extra_info): Return NULL if extra info is empty.
View Lorry Controller Status