aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2013-03-30*** empty log message ***gdbadmin1-1/+1
2013-03-29 * dwarf2read.c (open_dwo_file): Renamed from open_dwop_file.Doug Evans2-18/+44
Delete arg is_dwp. All callers updated. (open_dwp_file): New function. (open_and_init_dwp_file): Call it. (get_dwp_file): New function. (lookup_dwo_cutu): Call it.
2013-03-29 * dwarf2read.c (open_and_init_dwp_file): Remove incorrect, andDoug Evans2-4/+3
unnecessary, cleanup.
2013-03-29 * dwarf2read.c (lookup_dwo_cutu): Improve complaint text.Doug Evans2-2/+4
2013-03-29 * dwarf2read.c (read_cutu_die_from_dwo): New function.Doug Evans2-155/+246
(lookup_dwo_unit): New function. (init_cutu_and_read_dies): Move DWO handling to new functions.
2013-03-29 * dwarf2read.c (struct signatured_type): Tweak comment.Doug Evans2-16/+28
(struct dwo_unit): Tweak comment. (create_debug_types_hash_table): Tweak comment. Reformat long line. (create_dwo_debug_info_hash_table): Tweak comment. (dwarf2_per_cu_offset_and_type): Tweak comment.
2013-03-29 * dwarf2read.c (lookup_signatured_type): Remove complaint aboutDoug Evans2-7/+8
missing .debug_types section.
2013-03-29gdb/Yao Qi9-6/+61
2013-03-29 Yao Qi <yao@codesourcery.com> * corelow.c: Include "completer.h". (_initialize_corelow): Call add_target_with_completer with argument 'filename_completer'. * tracepoint.c: Likewise. * exec.c (_initialize_exec): Likewise. * target.c (add_target): Rename to ... (add_target_with_completer): ... this. Call set_cmd_completer if parameter completer is not NULL. (add_target): New. * target.h: Include "command.h". (add_target_with_completer): Declare it. gdb/testsuite: 2013-03-29 Yao Qi <yao@codesourcery.com> * gdb.base/completion.exp: Test completion of commands "target core", "target tfile" and "target exec". * gdb.trace/tfile.exp: Test completion of command "target tfile".
2013-03-29Ignore __fu<digits>__ symbols from COFF symbol tablesJoel Brobecker7-0/+151
The debugger sometimes prints strange function names for given addresses. For instance, with the following source code... 4 procedure Foo is 5 A : Integer; 6 begin 7 Do_Nothing (A'Address); 8 end Foo; ... we can see... (gdb) info line 5 Line 5 of "foo.adb" starts at address 0x4017ca <_ada_foo+6> and ends at 0x4017d2 <_fu29__system__scalar_values__is_is4+7>. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ _fu29__system__scalar_values__is_is4 is an artificial symbol generated by the linker, and interferes with the pc-to-symbol resolution. There isn't much in the general minimal_symbol data that could help us identify them, so this patch changes the COFF reader to simply ignore them. gdb/ChangeLog: * coffread.c (is_import_fixup_symbol): New function. (record_minimal_symbol): Use is_import_fixup_symbol to detect import fixup symbols, and discard them. gdb/testsuite/ChangeLog: * gdb.ada/win_fu_syms: New testcase.
2013-03-29 * dwarf2read.c (create_debug_types_hash_table): Don't allocate theDoug Evans2-8/+11
types hash table until we know we need it.
2013-03-29 * dwarf2read.c (create_addrmap_from_index): Complain about bad CUDoug Evans2-3/+15
index numbers.
2013-03-29 * dwarf2read.c (dw2_get_file_names): Delete arg "objfile".Doug Evans4-13/+28
All callers updated. (dw2_print_stats): Print #read CUs too. (dump_die_shallow): Print signatured types better. testsuite/ * gdb.base/maint.exp (maint print statistics): Update expected output.
2013-03-29*** empty log message ***gdbadmin1-1/+1
2013-03-28 * dwarf2read.c (struct dwarf2_per_cu_data): Rename memberDoug Evans2-22/+27
info_or_types_section to section. All uses updated. (struct dwo_unit): Ditto.
2013-03-28Stop sending qTStatus if the target doesn't recognize it; add packet ↵Pedro Alves5-1/+36
configuration command. GDB currently sends a qTStatus even if the target previously replied an empty packet to a previous qTStatus. If the target doesn't recognize the packet, there's no point in trying again. The machinery we have in place is packet_ok, which has the nice side effect of forcing one to install a configuration command/knob for the packet in question, which is often handy when you need to debug things, and/or emulate a target that doesn't support the packet, or even, it can be used as workaround for the old broken kgdb's that return error to qTSTatus instead of an empty packet. gdb/ 2013-03-28 Pedro Alves <palves@redhat.com> * NEWS (New options): New section. (New options): Mention set/show remote trace-status-packet. * remote.c (PACKET_qTStatus): New enumeration value. (remote_get_trace_status): Skip sending qTStatus if the packet is disabled. Use packet_ok. (_initialize_remote): Register a configuration command for qTStatus packet. gdb/doc/ 2013-03-28 Pedro Alves <palves@redhat.com> * gdb.texinfo (Remote Configuration) <set remote @var{name}-packet table>: Add entry for "trace-status".
2013-03-28Fix Doug Evans's commit of 2013-03-21.Eli Zaretskii2-5/+13
* gdb.texinfo (Maintenance Commands): Use @enumerate, not "@table @bullet", which is invalid (makeinfo 5.1 barfs).
2013-03-28 * symfile.c (find_separate_debug_file): Add comment.Doug Evans2-2/+7
(terminate_after_last_dir_separator): Tweak comment.
2013-03-28 * dwarf2read.c (create_partial_symtab): Add forward decl.Doug Evans2-186/+203
(create_partial_symtab): Move to be closer to other psymtab functions. (process_psymtab_comp_unit_reader, process_psymtab_comp_unit): Ditto.
2013-03-28 * dwarf2read.c (dwarf2_physname): Move declaration to better spot.Doug Evans2-5/+10
(compute_symtab_includes): Remove unnecessary forward declaration. (die_needs_namespace): Add comment marking group of functions for dwarf2 name computation.
2013-03-28 * typeprint.c (_initialize_typeprint): Improve type help text.Doug Evans2-3/+6
2013-03-28 * python/python.c (finish_python_initialization): Provide suggestionDoug Evans2-2/+11
for how to tell gdb to find its python files.
2013-03-28Fix PR gdb/15294: list with unlimited listsize brokenPedro Alves6-14/+30
Currently, "set listsize -1" is supposed to mean "unlimited" source lines, but, alas, it doesn't actually work: (gdb) set listsize -1 (gdb) show listsize Number of source lines gdb will list by default is unlimited. (gdb) list 1 (gdb) list 1 (gdb) list 1 (gdb) set listsize 10 (gdb) list 1 1 /* Main function for CLI gdb. 2 Copyright (C) 2002-2013 Free Software Foundation, Inc. 3 4 This file is part of GDB. 5 6 This program is free software; you can redistribute it and/or modify 7 it under the terms of the GNU General Public License as published by 8 the Free Software Foundation; either version 3 of the License, or 9 (at your option) any later version. 10 Before this patch: http://sourceware.org/ml/gdb-patches/2012-08/msg00367.html was applied, the "set listsize" command was a var_integer command, and "unlimited" was set with 0. Internally, var_integer maps 0 to INT_MAX case var_integer: { ... if (val == 0 && c->var_type == var_integer) val = INT_MAX; The change in that patch to zuinteger_unlimited command, meant that -1 is left as -1 in the command's control variable (lines_to_list), and the code in source.c isn't expecting that -- it only expects positive numbers. I previously suggested fixing the code and keeping the new behavior, but I found that "set listsize 0" is currently used in the wild, and we do have a bunch of other commands where "0" means unlimited, so I'm thinking that changing this command alone in isolation is not a good idea. So I now strongly prefer reverting back the behavior in 7.6 to the same behavior the command has had since 2006 (0==unlimited, -1=error). Before that, set listsize -1 would be accepted as unlimited as well. After 7.6 is out, in mainline, we can get back to reconsidering changing this command's behavior, if there's a real need for being able to suppress output. For now, let's play it safe. The "list line 1 with unlimited listsize" test in list.exp was originally written years and years ago expecting 0 to mean "no output", but GDB never actually worked that way, even when the tests were written, so the tests had been xfailed then. This patch now adjusts the test to the new behavior, so that the test actually passes, and the xfail is removed. gdb/ 2013-03-28 Pedro Alves <palves@redhat.com> PR gdb/15294 * source.c (_initialize_source): Change back "set listsize" to an integer command. gdb/testsuite/ 2013-03-28 Pedro Alves <palves@redhat.com> PR gdb/15294 * gdb.base/list.exp (set_listsize): Adjust to accept $arg == 0 to mean unlimited instead of $arg < 0. (test_listsize): Remove "listsize of 0 suppresses output" test. Test that "set listsize 0" ends up with an unlimited listsize. gdb/doc/ 2013-03-28 Pedro Alves <palves@redhat.com> PR gdb/15294 * gdb.texinfo (List) <set listsize>: Adjust to document that listsize 0 means no limit, and remove mention of -1.
2013-03-28list.exp: Avoid hardcoding line numbers.Pedro Alves3-9/+34
The previous patch actually wasn't the first time I had to update line numbers in this file. This avoids hard coding line numbers, hopefully making the next time a little easier. Tested on x86_64 Fedora 17. gdb/testsuite/ 2013-03-28 Pedro Alves <palves@redhat.com> * gdb.base/list.exp (last_line): New global. (last_line_re): New global. (test_listsize, test_list_function, test_list_forward) (test_repeat_list_command, test_list_range) (test_list_filename_and_function): Use them. * gdb.base/list0.c: Comment the last line of the file with "last line".
2013-03-28list.exp: Adjust "set listsize -1" to current test source's real line count.Pedro Alves2-1/+6
The "set listsize -1" test in list.exp can't work correct anymore nowadays, because the test's source files grew over time, and this particular test was never updated. This fixes it in the obvious way. gdb/testsuite/ 2013-03-28 Pedro Alves <palves@redhat.com> * gdb.base/list.exp (test_listsize): Adjust test to make sure we list the whole file.
2013-03-28list.exp: Catch "set listsize" failures (and "set listsize -1/0"'s history).Pedro Alves2-1/+6
Before the changes starting at <http://sourceware.org/ml/gdb-patches/2012-08/msg00020.html>, the 'set listsize' command only accepted "0" as special value, meaning "unlimited". The testsuite actually tried "set listsize -1" and expected that to mean unlimited too. If you tried testing list.exp at the time of that patch above, you'd get: (gdb) PASS: gdb.base/list.exp: list line 10 with listsize 100 set listsize 0 (gdb) PASS: gdb.base/list.exp: setting listsize to 0 #6 show listsize Number of source lines gdb will list by default is unlimited. (gdb) PASS: gdb.base/list.exp: show listsize unlimited #6 list 1 1 #include "list0.h" 2 ... 42 /* Not used for anything */ 43 } (gdb) PASS: gdb.base/list.exp: listsize of 0 suppresses output set listsize -1 integer 4294967295 out of range (gdb) PASS: gdb.base/list.exp: setting listsize to -1 #7 show listsize Number of source lines gdb will list by default is unlimited. (gdb) PASS: gdb.base/list.exp: show listsize unlimited #7 list 1 1 #include "list0.h" Notice that "set listsize -1" actually failed with "integer 4294967295 out of range", but we issued a PASS anyway. (and notice how the "listsize of 0 suppresses output" test passes bogusly too.) This patch fixes that testsuite problem in the obvious way. gdb/testsuite/ 2013-03-28 Pedro Alves <palves@redhat.com> * gdb.base/list.exp (set_listsize): Use gdb_test_no_output for "set listsize".
2013-03-28*** empty log message ***gdbadmin1-1/+1
2013-03-27gdb/Jan Kratochvil2-2/+6
PR gdb/15275 * remote.c (remote_get_trace_status): Include putpkt in TRY_CATCH.
2013-03-27Forbid "set history size (INT_MAX..UINT_MAX)"Pedro Alves2-31/+64
The whole readline interface is signed, and works with the 0..INT_MAX range. We don't allow setting the size to UINT_MAX directly. The documented user visible interface is "use 0 for unlimited". The UINT_MAX representation is an implementation detail we could change, e.g., by keeping a separate flag for "unlimited", which is actually what the readline interface does (stifled vs non stifled). Generically speaking, exposing this detail to clients of the interface may make our lives complicated when we find the need to extend the range of some command in the future, and it's better if users (frontends/scripts) aren't relying on anything but what we tell them to use for "unlimited". Making values other than 0 error out is the way to prevent users from using those ranges inappropriately. Quite related, note: (gdb) set history size 0xffffffff integer 4294967295 out of range But, (gdb) set history size 0xfffffffe (gdb) show history size The size of the command history is unlimited. (gdb) set history size 0x100000000 integer 4294967296 out of range If values over INT_MAX are accepted as unlimited, then there's no good argument for only accepting [INT_MAX..UINT_MAX) as valid "unlimited" magic numbers, while not accepting [UINT_MAX..inf). Making the setting's control variable of different type (unsigned int) of the rest of the related code (int) adds the need to recall that one variable among all these is unsigned, and that one need to think about whether these comparisons are signed or unsigned, along with the promotion/conversion rules. Since this is an easy to forget detail, this patch renames the variable to at least make it more obvious that this variable is not one of GNU history's public int variables, which are all signed. We don't actually need the only code that presently is affected by this, though, the code that is computing the current history's length. We can just use GNU history's history_length instead: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Variable: int history_length The number of entries currently stored in the history list. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /* Return the history entry which is logically at OFFSET in the history array. OFFSET is relative to history_base. */ HIST_ENTRY * history_get (offset) int offset; { int local_index; local_index = offset - history_base; return (local_index >= history_length || local_index < 0 || the_history == 0) ? (HIST_ENTRY *)NULL : the_history[local_index]; } ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ At the time this code was added (gdb 4.13 ~1994), 'history_length' was extern, but not documented in readline's GNU history documents, so I guess it wasn't considered public then and the loop was the workaround. One of the warts of GDB choosing 0 to mean unlimited is that "set history size 0" behaves differently from 'HISTSIZE=0 gdb'. The latter leaves GDB with no history, while the former means "unlimited"... $ HISTSIZE=0 ./gdb ... (gdb) show history size The size of the command history is 0. We shouldn't really change what HISTSIZE=0 means, as bash, etc. also handle 0 as real zero, and zero it's what really makes sense. gdb/ 2013-03-27 Pedro Alves <palves@redhat.com> * top.c (history_size): Rename to ... (history_size_setshow_var): ... this. Add comment. (show_commands): Use readline's 'history_length' instead of computing the history length by calling history_get in a loop. (set_history_size_command): Error out for sizes over INT_MAX. Restore previous history size on invalid size. (init_history): If HISTSIZE is negative, leave the history size as zero. Add comments. (init_main): Adjust.
2013-03-27Rename "set debug coff_pe_read" command to "set debug coff-pe-read".Pedro Alves2-1/+6
Hyphens are much more common than underscores in command names. gdb/ 2013-03-27 Pedro Alves <palves@redhat.com> * coff-pe-read.c (_initialize_coff_pe_read): Rename "set debug coff_pe_read" command to "set debug coff-pe-read".
2013-03-27record: fix instruction-history-size regressionMarkus Metzger2-8/+14
* record.c (command_size_to_target_size): Fix size comparison. Change parameter type from pointer to integer to integer. Update all users.
2013-03-27 * windows-nat.c (handle_output_debug_string): Avoid typecastPierre Muller2-1/+6
from integer of different size warning.
2013-03-27 * gdb.base/dprintf.exp: Fix typo preventing "dprintf info 2"Keith Seitz2-1/+6
from passing.
2013-03-27*** empty log message ***gdbadmin1-1/+1
2013-03-26windows-nat.c: Add empty line after local block variable definitions.Joel Brobecker2-0/+7
gdb/ChangeLog: * windows-nat.c (handle_output_debug_string): Add empty line after local block variable definition.
2013-03-26ser-tcp.c: Small signed->unsigned cleanup.Pedro Alves2-2/+7
The "set tcp connect-timeout" variable is unsigned: /* Timeout period for connections, in seconds. */ static unsigned int tcp_retry_limit = 15; And used like: /* Check for timeout. */ if (*polls > tcp_retry_limit * POLL_INTERVAL) { errno = ETIMEDOUT; return -1; } Which made me stop and look over why is it that 'polls' is signed. What I found is there's really no reason. gdb/ 2013-03-26 Pedro Alves <palves@redhat.com> * ser-tcp.c (wait_for_connect): Make 'polls' parameter unsigned. (net_open): Make 'polls' local unsigned.
2013-03-26Make "set/show remoteaddresssize" a zuinteger command instead of uinteger.Pedro Alves2-5/+10
It makes no sense to talk about an "unlimited" address size in this context. (gdb) show remoteaddresssize The maximum size of the address (in bits) in a memory packet is 0. (gdb) set remoteaddresssize 0 (gdb) show remoteaddresssize The maximum size of the address (in bits) in a memory packet is unlimited. "set remoteaddresssize 0" mapping to UINT_MAX means you can't force gdb through this path twice in the same GDB run: static CORE_ADDR remote_address_masked (CORE_ADDR addr) { unsigned int address_size = remote_address_size; /* If "remoteaddresssize" was not set, default to target address size. */ if (!address_size) address_size = gdbarch_addr_bit (target_gdbarch ()); gdb/ 2013-03-26 Pedro Alves <palves@redhat.com> * remote.c (_initialize_remote): Make "set remoteaddresssize" a zuinteger command instead of uinteger.
2013-03-26record-full.c: Remove always true checks.Pedro Alves2-32/+35
The "set record full insn-number-max" command is an uinteger command. If the variable that holds the maximum count of logged instructions is unsigned, it's better if the variable that holds the current number of logged instructions is also unsigned. Looking over the code, there's no case the variable could end up negative. Then, tests like "if (record_full_insn_max_num)" are always true, because being a uinteger command means that "set record full insn-number-max 0" is actually mapped to UINT_MAX internally. IOW, the command's variable is never 0. The checks might make some sense if 0 wasn't mapped to UINT_MAX, and 0 meant unlimited, but, that's not how things work. Tested on x86_64 Fedora 17. gdb/ 2013-03-26 Pedro Alves <palves@redhat.com> * record-full.c (record_full_insn_num): Make it unsigned. (record_full_check_insn_num, record_full_message) (record_full_registers_change, record_full_xfer_partial): Remove record_full_insn_max_num check (it's always != 0). (record_full_info, record_full_restore): Use %u as format string. (): Use %u as format string. (set_record_full_insn_max_num): Remove record_full_insn_max_num check (it's always != 0).
2013-03-26Make "set/show dcache line-size" and "set/show dcache size" zinteger ↵Pedro Alves2-12/+17
commands instead of uinteger. It doesn't make sense to request an "unlimited" dcache. You want to configure the cache with specific lines and length of lines. It doesn't actually work anyway: (gdb) set dcache line-size 0 Invalid dcache line size: 4294967295 (must be power of 2). (gdb) set dcache size 0 (gdb) show dcache size Number of dcache lines is unlimited. (gdb) info dcache Dcache 4294967295 lines of 64 bytes each. No data cache available. The code already has guards in place to forbid 0s: static void set_dcache_size (char *args, int from_tty, struct cmd_list_element *c) { if (dcache_size == 0) { dcache_size = DCACHE_DEFAULT_SIZE; error (_("Dcache size must be greater than 0.")); } if (last_cache) dcache_invalidate (last_cache); } static void set_dcache_line_size (char *args, int from_tty, struct cmd_list_element *c) { if (dcache_line_size < 2 || (dcache_line_size & (dcache_line_size - 1)) != 0) { unsigned d = dcache_line_size; dcache_line_size = DCACHE_DEFAULT_LINE_SIZE; error (_("Invalid dcache line size: %u (must be power of 2)."), d); } if (last_cache) dcache_invalidate (last_cache); } So we now get: (gdb) set dcache line-size 0 Invalid dcache line size: 0 (must be power of 2). (gdb) set dcache size 0 Dcache size must be greater than 0. gdb/ 2013-03-26 Pedro Alves <palves@redhat.com> * dcache.c (_initialize_dcache): Make the "set dcache line-size" and "set dcache size" commands zuinteger instead of uinteger.
2013-03-26Make "set/show cris-version" a zuinteger instead of uinteger.Pedro Alves2-9/+14
Being a uinteger means you revert back to having GDB decide the version. It makes no sense to have an "unlimited" version. (gdb) show cris-version The current CRIS version is 0. (gdb) set cris-version 0 (gdb) show cris-version The current CRIS version is unlimited. (gdb) gdb/ 2013-03-26 Pedro Alves <palves@redhat.com> * cris-tdep.c (_initialize_cris_tdep): Make the "set cris-version" command zuinteger instead of uinteger.
2013-03-26Make "set/show debug coff_pe_read" a zuinteger instead of uinteger.Pedro Alves2-8/+13
Being a uinteger means you can't disable debug output after enabling it... (gdb) show debug coff_pe_read Coff PE read debugging is 0. (gdb) set debug coff_pe_read 0 (gdb) show debug coff_pe_read Coff PE read debugging is unlimited. (gdb) gdb/ 2013-03-26 Pedro Alves <palves@redhat.com> * coff-pe-read.c (_initialize_coff_pe_read): Make the command zuinteger instead of uinteger.
2013-03-26Get rid of "No such file or directory" in the testsuite's btrace support ↵Pedro Alves2-1/+8
detection. When I tried running the btrace tests, I noticed something odd in the gdb.log file: (gdb) run Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.btrace/btrace22343.x Breakpoint 1, main () at /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.btrace/btrace22343.c:1 1 /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.btrace/btrace22343.c: No such file or directory. ^^^^^^^^^^^^^^^^^^^^^^^^^ (gdb) record btrace Target does not support branch tracing. (gdb) testcase ../../../src/gdb/testsuite/gdb.btrace/enable.exp completed in 0 seconds I knew that the btrace tests on my machine weren't supposed to work, but still, that error made me wonder if the test had something broken, and waste a few minutes looking up where that is coming from. The issue is that the btrace detection deletes the source file right after compiling it, and before GDB has a chance to open it. It's really harmless, but I'd rather spare others from going through the same exercise. We now get the regular: (gdb) run Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.btrace/btrace24210.x ... Breakpoint 1, main () at /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.btrace/btrace24210.c:1 1 int main(void) { return 0; } ... gdb/testsuite/ 2013-03-26 Pedro Alves <palves@redhat.com> * lib/gdb.exp (skip_btrace_tests): Delay deleting the source file until after GDB has run.
2013-03-26"set record instruction-history-size"/"set record ↵Pedro Alves2-16/+101
function-call-history-size" range validation. While the commands are uinteger, the target interfaces are limited to INT_MAX. Don't let the user request more than we can handle. gdb/ 2013-03-26 Pedro Alves <palves@redhat.com> * record.c (record_insn_history_size_setshow_var) (record_call_history_size_setshow_var): New globals. (command_size_to_target_size): New function. (cmd_record_insn_history, cmd_record_call_history): Use command_size_to_target_size instead of cast. (validate_history_size, set_record_insn_history_size) (set_record_call_history_size): New functions. (_initialize_record): Install set_record_insn_history_size and set_record_call_history_size as "set" hooks of "set record instruction-history-size" and "set record function-call-history-size".
2013-03-26Use readline's 'history_max_entries' instead of the old 'max_input_history'.Pedro Alves2-7/+7
Ref: http://www.sourceware.org/ml/gdb-patches/2002-08/msg00486.html We've long since imported a newer readline, no need to use the old compatibility variable anymore. Tested on x86_64 Fedora 17. gdb/ 2013-03-26 Pedro Alves <palves@redhat.com> * top.c (gdb_rl_operate_and_get_next): Replace max_input_history use with history_max_entries use. Remove FIXME note.
2013-03-26gdb/testsuite/Yao Qi5-0/+73
* gdb.trace/actions.c, gdb.trace/circ.c: Add license header. * gdb.trace/collection.c, gdb.trace/tfile.c: Likewise.
2013-03-26record-btrace: fix assertion when enabling recording after re-runMarkus Metzger4-0/+24
Reading symbols from /bin/true...(no debugging symbols found)...done. (gdb) b _start Function "_start" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (_start) pending. (gdb) r Starting program: /bin/true Breakpoint 1, 0x00000039a0400af0 in _start () from /lib64/ld-linux-x86-64.so.2 (gdb) rec b (gdb) r The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /bin/true Breakpoint 1, 0x00000039a0400af0 in _start () from /lib64/ld-linux-x86-64.so.2 (gdb) rec b gdb/record-btrace.c:154: internal-error: record_btrace_open: Assertion `record_btrace_thread_observer == NULL' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) gdb/ * record-btrace.c (record_btrace_close): Call record_btrace_auto_disable. testsuite/ * gdb.btrace/enable.exp: Add regression test.
2013-03-26Delete rs6000-nat.c:fixup_breakpoints extern declaration.Joel Brobecker2-2/+4
This function does not exist... gdb/ChangeLog: * rs6000-nat.c (fixup_breakpoints): Delete declaration.
2013-03-26*** empty log message ***gdbadmin1-1/+1
2013-03-25 * contrib/cc-with-tweaks.sh: Check exit code of dwp.Doug Evans2-0/+6
2013-03-25 PR symtab/11462:Tom Tromey4-0/+61
* c-exp.y (exp): Add new productions for destructors after '.' and '->'. (write_destructor_name): New function. gdb/testsuite * gdb.cp/m-static.exp: Add destructor-printing tests.
2013-03-25 PR c++/9197:Tom Tromey7-34/+48
* opencl-lang.c (evaluate_subexp_opencl) <STRUCTOP_STRUCT>: Use value_struct_elt, not lookup_struct_elt_type. * eval.c (evaluate_subexp_standard) <STRUCTOP_STRUCT, STRUCTOP_PTR>: Use value_struct_elt, not lookup_struct_elt_type. * expression.h (EVAL_AVOID_SIDE_EFFECTS): Update comment. gdb/testsuite * gdb.cp/m-static.exp: Add constructor ptype tests. * gdb.cp/m-static.cc (single_constructor): New class. (main): Make instance of single_constructor.