aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-08-06Add casts for legitimate integer to enum conversionsSimon Marchi25-57/+119
This patch is mostly extracted from Pedro's C++ branch. It adds explicit casts from integer to enum types, where it is really the intention to do so. This could be because we are ... * iterating on enum values (we need to iterate on an equivalent integer) * converting from a value read from bytes (dwarf attribute, agent expression opcode) to the equivalent enum * reading the equivalent integer value from another language (Python/Guile) An exception to that is the casts in regcache.c. It seems to me like struct regcache's register_status field could be a pointer to an array of enum register_status. Doing so would waste a bit of memory (4 bytes used by the enum vs 1 byte used by the current signed char, for each register). If we switch to C++11 one day, we can define the underlying type of an enum type, so we could have the best of both worlds. gdb/ChangeLog: * arm-tdep.c (set_fp_model_sfunc): Add cast from integer to enum. (arm_set_abi): Likewise. * ax-general.c (ax_print): Likewise. * c-exp.y (exp : string_exp): Likewise. * compile/compile-loc2c.c (compute_stack_depth_worker): Likewise. (do_compile_dwarf_expr_to_c): Likewise. * cp-name-parser.y (demangler_special : DEMANGLER_SPECIAL start): Likewise. * dwarf2expr.c (execute_stack_op): Likewise. * dwarf2loc.c (dwarf2_compile_expr_to_ax): Likewise. (disassemble_dwarf_expression): Likewise. * dwarf2read.c (dwarf2_add_member_fn): Likewise. (read_array_order): Likewise. (abbrev_table_read_table): Likewise. (read_attribute_value): Likewise. (skip_unknown_opcode): Likewise. (dwarf_decode_macro_bytes): Likewise. (dwarf_decode_macros): Likewise. * eval.c (value_f90_subarray): Likewise. * guile/scm-param.c (gdbscm_make_parameter): Likewise. * i386-linux-tdep.c (i386_canonicalize_syscall): Likewise. * infrun.c (handle_command): Likewise. * memory-map.c (memory_map_start_memory): Likewise. * osabi.c (set_osabi): Likewise. * parse.c (operator_length_standard): Likewise. * ppc-linux-tdep.c (ppc_canonicalize_syscall): Likewise, and use single return point. * python/py-frame.c (gdbpy_frame_stop_reason_string): Likewise. * python/py-symbol.c (gdbpy_lookup_symbol): Likewise. (gdbpy_lookup_global_symbol): Likewise. * record-full.c (record_full_restore): Likewise. * regcache.c (regcache_register_status): Likewise. (regcache_raw_read): Likewise. (regcache_cooked_read): Likewise. * rs6000-tdep.c (powerpc_set_vector_abi): Likewise. * symtab.c (initialize_ordinary_address_classes): Likewise. * target-debug.h (target_debug_print_signals): Likewise. * utils.c (do_restore_current_language): Likewise.
2015-08-06Add missing ChangeLog entry headerSimon Marchi1-0/+1
2015-08-06Fix ChangeLog formattingSimon Marchi1-1/+1
Spaces -> Tab.
2015-08-06gdbserver/tracepoint.c: make exported IPA global int instead of enumPedro Alves2-1/+8
Fixes another C++ -fpermissive error: src/gdb/gdbserver/tracepoint.c:4535:21: error: invalid conversion from ‘int’ to ‘eval_result_type’ [-fpermissive] expr_eval_result = ipa_expr_eval_result; gdb/gdbserver/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * tracepoint.c (expr_eval_result): Now an int.
2015-08-06gdbserver: no point in hiding the regcache type nowadaysPedro Alves5-9/+25
The regcache used to be hidden inside inferiors.c, but since the tracepoints support that it's a first class object. This also fixes a few implicit pointer conversion errors in C++ mode, caused by a few places missing the explicit cast. gdb/gdbserver/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * gdbthread.h (struct regcache): Forward declare. (struct thread_info) <regcache_data>: Now a struct regcache pointer. * inferiors.c (inferior_regcache_data) (set_inferior_regcache_data): Now work with struct regcache pointers. * inferiors.h (struct regcache): Forward declare. (inferior_regcache_data, set_inferior_regcache_data): Now work with struct regcache pointers. * regcache.c (get_thread_regcache, regcache_invalidate_thread) (free_register_cache_thread): Remove struct regcache pointer casts.
2015-08-06PR python/17136Clem Dickey2-1/+6
gdb/ChangeLog: * python/lib/gdb/command/type_printers.py (InfoTypePrinter): Fix typo.
2015-08-06gdbserver: fix silent error exitPedro Alves2-0/+11
Running gdb.threads/process-dies-while-handling-bp.exp against gdbserver sometimes FAILs because GDBserver drops the connection, but the logs leave no clue on what the reason could be. Running manually a few times, I saw the same: $ ./gdbserver/gdbserver --multi :9999 testsuite/gdb.threads/process-dies-while-handling-bp Process testsuite/gdb.threads/process-dies-while-handling-bp created; pid = 12766 Listening on port 9999 Remote debugging from host 127.0.0.1 Listening on port 9999 Child exited with status 0 Child exited with status 0 What happened is that an exception escaped and gdbserver reopened the connection, which led to that second "Listening on port 9999" output. The error was a failure to access registers from a now-dead thread. The exception probably shouldn't have escaped here, but meanwhile, this at least makes the issue less mysterious. Tested on x86_64 Fedora 20. gdb/gdbserver/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * server.c (captured_main): On error, print the exception message to stderr, and if run_once is set, throw a quit.
2015-08-06Change type of struct complaints::seriesSimon Marchi2-12/+14
Found while processing the C++ enum changes. It seems like series should be of type enum complaint_series, instead of adding a cast. Redundant and out of date comments are also removed. gdb/ChangeLog: * complaints.c (enum complaint_series): Add newlines and remove out of date comment. (struct complaints) <series>: Change type to enum complaint_series and remove out of date comment. (symfile_complaint_hook): Use equivalent enum value ISOLATED_MESSAGE instead of 0.
2015-08-06gdbserver: move_out_of_jump_pad_callback misses switching current threadPedro Alves2-0/+12
While hacking on the fix for PR threads/18600 (Threads left stopped after fork+thread spawn), I once saw its test (fork-plus-threads.exp) FAIL against gdbserver because move_out_of_jump_pad_callback has a gdb_breakpoint_here call, and the caller isn't making sure the current thread points to the right thread. In the case I saw, the current thread pointed to the wrong process, so gdb_breakpoint_here returned the wrong answer. Unfortunately I didn't save logs. Still, seems obvious enough and it should fix a potential occasional racy FAIL. Tested on x86_64 Fedora 20. gdb/gdbserver/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * linux-low.c (move_out_of_jump_pad_callback): Temporarily switch the current thread.
2015-08-06Fix gdbserver --debug issues caught by ValgrindPedro Alves4-10/+24
Running gdbserver --debug under Valgrind shows: ==4803== Invalid read of size 4 ==4803== at 0x432B62: linux_write_memory (linux-low.c:5320) ==4803== by 0x4143F7: write_inferior_memory (target.c:83) ==4803== by 0x415895: remove_memory_breakpoint (mem-break.c:362) ==4803== by 0x432EF5: linux_remove_point (linux-low.c:5460) ==4803== by 0x416319: delete_raw_breakpoint (mem-break.c:802) ==4803== by 0x4163F3: release_breakpoint (mem-break.c:842) ==4803== by 0x416477: delete_breakpoint_1 (mem-break.c:869) ==4803== by 0x4164EF: delete_breakpoint (mem-break.c:891) ==4803== by 0x416843: delete_gdb_breakpoint_1 (mem-break.c:1069) ==4803== by 0x4168D8: delete_gdb_breakpoint (mem-break.c:1098) ==4803== by 0x4134E3: process_serial_event (server.c:4051) ==4803== by 0x4138E4: handle_serial_event (server.c:4196) ==4803== Address 0x4c6b930 is 0 bytes inside a block of size 1 alloc'd ==4803== at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==4803== by 0x4240C6: xmalloc (common-utils.c:43) ==4803== by 0x41439C: write_inferior_memory (target.c:80) ==4803== by 0x415895: remove_memory_breakpoint (mem-break.c:362) ==4803== by 0x432EF5: linux_remove_point (linux-low.c:5460) ==4803== by 0x416319: delete_raw_breakpoint (mem-break.c:802) ==4803== by 0x4163F3: release_breakpoint (mem-break.c:842) ==4803== by 0x416477: delete_breakpoint_1 (mem-break.c:869) ==4803== by 0x4164EF: delete_breakpoint (mem-break.c:891) ==4803== by 0x416843: delete_gdb_breakpoint_1 (mem-break.c:1069) ==4803== by 0x4168D8: delete_gdb_breakpoint (mem-break.c:1098) ==4803== by 0x4134E3: process_serial_event (server.c:4051) ==4803== And: ==7272== Conditional jump or move depends on uninitialised value(s) ==7272== at 0x3615E48361: vfprintf (vfprintf.c:1634) ==7272== by 0x414E89: debug_vprintf (debug.c:60) ==7272== by 0x42800A: debug_printf (common-debug.c:35) ==7272== by 0x43937B: my_waitpid (linux-waitpid.c:149) ==7272== by 0x42D740: linux_wait_for_event_filtered (linux-low.c:2441) ==7272== by 0x42DADA: linux_wait_for_event (linux-low.c:2552) ==7272== by 0x42E165: linux_wait_1 (linux-low.c:2860) ==7272== by 0x42F5D8: linux_wait (linux-low.c:3453) ==7272== by 0x4144A4: mywait (target.c:107) ==7272== by 0x413969: handle_target_event (server.c:4214) ==7272== by 0x41A1A6: handle_file_event (event-loop.c:429) ==7272== by 0x41996D: process_event (event-loop.c:184) gdb/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * nat/linux-waitpid.c (my_waitpid): Only print *status if waitpid returned > 0. gdb/gdbserver/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * linux-low.c (linux_write_memory): Rewrite debug output to avoid reading beyond the passed in buffer length.
2015-08-06Revert "test slowdown"Pedro Alves2-5/+3
That was pushed by mistake.
2015-08-06Test for PR18749: problems if whole process dies while (ptrace-) stoppedPedro Alves3-0/+226
This adds a kfailed test that has the whole process exit just while several threads continuously step over a breakpoint. Usually, the process exits just while GDB or GDBserver is handling the breakpoint hit. In other words, the process disappears while the event thread is (ptrace-) stopped. This exposes several issues in GDB and GDBserver. Errors, crashes, etc. I fixed some of these issues recently, but there's a lot more to do. It's a bit like playing whack-a-mole at the moment. You fix an issue, which then exposes several others. E.g., with the native target, you get (among other errors): (...) [New Thread 0x7ffff47b9700 (LWP 18077)] [New Thread 0x7ffff3fb8700 (LWP 18078)] [New Thread 0x7ffff37b7700 (LWP 18079)] Cannot find user-level thread for LWP 18076: generic error (gdb) KFAIL: gdb.threads/process-dies-while-handling-bp.exp: non_stop=on: cond_bp_target=1: inferior 1 exited (prompt) (PRMS: gdb/18749) gdb/testsuite/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> PR gdb/18749 * gdb.threads/process-dies-while-handling-bp.c: New file. * gdb.threads/process-dies-while-handling-bp.exp: New file.
2015-08-06test slowdownPedro Alves2-3/+5
2015-08-06Remove required field in agent's symbolsPierre Langlois4-2/+8
This field was never set nor used. This patch removes it. gdb/ChangeLog: * common/agent.c (symbol_list) <required>: Remove. gdb/gdbserver/ChangeLog: * tracepoint.c (symbol_list) <required>: Remove.
2015-08-06gdbserver: Fix non-stop / fork / step-over issuesPedro Alves7-30/+486
Ref: https://sourceware.org/ml/gdb-patches/2015-07/msg00868.html This adds a test that has a multithreaded program have several threads continuously fork, while another thread continuously steps over a breakpoint. This exposes several intertwined issues, which this patch addresses: - When we're stopping and suspending threads, some thread may fork, and we missed setting its suspend count to 1, like we do when a new clone/thread is detected. When we next unsuspend threads, the fork child's suspend count goes below 0, which is bogus and fails an assertion. - If a step-over is cancelled because a signal arrives, but then gdb is not interested in the signal, we pass the signal straight back to the inferior. However, we miss that we need to re-increment the suspend counts of all other threads that had been paused for the step-over. As a result, other threads indefinitely end up stuck stopped. - If a detach request comes in just while gdbserver is handling a step-over (in the test at hand, this is GDB detaching the fork child), gdbserver internal errors in stabilize_thread's helpers, which assert that all thread's suspend counts are 0 (otherwise we wouldn't be able to move threads out of the jump pads). The suspend counts aren't 0 while a step-over is in progress, because all threads but the one stepping past the breakpoint must remain paused until the step-over finishes and the breakpoint can be reinserted. - Occasionally, we see "BAD - reinserting but not stepping." being output (from within linux_resume_one_lwp_throw). That was because GDB pokes memory while gdbserver is busy with a step-over, and that suspends threads, and then re-resumes them with proceed_one_lwp, which missed another reason to tell linux_resume_one_lwp that the thread should be set back to stepping. - In a couple places, we were resuming threads that are meant to be suspended. E.g., when a vCont;c/s request for thread B comes in just while gdbserver is stepping thread A past a breakpoint. The resume for thread B must be deferred until the step-over finishes. - The test runs with both "set detach-on-fork" on and off. When off, it exercises the case of GDB detaching the fork child explicitly. When on, it exercises the case of gdb resuming the child explicitly. In the "off" case, gdb seems to exponentially become slower as new inferiors are created. This is _very_ noticeable as with only 100 inferiors gdb is crawling already, which makes the test take quite a bit to run. For that reason, I've disabled the "off" variant for now. gdb/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * target/waitstatus.h (enum target_stop_reason) <TARGET_STOPPED_BY_SINGLE_STEP>: New value. gdb/gdbserver/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * linux-low.c (handle_extended_wait): Set the fork child's suspend count if stopping and suspending threads. (check_stopped_by_breakpoint): If stopped by trace, set the LWP's stop reason to TARGET_STOPPED_BY_SINGLE_STEP. (linux_detach): Complete an ongoing step-over. (lwp_suspended_inc, lwp_suspended_decr): New functions. Use throughout. (resume_stopped_resumed_lwps): Don't resume a suspended thread. (linux_wait_1): If passing a signal to the inferior after finishing a step-over, unsuspend and re-resume all lwps. If we see a single-step event but the thread should be continuing, don't pass the trap to gdb. (stuck_in_jump_pad_callback, move_out_of_jump_pad_callback): Use internal_error instead of gdb_assert. (enqueue_pending_signal): New function. (check_ptrace_stopped_lwp_gone): Add debug output. (start_step_over): Use internal_error instead of gdb_assert. (complete_ongoing_step_over): New function. (linux_resume_one_thread): Don't resume a suspended thread. (proceed_one_lwp): If the LWP is stepping over a breakpoint, reset it stepping. gdb/testsuite/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * gdb.threads/forking-threads-plus-breakpoint.exp: New file. * gdb.threads/forking-threads-plus-breakpoint.c: New file.
2015-08-06Linux gdbserver confused when event randomization picks process exit eventPedro Alves3-35/+54
The tail end of linux_wait_1 isn't expecting that the select_event_lwp machinery can pick a whole-process exit event to report to GDB. When that happens, both gdb and gdbserver end up quite confused: ... (gdb) [Thread 24971.24971] #1 stopped. 0x0000003615a011f0 in ?? () c& Continuing. (gdb) [New Thread 24971.24981] [New Thread 24983.24983] [New Thread 24971.24982] [Thread 24983.24983] #3 stopped. 0x0000003615ebc7cc in __libc_fork () at ../nptl/sysdeps/unix/sysv/linux/fork.c:130 130 pid = ARCH_FORK (); [New Thread 24984.24984] Error in re-setting breakpoint -16: PC register is not available Error in re-setting breakpoint -17: PC register is not available Error in re-setting breakpoint -18: PC register is not available Error in re-setting breakpoint -19: PC register is not available Error in re-setting breakpoint -24: PC register is not available Error in re-setting breakpoint -25: PC register is not available Error in re-setting breakpoint -26: PC register is not available Error in re-setting breakpoint -27: PC register is not available Error in re-setting breakpoint -28: PC register is not available Error in re-setting breakpoint -29: PC register is not available Error in re-setting breakpoint -30: PC register is not available PC register is not available (gdb) gdb/gdbserver/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * linux-low.c (add_lwp): Set waitstatus to TARGET_WAITKIND_IGNORE. (linux_thread_alive): Use lwp_is_marked_dead. (extended_event_reported): Delete. (linux_wait_1): Check if waitstatus is TARGET_WAITKIND_IGNORE instead of extended_event_reported. (mark_lwp_dead): Don't set the 'dead' flag. Store the waitstatus as well. (lwp_is_marked_dead): New function. (lwp_running): Use lwp_is_marked_dead. * linux-low.h: Delete 'dead' field, and update 'waitstatus's comment.
2015-08-06Linux gdbserver fork event debug outputPedro Alves2-7/+15
The "extended event with waitstatus" debug output is unreachable, as it is guarded by "if (!report_to_gdb)". If extended_event_reported is true, then so is report_to_gdb. Move it to where we print why we're reporting an event to GDB. Also, the debug output currently tries to print the wrong struct target_waitstatus. gdb/gdbserver/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * linux-low.c (linux_wait_1): Move fork event output out of the !report_to_gdb check. Pass event_child->waitstatus to target_waitstatus_to_string instead of ourstatus.
2015-08-06Revert ALIGN changesAlan Modra4-52/+43
Reverts a2c59f28 and e474ab13. Since the unary form of ALIGN only references "dot" implicitly, there isn't really a strong argument for making ALIGN use a relative value when inside an output section. * ldexp.c (align_dot_val): Delete. (fold_unary <ALIGN_K, NEXT>): Revert 2015-07-10 change. (is_align_conditional): Revert 2015-07-20 change. (exp_fold_tree_1): Likewise, but keep expanded comment. * scripttempl/elf.sc (.ldata, .bss): Revert 2015-07-20 change. * ld.texinfo (<ALIGN>): Correct description.
2015-08-06Automatic date update in version.inGDB Administrator1-1/+1
2015-08-05stepping is disturbed by setjmp/longjmp | try/catch in other threadsPedro Alves5-4/+193
At https://sourceware.org/ml/gdb-patches/2015-08/msg00097.html, Joel observed that trying to next/step a program on GNU/Linux sometimes results in the following failed assertion: % gdb -q .obj/gprof/main (gdb) start (gdb) n (gdb) step [...]/infrun.c:2391: internal-error: resume: Assertion `sig != GDB_SIGNAL_0' failed. What happened is that, during the "next" operation, GDB hit a longjmp/exception/step-resume breakpoint but failed to see that this breakpoint was set for a different thread than the one being stepped. Joel's detailed analysis follows: More precisely, at the end of the "start" command, we are stopped at the start of function Main in main.adb; there are 4 threads in total, and we are in the main thread (which is thread 1): (gdb) info thread Id Target Id Frame 4 Thread 0xb7a56ba0 (LWP 28379) 0xffffe410 in __kernel_vsyscall () 3 Thread 0xb7c5aba0 (LWP 28378) 0xffffe410 in __kernel_vsyscall () 2 Thread 0xb7e5eba0 (LWP 28377) 0xffffe410 in __kernel_vsyscall () * 1 Thread 0xb7ea18c0 (LWP 28370) main () at /[...]/main.adb:57 All the logs below reference Thread ID/LWP, but it'll be easier to talk about the threads by GDB thread number. For instance, thread 1 is LWP 28370 while thread 3 is LWP 28378. So, the explanations below translate the LWPs into thread numbers. Back to what happens while we are trying to "next' our program: (gdb) n infrun: clear_proceed_status_thread (Thread 0xb7a56ba0 (LWP 28379)) infrun: clear_proceed_status_thread (Thread 0xb7c5aba0 (LWP 28378)) infrun: clear_proceed_status_thread (Thread 0xb7e5eba0 (LWP 28377)) infrun: clear_proceed_status_thread (Thread 0xb7ea18c0 (LWP 28370)) infrun: proceed (addr=0xffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0xb7ea18c0 (LWP 28370)] at 0x805451e infrun: target_wait (-1.0.0, status) = infrun: 28370.28370.0 [Thread 0xb7ea18c0 (LWP 28370)], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x8054523 We've resumed thread 1 (LWP 28370), and received in return a signal that the same thread stopped slightly further. It's still in the range of instructions for the line of source we started the "next" from, as evidenced by the following trace... infrun: stepping inside range [0x805451e-0x8054531] ... and thus, we decide to continue stepping the same thread: infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0xb7ea18c0 (LWP 28370)] at 0x8054523 infrun: prepare_to_wait That's when we get an event from a different thread (thread 3)... infrun: target_wait (-1.0.0, status) = infrun: 28370.28378.0 [Thread 0xb7c5aba0 (LWP 28378)], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x80782d0 infrun: context switch infrun: Switching context from Thread 0xb7ea18c0 (LWP 28370) to Thread 0xb7c5aba0 (LWP 28378) ... which we find to be at the address where we set a breakpoint on "the unwinder debug hook" (namely "_Unwind_DebugHook"). But GDB fails to notice that the breakpoint was inserted for thread 1 only, and so decides to handle it as... infrun: BPSTAT_WHAT_SET_LONGJMP_RESUME ... and inserts a breakpoint at the corresponding resume address, as evidenced by this the next log: infrun: exception resume at 80542a2 That breakpoint seems innocent right now, but will play a role fairly quickly. But for now, GDB has inserted the exception-resume breakpoint, and needs to single-step thread 3 past the breakpoint it just hit. Thus, it temporarily disables the exception breakpoint, and requests a step of that thread: infrun: skipping breakpoint: stepping past insn at: 0x80782d0 infrun: skipping breakpoint: stepping past insn at: 0x80782d0 infrun: skipping breakpoint: stepping past insn at: 0x80782d0 infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [Thread 0xb7c5aba0 (LWP 28378)] at 0x80782d0 infrun: prepare_to_wait We then get a notification, still from thread 3, that it's now past that breakpoint... infrun: prepare_to_wait infrun: target_wait (-1.0.0, status) = infrun: 28370.28378.0 [Thread 0xb7c5aba0 (LWP 28378)], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x8078424 ... so we can resume what we were doing before, which is single-stepping thread 1 until we get to a new line of code: infrun: switching back to stepped thread infrun: Switching context from Thread 0xb7c5aba0 (LWP 28378) to Thread 0xb7ea18c0 (LWP 28370) infrun: expected thread still hasn't advanced infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0xb7ea18c0 (LWP 28370)] at 0x8054523 The "resume" log above shows that we're resuming thread 1 from where we left off (0x8054523). We get one more stop at 0x8054529, which is still inside our stepping range so we go again. That's when we get the following event, from thread 3: infrun: prepare_to_wait infrun: target_wait (-1.0.0, status) = infrun: 28370.28378.0 [Thread 0xb7c5aba0 (LWP 28378)], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x80542a2 Now the stop_pc address is interesting, because it's the address of "exception resume" breakpoint... infrun: context switch infrun: Switching context from Thread 0xb7ea18c0 (LWP 28370) to Thread 0xb7c5aba0 (LWP 28378) infrun: BPSTAT_WHAT_CLEAR_LONGJMP_RESUME ... and since that location is at a different line of code, this is where it decides the "next" operation should stop: infrun: stop_waiting [Switching to Thread 0xb7c5aba0 (LWP 28378)] 0x080542a2 in inte_tache_rt.ttache_rt ( <_task>=0x80968ec <inte_tache_rt_inst.tache2>) at /[...]/inte_tache_rt.adb:54 54 end loop; However, what GDB should have noticed earlier that the exception breakpoint we hit was for a different thread, thus should have single-stepped that thread out of the breakpoint _without_ inserting the exception-return breakpoint, and then resumed the single-stepping of the initial thread (thread 1) until that thread stepped out of its stepping range. This is what this patch does, and after applying it, GDB now correctly stops on the next line of code. The patch adds a C++ test that exercises this, both for setjmp/longjmp and exception breakpoints. With an unpatched GDB it shows: (gdb) next [Switching to Thread 22445.22455] thread_try_catch (arg=0x0) at /home/pedro/gdb/mygit/build/../src/gdb/testsuite/gdb.threads/next-other-thr-longjmp.c:59 59 catch (...) (gdb) FAIL: gdb.threads/next-other-thr-longjmp.exp: next to line 1 next /home/pedro/gdb/mygit/build/../src/gdb/infrun.c:4865: internal-error: process_event_stop_test: Assertion `ecs->event_thread->control.exception_resume_breakpoint != NULL' fa iled. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) FAIL: gdb.threads/next-other-thr-longjmp.exp: next to line 2 (GDB internal error) Resyncing due to internal error. n Tested on x86_64-linux, no regressions. gdb/ChangeLog: 2015-08-05 Pedro Alves <palves@redhat.com> Joel Brobecker <brobecker@adacore.com> * breakpoint.c (bpstat_what) <bp_longjmp, bp_longjmp_call_dummy> <bp_exception, bp_longjmp_resume, bp_exception_resume>: Handle the case where BS->STOP is not set. gdb/testsuite/ChangeLog: 2015-08-05 Pedro Alves <palves@redhat.com> * gdb.threads/next-while-other-thread-longjmps.c: New file. * gdb.threads/next-while-other-thread-longjmps.exp: New file.
2015-08-05Change the behaviour of the --only-keep-debug option to objcopy and strip so ↵Nick Clifton6-2/+157
that the sh_link and sh_info fields in stripped section headers are preserved. bfd * elf.c (_bfd_elf_copy_private_bfd_data): Copy the sh_link and sh_info fields of sections whose type has been changed to SHT_NOBITS. bin * doc/binutils.texi: Document that the --only-keep-debug option to strip and objcopy preserves the section headers of stripped sections. tests * binutils-all/objcopy.exp (keep_debug_symbols_and_check_links): New proc. Checks that debug-info-only binaries retain the sh_link field in stripped sections.
2015-08-05Protect nat/gdb_thread_db.h against multiple inclusion.Ulrich Weigand2-0/+27
Fixes a build error due to typedef redefinition with some compilers. Also added missing copyright header. gdb/ * nat/gdb_thread_db.h: Add copyright header. Protect against multiple inclusion.
2015-08-05Fix building GDB for the M32C by providing a stub sim_info function.Nick Clifton2-0/+11
* gdb-if.c (sim_info): Stub function to allow GDB to be built with this simulator.
2015-08-05Remove get_thread_idYao Qi4-62/+46
This patch removes get_thread_id from aarch64-linux-nat.c, arm-linux-nat.c and xtensa-linux-nat.c. get_thread_id was added in this commit below in 2000, 41c49b06c471443d3baf2eaa2463a315f9b5edca https://sourceware.org/ml/gdb-patches/2000-04/msg00398.html which predates the ptid_t stuff added into GDB. Nowadays, lwpid of inferior_ptid is only zero when the inferior is created (in fork-child.c:fork_inferior) and its lwpid will be set after linux_nat_wait_1 gets the first event. After that, lwpid of inferior_ptid is not zero for linux-nat target, then we can use ptid_get_lwp, so this function isn't needed anymore. Even when GDB attaches to a process, the lwp of inferior_ptid isn't zero, see linux-nat.c:linux_nat_attach, /* The ptrace base target adds the main thread with (pid,0,0) format. Decorate it with lwp info. */ ptid = ptid_build (ptid_get_pid (inferior_ptid), ptid_get_pid (inferior_ptid), 0); Note that linux_nat_xfer_partial shifts lwpid to pid for inferior_ptid temperately for calling linux_ops->to_xfer_partial, but all the affected functions in this patch are not called in linux_ops->to_xfer_partial. I think we can safely remove get_thread_id for all linux native targets. Regression tested on arm-linux and aarch64-linux. Unable to build native GDB and test it on xtensa-linux. gdb: 2015-08-05 Yao Qi <yao.qi@linaro.org> * aarch64-linux-nat.c (get_thread_id): Remove. (debug_reg_change_callback): Call ptid_get_lwp instead of get_thread_id. (fetch_gregs_from_thread): Likewise. (store_gregs_to_thread): Likewise. (fetch_fpregs_from_thread): Likewise. (store_fpregs_to_thread): Likewise. (aarch64_linux_get_debug_reg_capacity): Likewise. * arm-linux-nat.c (get_thread_id): Remove. (GET_THREAD_ID): Update macro to use ptid_get_lwp. * xtensa-linux-nat.c (get_thread_id): Remove. (GET_THREAD_ID): Update macro to use ptid_get_lwp. * arm-linux-nat.c (get_thread_id): Remove. (GET_THREAD_ID): Remove. (fetch_fpregs): Call ptid_get_lwp instead of GET_THREAD_ID. (store_fpregs, fetch_regs, store_regs): Likewise. (fetch_wmmx_regs, store_wmmx_regs): Likewise. (fetch_vfp_regs, store_vfp_regs): Likewise. (arm_linux_read_description): Likewise. (arm_linux_get_hwbp_cap): Likewise. * xtensa-linux-nat.c (get_thread_id): Remove. (GET_THREAD_ID): Remove. (fetch_gregs, store_gregs): Call ptid_get_lwp instead of GET_THREAD_ID.
2015-08-05Automatic date update in version.inGDB Administrator1-1/+1
2015-08-04python: fix Linetable case to LineTable in docstrings and commentsCiro Santilli3-11/+17
The class is called LineTable, not Linetable, as specified by py-linetable.c/gdbpy_initialize_linetable: if (gdb_pymodule_addobject (gdb_module, "LineTable", gdb/ChangeLog: * python/py-linetable.c: Fix case of Linetable to LineTable in docstrings and code comments. * python/py-symtab.c: Same.
2015-08-04Fix stack buffer overflows when parsing corrupt ihex files.Yuriy M. Kaminskiy5-5/+28
PR binutils/18750 * ihex.c (ihex_scan): Fixes incorrect escape sequence in error message and stack overflow when char is signed and \200-\376 was in place of hex digit; also fixes \377 was handled as EOF instead of "incorrect character". (ihex_read_section): Changed for consistency. (ihex_bad_byte): Prevent (now impossible to trigger) stack overflow and incorrect escape sequence handling. * srec.c (srec_bad_byte): Likewise. * readelf.c (process_mips_specific): Fix incorrect escape sequence handling.
2015-08-04Fix memory leak in ar if it encounters an invalid path whilst extracting files.Nick Clifton1-0/+1
* ar.c (extract_file): Free cbuf if the path is invalid.
2015-08-04Disable tracepoint support for aarch32Yao Qi2-1/+12
We only support tracepoint for aarch64. Although arm program can run on aarch64, GDBserver doesn't support tracepoint for it. gdb/gdbserver: 2015-08-04 Yao Qi <yao.qi@linaro.org> * linux-aarch64-low.c (aarch64_supports_tracepoints): Return 0 if current_thread is 32 bit.
2015-08-04Disable Z0 packet on aarch64 on multi-arch debuggingYao Qi4-1/+25
In multi-arch debugging, if GDB sends Z0 packet, GDBserver should be able to do several things below: - choose the right breakpoint instruction to insert according to the information available, such as 'kind' in Z0 packet and address, - choose the right breakpoint instruction to check memory writes and validate inserted memory breakpoint - be aware of different breakpoint instructions in $ARCH_breakpoint_at. unfortunately GDBserver can't do them now. Although x86 GDBserver supports multi-arch, it doesn't need to support them above because breakpoint instruction on i686 and x86_64 is the same. However, breakpoint instructions on aarch64 and arm (arm mode, thumb1, and thumb2) are different. I tried to teach aarch64 GDBserver backend to be really multi-arch-capable in the following ways, - linux_low_target return the right breakpoint instruction according to the 'kind' in Z0 packet, and insert_memory_breakpoint can do the right thing. - once breakpoint is inserted, the breakpoint data and length is recorded in each breakpoint object, so that validate_breakpoint and check_mem_write can get the right breakpoint instruction from each breakpoint object, rather than from global variable breakpoint_data. - linux_low_target needs another hook function for pc increment after hitting a breakpoint. - let set_breakpoint_at, which is widely used for tracepoint, use the 'default' breakpoint instruction. We can always use aarch64 breakpoint instruction since arm doesn't support tracepoint yet. looks it is not a small piece of work, so I decide to disable Z0 packet on multi-arch, which means aarch64 GDBserver only supports Z0 packet if it is started to debug only one process (extended protocol is not used) and process target description is 64-bit. gdb/gdbserver: 2015-08-04 Yao Qi <yao.qi@linaro.org> * linux-aarch64-low.c (aarch64_supports_z_point_type): Return 0 for Z_PACKET_SW_BP if it may be used in multi-arch debugging. * server.c (extended_protocol): Remove "static". * server.h (extended_protocol): Declare it.
2015-08-04Get and set PC correctly on aarch64 in multi-archYao Qi2-7/+33
gdb/gdbserver: 2015-08-04 Yao Qi <yao.qi@linaro.org> * linux-aarch64-low.c (aarch64_get_pc): Get PC register on both aarch64 and aarch32. (aarch64_set_pc): Likewise.
2015-08-04Use arm target description and regs_info for 32-bit file on aarch64 GDBserverYao Qi3-3/+56
This patch teaches aarch64-linux GDBserver use 32-bit arm target description and regs_info if the elf file is 32-bit. gdb/gdbserver: 2015-08-04 Yao Qi <yao.qi@linaro.org> * configure.srv (case aarch64*-*-linux*): Append arm-with-neon.o to srv_regobj and append arm-core.xml arm-vfpv3.xml and arm-with-neon.xml to srv_xmlfiles. * linux-aarch64-low.c: Include linux-aarch32-low.h. (is_64bit_tdesc): New function. (aarch64_linux_read_description): New function. (aarch64_arch_setup): Call aarch64_linux_read_description. (regs_info): Rename to regs_info_aarch64. (aarch64_regs_info): Return right regs_info. (initialize_low_arch): Call initialize_low_arch_aarch32.
2015-08-04New regs_info for aarch32Yao Qi5-47/+219
This patch adds a new regs_info regs_info_aarch32 for aarch32, which can be used by both aarch64 and arm backend. gdb/gdbserver: 2015-08-04 Yao Qi <yao.qi@linaro.org> * configure.srv (srv_tgtobj): Add linux-aarch32-low.o. * linux-aarch32-low.c: New file. * linux-aarch32-low.h: New file. * linux-arm-low.c (arm_fill_gregset): Move it to linux-aarch32-low.c. (arm_store_gregset): Likewise. (arm_fill_vfpregset): Call arm_fill_vfpregset_num (arm_store_vfpregset): Caa arm_store_vfpregset_num. (arm_arch_setup): Check if PTRACE_GETREGSET works. (regs_info): Rename to regs_info_arm. (arm_regs_info): Return regs_info_aarch32 if have_ptrace_getregset is 1 and target description is arm_with_neon or arm_with_vfpv3. (initialize_low_arch): Don't call init_registers_arm_with_neon. Call initialize_low_arch_aarch32 instead.
2015-08-04Move have_ptrace_getregset to linux-low.cYao Qi4-3/+11
This patch moves variable have_ptrace_getregset from linux-x86-low.c to linux-low.c, so that arm can use it too. gdb/gdbserver: 2015-08-04 Yao Qi <yao.qi@linaro.org> * linux-x86-low.c (have_ptrace_getregset): Move it to ... * linux-low.c: ... here. * linux-low.h (have_ptrace_getregset): Declare it.
2015-08-04signal_command: Leftover cleanup chain regressionJan Kratochvil2-0/+6
gdb/ChangeLog 2015-08-04 Jan Kratochvil <jan.kratochvil@redhat.com> * infcmd.c (signal_command): Call do_cleanups for args_chain.
2015-08-04ASAN attach crash - 7.9 regressionJan Kratochvil2-3/+13
-fsanitize=address gdb.base/attach-pie-noexec.exp ==32586==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200004ed90 at pc 0x48ad50 bp 0x7ffceb3aef50 sp 0x7ffceb3aef20 READ of size 2 at 0x60200004ed90 thread T0 #0 0x48ad4f in __interceptor_strlen (/home/jkratoch/redhat/gdb-test-asan/gdb/gdb+0x48ad4f) #1 0xeafe5c in xstrdup xstrdup.c:33 #2 0x85e024 in attach_command /home/jkratoch/redhat/gdb-test-asan/gdb/infcmd.c:2680 regressed by: commit 6c4486e63f7583ed85a0c72841f6ccceebbf858e Author: Pedro Alves <palves@redhat.com> Date: Fri Oct 17 13:31:26 2014 +0100 PR gdb/17471: Repeating a background command makes it foreground gdb/ChangeLog 2015-08-04 Jan Kratochvil <jan.kratochvil@redhat.com> PR gdb/18767 * infcmd.c (attach_command): Move ARGS_CHAIN cleanup after last ARGS use.
2015-08-04ld: map option for run_dump_test requires no program.Andrew Burgess2-0/+10
When using run_dump_test with the map option to compare the linker map file produced, no additional dump program should be required. A dump program can still be given if needed, but leaving it off will no longer produce an error. ld/testsuite/ChangeLog: * ld/ld-lib.exp (run_dump_test): When using the map option, no program is required.
2015-08-04ld: Add file based error/warning regexp for run_dump_test.Andrew Burgess2-17/+78
The run_dump_test mechanism supports options error and warning, which allow regexp to be specified within the test file, these regexp are matched against the stderr output from the linker. Similar dump test style functions for gas and gdb also support file based matching versions of these options; the patterns are placed into a file which the test driver then references. It is sometimes clearer, when the pattern to be matched spans multiple lines if the patterns can be placed into a separate file. This patch adds new options error_output and warning_output for the linker run_dump_test function. These new options take a filename parameter, this file is then used (with regexp_diff) to compare against the linker output. ld/testsuite/ChangeLog: * ld/ld-lib.exp (run_dump_test): Add error_output and warning_output options.
2015-08-04ld: Add '--require-defined' command line option.Andrew Burgess15-0/+209
Add a new command line option '--require-defined' to the linker. This option operates identically to the '--undefined' option, except that if the symbol is not defined in the final output file then the linker will exit with an error. When making use of --gc-section, or just when trying to pull in parts of a library, it is not uncommon for a user to use the '--undefined' command line option to specify a symbol that the user then expects to be defined by one of the object files supplied to the link. However, if for any reason the symbol is not satisfied by an object provided to the link the user will be left with an undefined symbol in the output file, instead of a defined symbol. In some cases the above behaviour is what the user wants, in other cases though we can do better. The '--require-defined' option tries to fill this gap. The symbol passed to the '--require-defined' option is treated exactly as if the symbol was passed to '--undefined', however, before the linker exits a check is made that all symbols passed to '--require-defined' are actually defined, if any are not then the link will fail with an error. ld/ChangeLog: * ld.texinfo (Options): Document --require-defined option. * ldlang.c (struct require_defined_symbol): New structure. (require_defined_symbol_list): New variable. (ldlang_add_require_defined): New function. (ldlang_check_require_defined_symbols): New function. (lang_process): Check required symbols are defined. * ldlang.h (ldlang_add_require_defined): Declare. * ldlex.h (enum option_values): Add OPTION_REQUIRE_DEFINED_SYMBOL. * lexsup.c (ld_options): Add '--require-defined' entry. (parse_args): Handle '--require-defined' entry. * NEWS: Mention new '--require-defined' option. ld/testsuite/ChangeLog: * ld-undefined/require-defined-1.d: New file. * ld-undefined/require-defined-2.d: New file. * ld-undefined/require-defined-3.d: New file. * ld-undefined/require-defined-4.d: New file. * ld-undefined/require-defined-5.d: New file. * ld-undefined/require-defined.exp: New file. * ld-undefined/require-defined.s: New file.
2015-08-04C++: dlsym casts in gdb/linux-thread-db.c and gdb/gdbserver/thread-db.cPedro Alves5-95/+137
Implicit void * -> function pointer conversion doesn't work in C++, so in C++, we need to cast the result of dlsym. This adds a few typedefs and macros that make this easy. GDBserver's version already had the CHK macro, so I added it to GDB too. Tested on x86_64 Fedora 20, native and gdbserver. gdb/gdbserver/ChangeLog: 2015-08-04 Pedro Alves <palves@redhat.com> * thread-db.c (struct thread_db): Use new typedefs. (try_thread_db_load_1): Define local TDB_DLSYM macro and use it in CHK calls. (disable_thread_event_reporting): Cast result of dlsym to destination function pointer type. (thread_db_mourn): Use td_ta_delete_ftype. gdb/ChangeLog: 2015-08-04 Pedro Alves <palves@redhat.com> * nat/gdb_thread_db.h (td_init_ftype, td_ta_new_ftype) (td_ta_map_lwp2thr_ftype, td_ta_thr_iter_ftype) (td_ta_event_addr_ftype, td_ta_set_event_ftype) (td_ta_clear_event_ftype, td_ta_event_getmsg_ftype) (td_thr_validate_ftype, td_thr_get_info_ftype) (td_thr_event_enable_ftype, td_thr_tls_get_addr_ftype) (td_thr_tlsbase_ftype, td_symbol_list_ftype, td_ta_delete_ftype): New typedefs. * linux-thread-db.c (struct thread_db_info): Use new typedefs. (try_thread_db_load_1): Define TDB_VERBOSE_DLSYM, TDB_DLSYM , CHK local macros and use them instead of verbose_dlsym and dlsym calls.
2015-08-04Update description of proc run_dump_testNick Clifton2-14/+29
* lib/utils-lib.exp (run_dump_test): Document DUMPPROG, readelf and size parameters. Alpha-sort switch tables. Include addr2line, and size in list of possible auto-detected dump programs.
2015-08-042015-08-04 Thomas Preud'homme <thomas.preudhomme@arm.com>Thomas Preud'homme2-0/+8
* doc/c-aarch64.texi (.xword): Document directive.
2015-08-04Automatic date update in version.inGDB Administrator1-1/+1
2015-08-03ld/doc: Document that multiple MEMORY commands are allowed.Andrew Burgess2-3/+9
The linker documentation explicitly states that there can be only one MEMORY command. This is not true. Multiple MEMORY commands are allowed, the contents of all will be treated as if a single MEMORY command was given. Update the documentation to make this clear to the users. ld/ChangeLog: * ld.texinfo (MEMORY): Explain that multiple MEMORY commands are acceptable.
2015-08-03Fix ChangeLog for "FAIL: -Bsymbolic-functions" for cris-linux in ldHans-Peter Nilsson1-1/+1
It's bfd_link_info, not elf_link_hash_entry, for the old reference: * elf32-cris.c (cris_elf_relocate_section) (elf_cris_finish_dynamic_symbol, cris_elf_check_relocs) (elf_cris_discard_excess_dso_dynamics): Use SYMBOLIC_BIND, not just bfd_link_info->symbolic, to check if a symbol should be bound symbolically.
2015-08-03Nios II R2 support for GDB.Sandra Loosemore6-95/+722
2015-08-03 Sandra Loosemore <sandra@codesourcery.com> gdb/ * nios2-tdep.h: Include opcode/nios2.h here. (NIOS2_CDX_OPCODE_SIZE): New. (struct gdbarch_tdep): Add OP parameter to syscall_next_pc. * nios2-tdep.c: Don't include opcode/nios2.h here. (nios2_fetch_insn): For R2, try reading 2-byte instruction if 4-byte read fails. (nios2_match_add, nios2_match_sub): Add cases for R2 encodings. (nios2_match_addi, nios2_match_orhi): Likewise. (nios2_match_stw, nios2_match_ldw): Likewise. (nios2_match_rdctl): Likewise. (nios2_match_stwm, nios2_match_ldwm): New. (nios2_match_branch): Add cases for R2 encodings. (nios2_match_jmpi, nios2_match_calli): Likewise. (nios2_match_jmpr, nios2_match_callr): Likewise. (nios2_match_break, nios2_match_trap): Likewise. (nios2_in_epilogue_p): Add R2 support. (nios2_analyze_prologue): Update comments. Recognize R2 CDX prologues. (nios2_breakpoint_from_pc): Handle R2 instructions. (nios2_get_next_pc): Likewise. Adjust call to tdep->syscall_next_pc. * nios2-linux-tdep.c (nios2_r1_linux_rt_sigreturn_tramp_frame): Renamed from nios2_linux_rt_sigreturn_tramp_frame. Use instruction field macros instead of literal hex values. (nios2_r2_linux_rt_sigreturn_tramp_frame): New. (nios2_linux_syscall_next_pc): Adjust signature to pass OP. Use size field from OP instead of assuming all instructions are the same size. (nios2_linux_init_abi): Register appropriate unwinder for mach. gdb/gdbserver/ * linux-nios2-low.c (NIOS2_BREAKPOINT): Conditionalize for arch variant. (CDX_BREAKPOINT): Define for R2. (nios2_breakpoint_at): Check for CDX_BREAKPOINT when R2. (the_low_target): Add comments.
2015-08-03Fix "FAIL: -Bsymbolic-functions" for cris-linux in ldHans-Peter Nilsson2-7/+15
* elf32-cris.c (cris_elf_relocate_section) (elf_cris_finish_dynamic_symbol, cris_elf_check_relocs) (elf_cris_discard_excess_dso_dynamics): Use SYMBOLIC_BIND, not just h->symbolic, to check if a symbol should be bound symbolically.
2015-08-03Further robustify gdb.base/bp-permanent.exp.Sandra Loosemore2-2/+20
2015-08-03 Sandra Loosemore <sandra@codesourcery.com> gdb/testsuite/ * gdb.base/bp-permanent.exp: Report test as unsupported if the target cannot stop at the permanent breakpoint.
2015-08-03dwarf2read.c: fix latent bugletPedro Alves1-1/+1
cust->includes is: struct compunit_symtab { ... struct compunit_symtab **includes; gdb/ChangeLog: 2015-08-03 Pedro Alves <palves@redhat.com> * dwarf2read.c (compute_compunit_symtab_includes): Use size of struct compunit_symtab pointer.
2015-08-03Missing changelog entry for previous commit: Add gmonster-{1,2} perf testcases.Doug Evans1-0/+33
These testcases are mocks of real programs. GDB doesn't care what the programs do, they just have to look and/or behave like the real program. These testcases exercise gdb when debugging really large programs. E.g., gmonster-1 has 10,000 CUs, and gmonster-2 has 1000 shared libs (which is actually a little small, 5000 would be more accurate). gdb/testsuite/ChangeLog: * gdb.perf/lib/perftest/utils.py: New file. * gdb.perf/gm-hello.cc: New file. * gdb.perf/gm-pervasive-typedef.cc: New file. * gdb.perf/gm-pervasive-typedef.h: New file. * gdb.perf/gm-std.cc: New file. * gdb.perf/gm-std.h: New file. * gdb.perf/gm-use-cerr.cc: New file. * gdb.perf/gm-utils.h: New file. * gdb.perf/gmonster-null-lookup.py: New file. * gdb.perf/gmonster-pervasive-typedef.py: New file. * gdb.perf/gmonster-print-cerr.py: New file. * gdb.perf/gmonster-ptype-string.py: New file. * gdb.perf/gmonster-runto-main.py: New file. * gdb.perf/gmonster-select-file.py: New file. * gdb.perf/gmonster1-null-lookup.exp: New file. * gdb.perf/gmonster1-pervasive-typedef.exp: New file. * gdb.perf/gmonster1-print-cerr.exp: New file. * gdb.perf/gmonster1-ptype-string.exp: New file. * gdb.perf/gmonster1-runto-main.exp: New file. * gdb.perf/gmonster1-select-file.exp: New file. * gdb.perf/gmonster1.cc: New file. * gdb.perf/gmonster1.exp: New file. * gdb.perf/gmonster2-null-lookup.exp: New file. * gdb.perf/gmonster2-pervasive-typedef.exp: New file. * gdb.perf/gmonster2-print-cerr.exp: New file. * gdb.perf/gmonster2-ptype-string.exp: New file. * gdb.perf/gmonster2-runto-main.exp: New file. * gdb.perf/gmonster2-select-file.exp: New file. * gdb.perf/gmonster2.cc: New file. * gdb.perf/gmonster2.exp: New file.
generated by cgit v1.1 at 2024-07-14 06:38:26 +0000