aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2017-11-17Use an enum to represent subclasses of symbolTom Tromey4-11/+32
This changes struct symbol to use an enum to encode the concrete subclass of a particular symbol. Note that "enum class" doesn't work properly with bitfields, so a plain enum is used. 2017-11-17 Tom Tromey <tom@tromey.com> * symtab.h (enum symbol_subclass_kind): New. (struct symbol) <is_cplus_template_function, is_rust_vtable>: Remove. <subclass>: New member. (SYMBOL_IS_CPLUS_TEMPLATE_FUNCTION): Update. * rust-lang.c (rust_get_trait_object_pointer): Update. * dwarf2read.c (read_func_scope): Update. (read_variable): Update.
2017-11-17Make template_symbol derive from symbolTom Tromey4-10/+11
This changes template_symbol to derive from symbol, which seems a bit cleaner; and also more consistent with rust_vtable_symbol. 2017-11-17 Tom Tromey <tom@tromey.com> * dwarf2read.c (read_func_scope): Update. * symtab.h (struct template_symbol): Derive from symbol. <base>: Remove.
2017-11-17Handle dereferencing Rust trait objectsTom Tromey12-0/+405
In Rust, virtual tables work a bit differently than they do in C++. In C++, as you know, they are connected to a particular class hierarchy. Rust, instead, can generate a virtual table for potentially any type -- in fact, one such virtual table for each trait (a trait is similar to an abstract class or to a Java interface) that a type implements. Objects that are referenced via a trait can't currently be inspected by gdb. This patch implements the Rust equivalent of "set print object". gdb relies heavily on the C++ ABI to decode virtual tables; primarily to make "set print object" work; but also "info vtbl". However, Rust does not currently have a specified ABI, so this approach seems unwise to emulate. Instead, I've changed the Rust compiler to emit some DWARF that describes trait objects (previously their internal structure was opaque), vtables (currently just a size -- but I hope to expand this in the future), and the concrete type for which a vtable was emitted. The concrete type is expressed as a DW_AT_containing_type on the vtable's type. This is a small extension to DWARF. This patch adds a new entry to quick_symbol_functions to return the symtab that holds a data address. Previously there was no way in gdb to look up a full (only minimal) non-text symbol by address. The psymbol implementation of this method works by lazily filling in a map that is added to the objfile. This avoids slowing down psymbol reading for a feature that is likely to not be used too frequently. I did not update .gdb_index. My thinking here is that the DWARF 5 indices will obsolete .gdb_index soon-ish, meaning that adding a new feature to them is probably wasted work. If necessary I can update the DWARF 5 index code when it lands in gdb. Regression tested on x86-64 Fedora 25. 2017-11-17 Tom Tromey <tom@tromey.com> * symtab.h (struct symbol) <is_rust_vtable>: New member. (struct rust_vtable_symbol): New. (find_symbol_at_address): Declare. * symtab.c (find_symbol_at_address): New function. * symfile.h (struct quick_symbol_functions) <find_compunit_symtab_by_address>: New member. * symfile-debug.c (debug_qf_find_compunit_symtab_by_address): New function. (debug_sym_quick_functions): Link to debug_qf_find_compunit_symtab_by_address. * rust-lang.c (rust_get_trait_object_pointer): New function. (rust_evaluate_subexp) <case UNOP_IND>: New case. Call rust_get_trait_object_pointer. * psymtab.c (psym_relocate): Clear psymbol_map. (psym_fill_psymbol_map, psym_find_compunit_symtab_by_address): New functions. (psym_functions): Link to psym_find_compunit_symtab_by_address. * objfiles.h (struct objfile) <psymbol_map>: New member. * dwarf2read.c (dwarf2_gdb_index_functions): Update. (process_die) <DW_TAG_variable>: New case. Call read_variable. (rust_containing_type, read_variable): New functions. 2017-11-17 Tom Tromey <tom@tromey.com> * gdb.rust/traits.rs: New file. * gdb.rust/traits.exp: New file.
2017-11-17Remove DEF_VEC_I (int)Simon Marchi2-2/+4
Now that all its usages are removed, we can get rid of DEF_VEC_I (int). gdb/ChangeLog: * common/gdb_vecs.h (DEF_VEC_I (int)): Remove.
2017-11-17Make process_info::syscalls_to_catch an std::vectorSimon Marchi5-28/+36
This patch makes the syscalls_to_catch field of process_info an std::vector<int>. The process_info structure must now be newed/deleted. In handle_extended_wait, the code that handles exec events destroys the existing process_info and creates a new one. It moves the content of syscalls_to_catch from the old to the new vector. I used std::move for that (through an intermediary variable), which should have the same behavior as the old code. gdb/gdbserver/ChangeLog: * inferiors.h (struct process_info): Add constructor, initialize fields.. <syscalls_to_catch>: Change type to std::vector<int>. * inferiors.c (add_process): Allocate process_info with new. (remove_process): Free process_info with delete. * linux-low.c (handle_extended_wait): Adjust. (gdb_catching_syscalls_p, gdb_catch_this_syscall_p): Adjust. * server.c (handle_general_set): Adjust.
2017-11-17Make open_fds an std::vectorSimon Marchi2-19/+19
Simple replacement of VEC with std::vector. gdb/ChangeLog: * common/filestuff.c: Include <algorithm>. (open_fds): Change type to std::vector<int>. (do_mark_open_fd): Adjust. (unmark_fd_no_cloexec): Adjust. (do_close): Adjust.
2017-11-17Make output_thread_groups take an std::vector<int>Simon Marchi2-10/+12
A simple replacement of VEC with std::vector. gdb/ChangeLog: * breakpoint.c (output_thread_groups): Take an std::vector. (print_one_breakpoint_location): Adjust.
2017-11-17(Ada) fix handling of minimal symbols (UNOP_CAST and UNOP_ADDR)Joel Brobecker9-10/+192
Consider a program which provides a symbol without debugging information. For instance, compiling the following code without -g: Some_Minimal_Symbol : Integer := 1234; pragma Export (C, Some_Minimal_Symbol, "some_minsym"); Trying to print this variable with GDB now causes an error, which is now expected: (gdb) p some_minsym 'some_minsym' has unknown type; cast it to its declared type However, trying to cast this symbol, or to take its address does not work: (gdb) p integer(some_minsym) 'some_minsym' has unknown type; cast it to its declared type (gdb) p &some_minsym 'some_minsym' has unknown type; cast it to its declared type Another manisfestation of this issue can be seen when trying to insert an Ada exception catchpoint for a specific standard exception (this only occurs if the Ada runtime is built without debugging information, which is the default). For instance: $ (gdb) catch exception constraint_error warning: failed to reevaluate internal exception condition for catchpoint 0: 'constraint_error' has unknown type; cast it to its declared type This is because, internally, the cachtpoint uses a condition referencing a minimal symbol, more precisely: long_integer (e) = long_integer (&constraint_error) This patch fixes all issues listed above: 1. resolve_subexp: Special-case the handling of OP_VAR_MSYM_VALUE expression elements, where there are no ambiguities to be resolved in that situation; 2. ada_evaluate_subexp: Enhance the handling of the UNOP_CAST handling so as to process the case where the target of the cast is a minimal symbol (as well as a symbol with debugging information). This mimics what's done in C. gdb/ChangeLog: * ada-lang.c (resolve_subexp): Add handling of OP_VAR_MSYM_VALUE. (ada_evaluate_subexp_for_cast): New function. (ada_evaluate_subexp) <UNOP_CAST>: Replace code by call to ada_evaluate_subexp_for_cast. (ada_evaluate_subexp) <nosideret>: Replace code by call to eval_skip_value. * eval.c (evaluate_var_value): Make non-static. (evaluate_var_msym_value, eval_skip_value): Likewise. * value.h (evaluate_var_value, evaluate_var_msym_value) (eval_skip_value): Declare. gdb/testsuite/ChangeLog: * gdb.ada/minsyms: New testcase. Tested on x86_64-linux. No regression. Fixes the following failures: catch_ex.exp: continuing to Program_Error exception catch_ex.exp: continuing to failed assertion catch_ex.exp: continuing to unhandled exception catch_ex.exp: continuing to program completion complete.exp: p <Exported_Capitalized> complete.exp: p Exported_Capitalized complete.exp: p exported_capitalized mi_catch_ex.exp: catch Program_Error (unexpected output) mi_catch_ex.exp: continue to exception catchpoint hit (unknown output after running) mi_catch_ex.exp: continue to assert failure catchpoint hit (unknown output after running) mi_catch_ex.exp: continue to unhandled exception catchpoint hit (unknown output after running) mi_ex_cond.exp: catch C_E if i = 2 (unexpected output)
2017-11-16ada-lang.c::ada_value_cast: remove unused parameter nosideJoel Brobecker2-3/+8
gdb/ChangeLog: * ada-lang.c (ada_value_cast): Remove parameter "noside". Update all callers.
2017-11-16Test breakpoint commands w/ "continue" + Ctrl-CPedro Alves3-0/+176
This adds the testcase that exposed the multiple problems with Ctrl-C handling fixed by the previous patches, when run against both native and gdbserver GNU/Linux. gdb/ChangeLog: 2017-11-16 Pedro Alves <palves@redhat.com> * gdb.base/bp-cmds-continue-ctrl-c.c: New file. * gdb.base/bp-cmds-continue-ctrl-c.exp: New file.
2017-11-16Python unwinder sniffer: PyExc_KeyboardInterrupt -> QuitPedro Alves2-0/+12
If you happen to press Ctrl-C while GDB is running the Python unwinder machinery, the Ctrl-C is swallowed by the Python unwinder machinery. For example, with: break foo commands > c > end and while (1) foo (); and then let the inferior hit "foo" repeatedly, sometimes Ctrl-C results in: ~~~ 23 usleep (100); Breakpoint 2, foo () at gdb.base/bp-cmds-continue-ctrl-c.c:23 23 usleep (100); ^C Breakpoint 2, Python Exception <class 'KeyboardInterrupt'> <class 'KeyboardInterrupt'>: foo () at gdb.base/bp-cmds-continue-ctrl-c.c:23 23 usleep (100); Breakpoint 2, foo () at gdb.base/bp-cmds-continue-ctrl-c.c:23 23 usleep (100); Breakpoint 2, foo () at gdb.base/bp-cmds-continue-ctrl-c.c:23 23 usleep (100); ~~~ Notice the Python exception above. The interesting thing here is that GDB continues as if nothing happened, doesn't really stop and give back control to the user. Instead, the Ctrl-C aborted the Python unwinder sniffer and GDB moved on to just use another unwinder. Fix this by translating a PyExc_KeyboardInterrupt back into a Quit exception once back in GDB. This was exposed by the new gdb.base/bp-cmds-continue-ctrl-c.exp testcase added later in the series. gdb/ChangeLog: 2017-11-16 Pedro Alves <palves@redhat.com> * python/py-unwind.c (pyuw_sniffer): Translate PyExc_KeyboardInterrupt to a GDB Quit exception.
2017-11-16Don't ever Quit out of resumePedro Alves2-35/+17
If you have a breakpoint command that re-resumes the target, like: break foo commands > c > end and then let the inferior run, hitting the breakpoint, and then press Ctrl-C at just the right time, between GDB processing the stop at "foo", and re-resuming the target, you'll hit the QUIT call in infrun.c:resume. With this hack, we can reproduce the bad case consistently: --- a/gdb/inf-loop.c +++ b/gdb/inf-loop.c @@ -31,6 +31,8 @@ #include "top.h" #include "observer.h" +bool continue_hack; + /* General function to handle events in the inferior. */ void @@ -64,6 +66,8 @@ inferior_event_handler (enum inferior_event_type event_type, { check_frame_language_change (); + continue_hack = true; + /* Don't propagate breakpoint commands errors. Either we're stopping or some command resumes the inferior. The user will be informed. */ diff --git a/gdb/infrun.c b/gdb/infrun.c index d425664..c74b14c 100644 --- a/gdb/infrun.c +++ b/gdb/infrun.c @@ -2403,6 +2403,10 @@ resume (enum gdb_signal sig) gdb_assert (!tp->stop_requested); gdb_assert (!thread_is_in_step_over_chain (tp)); + extern bool continue_hack; + + if (continue_hack) + set_quit_flag (); QUIT; The GDB backtrace looks like this: (top-gdb) bt ... #3 0x0000000000612e8b in throw_quit(char const*, ...) (fmt=0xaf84a1 "Quit") at src/gdb/common/common-exceptions.c:408 #4 0x00000000007fc104 in quit() () at src/gdb/utils.c:748 #5 0x00000000006a79d2 in default_quit_handler() () at src/gdb/event-top.c:954 #6 0x00000000007fc134 in maybe_quit() () at src/gdb/utils.c:762 #7 0x00000000006f66a3 in resume(gdb_signal) (sig=GDB_SIGNAL_0) at src/gdb/infrun.c:2406 #8 0x0000000000700c3d in keep_going_pass_signal(execution_control_state*) (ecs=0x7ffcf3744e60) at src/gdb/infrun.c:7793 #9 0x00000000006f5fcd in start_step_over() () at src/gdb/infrun.c:2145 #10 0x00000000006f7b1f in proceed(unsigned long, gdb_signal) (addr=18446744073709551615, siggnal=GDB_SIGNAL_DEFAULT) at src/gdb/infrun.c:3135 #11 0x00000000006ebdd4 in continue_1(int) (all_threads=0) at src/gdb/infcmd.c:842 #12 0x00000000006ec097 in continue_command(char*, int) (args=0x0, from_tty=0) at src/gdb/infcmd.c:938 #13 0x00000000004b5140 in do_cfunc(cmd_list_element*, char*, int) (c=0x2d18570, args=0x0, from_tty=0) at src/gdb/cli/cli-decode.c:106 #14 0x00000000004b8219 in cmd_func(cmd_list_element*, char*, int) (cmd=0x2d18570, args=0x0, from_tty=0) at src/gdb/cli/cli-decode.c:1952 #15 0x00000000007f1532 in execute_command(char*, int) (p=0x7ffcf37452b1 "", from_tty=0) at src/gdb/top.c:608 #16 0x00000000004bd127 in execute_control_command(command_line*) (cmd=0x3a88ef0) at src/gdb/cli/cli-script.c:485 #17 0x00000000005cae0c in bpstat_do_actions_1(bpstat*) (bsp=0x37edcf0) at src/gdb/breakpoint.c:4513 #18 0x00000000005caf67 in bpstat_do_actions() () at src/gdb/breakpoint.c:4563 #19 0x00000000006e8798 in inferior_event_handler(inferior_event_type, void*) (event_type=INF_EXEC_COMPLETE, client_data=0x0) at src/gdb/inf-loop.c:72 #20 0x00000000006f9447 in fetch_inferior_event(void*) (client_data=0x0) at src/gdb/infrun.c:3970 #21 0x00000000006e870e in inferior_event_handler(inferior_event_type, void*) (event_type=INF_REG_EVENT, client_data=0x0) at src/gdb/inf-loop.c:43 #22 0x0000000000494d58 in remote_async_serial_handler(serial*, void*) (scb=0x3585ca0, context=0x2cd1b80) at src/gdb/remote.c:13820 #23 0x000000000044d682 in run_async_handler_and_reschedule(serial*) (scb=0x3585ca0) at src/gdb/ser-base.c:137 #24 0x000000000044d767 in fd_event(int, void*) (error=0, context=0x3585ca0) at src/gdb/ser-base.c:188 #25 0x00000000006a5686 in handle_file_event(file_handler*, int) (file_ptr=0x45997d0, ready_mask=1) at src/gdb/event-loop.c:733 #26 0x00000000006a5c29 in gdb_wait_for_event(int) (block=1) at src/gdb/event-loop.c:859 #27 0x00000000006a4aa6 in gdb_do_one_event() () at src/gdb/event-loop.c:347 #28 0x00000000006a4ade in start_event_loop() () at src/gdb/event-loop.c:371 and when that happens, you end up with GDB's run control in quite a messed up state. Something like this: thread_function1 (arg=0x1) at threads.c:107 107 usleep (SLEEP); /* Loop increment. */ Quit (gdb) c Continuing. ** nothing happens, time passes..., press ctrl-c again ** ^CQuit (gdb) info threads Id Target Id Frame 1 Thread 1462.1462 "threads" (running) * 2 Thread 1462.1466 "threads" (running) 3 Thread 1462.1465 "function0" (running) (gdb) c Cannot execute this command while the selected thread is running. (gdb) The first "Quit" above is thrown from within "resume", and cancels run control while GDB is in the middle of stepping over a breakpoint. with step_over_info_valid_p() true. The next "c" didn't actually resume anything, because GDB throught that the step-over was still in progress. It wasn't, because the thread that was supposed to be stepping over the breakpoint wasn't actually resumed. So at this point, we press Ctrl-C again, and this time, the default quit handler is called directly from the event loop (event-top.c:default_quit_handler -> quit()), because gdb was left owning the terminal (because the previous resume was cancelled before we reach target_resume -> target_terminal::inferior()). Note that the exception called from within resume ends up calling normal_stop via resume_cleanups. That's very borked though, because normal_stop is going to re-handle whatever was the last reported event, possibly even re-running a hook stop... I think that the only sane way to safely cancel the run control state machinery is to push an event via handle_inferior_event like all other events. The fix here does two things, and either alone would fix the problem at hand: #1 - passes the terminal to the inferior earlier, so that any QUIT call from the point we declare the target as running goes to the inferior directly, protecting run control from unsafe QUIT calls. #2 - gets rid of this QUIT call in resume and of its related unsafe resume_cleanups. Aboout #2, the comment describing resume says: /* Resume the inferior, but allow a QUIT. This is useful if the user wants to interrupt some lengthy single-stepping operation (for child processes, the SIGINT goes to the inferior, and so we get a SIGINT random_signal, but for remote debugging and perhaps other targets, that's not true). but that's a really old comment that predates a lot of fixes to Ctrl-C handling throughout both GDB core and the remote target, that made sure that a Ctrl-C isn't ever lost. In any case, if some target depended on this, a much better fix would be to make the target return a SIGINT stop out of target_wait the next time that is called. This was exposed by the new gdb.base/bp-cmds-continue-ctrl-c.exp testcase added later in the series. gdb/ChangeLog: 2017-11-16 Pedro Alves <palves@redhat.com> * infrun.c (resume_cleanups): Delete. (resume): No longer install a resume_cleanups cleanup nor call QUIT. (proceed): Pass the terminal to the inferior. (keep_going_pass_signal): No longer install a resume_cleanups cleanup.
2017-11-16Fix stdin ending up not registered after a QuitPedro Alves2-1/+14
If you press Ctrl-C while GDB is processing breakpoint commands the TRY/CATCH in inferior_event_handler catches the Quit exception and prints it, and then if the interpreter was running a foreground execution command, nothing re-adds stdin back in the event loop, meaning the debug session ends up busted, because the user can't type anything... This was exposed by the new gdb.base/bp-cmds-continue-ctrl-c.exp testcase added later in the series. gdb/ChangeLog: 2017-11-16 Pedro Alves <palves@redhat.com> * inf-loop.c (inferior_event_handler): Don't swallow the exception if the prompt is blocked.
2017-11-16Fix swallowed "Quit" when inserting breakpointsPedro Alves2-20/+26
If GDB is inserting a breakpoint and you type Ctrl-C at the exact "right" time, you'll hit a QUIT call in target_read, and the breakpoint insertion is cancelled. However, the related TRY/CATCH code in insert_bp_location does: CATCH (e, RETURN_MASK_ALL) { bp_err = e.error; bp_err_message = e.message; } The problem with that is that a RETURN_QUIT exception has e.error == 0, which means that further below, in the places that check for error with: if (bp_err != GDB_NO_ERROR) because GDB_NO_ERROR == 0, GDB continues as if the breakpoint was inserted succesfully, and resumes the inferior. Since the breakpoint wasn't inserted the inferior runs free, out of our control... Fix this by having insert_bp_location store a copy of the whole exception instead of just a error/message parts, and then checking "gdb_exception::reason" instead. This was exposed by the new gdb.base/bp-cmds-continue-ctrl-c.exp testcase added later in the series. gdb/ChangeLog: 2017-11-16 Pedro Alves <palves@redhat.com> * breakpoint.c (insert_bp_location): Replace bp_err and bp_err_message locals by a gdb_exception local.
2017-11-16gdb/inflow.c: Move SIGTTOU temporary ignoring to a RAII classPedro Alves2-17/+38
I expect to use this in more places (in inflow.c) in follow up patches, but I think this is still good on its own. gdb/ChangeLog: 2017-11-16 Pedro Alves <palves@redhat.com> * inflow.c (scoped_ignore_sigttou): New class. (child_terminal_ours_1, new_tty): Use it.
2017-11-16Fix testing gdb.rust/modules.exp against gdbserverPedro Alves2-8/+15
Currently several tests in gdb.rust/modules.exp fail with --target_board=native-gdbserver: Running src/gdb/testsuite/gdb.rust/modules.exp ... FAIL: gdb.rust/modules.exp: call f3() FAIL: gdb.rust/modules.exp: call self::f2() FAIL: gdb.rust/modules.exp: call self::super::f2() FAIL: gdb.rust/modules.exp: call super::f2() FAIL: gdb.rust/modules.exp: call self::super::super::f2() FAIL: gdb.rust/modules.exp: call super::super::f2() FAIL: gdb.rust/modules.exp: call ::f2() FAIL: gdb.rust/modules.exp: call extern modules::mod1::f2() This is because these tests rely on matching inferior output. However, when testing with gdbserver, inferior output goes to a separate terminal instead of to gdb's terminal, and so gdb_test won't cut it, as that is only reading from gdb's pty/gdb_spawn_id: (gdb) call f3() (gdb) FAIL: gdb.rust/modules.exp: call f3() call self::f2() (gdb) FAIL: gdb.rust/modules.exp: call self::f2() Fix this by using gdb_test_stdio instead, which handles output coming out of gdbserver's pty. Also, skip the tests if the target/board doesn't support inferior I/O at all. gdb/ChangeLog: 2017-11-16 Pedro Alves <palves@redhat.com> * gdb.rust/modules.exp: Skip tests that rely on inferior I/O if gdb,noinferiorio is set, and use gdb_test_stdio otherwise.
2017-11-16Refactor endian handling in DFP routinesUlrich Weigand2-39/+43
This patch moves endian conversion into the decimal_from_number and decimal_to_number routines, and removes it from all their callers, making the code simpler overall. No functional change. gdb/ChangeLog: 2017-11-16 Ulrich Weigand <uweigand@de.ibm.com> * target-float.c (decimal_from_number): Add byte_order argument and call match_endianness. Error if unknown floating-point type. (decimal_to_number): Add byte_order argument and call match_endianness. (decimal_from_longest): Update call. Do not call match_endianness. (decimal_from_ulongest): Likewise. (decimal_binop): Likewise. (decimal_is_zero): Likewise. (decimal_compare): Likewise. (decimal_convert): Likewise.
2017-11-16GDBserver: Fix ignored Ctrl-C after reconnectionPedro Alves5-4/+111
This fixes the issue reported by Dmitry Antipov <dantipov@nvidia.com> here: https://sourceware.org/ml/gdb/2017-10/msg00048.html The problem is that GDBserver stops listening to Ctrl-C/interrupt requests if you disconnect and reconnect back. Dmitry wrote: ~~~ Currently gdbserver installs SIGIO handler just once, in initialize_async_io() called from captured_main(), and this handler is removed when remote_desc is closed in remote_close(). Next, when a new instance of remote_desc is fetched from accept() and has '\003' arrived, input_interrupt() is never called because it is not registered as SIGIO handler. ~~~ The fix here is not remove the SIGIO handler in the first place, thus going back to the original before-first-connection state. (I haven't gone back to try it, but I think this was a regression caused by commit 8b2073398477 ("[GDBserver] Block and unblock SIGIO"), which was what made remote_close remove the signal handler.) New test included. gdb/gdbserver/ChangeLog: 2017-11-16 Pedro Alves <palves@redhat.com> * remote-utils.c (remote_close): Block SIGIO signals instead of uninstalling the SIGIO handler. gdb/testsuite/ChangeLog: 2017-11-16 Pedro Alves <palves@redhat.com> * gdb.server/reconnect-ctrl-c.c: New file. * gdb.server/reconnect-ctrl-c.exp: New file.
2017-11-16Add Python rbreak command.Phil Muldoon9-1/+388
gdb/Changelog 2017-11-16 Phil Muldoon <pmuldoon@redhat.com> * python/python.c (gdbpy_rbreak): New function. * NEWS: Document Python rbreak feature. testsuite/Changelog 2017-11-16 Phil Muldoon <pmuldoon@redhat.com> * gdb.python/py-rbreak.exp: New file. * gdb.python/py-rbreak.c: New file. * gdb.python/py-rbreak-func2.c: New file. doc/Changelog 2017-11-16 Phil Muldoon <pmuldoon@redhat.com> * python.texi (Basic Python): Add rbreak documentation.
2017-11-16Fix gdb.base/starti.exp racy testPedro Alves3-3/+13
This commit fixes a couple problems with gdb.base/starti.exp, causing spurious FAILs. The first is a double-prompt problem: ~~~ (gdb) PASS: gdb.base/starti.exp: hook-stop starti [....] gdb_expect_list pattern: /\$1 = 0/ $1 = 0 gdb_expect_list pattern: // 0x00007ffff7ddcc80 in _start () from /lib64/ld-linux-x86-64.so.2 (gdb) # EXPECTED PROMPT (gdb) PASS: gdb.base/starti.exp: starti # ANOTHER PROMPT! break main ~~~ This happens because the test uses gdb_test_sequence with no command, like this: gdb_test_sequence "" "starti" { "Program stopped." "\\$1 = 0" } but gdb_test_sequence doesn't have a check for empty command like gdb_test_multiple does, and so sends "\n" to GDB: proc gdb_test_sequence { command test_name expected_output_list } { global gdb_prompt if { $test_name == "" } { set test_name $command } lappend expected_output_list ""; # implicit ".*" before gdb prompt send_gdb "$command\n" return [gdb_expect_list $test_name "$gdb_prompt $" $expected_output_list] } "starti" is a no-repeat command, so pressing <ret> just makes another prompt appear, confusing the following gdb_test/gdb_test_multiple/etc. Even with that fixed, the testcase is still racy though. The second problem is that sometimes the "continue" test times out here: ~~~ continue Continuing. $2 = 1 gdb_expect_list pattern: /.*Breakpoint .*main \(\) at .*starti.c.*/ Breakpoint 1, main () at /home/pedro/src/gdb/testsuite/gdb.base/starti.c:29 29 return 0; (gdb) gdb_expect_list pattern: // * hung here * ~~~ The problem is that the too-greedy ".*" trailing match in gdb_expect_list's pattern ends up consuming GDB's prompt too soon. Fix that by removing the unnecessary trailing ".*". While at it, remove all ".*"s to be stricter. Tested on x86_64 GNU/Linux. gdb/testsuite/ChangeLog: 2017-11-16 Pedro Alves <palves@redhat.com> * gdb.base/starti.exp ("continue" test): Remove ".*"s from pattern. * lib/gdb.exp (gdb_test_sequence): Don't send empty command to GDB.
2017-11-16Remove non-linux tic6x target descriptionsYao Qi4-39/+6
They are not used by GDB nor by GDBserver. This patch removes them. gdb: 2017-11-16 Yao Qi <yao.qi@linaro.org> * features/tic6x-c62x.xml: Remove. * features/tic6x-c64x.xml: Remove. * features/tic6x-c64xp.xml: Remove.
2017-11-16Allow osabi to be optional in target descriptionsAlan Hayward2-5/+11
gdbserver/ * tdesc.c (tdesc_get_features_xml): Allow null osabi.
2017-11-16Fix tic6x-uclinux GDBserver build failureYao Qi2-10/+13
I can't find a c6x-uclinux c++ compiler, so I use my host g++ to build tic6x-uclinux GDBserver, and find the following build failures. They are not target specific, so I believe they are real errors. This patch fixes them. ../binutils-gdb/gdb/gdbserver/linux-tic6x-low.c:313:34: error: invalid conversion from 'void*' to 'tic6x_register*' [-fpermissive] union tic6x_register *regset = buf; ^ ../binutils-gdb/gdb/gdbserver/linux-tic6x-low.c: In function 'void tic6x_store_gregset(regcache*, const void*)': ../binutils-gdb/gdb/gdbserver/linux-tic6x-low.c:324:40: error: invalid conversion from 'const void*' to 'const tic6x_register*' [-fpermissive] const union tic6x_register *regset = buf; ^ ../binutils-gdb/gdb/gdbserver/linux-tic6x-low.c: At global scope: ../binutils-gdb/gdb/gdbserver/linux-tic6x-low.c:359:28: error: redefinition of 'usrregs_info tic6x_usrregs_info' static struct usrregs_info tic6x_usrregs_info = ^ ../binutils-gdb/gdb/gdbserver/linux-tic6x-low.c:186:28: note: 'usrregs_info tic6x_usrregs_info' previously declared here static struct usrregs_info tic6x_usrregs_info; ^ gdb/gdbserver: 2017-11-16 Yao Qi <yao.qi@linaro.org> * linux-tic6x-low.c (tic6x_fill_gregset): Cast buf. (tic6x_store_gregset): Likewise. (tic6x_usrregs_info): Move it up.
2017-11-15Include <array> to declare std::array<>.John Baldwin2-0/+5
gdb/ChangeLog: * symtab.h: Include <array>.
2017-11-15Constify the 'arg' passed to commands in bsd-kvm.c.John Baldwin2-2/+7
gdb/ChangeLog: * bsd-kvm.c (bsd_kvm_cmd): Constify 'arg'. (bsd_kvm_proc_cmd): Likewise.
2017-11-15tui-win: Replace VEC with std::vectorSimon Marchi2-12/+14
This patch replaces an instance of VEC (const_char_ptr) with std::vector<const char *>. Tested by running gdb.tui/completion.exp, which exercises this function. gdb/ChangeLog: * tui/tui-win.c (window_name_completer): Replace VEC with std::vector.
2017-11-15Fix gdb.tui/completion.exp testSimon Marchi2-1/+6
When I run it locally, the test gdb.tui/completion.exp test fails because of a timeout: Running /home/emaisin/src/binutils-gdb/gdb/testsuite/gdb.tui/completion.exp ... FAIL: gdb.tui/completion.exp: completion of layout names: tab completion (timeout) The problem seems to be this regex, which confirms that after doing layout<TAB>, "layout" is printed again after the gdb prompt: -re "^$input_line$" The problem is that there's a trailing space in the output after "layout". Since the regex has an anchored end (the $), it doesn't match. Adding a space fixes the test. gdb/testsuite/ChangeLog: * gdb.tui/completionn.exp (test_tab_completion): Add space in regex.
2017-11-15Remove no-longer applicable maintainer entriesAndrew Cagney2-2/+4
2017-11-15 Andrew Cagney <cagney@gnu.org> * MAINTAINERS: Remove no-longer applicable entries.
2017-11-15Move self to Past Maintainers.Andrew Cagney2-1/+7
2017-11-15 Andrew Cagney <cagney@gnu.org> * MAINTAINERS: Move self to Past Maintainers.
2017-11-15Remove features/nios2-linux.cYao Qi4-76/+7
tdesc_nios2_linux is not used at all. Remove features/nios2-linux.c, and don't generate it anymore. gdb: 2017-11-15 Yao Qi <yao.qi@linaro.org> * features/Makefile (XMLTOC): Remove nios2-linux.xml. * features/nios2-linux.c: Remove. * nios2-linux-tdep.c (_initialize_nios2_linux_tdep): Don't call initialize_tdesc_nios2_linux.
2017-11-15Better make rule for arch/ files built for IPAAlan Hayward3-3/+8
gdbserver/ * Makefile.in: Update arch rules. * configure.srv: Explicitly mark arch/ files.
2017-11-15Fix M68HC11_NUM_REGSYao Qi2-1/+6
M68HC11_LAST_HARD_REG is 8, but m68hc11 register number is started from 0, so there are 9 raw registers, but M68HC11_NUM_REGS is 8 by mistake. My following unit test can find this issue (GDB is built with asan) ================================================================= ==15555==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000113150 at pc 0x51393f bp 0x7fffcec36f60 sp 0x7fffcec36f58 WRITE of size 2 at 0x602000113150 thread T0 #0 0x51393e in m68hc11_pseudo_register_read gdb/m68hc11-tdep.c:320 #1 0xc4b620 in gdbarch_pseudo_register_read(gdbarch*, regcache*, int, unsigned char*) gdb/gdbarch.c:1974 #2 0xddad88 in regcache::cooked_read(int, unsigned char*) gdb/regcache.c:710 #3 0xddff2b in cooked_read_test gdb/regcache.c:1850 #4 0xdf8cfb in selftests::gdbarch_selftest::operator()() const gdb/selftest-arch.c:73 gdb: 2017-11-15 Yao Qi <yao.qi@linaro.org> * m68hc11-tdep.c (M68HC11_NUM_REGS): Change it to M68HC11_LAST_HARD_REG + 1.
2017-11-14Fix 'xfered>0' assertion in target.c for remote connectionPaul Carroll2-5/+13
We have a customer who is using a Corelis gdb server to connect to gdb. Occasionally, the gdb server will send a 0-byte block of memory for a read. When this happens, gdb gives an assertion from target.c: internal-error: target_xfer_partial: Assertion `*xfered_len > 0' failed. This problem is almost identical to that fixed in https://sourceware.org/ml/gdb-patches/2014-02/msg00636.html In this case, remote.c needs to be modified to return TARGET_XFER_EOF instead of TARGET_XFER_OK or TARGET_XFER_UNAVAILABLE when 0 bytes are transferred. gdb/ChangeLog: PR gdb/22388 * remote.c (remote_write_bytes_aux, remote_read_bytes_1, remote_read_bytes, remote_write_qxfer, remote_xfer_partial): Return TARGET_XFER_EOF if size of returned data is 0.
2017-11-14Fix mem region parsing regression and add testSimon Marchi4-1/+93
In my patch Get rid of VEC (mem_region) a664f67e50eff30198097d51cec0ec4690abb2a1 I introduced a regression, where the length of the memory region is assigned to the "hi" field. It should obviously be computed as "start + length". To my defense, no test had caught this :). As a penance, I wrote one. gdb/ChangeLog: * Makefile.in (SUBDIR_UNITTESTS_SRCS): Add memory-map-selftests.c. (SUBDIR_UNITTESTS_OBS): Add memory-map-selftests.o. * memory-map.c (memory_map_start_memory): Fix computation of hi address. * unittests/memory-map-selftests.c: New file.
2017-11-13gdb.opt/inline-locals.exp: Remove trailing parentheses in test namesSimon Marchi2-18/+23
Test names should not end with parentheses, since the buildbot strips those. gdb/testsuite/ChangeLog: * gdb.opt/inline-locals.exp: Remove trailing parentheses from test names.
2017-11-13Enable hardware single step for m68k in GDBServerAndreas Schwab2-0/+37
* linux-m68k-low.c (m68k_supports_hardware_single_step): New function. (struct linux_target_ops) <supports_hardware_single_step>: Initialize.
2017-11-09Fix racy output matching in gdb.tui/tui-completion.expPedro Alves2-19/+24
'make check-read1 TESTS="gdb.tui/tui-completion.exp"' exposes this test race: (gdb) PASS: gdb.tui/completion.exp: set max-completions unlimited layout ^G asm next prev regs split src (gdb) FAIL: gdb.tui/completion.exp: completion of layout names: tab completion Quit (gdb) PASS: gdb.tui/completion.exp: completion of layout names: quit command input focus ^G cmd next prev src (gdb) FAIL: gdb.tui/completion.exp: completion of focus command: tab completion Quit This is caused by expecting "$gdb_prompt layout $". gdb_test_multiple's internal prompt regexp can match first if expect's internal buffer is filled with partial output. Fix that by splitting the gdb_test_multiple in question in two. Since the same problem/code appears twice in the file, factor out a common procedure. gdb/testsuite/ChangeLog: 2017-11-09 Pedro Alves <palves@redhat.com> * gdb.tui/tui-completion.exp (test_tab_completion): New procedure, factored out from ... (top level): ... here, and adjusted to avoid expecting beyond the prompt in a single gdb_test_multiple.
2017-11-09Fix racy output matching in gdb.base/multi-attach.exp, ↵Pedro Alves6-6/+15
gdb.server/ext-{attach, restart, ext-run}.exp This commit fixes this same problem in several places: (gdb) PASS: gdb.multi/multi-attach.exp: backtrace 2 kill Kill the program being debugged? (y or n) y (gdb) FAIL: gdb.multi/multi-attach.exp: kill inferior 2 (got interactive prompt) This is just another case of the gdb_test_multiple's internal "got interactive prompt" pattern matching because the testcase misses matching enough. gdb/testsuite/ChangeLog: 2017-11-09 Pedro Alves <palves@redhat.com> * gdb.multi/multi-attach.exp ("kill" test): Match the whole query output. * gdb.server/ext-attach.exp ("kill" test): Likewise. * gdb.server/ext-restart.exp ("kill" test): Likewise. * gdb.server/ext-run.exp ("kill" test): Likewise. * gdb.server/ext-wrapper.exp ("kill" test): Likewise.
2017-11-09Fix racy output matching in gdb.base/cpcompletion.expPedro Alves2-1/+6
With: $ make check-read1 TESTS="gdb.cp/cpcompletion.exp" we get (from gdb.log): (gdb) complete break Foo:: break Foo::Foo() break Foo::Foofoo() break Foo::get_foo() break Foo::set_foo(int) break Foo::~Foo() (gdb) FAIL: gdb.cp/cpcompletion.exp: complete class methods (Foo not found) The problem is that the "break ${class}::\[A-Za-z0-9_~\]+" regexp patches partial input, like: break Foo::F break Foo::Fo break Foo::Foo etc. Fix that by expecting each whole line. gdb/testsuite/ChangeLog: 2017-11-09 Pedro Alves <palves@redhat.com> * gdb.cp/cpcompletion.exp (test_class_complete): Tighten regex to match till end of line.
2017-11-09Fix racy output matching in gdb.base/memattr.expPedro Alves2-6/+10
Testing with: $ make check-read1 TESTS="gdb.base/memattr.exp" Exposes a testcase bug that can result in racy fails: info mem Using user-defined memory regions. Num Enb Low Addr High Addr Attrs 1 y 0x0000000000601060 0x0000000000601160 wo nocache 2 y 0x0000000000601180 0x0000000000601280 ro nocache 4 y 0x0000000000601280 0x0000000000601380 rw nocache 3 y 0x0000000000601380 0x0000000000601480 rw nocache 5 y 0x0000000000601480 0x0000000000601580 rw nocache (gdb) FAIL: gdb.base/memattr.exp: info mem (1) The problem is that: "Attrs\[^\n\r]*.." matches: "Attrs \r" when the output buffer is filled with partial output like this: "info mem\r\nUsing user-defined memory regions.\r\nNum Enb Low Addr High Addr Attrs \r" gdb/testsuite/ChangeLog: 2017-11-09 Pedro Alves <palves@redhat.com> * gdb.base/memattr.exp: Tighten regexes to match the end line.
2017-11-09Fix racy output matching in gdb.base/completion.expPedro Alves2-52/+41
Testing with: $ make check-read1 TESTS="gdb.base/completion.exp" Exposes a testcase bug that can result in racy fails: FAIL: gdb.base/completion.exp: command-name completion limiting using tab character ERROR: Undefined command "". FAIL: gdb.base/completion.exp: symbol-name completion limiting using tab character FAIL: gdb.base/completion.exp: symbol-name completion limiting using complete command testsuite/gdb.log shows: (gdb) PASS: gdb.base/completion.exp: set max-completions 5 p^G passcount path print print-object printf *** List may be truncated, max-completions reached. *** (gdb) FAIL: gdb.base/completion.exp: command-name completion limiting using tab character pcomplete p Undefined command: "pcomplete". Try "help". (gdb) ERROR: Undefined command "". The problem is that the expect buffer can get filled with partial output that ends in the gdb prompt, and so the default FAIL inside gdb_test_multiple matches. Fix that by splitting the gdb_test_multiple in two stages. Since that is done in more than one place in the testcase, move the otherwise duplicate code to helper procedures. gdb/testsuite/ChangeLog: 2017-11-09 Pedro Alves <palves@redhat.com> * gdb.base/completion.exp (ignore_and_resync, test_tab_complete): New procedures, factored out from ... (top level): ... here, and adjusted to avoid expecting beyond the prompt in one go.
2017-11-09Fix racy output matching in gdb.asm/asm-source.expPedro Alves2-1/+6
Testing with: $ make check-read1 TESTS="gdb.asm/asm-source.exp" Exposes a testcase bug that can result in racy fails: (gdb) PASS: gdb.asm/asm-source.exp: next over foo3 return Make selected stack frame return now? (y or n) y n #0 main () at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.asm/asmsrc1.s:53 53 gdbasm_exit0 (gdb) FAIL: gdb.asm/asm-source.exp: return from foo2 (got interactive prompt) n The problem is that the "return now\?.*" regex can match partial output like this: "Make selected stack frame return no" and then we send the 'y' too early, and then the next time around we hit gdb_test_multiple's internal "got interactive prompt" regex. Also, note we match "return no" instead of "return now" because the regex is missing one quote level. gdb/testsuite/ChangeLog: 2017-11-09 Pedro Alves <palves@redhat.com> * gdb.asm/asm-source.exp ("kill" test): Match the whole query output. Fix '?' match.
2017-11-09fix typos in ada-lang.c commentJoel Brobecker2-2/+8
gdb/ChangeLog: * ada-lang.c: Fix some typos in the general command documenting how Ada expressions are being evaluated and how their result is printed.
2017-11-09Simplify the psymbol hash functionTom Tromey2-1/+11
This patch simplifies the psymbol_hash function, by changing it not to examine the contents of the symbol's name. This change just mirrors what psymbol_compare already does -- it is checking for name equality, which is ok because symbol names are interned in symbol_set_names. This change speeds up psymbol reading. "gdb -nx -batch gdb" previously took ~1.8 seconds on my machine, and with this patch it now takes ~1.7 seconds. gdb/ChangeLog 2017-11-09 Tom Tromey <tom@tromey.com> * psymtab.c (psymbol_hash): Do not hash string contents. (psymbol_compare): Add comment.
2017-11-09Speed up dict_hashTom Tromey2-16/+20
This speeds up dict_hash a bit, by moving the "TKB" check into the switch in the loop. For "gdb -nx -readnow -batch gdb", this improves the time from ~9.8s before to ~8.5s afterward. gdb/ChangeLog 2017-11-09 Tom Tromey <tom@tromey.com> * dictionary.c (dict_hash): Move "TKB" check into the "switch".
2017-11-08local variable watchpoint not deleted after leaving scopeJoel Brobecker10-14/+207
When debugging an Ada program, and inserting a watchpoint tracking a local variable, the watchpoint doesn't get automatically deleted upon leaving that variable's scope. This watchpoint then starts creating problems later on, when trying to resume the program's execution from a location outside of the watchpoint's scope: (gdb) c Continuing. Breakpoint 2, foo_p708_025 () at foo_p708_025.adb:7 7 Do_Nothing (Val); (gdb) n No frame is currently executing in block pck.get_val. Command aborted. (gdb) c Continuing. No frame is currently executing in block pck.get_val. Command aborted. The expected output is the following: - The program's execution after the first continue should stop as soon as we reach the end of the watchpoint's scope, and the debugger should be deleting it. - Then we can continue until reaching breakpoint 2 above; - After which we should be able to do next/continue as usual. The reason the watchpoint is not automatically deleted at scope exit is because the watchpoint is not marked as being scope-specific (b->exp_valid_block is equal NULL), and this is because the symbol lookup for our local variable failed to set the innermost_block global variable during the lookup. More precisely, if we look at watch_command_1, we do the following: innermost_block = NULL; [...] exp = parse_exp_1 (&arg, 0, 0, 0); [...] exp_valid_block = innermost_block; Currently, innermost_block stays NULL after the call to parse_exp_1. Digging further, this innermost_block is typically set during symbol lookup when the symbol is considered to have a frame-relative address. For instance, in c-exp.y, we see some code like the following: if (symbol_read_needs_frame (sym.symbol)) { if (innermost_block == 0 || contained_in (sym.block, innermost_block)) innermost_block = sym.block; } We actually have the exact same mechanism in ada-exp.y, except that it vhas accidently been turned off. See write_var_from_sym, where we start with: if (orig_left_context == NULL && symbol_read_needs_frame (sym)) { if (innermost_block == 0 || contained_in (block, innermost_block)) innermost_block = block; } In this case, orig_left_context is a parameter, and looking at the point of call in write_var_or_type, we see: if (nsyms == 1) { write_var_from_sym (par_state, block, syms[0].block, syms[0].symbol); In the call above, the paramater we are interested in is "block", which is a parameter for write_var_or_type as well, except we explicitly override its value at the beginning when found to be NULL: if (block == NULL) block = expression_context_block; So the block we pass to write_var_from_sym is not NULL, and we therefore don't set innermost_block, which leads to the watchpoint no longer being marked as scope-specific. The handling of orig_left_context in write_var_from_sym was there to handle the case where a user writes an expression where the symbol is qualified with a scope (Eg: "function::variable"). But it appears that handling this is specifically here is no longer necessary, so this patch simply removes that parameter and the associated check, and then updates all the points of calls. Interestingly, this also affects GDB/MI, and in particular varobjs, because local variables are now properly reported as having a block, which causes the associated varob to have a "thread-id" field. This patch also adjusts a couple of Ada/gdb-mi tests. gdb/ChangeLog: * ada-exp.y (write_var_from_sym): Remove parameter "orig_left_context". Update all callers. gdb/testsuite/ChangeLog: * gdb.ada/scoped_watch: New testcase. * gdb.ada/watch_arg.exp: Adjust expected behavior to the behavior which is actually correct. * gdb.ada/mi_interface.exp: Add missing thread-id in expected varobj. * gdb.ada/mi_var_array.exp: Add missing thread-id in expected varobj.
2017-11-08Make encode_actions_rsp use std::vectorSimon Marchi4-94/+65
Currently, encode_actions_rsp returns two malloc'ed arrays of malloc'ed strings (char *) by pointer. Change this to use std::vector<std::string>. This eliminates some cleanups in remote.c. Regtested on the buildbot. gdb/ChangeLog: * tracepoint.h (class collection_list) <stringify>: Return std::vector<std::string>. (encode_actions_rsp): Change parameters to std::vector<std::string> *. * tracepoint.c (collection_list::stringify): Return std::vector<std::string> and adjust accordingly. (encode_actions_rsp): Changee parameters to std::vector<std::string> and adjust accordingly. * remote.c (free_actions_list), free_actions_list_cleanup_wrapper): Remove. (remote_download_tracepoint): Adjust to std::vector.
2017-11-08Avoid expensive complaint calls when complaints are disabledPedro Alves4-16/+44
Running perf on "gdb -nx -readnow -batch gdb", I'm seeing a lot of time (24%.75!) spent in gettext, via complaints. 'perf report -g' shows: - 86.23% 0.00% gdb gdb [.] gdb_main - gdb_main - 85.60% catch_command_errors symbol_file_add_main_adapter symbol_file_add_main symbol_file_add_main_1 symbol_file_add - symbol_file_add_with_addrs - 84.31% dw2_expand_all_symtabs - dw2_instantiate_symtab - 83.79% dw2_do_instantiate_symtab - 70.85% process_die - 41.11% dwarf_decode_macros - 41.09% dwarf_decode_macro_bytes - 39.74% dwarf_decode_macro_bytes >>>>>>>>>>>>>>>>>>>>>>> + 24.75% __dcigettext <<<<<<< + 7.37% macro_define_object_internal + 3.16% macro_define_function 0.77% splay_tree_insert + 0.76% savestring + 0.58% free 0.53% read_indirect_string_at_offset_from 0.54% macro_define_object_internal 0.51% macro_start_file + 25.57% process_die + 4.07% dwarf_decode_lines + 4.28% compute_delayed_physnames + 3.85% end_symtab_from_static_block + 3.38% load_cu + 1.29% end_symtab_get_static_block + 0.52% do_my_cleanups + 1.29% read_symbols + 0.54% gdb_init The problem is that we're always computing the arguments to pass to complaint, including passing the format strings through gettext, even when complaints are disabled. As seen above, gettext can be quite expensive. Fix this by wrapping complaint in a macro that skips the real complaint call when complaints are disabled. This improves "gdb -nx -readnow -batch gdb" from ~11.0s => ~7.8s with -O2 -g3, and ~6.0s => ~5.3s with -O2 -g. w/ gcc 5.3.1, on x86_64, for me. gdb/ChangeLog: 2017-11-08 Pedro Alves <palves@redhat.com> * complaints.c (stop_whining): Make extern. (complaint): Rename to ... (complaint_internal): ... this. * complaints.h (complaint): Rename to ... (complaint_internal): ... this. (complaint): Reimplement as macro around complaint_internal. gdb/testsuite/ChangeLog: 2017-11-08 Pedro Alves <palves@redhat.com> * gdb.gdb/complaints.exp (test_initial_complaints) (test_serial_complaints, test_short_complaints): Call complaint_internal instead of complaint.
2017-11-08Add test for fetching TLS from core fileDjordje Todorovic3-0/+98
A correct PID is needed by `libthread_db' library supplied with glibc repository revisions before commit c579f48edba8 ("Remove cached PID/TID in clone") or versions before 2.25 release for GDB to fetch value of TLS variable from core file. On MIPS platforms it was omitted and fetching value of TLS variable was not available. This adds a new test in order to be sure if GDB on native platforms can successfully fetch value of TLS variable. gdb/testsuite: * gdb.threads/tls-core.c: New file. * gdb.threads/tls-core.exp: Likewise.
2017-11-08Remove symbolp vectorTom Tromey2-16/+16
This removes the symbolp typedef from dwarf2read.c and converts the associated VEC uses to std::vector. This fixes a latent possible memory leak if an exception were thrown, because there were no cleanups installed for these VECs. Regression tested on the buildbot. gdb/ChangeLog 2017-11-08 Tom Tromey <tom@tromey.com> * dwarf2read.c (symbolp): Remove typedef. (read_func_scope): Use std::vector. (process_structure_scope): Use std::vector.
generated by cgit v1.1 at 2024-09-18 08:46:56 +0000