aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2016-03-13gdb/s390: Fill gen_return_address hook.Marcin Kościelnicki2-0/+20
gdb/ChangeLog: * s390-linux-tdep.c (s390_gen_return_address): New function. (s390_gdbarch_init): Fill gen_return_address hook.
2016-03-11gdb: New maint info line-table command.Andrew Burgess7-0/+138
Add a new command 'maint info line-table' to display the contents of GDB's internal line table structure. Useful when trying to understand problems (within gdb) relating to line tables. gdb/ChangeLog: * symmisc.c (maintenance_info_line_tables): New function. (maintenance_print_one_line_table): New function. (_initialize_symmisc): Register 'maint info line-table' command. * NEWS: Mention new command. gdb/doc/ChangeLog: * gdb.texinfo (Symbols): Document new 'maint info line-table' command. gdb/testsuite/ChangeLog: * gdb.base/maint.exp: New tests for 'maint info line-table'.
2016-03-11gdb/s390: Fill pseudo register agent expression hooks.Marcin Kościelnicki2-0/+91
gdb/ChangeLog: * s390-linux-tdep.c (s390_ax_pseudo_register_collect): New function. (s390_ax_pseudo_register_push_stack): New function. (s390_gdbarch_init): Fill ax_pseudo_register_collect and ax_pseudo_register_push_stack hooks.
2016-03-10Add $_as_string convenience functionSimon Marchi9-0/+145
This patch is a follow-up to "Add printf format specifier for printing enumerator": https://sourceware.org/ml/gdb-patches/2016-02/msg00144.html Instead of having a solution specific to the printf command, Pedro suggested adding a general purpose function $_as_string() that would cover this use case and more. So, in order to print the textual label of an enum, one can use: (gdb) printf "Visiting node of type %s\n", $_as_string(node) Visiting node of type NODE_INTEGER gdb/ChangeLog: * data-directory/Makefile.in (PYTHON_FILE_LIST): Install gdb/function/as_string.py. * python/lib/gdb/function/as_string.py: New file. * NEWS: Mention the new $_as_string function. gdb/testsuite/ChangeLog: * gdb.python/py-as-string.exp: New file. * gdb.python/py-as-string.c: New file. gdb/doc/ChangeLog: * gdb.texinfo (Convenience Functions): Document $_as_string.
2016-03-09More "Program" -> "Thread NN received signal" testsuite adjustmentPedro Alves10-11/+24
These tests should have been adjusted by f303dbd60d9c (Fix PR threads/19422 - show which thread caused stop), but clearly I had missed grepping for potential-fail cases. gdb/testsuite/ChangeLog 2016-03-09 Pedro Alves <palves@redhat.com> * gdb.threads/attach-into-signal.exp: Adjust to "Program received signal" -> "Thread NN received signal" output change. * gdb.threads/ia64-sigill.exp: Likewise. * gdb.threads/linux-dp.exp: Likewise. * gdb.threads/manythreads.exp: Likewise. * gdb.threads/pending-step.exp: Likewise. * gdb.threads/print-threads.exp: Likewise. * gdb.threads/sigstep-threads.exp: Likewise. * gdb.threads/staticthreads.exp: Likewise. * gdb.threads/tls.exp: Likewise.
2016-03-09gdb: fix doc string of target_can_use_hardware_watchpoint.Jose E. Marchesi2-1/+6
gdb/ChangeLog 2016-03-09 Jose E. Marchesi <jose.marchesi@oracle.com> * target.h: Fix doc string of target_can_use_hardware_watchpoint.
2016-03-09Command line input handling TLCPedro Alves5-318/+219
I didn't manage to usefully split this further into smaller independent pieces, so: - Use "struct buffer" more. - Split out the responsibility of composing a complete command line from multiple input lines split with backslash ( E.g.: (gdb) print \ 1 + \ 2 $1 = 3 (gdb) ) to a separate function. Note we don't need the separate readline_input_state and more_to_come globals at all. They were just obfuscating the logic. - Factor out the tricky mostly duplicated code in command_line_handler and command_line_input. gdb/ChangeLog 2016-03-09 Pedro Alves <palves@redhat.com> * event-top.c (more_to_come): Delete. (struct readline_input_state): Delete. (readline_input_state): Delete. (get_command_line_buffer): New function. (command_handler): Update comments. Don't handle NULL commands here. Do not execute commented lines. (command_line_append_input_line): New function. (handle_line_of_input): New function, partly based on command_line_handler and command_line_input. (command_line_handler): Rewrite. * event-top.h (command_handler): New declaration. (command_loop): Defer command execution to command_handler. (command_line_input): Update comments. Simplify, using struct buffer and handle_line_of_input. * top.h (struct buffer): New forward declaration. (handle_line_of_input): New declaration.
2016-03-09Simplify saved_command_line handlingPedro Alves5-21/+19
There doesn't seem to be much point in trying to reuse this buffer. Prefer simplicity instead. (In case you're wondering whether this fixes an off-by-one: linelength is misnamed; it's really a size including terminating null char.) gdb/ChangeLog: 2016-03-09 Pedro Alves <palves@redhat.com> * event-top.c (command_line_handler): Use xfree + xstrdup instead of xrealloc + strcpy. * main.c (captured_main): Use xstrdup instead of xmalloc plus manual clear. * top.c (saved_command_line): Rewrite comment. (saved_command_line_size): Delete. (command_line_input): Use xfree + xstrdup instead of xrealloc + strcpy. * top.h (saved_command_line_size): Delete declaration.
2016-03-09Use struct buffer in gdb_readline_no_editing_callbackPedro Alves2-20/+25
gdb/ChangeLog: 2016-03-09 Pedro Alves <palves@redhat.com> * event-top.c: Include buffer.h. (gdb_readline_no_editing_callback): Use struct buffer instead of xrealloc.
2016-03-09Use struct buffer in gdb_readline_no_editingPedro Alves3-22/+34
gdb/ChangeLog: 2016-03-09 Pedro Alves <palves@redhat.com> * common/buffer.h (buffer_grow_char): New function. * top.c: Include buffer.h. (gdb_readline_no_editing): Rename 'prompt_arg' parameter to 'prompt'. Use struct buffer instead of xrealloc.
2016-03-09gdb_readline -> gdb_readline_no_editingPedro Alves3-5/+10
Name this such that it's clearer that this is not a wrapper for the real readline, but instead a replacement that provides no command line editing features. gdb/ChangeLog: 2016-03-09 Pedro Alves <palves@redhat.com> * defs.h (gdb_readline): Delete declaration. * top.c (gdb_readline): Rename to ... (gdb_readline_no_editing): ... this, and make static.
2016-03-09Update prompt_for_continue commentsPedro Alves2-14/+12
These comments are out of date -- we no longer call gdb_readline. And I think that mentioning the event loop is more useful here than whatever GO32 issue had with gdb_readline, which may even no longer be an issue. gdb/ChangeLog: 2016-03-09 Pedro Alves <palves@redhat.com> * utils.c (prompt_for_continue): Update comments.
2016-03-09Eliminate async_annotation_suffixPedro Alves4-43/+16
The comments and existence of this global are a bit of misleading obfuscation, since this is only ever used to print the prompt annotation, and never changes. Just hardcode "prompt" where necessary, as done for most other annotations. gdb/ChangeLog: 2016-03-09 Pedro Alves <palves@redhat.com> * event-top.c (async_annotation_suffix): Delete. (top_level_prompt, command_line_handler): Don't use 'async_annotation_suffix' and simplify. * event-top.h (async_annotation_suffix): Delete declaration. (init_main): Remove reference to 'async_annotation_suffix'.
2016-03-09gdb_readline2 -> gdb_readline_no_editing_callbackPedro Alves4-20/+31
The "2" in "gdb_readline2" doesn't really convey much. Rename for clarity. gdb/ChangeLog: 2016-03-09 Pedro Alves <palves@redhat.com> * event-top.c (gdb_readline2): Rename to ... (gdb_readline_no_editing_callback): ... this. (change_line_handler, stdin_event_handler) (gdb_setup_readline): Adjust. * event-top.h (gdb_readline2): Rename to ... (gdb_readline_no_editing_callback): ... this, and move closer to other readline-related declarations. * mi/mi-interp.c (mi_interpreter_resume): Adjust.
2016-03-09Garbage collect window_hookPedro Alves2-9/+5
I checked, and Insight doesn't set this. gdb/ChangeLog: 2016-03-09 Pedro Alves <palves@redhat.com> * top.c (window_hook): Delete. (command_loop): Remove references to window_hook.
2016-03-09Test issuing a command split in multiple lines with continuation charsPedro Alves2-0/+40
I happened to break this locally and the testsuite didn't notice it. Add some tests. gdb/ChangeLog: 2016-03-09 Pedro Alves <palves@redhat.com> * gdb.base/command-line-input.exp: New file.
2016-03-09gdb: Add tracepoint support for powerpc.Marcin Kościelnicki8-3/+31
gdb/gdbserver/ChangeLog: * linux-ppc-low.c (ppc_supports_tracepoints): New function. (struct linux_target_ops): Wire in the above. gdb/testsuite/ChangeLog: * gdb.trace/ftrace.exp: Set arg0exp for ppc. * gdb.trace/mi-trace-unavailable.exp: Set pcnum for ppc. * gdb.trace/pending.exp: Accept leading dot before function name. * gdb.trace/trace-common.h: Add fast tracepoint dummy insn for ppc. * lib/trace-support.exp: Set registers for ppc.
2016-03-09gdb.trace/entry-values.exp: Fixes for powerpc64.Marcin Kościelnicki2-4/+14
On powerpc64, "disassemble foo" doesn't work properly on object files (it can't process the relocations in .opd section) - instead, let's link it into an executable and load that. Also, backtrace displays .main, not main. Accept both. gdb/testsuite/ChangeLog: * gdb.trace/entry-values.exp: Link ${binfile}1.o to ${binfile}1 and use it for disassembly; accept .main in addition to main in backtrace.
2016-03-09gdb.trace/tfind.exp: Force call via global entry point on ppc64le.Marcin Kościelnicki2-2/+16
tfind.exp sets a breakpoint on *gdb_recursion_test, which is the global entry point on ppc64le, and won't be hit, since the call uses the local entry. Fix by calling the function via a pointer in a global variable, forcing use of the global entry. This patch is a slightly modified hunk extracted from https://sourceware.org/ml/gdb-patches/2015-07/msg00353.html gdb/testsuite/ChangeLog: 2016-03-09 Wei-cheng Wang <cole945@gmail.com> Marcin Kościelnicki <koriakin@0x04.net> * gdb.trace/actions.c (gdb_recursion_test_fp): New typedef. (gdb_recursion_test_ptr): New global variable. (gdb_recursion_test): Call gdb_recursion_test_ptr instead of gdb_recursion_test. (gdb_c_test): Ditto.
2016-03-09gdb.trace/change-loc.exp: Don't depend on tracepoint ordering.Marcin Kościelnicki2-4/+21
powerpc (32-bit) loads shared libraries below the main executable, so the PENDING location is the first one, which the current regex doesn't match. Split it into two tests instead, one looking for the pending tracepoint location, and the other for two installed locations. gdb/testsuite/ChangeLog: * gdb.trace/change-loc.exp: Don't depend on tracepoint location ordering.
2016-03-09gdb.trace: Use manually-defined start labels in unavailable-dwarf-piece.expMarcin Kościelnicki3-4/+13
On powerpc64, foo/bar point to a function descriptor, not to function code. Since there are no global labels pointing at the actual function code, let's make our own. Regression-tested on x86_64. gdb/testsuite/ChangeLog: * gdb.trace/unavailable-dwarf-piece.c (foo): Add foo_start_lbl label. (bar): Add bar_start_lbl label. * gdb.trace/unavailable-dwarf-piece.exp: Use foo/bar_start_lbl instead of foo/bar for emitting DWARF and tracing.
2016-03-09gdb/rs6000: Read backchain as unsigned.Marcin Kościelnicki4-3/+30
Previously, backchain was read as a signed quantity, resulting in addresses like 0xfffffffffffeded0 instead of 0xfffeded0 returned by unwinder on 32-bit powerpc. While normally such addresses are masked off, this causes problems for tracepoints, since 0xfffffffffffeded0 is considered unavailable. Fixes a test failure in gdb.trace/entry-values.exp. gdb/ChangeLog: * corefile.c (safe_read_memory_unsigned_integer): New function. * gdbcore.h (safe_read_memory_unsigned_integer): New prototype. * rs6000-tdep.c (rs6000_frame_cache): Read backchain as unsigned.
2016-03-09gdb: Add gen_return_address for powerpc.Marcin Kościelnicki2-0/+23
gdb/ChangeLog: * rs6000-tdep.c: Add "ax.h" and "ax-gdb.h" includes. (rs6000_gen_return_address): New function. (rs6000_gdbarch_init): Wire in the above.
2016-03-09gdb: Add ax_pseudo_register_collect for powerpc.Marcin Kościelnicki2-0/+51
gdb/ChangeLog: * rs6000-tdep.c (rs6000_ax_pseudo_register_collect): New function. (rs6000_gdbarch_init): Wire in the above.
2016-03-09S390: Recognize special jumps in prologue parserAndreas Arnez2-2/+19
Functions compiled with the gcc option `-mhotpatch' may start with a branch-never BRCL instruction as a 6-byte NOP. And functions compiled with `-mstack-size' contain a BRC instruction in their prologue that is actually a conditional trap. Both of these special jumps cause the prologue parser to stop and yield bad unwinding results. This change makes the prologue analyzer recognize such special jumps and ignore them. gdb/ChangeLog: * s390-linux-tdep.c (s390_analyze_prologue): Ignore BRC and BRCL instructions that do nothing or are conditional traps.
2016-03-09S390: Add use of unavailable-stack frame IDAndreas Arnez2-5/+18
When determining the frame ID of an inline frame, GDB currently asserts that a valid ID of the underlying real frame is found, and that it does not match outer_frame_id. From inline_frame_this_id(): /* For now, require we don't match outer_frame_id either (see comment above). */ gdb_assert (!frame_id_eq (*this_id, outer_frame_id)); However, this assertion may fail when the real frame's unwinder can not determine the frame ID. This happened on an s390x target with a binary that lacked call frame information and also confused the prologue analyzer, because then s390_frame_this_id() left the frame ID at its default. To fix this, this change enhances s390_frame_this_id such that an unavailable-stack frame ID is built if no frame base can be determined but the function address is available. gdb/ChangeLog: * s390-linux-tdep.c (s390_prologue_frame_unwind_cache): Store frame func's PC in info->func before any other failure can occur. (s390_frame_this_id): Use frame_id_build_unavailable_stack if info->func has been filled out.
2016-03-09Avoid spaces in osabi namesPedro Alves2-9/+13
It's not possible today to select some of the osabis by name. Specifically, those that have spaces in their names and then the first word is ambiguous... For example: (gdb) set osabi <TAB> [...] FreeBSD ELF FreeBSD a.out [...] (gdb) set osabi FreeBSD ELF Ambiguous item "FreeBSD ELF". In reality, because "set osabi" is an enum command, that was equivalent to trying "set osabi FreeBSD", which is then obviously ambiguous, because of "FreeBSD ELF" and "FreeBSD a.out". Also, even if the first word is not ambiguous, we actually ignore whatever comes after the first word: (gdb) set osabi GNU/Linux (gdb) show osabi The current OS ABI is "GNU/Linux". The default OS ABI is "GNU/Linux". (gdb) set osabi Windows SomeNonsense ^^^^^^^^^^^^ (gdb) show osabi The current OS ABI is "Windows CE". The default OS ABI is "GNU/Linux". (gdb) Fix this by avoiding spaces in osabi names. We could instead make "set osabi" have a custom set hook, or alternatively make the enum set hook (in cli-setshow.c) handle values with spaces, but OTOH, I have a feeling that could cause trouble. E.g., in cases where we might want to write more than one enum value in the same line. We could support quoting as workaround, but, not sure we want that. "No spaces" seems like a simpler rule. gdb/ChangeLog: 2016-03-09 Pedro Alves <palves@redhat.com> * osabi.c (gdb_osabi_names): Avoid spaces in osabi names.
2016-03-09[FR-V] Handle FR300Pedro Alves2-0/+6
Even though "set architecture" presents fr300 as option: (gdb) set architecture fr<TAB> fr300 fr400 fr450 fr500 fr550 frv Actually selecting fr300 doesn't work: (gdb) set architecture fr300 Architecture `fr300' not recognized. The target architecture is set automatically (currently i386) (gdb) This just looks like an obvious oversight. Looking around gcc and binutils sources, FR300 is basically a FR500 specialized for DSP and low power. gdb/ChangeLog: 2016-03-09 Pedro Alves <palves@redhat.com> * frv-tdep.c (frv_gdbarch_init): Handle bfd_mach_fr300.
2016-03-09[CRIS] Don't internal error if forced big endianPedro Alves2-9/+12
This fixes: $ ./gdb -q -ex "set endian big" -ex "set architecture cris" The target is assumed to be big endian .../src/gdb/cris-tdep.c:4051: internal-error: cris_gdbarch_init: big endian byte order in info A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) The "set cris-version" command can likewise cause internal errors. The gdbarch init routine should be returning 0 to reject the architecture instead of internal erroring on user input. gdb/ChangeLog: 2016-03-09 Pedro Alves <palves@redhat.com> * cris-tdep.c (cris_gdbarch_init): Return 0 if the info's byte order is BFD_ENDIAN_BIG or if the cris version is unsupported.
2016-03-09Fix floating conversion buffer overrun when host/target format matchesPedro Alves2-10/+26
Running the testsuite with a gdb configured with --enable-libmcheck reveals a problem: (gdb) ptype 3 * 2.0 type = <12-byte float> memory clobbered past end of allocated block ERROR: Process no longer exists UNRESOLVED: gdb.ada/ptype_arith_binop.exp: ptype 3 * 2.0 (gdb) PASS: gdb.dlang/expression.exp: ptype 0x1.FFFFFFFFFFFFFp1023 ptype 0x1p-52L type = real memory clobbered past end of allocated block ERROR: Process no longer exists UNRESOLVED: gdb.dlang/expression.exp: ptype 0x1p-52L Even though this shows up with Ada and D, it's easy to reproduce in C too. We just need to print a long double, when the current arch is 32-bit, which is the default when gdb starts up: $ ./gdb -q -ex "ptype 1.0L" type = long double memory clobbered past end of allocated block Aborted (core dumped) Valgrind shows: ==22159== Invalid write of size 8 ==22159== at 0x8464A9: floatformat_from_doublest (doublest.c:756) ==22159== by 0x846822: store_typed_floating (doublest.c:867) ==22159== by 0x6A7959: value_from_double (value.c:3662) ==22159== by 0x6A9F2D: evaluate_subexp_standard (eval.c:745) ==22159== by 0x7F31AF: evaluate_subexp_c (c-lang.c:716) ==22159== by 0x6A8986: evaluate_subexp (eval.c:79) ==22159== by 0x6A8BA3: evaluate_type (eval.c:174) ==22159== by 0x817CCF: whatis_exp (typeprint.c:456) ==22159== by 0x817EAA: ptype_command (typeprint.c:508) ==22159== by 0x5F267B: do_cfunc (cli-decode.c:105) ==22159== by 0x5F5618: cmd_func (cli-decode.c:1885) ==22159== by 0x83622A: execute_command (top.c:475) ==22159== Address 0x8c6cb28 is 8 bytes inside a block of size 12 alloc'd ==22159== at 0x4C2AA98: calloc (vg_replace_malloc.c:711) ==22159== by 0x87384A: xcalloc (common-utils.c:83) ==22159== by 0x873889: xzalloc (common-utils.c:93) ==22159== by 0x6A34CB: allocate_value_contents (value.c:1036) ==22159== by 0x6A3501: allocate_value (value.c:1047) ==22159== by 0x6A790A: value_from_double (value.c:3656) ==22159== by 0x6A9F2D: evaluate_subexp_standard (eval.c:745) ==22159== by 0x7F31AF: evaluate_subexp_c (c-lang.c:716) ==22159== by 0x6A8986: evaluate_subexp (eval.c:79) ==22159== by 0x6A8BA3: evaluate_type (eval.c:174) ==22159== by 0x817CCF: whatis_exp (typeprint.c:456) ==22159== by 0x817EAA: ptype_command (typeprint.c:508) ==22159== type = long double (gdb) Even if the target and host floating-point formats match, the length of the types might still be different. On x86, long double is the 80-bit extended precision type on both 32-bit and 64-bit ABIs, but by default it is stored as 12 bytes on 32-bit, and 16 bytes on 64-bit, for alignment reasons. Several places in doublest.c already consider this, but floatformat_to_doublest and floatformat_from_doublest miss it. E.g., convert_typed_floating and store_typed_floating, Tested on x86-64 Fedora 23 with --enable-libmcheck, where it fixes the crashed above. gdb/ChangeLog: 2016-03-09 Pedro Alves <palves@redhat.com> * doublest.c: Extend comments. (floatformat_to_doublest, floatformat_from_doublest): Copy the floatformat's total size, not the host type's size.
2016-03-09Assert that a floating type's length is at least as long as its formatPedro Alves4-2/+37
This would have caught the HP/PA bug fixed in the previous patch: .../src/gdb/gdbtypes.c:4690: internal-error: arch_float_type: Assertion `len >= floatformat_totalsize_bytes (floatformats[0])' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) Tested on x86-64 Fedora 23, --enable-targets=all. gdb/ChangeLog: 2016-03-09 Pedro Alves <palves@redhat.com> * doublest.c (floatformat_totalsize_bytes): New function. (floatformat_from_type): Assert that the type's length is at least as long as the floatformat's totalsize. * doublest.h (floatformat_totalsize_bytes): New declaration. * gdbtypes.c (arch_float_type): Assert that the type's length is at least as long as the floatformat's totalsize.
2016-03-09Fix HP/PA GNU/Linux "long double" formatPedro Alves2-0/+6
This: $ ./gdb -ex "set architecture hppa1.0" -ex "set osabi GNU/Linux" -ex "ptype 1.0L" Shows that HPPA/Linux support for long doubles is broken. It causes GDB to access memory out of bounds. With Valgrind, we see: The target architecture is assumed to be hppa1.0 ==4371== Invalid write of size 8 ==4371== at 0x4C2F21F: memset (vg_replace_strmem.c:1224) ==4371== by 0x8451C4: convert_doublest_to_floatformat (doublest.c:362) ==4371== by 0x845F86: floatformat_from_doublest (doublest.c:769) ==4371== by 0x84628E: store_typed_floating (doublest.c:873) ==4371== by 0x6A7C3D: value_from_double (value.c:3662) ==4371== by 0x6AA211: evaluate_subexp_standard (eval.c:745) ==4371== by 0x7F306D: evaluate_subexp_c (c-lang.c:716) ==4371== by 0x6A8C6A: evaluate_subexp (eval.c:79) ==4371== by 0x6A8E87: evaluate_type (eval.c:174) ==4371== by 0x817B8D: whatis_exp (typeprint.c:456) ==4371== by 0x817D68: ptype_command (typeprint.c:508) ==4371== by 0x5F2977: do_cfunc (cli-decode.c:105) ==4371== Address 0x8998d18 is 0 bytes after a block of size 8 alloc'd ==4371== at 0x4C2AA98: calloc (vg_replace_malloc.c:711) ==4371== by 0x8732B6: xcalloc (common-utils.c:83) ==4371== by 0x8732F5: xzalloc (common-utils.c:93) ==4371== by 0x6A37AF: allocate_value_contents (value.c:1036) ==4371== by 0x6A37E5: allocate_value (value.c:1047) ==4371== by 0x6A7BEE: value_from_double (value.c:3656) ==4371== by 0x6AA211: evaluate_subexp_standard (eval.c:745) ==4371== by 0x7F306D: evaluate_subexp_c (c-lang.c:716) ==4371== by 0x6A8C6A: evaluate_subexp (eval.c:79) ==4371== by 0x6A8E87: evaluate_type (eval.c:174) ==4371== by 0x817B8D: whatis_exp (typeprint.c:456) ==4371== by 0x817D68: ptype_command (typeprint.c:508) The trouble is that hppa_linux_init_abi overrides the default long_double_bit set by the generic hppa-tdep.c: set_gdbarch_long_double_bit (gdbarch, 128); set_gdbarch_long_double_format (gdbarch, floatformats_ia64_quad); with: /* On hppa-linux, currently, sizeof(long double) == 8. There has been some discussions to support 128-bit long double, but it requires some more work in gcc and glibc first. */ set_gdbarch_long_double_bit (gdbarch, 64); which misses overriding the long_double_format, so we end with a weird combination of: set_gdbarch_long_double_bit (gdbarch, 64); set_gdbarch_long_double_format (gdbarch, floatformats_ia64_quad); Weird because floatformats_ia64_quad's totalsize is longer than 64-bits. The floatformat conversion routines use the struct floatformat's totalsize (in bits) to know how much to copy/convert, thus the buffer overruns. gdb/ChangeLog: 2016-03-09 Pedro Alves <palves@redhat.com> * hppa-linux-tdep.c (hppa_linux_init_abi): Set the long double format to floatformats_ieee_double.
2016-03-07Fix "set architecture mips:10000" crashPedro Alves2-1/+7
Fix this GDB crash: $ gdb -ex "set architecture mips:10000" Segmentation fault (core dumped) Backtrace: Program received signal SIGSEGV, Segmentation fault. 0x0000000000495b1b in mips_gdbarch_init (info=..., arches=0x0) at /home/pedro/gdb/mygit/cxx-convertion/src/gdb/mips-tdep.c:8436 8436 if (bfd_get_flavour (info.abfd) == bfd_target_elf_flavour (top-gdb) bt #0 0x0000000000495b1b in mips_gdbarch_init (info=..., arches=0x0) at .../src/gdb/mips-tdep.c:8436 #1 0x00000000007348a6 in gdbarch_find_by_info (info=...) at .../src/gdb/gdbarch.c:5155 #2 0x000000000073563c in gdbarch_update_p (info=...) at .../src/gdb/arch-utils.c:522 #3 0x0000000000735585 in set_architecture (ignore_args=0x0, from_tty=1, c=0x26bc870) at .../src/gdb/arch-utils.c:496 #4 0x00000000005f29fd in do_sfunc (c=0x26bc870, args=0x0, from_tty=1) at .../src/gdb/cli/cli-decode.c:121 #5 0x00000000005fd3f3 in do_set_command (arg=0x7fffffffdcdd "mips:10000", from_tty=1, c=0x26bc870) at .../src/gdb/cli/cli-setshow.c:455 #6 0x0000000000836157 in execute_command (p=0x7fffffffdcdd "mips:10000", from_tty=1) at .../src/gdb/top.c:460 #7 0x000000000071abfb in catch_command_errors (command=0x835f6b <execute_command>, arg=0x7fffffffdccc "set architecture mips:10000", from_tty=1) at .../src/gdb/main.c:368 #8 0x000000000071bf4f in captured_main (data=0x7fffffffd750) at .../src/gdb/main.c:1132 #9 0x0000000000716737 in catch_errors (func=0x71af44 <captured_main>, func_args=0x7fffffffd750, errstring=0x106b9a1 "", mask=RETURN_MASK_ALL) at .../src/gdb/exceptions.c:240 #10 0x000000000071bfe6 in gdb_main (args=0x7fffffffd750) at .../src/gdb/main.c:1164 #11 0x000000000040a6ad in main (argc=4, argv=0x7fffffffd858) at .../src/gdb/gdb.c:32 (top-gdb) We already check whether info.abfd is NULL before all other bfd_get_flavour calls in the same function. Just this one case was missing. (This was exposed by a WIP test that tries all "set architecture ARCH" values.) gdb/ChangeLog: 2016-03-07 Pedro Alves <palves@redhat.com> * mips-tdep.c (mips_gdbarch_init): Check whether info.abfd is NULL before calling bfd_get_flavour.
2016-03-06Set executable bit on analyze-racy-logs.pySergio Durigan Junior2-0/+4
I forgot to do it in my previous commit. This is necessary because we execute the script directly on gdb/testsuite/Makefile.in. gdb/testsuite/ChangeLog: 2016-03-06 Sergio Durigan Junior <sergiodj@redhat.com> * analyze-racy-logs.py: Set executable bit.
2016-03-05Improve analysis of racy testcasesSergio Durigan Junior4-3/+298
This is an initial attempt to introduce some mechanisms to identify racy testcases present in our testsuite. As can be seen in previous discussions, racy tests are really bothersome and cause our BuildBot to pollute the gdb-testers mailing list with hundreds of false-positives messages every month. Hopefully, identifying these racy tests in advance (and automatically) will contribute to the reduction of noise traffic to gdb-testers, maybe to the point where we will be able to send the failure messages directly to the authors of the commits. I spent some time trying to decide the best way to tackle this problem, and decided that there is no silver bullet. Racy tests are tricky and it is difficult to catch them, so the best solution I could find (for now?) is to run our testsuite a number of times in a row, and then compare the results (i.e., the gdb.sum files generated during each run). The more times you run the tests, the more racy tests you are likely to detect (at the expense of waiting longer and longer). You can also run the tests in parallel, which makes things faster (and contribute to catching more racy tests, because your machine will have less resources for each test and some of them are likely to fail when this happens). I did some tests in my machine (8-core i7, 16GB RAM), and running the whole GDB testsuite 5 times using -j6 took 23 minutes. Not bad. In order to run the racy test machinery, you need to specify the RACY_ITER environment variable. You will assign a number to this variable, which represents the number of times you want to run the tests. So, for example, if you want to run the whole testsuite 3 times in parallel (using 2 cores), you will do: make check RACY_ITER=3 -j2 It is also possible to use the TESTS variable and specify which tests you want to run: make check TEST='gdb.base/default.exp' RACY_ITER=3 -j2 And so on. The output files will be put at the directory gdb/testsuite/racy_outputs/. After make invokes the necessary rules to run the tests, it finally runs a Python script that will analyze the resulting gdb.sum files. This Python script will read each file, and construct a series of sets based on the results of the tests (one set for FAIL's, one for PASS'es, one for KFAIL's, etc.). It will then do some set operations and come up with a list of unique, sorted testcases that are racy. The algorithm behind this is: for state in PASS, FAIL, XFAIL, XPASS...; do if a test's state in every sumfile is $state; then it is not racy else it is racy (The algorithm is actually a bit more complex than that, because it takes into account other things in order to decide whether the test should be ignored or not). IOW, a test must have the same state in every sumfile. After processing everything, the script prints the racy tests it could identify on stdout. I am redirecting this to a file named racy.sum. Something else that I wasn't sure how to deal with was non-unique messages in our testsuite. I decided to do the same thing I do in our BuildBot: include a unique identifier in the end of message, like: gdb.base/xyz.exp: non-unique message gdb.base/xyz.exp: non-unique message <<2>> This means that you will have to be careful about them when you use the racy.sum file. I ran the script several times here, and it did a good job catching some well-known racy tests. Overall, I am satisfied with this approach and I think it will be helpful to have it upstream'ed. I also intend to extend our BuildBot and create new, specialized builders that will be responsible for detecting the racy tests every X number of days. 2016-03-05 Sergio Durigan Junior <sergiodj@redhat.com> * Makefile.in (DEFAULT_RACY_ITER): New variable. (CHECK_TARGET_TMP): Likewise. (check-single-racy): New rule. (check-parallel-racy): Likewise. (TEST_TARGETS): Adjust rule to account for RACY_ITER. (do-check-parallel-racy): New rule. (check-racy/%.exp): Likewise. * README (Racy testcases): New section. * analyze-racy-logs.py: New file.
2016-03-05Fix argument passing for callDenis Chertykov2-7/+16
When calling function with argument of size more than 8 bytes fails with an error "That operation is not available on integers of more than 8 bytes.". avr-gdb considers only 8 bytes (sizeof(long long)) in case of passing the argument in registers. When the argument is of size more than 8 byte then the utility function to extract bytes failed with the above error. gdb/ * avr-tdep.c (AVR_LAST_ARG_REGNUM): Define. (avr_push_dummy_call): Correct last needed argument register. Write MSB of argument into register and subsequent bytes into other registers in decreasing order.
2016-03-04ARM process record: VMOVYao Qi2-11/+7
ARM process record gets the wrong register number for VMOV (from core register to single-precision register). That is, we should record the D register rather than the S pseudo register. The patch also removes the condition "bit (arm_insn_r->arm_insn, 20)" check, which has been checked above. It fixes the following internal error, (gdb) PASS: gdb.reverse/finish-precsave.exp: BP at end of main continue^M Continuing.^M ../../binutils-gdb/gdb/regcache.c:649: internal-error: regcache_raw_read: Assertion `regnum >= 0 && regnum < regcache->descr->nr_raw_registers' failed.^M A problem internal to GDB has been detected,FAIL: gdb.reverse/finish-precsave.exp: run to end of main (GDB internal error) gdb: 2016-03-04 Yao Qi <yao.qi@linaro.org> * arm-tdep.c (arm_record_vdata_transfer_insn): Simplify the condition check. Record the right D register number.
2016-03-04Tweak ARM process recordYao Qi2-32/+29
This patch removes the printing "Process record does not support", and do the print by calling arm_record_unsupported_insn in the caller. Also, call arm_record_extension_space only when condition is 0xf. gdb: 2016-03-04 Yao Qi <yao.qi@linaro.org> * arm-tdep.c (arm_record_extension_space): Remove code printing "Process record does not support". (arm_record_data_proc_misc_ld_str): Likewise. (decode_insn): Call arm_record_extension_space if condition is 0xf. Call arm_record_unsupported_insn if ret isn't ARM_RECORD_SUCCESS. Use 'ret' instead of 'insn_id' to hold the value of thumb2_record_decode_insn_handler.
2016-03-04feature_to_c.sh: Print help when passing no argumentsSimon Marchi2-4/+9
I found that odd that passing no arguments to feature_to_c.sh produces this: $ ./feature_to_c.sh ./feature_to_c.sh: 23: shift: can't shift that many but passing one argument shows the help: $ ./feature_to_c.sh hello Usage: ./feature_to_c.sh OUTPUTFILE INPUTFILE... This patch changes the script to show the help in both cases. gdb/ChangeLog: * features/feature_to_c.sh: Print the help when passing no argument.
2016-03-03gdb.base/skip.exp: Use with_test_prefix.Doug Evans2-126/+147
gdb/testsuite/ChangeLog: * gdb.base/skip.exp: Use with_test_prefix.
2016-03-03Update comments to start_step_overYao Qi2-12/+8
I happen to see that comments to start_step_over isn't in sync with code, so this patch is to update the comments. gdb/gdbserver: 2016-03-03 Yao Qi <yao.qi@linaro.org> * linux-low.c: Update comments to start_step_over.
2016-03-03New test about step over clone syscallYao Qi3-0/+82
This patch adds a new test for stepping over clone syscall. 2016-03-03 Yao Qi <yao.qi@linaro.org> * gdb.base/step-over-syscall.exp (step_over_syscall): Kfail. Invoke step_over_syscall "clone" and break_cond_on_syscall "clone". * gdb.base/step-over-clone.c: New file.
2016-03-03Reformat gdb.base/step-over-syscall.expYao Qi2-30/+34
gdb/testsuite: 2016-03-03 Yao Qi <yao.qi@linaro.org> * gdb.base/step-over-syscall.exp (disp_step_cross_syscall): Fix code format.
2016-03-03Rename disp-step-syscall.exp to step-over-syscall.expYao Qi4-7/+18
disp-step-syscall.exp is extended for stepping over syscall instruction in different cases, with or without displaced stepping, and stepping over by GDBserver. This patch rename disp-step-syscall.exp to step-over-syscall.exp to reflect this. gdb/testsuite: 2016-03-03 Yao Qi <yao.qi@linaro.org> * gdb.base/disp-step-fork.c: Rename to ... * gdb.base/step-over-fork.c: ... it. New file. * gdb.base/disp-step-vfork.c: Rename to ... * gdb.base/step-over-vfork.c: ... it. New file. * gdb.base/disp-step-syscall.exp: Rename to ... * gdb.base/step-over-syscall.exp: ... it. New file. (disp_step_cross_syscall): Rename to ... (step_over_syscall): ... it.
2016-03-03Step over fork/vfork syscall insn in gdbserverYao Qi2-0/+63
We can also extend disp-step-syscall.exp to test GDBserver step over breakpoint on syscall instruction. That is, we set a breakpoint with a false condition on syscall instruction, so that GDBserver will step over it. This test triggers a GDBserver internal error, which can be fixed by this series. (gdb) PASS: gdb.base/disp-step-syscall.exp: fork: break cond on target: break on syscall insns continue^M Continuing.^M Remote connection closed^M (gdb) FAIL: gdb.base/disp-step-syscall.exp: fork: break cond on target: continue to fork again In GDBserver, there is an internal error, /home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/linux-low.c:1922: A problem internal to GDBserver has been detected. unsuspend LWP 25554, suspended=-1 the simplified reproducer is like, $ ./gdb ./testsuite/outputs/gdb.base/disp-step-syscall/disp-step-fork (gdb) b main (gdb) c (gdb) disassemble fork // in order to find the address of insn 'syscall' .... 0x00007ffff7ad6023 <+179>: syscall (gdb) b *0x00007ffff7ad6023 if main == 0 (gdb) c gdb/testsuite: 2016-03-03 Yao Qi <yao.qi@linaro.org> * gdb.base/disp-step-syscall.exp (break_cond_on_syscall): New. If target supports condition evaluation on target, invoke break_cond_on_syscall for fork and vfork.
2016-03-03Step over syscalll insn with disp-step on and offYao Qi2-6/+14
disp-step-syscall.exp was added to test displaced stepping over syscall instructions, in which we set breakpoint on syscall instruction, and step over it. In fact, we can extend the test to non-displaced-stepping case. This patch wraps the test with displaced stepping on and off. Note that the indentation and format isn't adjusted here to make this patch easy to read. The following patch will fix the format separately. gdb/testsuite: 2016-03-03 Yao Qi <yao.qi@linaro.org> * gdb.base/disp-step-syscall.exp: Don't invoke support_displaced_stepping. (disp_step_cross_syscall): Test with displaced stepping off and on if supported.
2016-03-03Refactor gdb.base/disp-step-syscall.exp for general step over testYao Qi2-66/+91
This patch moves some code out of disp_step_cross_syscall to a new proc check_pc_after_cross_syscall and setup. Procedure setup is to start a fresh GDB and compute the syscall instruction address. gdb/testsuite: 2016-03-03 Yao Qi <yao.qi@linaro.org> * gdb.base/disp-step-syscall.exp (check_pc_after_cross_syscall): New proc. (setup): New proc. (disp_step_cross_syscall): Move code to check_pc_after_cross_syscall and setup.
2016-03-03[GDBserver] Leave child suspended when step over parentYao Qi2-5/+17
I see the following GDBserver internal error in two cases, gdb/gdbserver/linux-low.c:1922: A problem internal to GDBserver has been detected. unsuspend LWP 17200, suspended=-1 1. step over a breakpoint on fork/vfork syscall instruction, 2. step over a breakpoint on clone syscall instruction and child threads hits a breakpoint, the stack backtrace is #0 internal_error (file=file@entry=0x44c4c0 "gdb/gdbserver/linux-low.c", line=line@entry=1922, fmt=fmt@entry=0x44c7d0 "unsuspend LWP %ld, suspended=%d\n") at gdb/gdbserver/../common/errors.c:51 #1 0x0000000000424014 in lwp_suspended_decr (lwp=<optimised out>, lwp=<optimised out>) at gdb/gdbserver/linux-low.c:1922 #2 0x000000000042403a in unsuspend_one_lwp (entry=<optimised out>, except=0x66e8c0) at gdb/gdbserver/linux-low.c:2885 #3 0x0000000000405f45 in find_inferior (list=<optimised out>, func=func@entry=0x424020 <unsuspend_one_lwp>, arg=arg@entry=0x66e8c0) at gdb/gdbserver/inferiors.c:243 #4 0x00000000004297de in unsuspend_all_lwps (except=0x66e8c0) at gdb/gdbserver/linux-low.c:2895 #5 linux_wait_1 (ptid=..., ourstatus=ourstatus@entry=0x665ec0 <last_status>, target_options=target_options@entry=0) at gdb/gdbserver/linux-low.c:3632 #6 0x000000000042a764 in linux_wait (ptid=..., ourstatus=0x665ec0 <last_status>, target_options=0) at gdb/gdbserver/linux-low.c:3770 #7 0x0000000000411163 in mywait (ptid=..., ourstatus=ourstatus@entry=0x665ec0 <last_status>, options=options@entry=0, connected_wait=connected_wait@entry=1) at gdb/gdbserver/target.c:214 #8 0x000000000040b1f2 in resume (actions=0x66f800, num_actions=1) at gdb/gdbserver/server.c:2757 #9 0x000000000040f660 in handle_v_cont (own_buf=0x66a630 "vCont;c:p45e9.-1") at gdb/gdbserver/server.c:2719 when GDBserver steps over a thread, other threads have been suspended, the "stepping" thread may create new thread, but GDBserver doesn't set it suspend count to 1. When GDBserver unsuspend threads, the child's suspend count goes to -1, and the assert is triggered. In fact, GDBserver has already taken care of suspend count of new thread when GDBserver is suspending all threads except the one GDBserver wants to step over by https://sourceware.org/ml/gdb-patches/2015-07/msg00946.html + /* If we're suspending all threads, leave this one suspended + too. */ + if (stopping_threads == STOPPING_AND_SUSPENDING_THREADS) + { + if (debug_threads) + debug_printf ("HEW: leaving child suspended\n"); + child_lwp->suspended = 1; + } but that is not enough, because new thread is still can be spawned in the thread which is being stepped over. This patch extends the condition that GDBserver set child's suspend count to one if it is suspending threads or stepping over the thread. gdb/gdbserver: 2016-03-03 Yao Qi <yao.qi@linaro.org> PR server/19736 * linux-low.c (handle_extended_wait): Set child suspended if event_lwp->bp_reinsert isn't zero.
2016-03-02Call enqueue_pending_signal in linux_resume_one_lwp_throwYao Qi2-11/+6
Replace the code which is exactly what enqueue_pending_signal does. gdb/gdbserver: 2016-03-02 Yao Qi <yao.qi@linaro.org> * linux-low.c (linux_resume_one_lwp_throw): Replace code with enqueue_pending_signal.
2016-03-02[OBV] gdbserver: Only write ipa_tdesc_idx if agent is actually loaded.Marcin Kościelnicki2-4/+12
Fixes rather embarassing gdb.trace regressions. gdb/gdbserver/ChangeLog: * tracepoint.c (cmd_qtstart): Only set ipa_tdesc_idx if agent is actually loaded.
generated by cgit v1.1 at 2024-11-26 06:03:28 +0000