aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2014-06-12Iterate over 'struct varobj_item' instead of PyObjectYao Qi4-53/+70
In previous patch, "saved_item" is still a PyOjbect and iteration is still performed over PyObject. This patch continues to decouple iteration from python code, so it changes its type to "struct varobj_item *", so that the iterator itself is independent of python. V2: - Call varobj_delete_iter in free_variable. - Fix changelog entries. - Use XNEW. V3: - Return NULL early in py_varobj_iter_next if gdb_python_initialized is false. gdb: 2014-06-12 Pedro Alves <pedro@codesourcery.com> Yao Qi <yao@codesourcery.com> * python/py-varobj.c (py_varobj_iter_next): Return NULL if gdb_python_initialized is false. Move some code from varobj.c. * varobj-iter.h (struct varobj_item): Moved from varobj.c. * varobj.c: Move "varobj-iter.h" inclusion earlier. (struct varobj_item): Moved to varobj-iter.h". (varobj_clear_saved_item): New function. (update_dynamic_varobj_children): Move python-related code to py-varobj.c. (free_variable): Call varobj_clear_saved_item and varobj_iter_delete.
2014-06-12Generalize varobj iteratorYao Qi7-80/+323
This patch generalizes varobj iterator, in a python-independent way. Note varobj_item is still a typedef of PyObject, we can only focus on API changes, and leave the data type changes to the next patch. As a result, we include "varobj-iter.h" after the typedef of PyObject in varobj.c, but it is an intermediate state. Finally, varobj-iter.h is independent of PyObject. This change is helpful to move some python-related code out of varobj.c. V2: - Fix a missing cleanup. - Fix typos. - Use XNEW. - Check against NULL explicitly. - Update copyright year for new added files. V3: - Call PyGILState_Ensure before Py_XDECREF. - Use CPYCHECKER_STEALS_REFERENCE_TO_ARG. - Code indentation. V4: - use varobj_ensure_python_env instead of PyGILState_Ensure. gdb: 2014-06-12 Pedro Alves <pedro@codesourcery.com> Yao Qi <yao@codesourcery.com> * Makefile.in (SUBDIR_PYTHON_OBS): Add "py-varobj.o". (SUBDIR_PYTHON_SRCS): Add "python/py-varobj.c". (HFILES_NO_SRCDIR): Add "varobj-iter.h". (py-varobj.o): New rule. * python/py-varobj.c: New file. * python/python-internal.h (py_varobj_get_iterator): Declare. * varobj-iter.h: New file. * varobj.c: Include "varobj-iter.h" (struct varobj) <child_iter>: Change its type from "PyObject *" to "struct varobj_iter *". <saved_item>: Likewise. [HAVE_PYTHON] (varobj_ensure_python_env): Make it extern. [HAVE_PYTHON] (varobj_get_iterator): New function. (update_dynamic_varobj_children) [HAVE_PYTHON]: Move python-specific code to python/py-varobj.c. (install_visualizer): Call varobj_iter_delete instead of Py_XDECREF. * varobj.h (varobj_ensure_python_env): Declare.
2014-06-12Use 'struct varobj_item' to represent name and value pairYao Qi2-25/+51
Hi, name and value pair is widely used in varobj.c. This patch is to add a new struct varobj_item to represent them, so that the number of function arguments can be reduced. Finally, the iteration is done on 'struct varobj_item' instead of PyObject after this patch series. V2: - Fix changelog entry. - Fix one grammatical mistake. gdb: 2014-06-12 Yao Qi <yao@codesourcery.com> * varobj.c (struct varobj_item): New structure. (create_child_with_value): Update declaration. (varobj_add_child): Replace arguments 'name' and 'value' with 'item'. All callers updated. (install_dynamic_child): Likewise. (update_dynamic_varobj_children): Likewise. (varobj_add_child): Likewise. (create_child_with_value): Likewise.
2014-06-12Whitespace fixes for cpu/or1k.opcAlan Modra11-223/+231
* or1k.opc: Whitespace fixes.
2014-06-12daily updateAlan Modra1-1/+1
2014-06-11Update NEWS post GDB 7.8 branch creation.Joel Brobecker2-1/+9
gdb/ChangeLog: * NEWS: Create a new section for the next release branch. Rename the section of the current branch, now that it has been cut.
2014-06-11Bump version to 7.8.50.DATE-cvs.Joel Brobecker2-1/+6
Now that the GDB 7.8 branch has been created, we can bump the version number. gdb/ChangeLog: GDB 7.8 branch created (173373c6f6388171d1d62a217fae90a052395be2): * version.in: Bump version to 7.8.50.DATE-cvs.
2014-06-11Delete temporary string within demangler even in failure cases.gdb-7.8-branchpointAndrew Burgess2-1/+9
A call to demangle_template might allocate storage within a temporary string even if the call to demangle_template eventually returns failure. This will never cause the demangler to crash, but does leak memory, as a result I've not added any tests for this. Calling string_delete is safe, even if nothing is allocated into the string, the string is initialised with string_init, so we know the internal pointers are NULL. libiberty/ChangeLog * cplus-dem.c (do_type): Call string_delete even if the call to demangle_template fails.
2014-06-11PR remote/17028: GDB+GDBserver hangs on WindowsPedro Alves2-72/+79
Since target-async was turned on by default, debugging on Windows using GDB+GDBserver sometimes hangs while waiting for a RSP reply. The problem is a race in the gdb_select machinery. This is what we see for a faulty next on the GDB side: (gdb) n infrun: clear_proceed_status_thread (Thread 4424) infrun: proceed (addr=0xffffffff, signal=GDB_SIGNAL_DEFAULT, step=1) (...) infrun: resume (step=1, signal=GDB_SIGNAL_0), ... Sending packet: $vCont;s:1148;c#5e... *hang* At this point, attaching a debugger to the hanging GDB confirms that it is blocked, waiting for a socket event: #6 0x757841d8 in WaitForMultipleObjects () from C:\Windows\syswow64\kernel32.dll #7 0x004708e7 in gdb_select (n=469, readfds=0x88ca50 <gdb_notifier+784>, writefds=0x88cb54 <gdb_notifier+1044>, exceptfds=0x88cc58 <gdb_notifier+1304>, timeout=0x0) at /[...]/gdb/mingw-hdep.c:172 #8 0x00527926 in gdb_wait_for_event (block=1) at /[...]/gdb/event-loop.c:831 #9 0x00526ff1 in gdb_do_one_event () at /[...]/gdb/event-loop.c:403 However, on the GDBserver side, we see that GDBserver already sent a T05 packet reply: gdbserver: kernel event EXCEPTION_DEBUG_EVENT for pid=4968 tid=1148 EXCEPTION_SINGLE_STEP Child Stopped with signal = 5 Writing resume reply for LWP 4968.4424:1 DEBUG: write_prim ($T0505:c8fe2800;04:a0fe2800;08:38164000;thread:1148;#f0) -> 55 To recap, on Windows, 'select' only works with sockets, so we have a wrapper, gdb_select, that uses the GDB serial abstraction to handle sockets, consoles, pipes, and serial ports. Each serial descriptor has a thread associated (we call those the select threads), and those threads communicate with the main thread by means of standard Windows events. It basically goes like this: gdb_select first loops through all fds of interest, calling their wait_handle hooks, which returns an event that WaitForMultipleObjects can wait on. gdb_select then blocks in WaitForMultipleObjects with all those event handles. The wait_handle hook is responsible for arranging for the returned event to become set once data is available. This is done by setting the descriptor's helper thread running, which itself knows how to wait for data from the type of handle it manages (sockets, pipes, consoles, files, etc.). Once data arrives, the select thread sets the corresponding event which unblocks WaitForMultipleObjects within gdb_select. However, the wait_handle hook can also apply an optimization: if data is already pending, then there's no need to set the thread running, and the descriptors event can be set immediately. It's around this latter aspect that lies the bug/race. Adding some ad hoc debug logs to ser-mingw.c and mingw-hdep.c, we see the following sequence of events, right after sending "$vCont;s:1148;c#5e". Thread 1 is the main thread, and thread 2 is the socket's helper/select thread. gdb_select was only passed one descriptor to wait on, the remote target's socket. net_windows_select_thread is the entry point of the select threads for sockets. #1 - thread 1: gdb_select: enter #2 - thread 2: net_windows_select_thread: WaitForMultipleObjects blocking gdb_select walked over the wait_handle hooks, and woke up the socket's helper thread. The helper thread is now blocked waiting for socket events. #3 - thread 1: gdb_select: WaitForMultipleObjects polling (timeout=0ms) #4 - thread 1: gdb_select: WaitForMultipleObjects returned 102 (WAIT_TIMEOUT) There was no pending data available yet, and gdb_select was passed timeout==0ms, and so WaitForMultipleObjects times out immediately. #5 - thread 2: net_windows_select_thread: WaitForMultipleObjects returned 1 Just afterwards, socket data arrives, and thread 2 wakes up. Thread 2 calls WSAEnumNetworkEvents, which clears state->sock_event, and marks the serial's read_event event, telling the main thread that data is available. #6 - thread 1: gdb_select: call serial_done_wait_handle on each serial gdb_select stops all the helper/select threads. #7 - thread 1: gdb_select: return 0 (WAIT_TIMEOUT) gdb_select in the main thread returns to the caller. Note that at this point, data is pending on the socket, the serial's read_event is set, but the socket's sock_event event is not set, until _further_ data arrives. Now GDB does its thing and goes back to the event loop. That calls gdb_select, but with timeout==INFINITE. Again, gdb_select calls the socket serial's wait_handle hook. It first clears its events, starting from a clean slate: ResetEvent (state->base.read_event); ResetEvent (state->base.except_event); ResetEvent (state->base.stop_select); That cleared read_event, which was previously set in #5 above. And then it checks for pending events, in the sock_event event: /* Check any pending events. This both avoids starting the thread unnecessarily, and handles stray FD_READ events (see below). */ if (WaitForSingleObject (state->sock_event, 0) == WAIT_OBJECT_0) { That also fails because state->sock_event was cleared in #5 too... So the wait_handle hook erroneously decides that it needs to start the helper thread to wait for input: #8 - thread 2: net_windows_select_thread: WaitForMultipleObjects blocking #9 - thread 1: gdb_select: WaitForMultipleObjects blocking (INFINITE) But, GDBserver already sent all it had to send, so both threads waits forever... At first I thought that net_windows_wait_handle shouldn't be resetting state->base.read_event or state->base.except_event, but looking deeper, the pipe and console wait_handle hooks reset all events too. It actually makes sense that way -- consuming an event from different threads is bad practice, and, we should always be able to query pending state without looking at the state->sock_event from within net_windows_wait_handle. The end result is much simpler, and makes net_windows_select_thread look a lot like console_select_thread, actually. gdb/ 2014-06-11 Pedro Alves <palves@redhat.com> PR remote/17028 * ser-mingw.c (net_windows_socket_check_pending): New function. (net_windows_select_thread): Ignore spurious wakeups. Use net_windows_socket_check_pending. (net_windows_wait_handle): Check for pending events with ioctlsocket, through net_windows_socket_check_pending, instead of checking the socket's event.
2014-06-11Fix silly thinkoAlan Modra2-1/+5
* linker.c (unwrap_hash_lookup): Add missing parens.
2014-06-11 * libcoff-in.h (coff_tdata): Make relocbase member unsigned.Kai Tietz1-0/+5
* libcoff.h: Regenerated.
2014-06-11 * libcoff-in.h (coff_tdata): Make relocbase member unsigned.Kai Tietz2-2/+2
* libcoff.h: Regenerated.
2014-06-11daily updateAlan Modra1-1/+1
2014-06-10Wrap PyObject_Get/HasAttrString in a function with second arg having const ↵Siva Chandra3-2/+34
qualifier. This is done to avoid errors when compiled with -Werror against Python-2.4 which did not have the const qualifier for the second argument of these functions. gdb/ * python/python-internal.h (gdb_PyObject_GetAttrString) (gdb_PyObject_HasAttrString): New inline function definitions. * py-value.c (get_field_flag): Remove the now unnecessary cast to char * of the second argument to PyObject_GetAttrString.
2014-06-10Only print prefixes before fwaitH.J. Lu5-2/+20
gas/testsuite/ * gas/i386/prefix.s: Add another fwait test. * gas/i386/prefix.d: Updated. opcodes/ * i386-dis.c (fwait_prefix): New. (ckprefix): Set fwait_prefix. (print_insn): Properly print prefixes before fwait.
2014-06-10add pr number to changelogAlan Modra2-0/+2
2014-06-10missing changelog entries for 8a5da09b9Alan Modra2-0/+16
2014-06-10Unwrap symbols for debug informationAlan Modra10-2/+86
Fixes issues with dwz multi-file (-m) and ld's -wrap option. Symbols referenced from DWARF debug info in a separate file, eg. to specify low and high pc, must use the real symbol. The DWARF info is specifying attributes of the real function, not one interposed with --wrap. include/ * bfdlink.h (unwrap_hash_lookup): Declare. bfd/ * linker.c (unwrap_hash_lookup): New function. * elf-bfd (RELOC_FOR_GLOBAL_SYMBOL): Call unwrap_hash_lookup. * elf32-i370.c (i370_elf_relocate_section): Likewise. * elf32-m32c.c (m32c_elf_relocate_section): Likewise. * elf32-m32r.c (m32r_elf_relocate_section): Likewise. * elf32-score.c (s3_bfd_score_elf_relocate_section): Likewise. * elf32-score7.c (s7_bfd_score_elf_relocate_section): Likewise. * elf32-spu.c (spu_elf_relocate_section): Likewise. * elf64-hppa.c (elf64_hppa_relocate_section): Likewise.
2014-06-10thinko in serial.c::serial_write debug traceJoel Brobecker2-1/+6
I noticed that, when using 'set debug serial 1', the "write" traces would always be NUL characters: [ w \x00][\x00][\x00][\x00][\x00][etc] This is due to a small thinko in the loop that output each character, where we accidently used the loop boundary instead of the loop index to index the character to be printed. After this patch is applied, the output now becomes: [ w $][v][C][o][n][t][?][#][4][9] gdb/ChangeLog: * serial.c (serial_write): Fix index of character to be printed in call to serial_logchar when serial debug traces are enabled.
2014-06-10gdbtypes.resolve_dynamic_range: Add function description.Joel Brobecker2-0/+7
gdb/ChangeLog: * gdbtypes (resolve_dynamic_range): Add function description.
2014-06-10daily updateAlan Modra1-1/+1
2014-06-09Add check to keep from segfaulting on a corrupt .debug_pubnames section.Cary Coutant2-0/+11
gold/ * dwarf_reader.cc (Dwarf_pubnames_table::read_header): Check that unit_length is within section bounds.
2014-06-09Print unattached sections in the link map.Cary Coutant2-0/+10
gold/ PR gold/16980 * layout.cc (Layout::print_to_mapfile): Print unattached sections in map.
2014-06-09Add space before the opening parenthesis in function descriptions.Siva Chandra2-6/+11
gdb/doc * python.texi (Xmethod API): Add space before the opening parenthesis in function descriptions.
2014-06-09Correctly save and recall the CFA saved register state.Romain Chastenet2-6/+20
PR binutils/16252 * dwarf.c (display_debug_frames): Remember the state of the cfa_offset, cfa_reg, ra and cfa_exp field
2014-06-09Remove reference to GASp from linker testsuite configuration.Ryan Mansfield2-4/+4
* config/default.exp (GASP): Remove.
2014-06-09Update expected disassembly of MSP430X instructions now that the disassemblerNick Clifton2-53/+57
correcctly interprets an extension word with zero index offsets. * gas/msp430/msp430x.d: Update to match revised assembler output.
2014-06-09Fix a bunch of fork related regressions.Pedro Alves2-4/+17
I'm seeing a ton of new FAILs in fork-related tests. Like, these and many more: +FAIL: gdb.base/disp-step-syscall.exp: vfork: continue to vfork (2nd time) (timeout) +FAIL: gdb.base/disp-step-syscall.exp: vfork: display/i $pc (timeout) ... -PASS: gdb.base/foll-vfork.exp: exec: vfork parent follow, through step: step +FAIL: gdb.base/foll-vfork.exp: exec: vfork parent follow, through step: step (timeout) -PASS: gdb.base/foll-vfork.exp: exec: vfork parent follow, to bp: continue to bp +FAIL: gdb.base/foll-vfork.exp: exec: vfork parent follow, to bp: continue to bp (timeout) ... FAIL: gdb.threads/watchpoint-fork.exp: parent: multithreaded: breakpoint (A) after the first fork (timeout) FAIL: gdb.threads/watchpoint-fork.exp: parent: multithreaded: watchpoint A after the first fork (timeout) FAIL: gdb.base/fileio.exp: System(3) call (timeout) FAIL: gdb.threads/watchpoint-fork.exp: parent: multithreaded: watchpoint B after the first fork (timeout) -PASS: gdb.base/multi-forks.exp: run to exit 2 +FAIL: gdb.base/multi-forks.exp: run to exit 2 (timeout) ... PASS: gdb.base/watch-vfork.exp: Watchpoint on global variable (hw) -PASS: gdb.base/watch-vfork.exp: Watchpoint triggers after vfork (hw) +FAIL: gdb.base/watch-vfork.exp: Watchpoint triggers after vfork (hw) (timeout) PASS: gdb.base/watch-vfork.exp: Watchpoint on global variable (sw) -PASS: gdb.base/watch-vfork.exp: Watchpoint triggers after vfork (sw) +FAIL: gdb.base/watch-vfork.exp: Watchpoint triggers after vfork (sw) (timeout) Three issues with https://sourceware.org/ml/gdb-patches/2014-06/msg00348.html (c077881a). - The inner 'status' local is shadowing the outer 'status' local, thus PTRACE_DETACH is never seeing the status it intends to pass on the inferior. - With that fixed, we then try to pass down the SIGTRAP that results from the step to the inferior. Need to filter out signals that are in nopass state. - For software single-step archs, the current code is equivalent to: int status = 0; if (WIFSTOPPED (status)) ptrace (PTRACE_DETACH, child_pid, 0, WSTOPSIG (status)); ... and status == 0 is WIFEXITED, not WIFSTOPPED, so we're never detaching. gdb/ 2014-06-09 Pedro Alves <palves@redhat.com> * linux-nat.c (linux_child_follow_fork): Initialize status with W_STOPCODE (0) instead of 0. Remove shodowing 'status' local from inner block. Only pass the signal to PTRACE_DETACH if in pass state.
2014-06-09Separate out ANSI-standard signalsGary Benson6-129/+205
This commit reorders various pieces of code to separate ANSI-standard signals from other signals that need checking. Comments are added to document this, and to document the ordering of the signals. gdb/ 2014-06-09 Gary Benson <gbenson@redhat.com> * common/signals.c (gdb_signal_from_host): Reorder to separate the always-available ANSI-standard signals from the signals that require checking. (do_gdb_signal_to_host): Likewise. * proc-events.c (signal_table): Likewise. gdb/testsuite/ 2014-06-09 Gary Benson <gbenson@redhat.com> * gdb.base/sigall.c [Functions to send signals]: Reorder to separate the always-available ANSI-standard signals from the signals that require checking. (main): Likewise. * gdb.reverse/sigall-reverse.c [Functions to send signals]: Likewise. (main): Likewise.
2014-06-09daily updateAlan Modra1-1/+1
2014-06-08Fix gdb.base/watch-vfork.exp: Watchpoint triggers after vfork (sw) (timeout) ↵Hui Zhu4-1/+43
with Linux 2.6.32 and older version https://sourceware.org/ml/gdb-patches/2014-04/msg00047.html Got gdb.base/watch-vfork.exp: Watchpoint triggers after vfork (sw) (timeout) with Linux 2.6.32 and older version. The rootcause is after the test use "set can-use-hw-watchpoints 0" let GDB doesn't use hardware breakpoint and set a watchpoint on "global", GDB continue will keep single step inside function "vfork". The Linux 2.6.32 and older version doesn't have commit 6580807da14c423f0d0a708108e6df6ebc8bc83d (get more info please goto http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=6580807da14c423f0d0a708108e6df6ebc8bc83d). When the function "vfork" do syscall, the single step flag TIF_SINGLESTEP will copy to child process. Then GDB detach it, child process and parent process will be hanged. So I make a patch that do a single step before detach. Then TIF_SINGLESTEP of child process in old Linux kernel will be cleared before detach. Child process in new Linux kernel will not be affected by this single step. 2014-06-08 Hui Zhu <hui@codesourcery.com> * common/linux-ptrace.c (linux_disable_event_reporting): New function. * common/linux-ptrace.h (linux_disable_event_reporting): New declaration. * linux-nat.c (linux_child_follow_fork): Do a single step before detach.
2014-06-08daily updateAlan Modra1-1/+1
2014-06-07Revert patchset for c++/16253: it causes a large performance regression.Keith Seitz14-299/+114
See the bug for further information.
2014-06-07PROVIDE in linker script vs. built-in symbolsAlan Modra2-1/+9
* ldexp.c (exp_fold_tree_1 <etree_provide>): Make PROVIDEd linker script symbol value override a built-in linker symbol.
2014-06-07Allow both signed and unsigned fields in PowerPC cmpli insnAlan Modra9-28/+67
There are legitimate reasons to allow a signed value in a cmpli insn field, for example to test for a "stw r1,lock@sdarel(r13)" instruction in user code, a kernel might use subis r3,r3,STW_R1_0R13@ha # subtract off high part cmplwi r3,lock@sdarel # is low part accessing lock? Since the lock@sdarel may take a range of -32768 to 32767, the allowed range of cmpli immediate must be at least [-32768,65535]. bfd/ * elf32-ppc.c (ppc_elf_relocate_section): Treat field of cmpli insn as a bitfield; Use complain_overflow_bitfield. * elf64-ppc.c (ppc64_elf_relocate_section): Likewise. opcodes/ * ppc-opc.c (UISIGNOPT): Define and use with cmpli. gas/ * config/tc-ppc.c (ppc_insert_operand): Handle PPC_OPERAND_SIGNOPT on unsigned fields. Comment on PPC_OPERAND_SIGNOPT signed fields in 64-bit mode. gold/ * powerpc.cc (relocate): Treat field of cmpli insn as a bitfield.
2014-06-07daily updateAlan Modra1-1/+1
2014-06-06Strip .debug_gnu_pubnames and .debug_gnu_pubtypes when building .gdb_index.Cary Coutant4-13/+11
When not stripping those sections, there was a bug where gold was incorrectly adjusting section-relative offsets by the offset of the input section within the output section. That adjustment was both unnecessary and wrong, causing gold to miss a number of debug entries that should have been added to .gdb_index. (With stripping, the adjustment was always 0, so the bug in dwarf_reader.cc would have been hidden by the change to layout.cc.) gold/ * dwarf_reader.h (Dwarf_pubnames_table): Remove output_section_offset_. * dwarf_reader.cc (Dwarf_pubnames_table::read_section): Likewise. (Dwarf_pubnames_table::read_header): Likewise. * layout.cc (gdb_fast_lookup_sections): Add .debug_gnu_pubnames and .debug_gnu_pubtypes.
2014-06-06fix email address of previous checkinsDoug Evans3-3/+3
2014-06-06Add support for guile 2.0.5.Doug Evans12-23/+127
* guile/guile-internal.h (gdbscm_guile_major_version): Declare. (gdbscm_guile_minor_version, gdbscm_guile_micro_version): Declare. (gdbscm_guile_version_is_at_least): Declare. (gdbscm_scm_string_to_int): Declare. * guile/guile.c (gdbscm_guile_major_version): New global. (gdbscm_guile_minor_version, gdbscm_guile_micro_version): New globals. (guile_datadir): New static global. (gdbscm_guile_data_directory): New function. (initialize_scheme_side): Update. (misc_guile_functions): Add guile-data-directory. (initialize_gdb_module): Fetch guile version number. * guile/lib/gdb.scm: Remove call to add-to-load-path. * guile/lib/gdb/init.scm (%initialize!): Ditto. * guile/lib/gdb/boot.scm: Use guile-data-directory. * guile/scm-exception.c (gdbscm_print_exception_with_stack): Fix comments. * guile/scm-string.c (gdbscm_scm_string_to_int): New function. * guile/scm-utils.c (gdbscm_guile_version_is_at_least): New function. * guile/scm-value.c (gdbscm_value_to_string): Only call scm_port_conversion_strategy if Guile version >= 2.0.6. doc/ * guile.texi (Guile Configuration): Document guile-data-directory.
2014-06-06* gdb.guile/scm-frame-args.c (foo): Tweak to work with gcc 4.6.3.Doug Evans2-1/+5
2014-06-06sss-bp-on-user-bp-2.exp sometimes fails on native GNU/Linux.Pedro Alves2-17/+21
I noticed that sss-bp-on-user-bp-2.exp is racy on native GNU/Linux. I sometimes still see an int3 in the disassembly: (gdb) PASS: gdb.base/sss-bp-on-user-bp-2.exp: set debug target 0 disassemble test Dump of assembler code for function test: 0x0000000000400590 <+0>: push %rbp 0x0000000000400591 <+1>: mov %rsp,%rbp 0x0000000000400594 <+4>: nop => 0x0000000000400595 <+5>: int3 0x0000000000400596 <+6>: pop %rbp 0x0000000000400597 <+7>: retq End of assembler dump. (gdb) FAIL: gdb.base/sss-bp-on-user-bp-2.exp: before/after disassembly matches Enabling infrun/target debug logs, we can see the problem. Simplified, that's: (gdb) PASS: gdb.base/sss-bp-on-user-bp-2.exp: define stepi_del_break stepi_del_break infrun: clear_proceed_status_thread (process 25311) infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 25311] at 0x400594 LLR: PTRACE_SINGLESTEP process 25311, 0 (resume event thread) target_resume (25311, step, 0) native:target_xfer_partial (3, (null), 0x0, 0x32dce4c, 0x400595, 1) = 0, 0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (gdb) linux_nat_wait: [process -1], [TARGET_WNOHANG] 0x400595 is the address of the breakpoint, and "= 0" is TARGET_XFER_EOF. That's default_memory_remove_breakpoint trying to remove the breakpoint, but failing. The problem is that we had just resumed the target and the native GNU/Linux target can't read memory off of a running thread. Most of the time, we get "lucky", because we manage to read memory before the kernel actually schedules the target to run. So just give up and skip the test on any target that uses hardware stepping, not just remote targets. gdb/testsuite/ 2014-06-06 Pedro Alves <palves@redhat.com> * gdb.base/sss-bp-on-user-bp-2.exp: Look for target_resume(step) in target debug output instead of looking at RSP packets, disabling the test on any target that uses hardware stepping. Update comments.
2014-06-06break-unload-file.exp: Fix typo.Pedro Alves2-1/+5
s/is not pending/is pending/ gdb/testsuite/ 2014-06-06 Pedro Alves <palves@redhat.com> * gdb.base/break-unload-file.exp: Fix typo.
2014-06-06Restrict the pattern in gdb.base/jit.expYao Qi2-1/+6
I see the following fail in some thumb multi-lib in arm-none-linux-gnueabi, info function jit_function^M All functions matching regular expression "jit_function":^M ^M Non-debugging symbols:^M 0x00000790 __real_jit_function_XXXX^M 0x0000079c __jit_function_XXXX_from_arm^M 0x0000079c jit_function_0000^M 0x00000790 __real_jit_function_XXXX^M 0x0000079c __jit_function_XXXX_from_arm^M 0x0000079c jit_function_0001^M (gdb) FAIL: gdb.base/jit.exp: one_jit_test-2: info function jit_function the test expects to see only jit_function_0000 and jit_function_0001 one_jit_test 2 "${hex} jit_function_0000\[\r\n\]+${hex} jit_function_0001" Symbols with the prefix "__real_" or suffix "_from_arm" is generated by gcc/ld for arm/thumb interworking. This patch is to restrict the pattern from "jit_function" to "^jit_function", the output becomes expected. gdb/testsuite: 2014-06-06 Yao Qi <yao@codesourcery.com> * gdb.base/jit.exp (one_jit_test): Restrict the pattern from "jit_function" to "^jit_function".
2014-06-06Tweak gdb.base/async.expYao Qi3-3/+22
I see two fails in async.exp on arm-none-eabi target: nexti&^M (gdb) 0x000001ba 14 x = 5; x = 5;^M completed.^M FAIL: gdb.base/async.exp: nexti& finish&^M Run till exit from #0 0x000001ba in foo () at /scratch/yqi/arm-none-eabi-lite/src/gdb-trunk/gdb/testsuite/gdb.base/async.c:14^M (gdb) 0x000001e6 in main () at /scratch/yqi/arm-none-eabi-lite/src/gdb-trunk/gdb/testsuite/gdb.base/async.c:32^M 32 y = foo ();^M Value returned is $1 = 8^M completed.^M FAIL: gdb.base/async.exp: finish& The corresponding test is "test_background "nexti&" "" ".*y = 3.*"", and it assumes that GDB "nexti" into the next source line. It is wrong on arm. After "nexti", it still stops at the same source line, and it fails. When gdb does "finish", if the PC is in the middle of a source line, the PC address is printed too. See stack.c:print_frame, if (opts.addressprint) if (!sal.symtab || frame_show_address (frame, sal) || print_what == LOC_AND_ADDRESS) { annotate_frame_address (); if (pc_p) ui_out_field_core_addr (uiout, "addr", gdbarch, pc); else ui_out_field_string (uiout, "addr", "<unavailable>"); annotate_frame_address_end (); ui_out_text (uiout, " in "); } frame_show_address checks whether PC is the middle of a source line. Since after "nexti", the inferior stops at the middle of a source line, when we do "finish" the PC address is displayed. In sum, GDB works well, but test case needs update. This patch is to add a statement at the same line to make sure "nexti" doesn't go to the new line, match the next instruction address in the output and match the hex address the output of "finish". gdb/testsuite: 2014-06-06 Yao Qi <yao@codesourcery.com> * gdb.base/async.c (foo): Add one statement. * gdb.base/async.exp: Get the next instruction address and match the output of "nexti" by instruction address. Match the hex address in the output of "finish".
2014-06-06update ChangeLogxmj2-0/+8
2014-06-06Remove preprocessor conditionals for ANSI-standard signalsGary Benson8-72/+20
The six signals SIGINT, SIGILL, SIGABRT, SIGFPE, SIGSEGV and SIGTERM are ANSI-standard and thus guaranteed to be available. This patch removes all preprocessor conditionals relating to these symbols. gdb/ 2014-06-06 Gary Benson <gbenson@redhat.com> * common/signals.c: Remove preprocessor conditionals for always-defined signals SIGINT, SIGILL, SIGABRT, SIGFPE, SIGSEGV and SIGTERM. * proc-events.c: Likewise. gdb/testsuite/ 2014-06-06 Gary Benson <gbenson@redhat.com> * gdb.base/call-signals.c: Remove preprocessor conditionals for always-defined signals SIGINT, SIGILL, SIGABRT, SIGFPE, SIGSEGV and SIGTERM. * gdb.base/sigall.c: Likewise. * gdb.base/unwindonsignal.c: Likewise. * gdb.reverse/sigall-reverse.c: Likewise.
2014-06-06add -q in help info and docxmj2-3/+5
2014-06-06Skip hbreak-unmapped.exp if memory at address 0 is readableYao Qi2-0/+15
hbreak-unmapped.exp assumes that memory at address 0 is unmapped or unreadable, but on bare metal or uclinux targets, memory at address 0 is readable. For example, on arm-none-eabi, the vector table base address is 0x0. hbreak *0^M Hardware assisted breakpoint 3 at 0x0: file /scratch/yqi/arm-none-eabi-lite/obj/cs3-2014.11-999999-arm-none-eabi-i686-pc-linux-gnu/generated/arm-vector.S, line 25.^M (gdb) FAIL: gdb.base/hbreak-unmapped.exp: hbreak *0 info break^M Num Type Disp Enb Address What^M 3 hw breakpoint keep y 0x00000000 /scratch/yqi/arm-none-eabi-lite/obj/cs3-2014.11-999999-arm-none-eabi-i686-pc-linux-gnu/generated/arm-vector.S:25^M (gdb) FAIL: gdb.base/hbreak-unmapped.exp: info break shows hw breakpoint delete $bpnum This patch is to check whether address 0 is readable via command 'x 0'. If it is, skip the test. gdb/testsuite: 2014-06-06 Yao Qi <yao@codesourcery.com> * gdb.base/hbreak-unmapped.exp: Read memory at address 0. If readable, skip the test.
2014-06-06symfile, vdso: remove target sectionsMarkus Metzger3-19/+10
Target sections added by the add-symbol-file-from-memory command are not removed when the process exits. In fact, they are not removed, at all. This causes GDB to crash in gdb.base/break-interp.exp. Change the owner of those target sections to the object file generated in symbol_file_add_from_memory and generalize the free_objfile observer in symfile.c to remove target sections of any freed object file.
2014-06-06[AArch64] Fix the documentation on :pg_hi21:Martin Storsjo2-5/+9