aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2013-10-25testsuite: Fix gdb.base/bang.exp for remote stubs without exitAnton Kolesov2-9/+7
Some remote stubs do not have a proper exit() function implementation. gdb.base/bang.exp was failing on those targets due to timeout. With this patch bang.exp uses already defined library procedures to handle this situation gracefully without breaking native targets. Tested with x86_64 (unix, native-gdbserver) and with arc-*-elf32. gdb/testsuite/ChangeLog: 2013-10-25 Anton Kolesov <Anton.Kolesov@synopsys.com> (tiny change) * gdb.base/bang.exp: Use gdb_continue_to_end to properly support remote stubs where exit() behaviour is unreliable.
2013-10-25Print nonexisting/optimized out static fields gracefully.Pedro Alves8-35/+53
With: struct static_struct { static int aaa; }; struct static_struct sss; int main () { return 0; } We get: (gdb) p sss $1 = {static aaa = <optimized out>} (gdb) p sss.aaa field aaa is nonexistent or has been optimized out Note that the "field aaa ..." message is an error being thrown. GDB is graceful everywhere else when printing optimized out values. IOW it usually prints an <optimized out> value and puts that in the value history. I see no reason for here to be different, more so that when the print the whole "containing" object (well, it's a static field, so it's not really a container), we already print <optimized out>. After the patch: (gdb) p sss $1 = {static aaa = <optimized out>} (gdb) p sss.aaa $2 = <optimized out> The value_entirely_optimized_out checks are there to preserve behavior. Without those, if the static field is a struct/union, GDB would go and print its fields one by one (and print <optimized out> for each). Tested on x86_64 Fedora 17. gdb/ 2013-10-25 Pedro Alves <palves@redhat.com> * cp-valprint.c (cp_print_value_fields): No longer handle a NULL static field value. (cp_print_static_field): If the value is entirely optimized out, print <optimized out> here. * jv-valprint.c (java_print_value_fields): No longer handle a NULL static field value. * p-valprint.c (pascal_object_print_static_field): If the value is entirely optimized out, print <optimized out> here. * valops.c (do_search_struct_field) (value_struct_elt_for_reference): No longer handle a NULL static field value. * value.c (value_static_field): Return an optimized out value instead of NULL. gdb/testsuite/ 2013-10-25 Pedro Alves <palves@redhat.com> * gdb.cp/m-static.exp: Adjust expected output of printing a nonexistent or optimized out static field. Also test printing the the "container" object.
2013-10-25Send qXfer:traceframe-info:read when traceframe is selected.Yao Qi2-0/+10
When I do 'si', I find many 'qXfer:traceframe-info:read' packets are sent, which is not necessary. It slows down the single step. (gdb) si Sending packet: $qTStatus#49...Packet received: T0;tnotrun:0;tframes:0;tcreated:0;tfree:500000;tsize:500000;circular:0;disconn:0;starttime:0;stoptime:0;username:;notes:: Sending packet: $Z0,80483c7,1#b4...Packet received: OK Sending packet: $Z0,4ce5b6b0,1#6e...Packet received: OK Sending packet: $QPassSignals:e;10;14;17;1a;1b;1c;21;24;25;2c;4c;#5f...Packet received: OK Sending packet: $vCont;s:p1b15.1b15;c#20...Packet received: T0505:44efffbf;04:44efffbf;08:d1830408;thread:p1b15.1b15;core:3; Sending packet: $qXfer:traceframe-info:read::0,fff#0b...Packet received: E01 Sending packet: $mbfffef40,40#c0...Packet received: d183040878efffbf2e840408030000000000a040030000000500000070efffbf07000000010000004984040807000000030000000500000000000000b396e84c Sending packet: $qXfer:traceframe-info:read::0,fff#0b...Packet received: E01 Sending packet: $qXfer:traceframe-info:read::0,fff#0b...Packet received: E01 Sending packet: $qXfer:traceframe-info:read::0,fff#0b...Packet received: E01 Sending packet: $z0,80483c7,1#d4...Packet received: OK Sending packet: $z0,4ce5b6b0,1#8e...Packet received: OK Sending packet: $qXfer:traceframe-info:read::0,fff#0b...Packet received: E01 Sending packet: $qXfer:traceframe-info:read::0,fff#0b...Packet received: E01 Sending packet: $qXfer:traceframe-info:read::0,fff#0b...Packet received: E01 Sending packet: $qXfer:traceframe-info:read::0,fff#0b...Packet received: E01 Sending packet: $qXfer:traceframe-info:read::0,fff#0b...Packet received: E01 Sending packet: $qXfer:traceframe-info:read::0,fff#0b...Packet received: E01 This problem was introduced by this patch (https://sourceware.org/ml/gdb-patches/2013-04/msg00000.html), in which get_traceframe_number is not checked before calling traceframe_available_memory. This patch moves the check to remote_traceframe_info, say, if GDB doesn't have traceframe selected, GDB doesn't need to send qXfer:traceframe-info:read packets. With this patch applied, there is no qXfer:traceframe-info:read sent out and single step is speed up a little bit. Here is the experiment I did: Num of single step Original Patched single-step cpu_time 10000 8.08 7.57 single-step cpu_time 20000 16.23 14.23 single-step cpu_time 30000 24.19 21.59 single-step cpu_time 40000 32.49 28.0 single-step wall_time 10000 14.1974210739 13.2641420364 single-step wall_time 20000 28.5278921127 25.0541369915 single-step wall_time 30000 42.5864038467 38.0038759708 single-step wall_time 40000 57.2107698917 49.2350611687 single-step vmsize 10000 16128 16388 single-step vmsize 20000 16128 16388 single-step vmsize 30000 16260 16520 single-step vmsize 40000 16444 16704 The patch is tested on x86_64-linux. gdb: 2013-10-24 Yao Qi <yao@codesourcery.com> * remote.c (remote_traceframe_info): Return early if traceframe is not selected.
2013-10-25Fix changelog.Yao Qi1-0/+6
gdb/ Add changelog entry for my previous commit.
2013-10-25Remove global traceframe_fun and traceframe_salYao Qi1-6/+2
I happen to see traceframe_fun and traceframe_sal are static variables, which are not necessary to me. They are only used in set_traceframe_context, and they are not stateful. This patch is to remove them. gdb: 2013-10-24 Yao Qi <yao@codesourcery.com> * tracepoint.c (traceframe_fun): Remove. (traceframe_sal): Remove. (set_traceframe_context): Add local variables.
2013-10-25Minor coding style fixes in varobj.hJoel Brobecker2-7/+12
No actual code change, just a minor style fix. gdb/ChangeLog: * varobj.h (struct lang_varobj_ops): Remove spaces between '*' and parameter name.
2013-10-25testsuite: Persistent gdbserver cleanupMaciej W. Rozycki3-0/+24
* lib/gdb.exp (gdb_finish): Send a kill request to `gdbserver' if in the persistent mode. * gdb.trace/disconnected-tracing.exp: Reconnect before completion.
2013-10-25Avoid producing broken non-native core filesMaciej W. Rozycki4-4/+15
gdb/ * linux-tdep.c (linux_corefile_thread_callback): Propagate any failure from register information collection. gdb/testsuite/ * lib/gdb.exp (gdb_gcore_cmd): Also handle a "Target does not support core file generation" reply.
2013-10-25Fix ChangeLog typoMaciej W. Rozycki1-1/+1
2013-10-25linux-tdep.c: Remove unused `num_notes' struct memberMaciej W. Rozycki2-4/+7
* linux-tdep.c (linux_corefile_thread_data): Remove `num_notes' member. (linux_corefile_thread_callback): Update accordingly. (linux_make_corefile_notes): Likewise.
2013-10-25Make STARTUP_WITH_SHELL a runtime toggle -- add new "set/show ↵Pedro Alves11-37/+118
startup-with-shell" option. Occasionaly we hear about people having problems with GDB not being able to start programs (with "run"/"start"). GDB spawns a shell to start the program, and most often, it'll be the case that the problem is actually with the user's shell setup. GDB has code to disable the use of the shell to start programs. That's the STARTUP_WITH_SHELL macro that native targets could set to 0 in their nm.h file (though no target actually uses it nowadays). This patch makes that setting a run-time knob instead. This will be useful to quickly diagnose such shell issues, and might also come in handy at other times (such as when debugging the shell itself, if you don't have a different shell handy). gdb/ 2013-10-24 Pedro Alves <palves@redhat.com> * NEWS (New options): Mention set/show startup-with-shell. * config/alpha/nm-osf3.h (START_INFERIOR_TRAPS_EXPECTED): Set to 2 instead of 3. * fork-child.c (fork_inferior, startup_inferior): Handle 'set startup-with-shell'. (show_startup_with_shell): New function. (_initialize_fork_child): Register the set/show startup-with-shell commands. * inf-ptrace.c (inf_ptrace_create_inferior): Remove comment. * inf-ttrace.c (inf_ttrace_him): Remove comment. * procfs.c (procfs_init_inferior): Remove comment. * infcmd.c (startup_with_shell): New global. * inferior.h (startup_with_shell): Declare global. (STARTUP_WITH_SHELL): Delete. (START_INFERIOR_TRAPS_EXPECTED): Set to 1 by default instead of 2. gdb/doc/ 2013-10-24 Pedro Alves <palves@redhat.com> * gdb.texinfo (Starting): Document set/show startup-with-shell.
2013-10-25infrun debug output: print enum gdb_signal symbol names instead of POSIX ↵Pedro Alves5-9/+40
signal names. The other day while debugging something related to random signals, I got confused with "set debug infrun 1" output, for it said: infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x323d4e8b94 infrun: random signal 20 On GNU/Linux, 20 is SIGTSTP. For some reason, it took me a few minutes to realize that 20 is actually a GDB signal number, not a target signal number (duh!). In any case, I propose making GDB's output clearer here: One way would be to use gdb_signal_to_name, like already used elsewhere: infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x323d4e8b94 infrun: random signal SIGCHLD (20) but I think that might confuse someone too ("20? Why does GDB believe SIGCHLD is 20?"). So I thought of printing the enum string instead: infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x323d4e8b94 infrun: random signal GDB_SIGNAL_CHLD (20) Looking at a more complete infrun debug log, we had actually printed the (POSIX) signal name name a bit before: infrun: target_wait (-1, status) = infrun: 9300 [Thread 0x7ffff7fcb740 (LWP 9300)], infrun: status->kind = stopped, signal = SIGCHLD ... infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x323d4e8b94 infrun: random signal 20 So I'm now thinking that it'd be even better to make infrun output consistently use the enum symbol string, like so: infrun: clear_proceed_status_thread (Thread 0x7ffff7fca700 (LWP 25663)) infrun: clear_proceed_status_thread (Thread 0x7ffff7fcb740 (LWP 25659)) - infrun: proceed (addr=0xffffffffffffffff, signal=144, step=1) + infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT, step=1) - infrun: resume (step=1, signal=0), trap_expected=0, current thread [Thread 0x7ffff7fcb740 (LWP 25659)] at 0x400700 + infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0x7ffff7fcb740 (LWP 25659)] at 0x400700 infrun: wait_for_inferior () infrun: target_wait (-1, status) = infrun: 25659 [Thread 0x7ffff7fcb740 (LWP 25659)], - infrun: status->kind = stopped, signal = SIGCHLD + infrun: status->kind = stopped, signal = GDB_SIGNAL_CHLD infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x400700 - infrun: random signal 20 + infrun: random signal (GDB_SIGNAL_CHLD) infrun: random signal, keep going - infrun: resume (step=1, signal=20), trap_expected=0, current thread [Thread 0x7ffff7fcb740 (LWP 25659)] at 0x400700 + infrun: resume (step=1, signal=GDB_SIGNAL_CHLD), trap_expected=0, current thread [Thread 0x7ffff7fcb740 (LWP 25659)] at 0x400700 infrun: prepare_to_wait infrun: target_wait (-1, status) = infrun: 25659 [Thread 0x7ffff7fcb740 (LWP 25659)], - infrun: status->kind = stopped, signal = SIGTRAP + infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x400704 infrun: stepi/nexti infrun: stop_stepping GDB's signal numbers are public and hardcoded (see include/gdb/signals.h), so there's really no need to clutter the output with numeric values in some places while others not. Replacing the magic "144" with GDB_SIGNAL_DEFAULT in "proceed"'s debug output (see above) I think is quite nice. I posit that all this makes it clearer to newcomers that GDB has its own signal numbering (and that there must be some mapping going on). Tested on x86_64 Fedora 17. gdb/ 2013-10-23 Pedro Alves <palves@redhat.com> * common/gdb_signals.h (gdb_signal_to_symbol_string): Declare. * common/signals.c: Include "gdb_assert.h". (signals): New field 'symbol'. (SET): Use the 'symbol' parameter. (gdb_signal_to_symbol_string): New function. * infrun.c (handle_inferior_event) <random signal>: In debug output, print the random signal enum as string in addition to its number. * target/waitstatus.c (target_waitstatus_to_string): Print the signal's enum value as string instead of the (POSIX) signal name.
2013-10-25Fix off-by-one errors in *scanf format strings.Gary Benson2-25/+54
In the first hunk, the format string was off-by-one for cmd, and cmd itself was larger than the maximum size required. cmd was reduced in size and the format string adjusted. In the second hunk, the format string was off-by-one for local_address, remote_address and extra, although the buffers for the two addresses were large enough for this not to matter. The specifiers for the two addresses was corrected, and a number of unused variables including extra were suppressed from parsing. In the third hunk, the format string was off-by-one for name, dependencies and status. This code was rewritten using strtok since dependencies can be arbitrarily long. gdb/ 2013-10-23 Gary Benson <gbenson@redhat.com> PR 16013 * common/linux-osdata.c (command_from_pid): Reduced size of cmd from 32 to 18. Adjusted fscanf format string accordingly. (Avoids leaving cmd unterminated.) (print_sockets): Do not parse tlen, inode, sl, timeout, txq, rxq, trun, retn or extra. (Avoids leaving extra unterminated.) Check that local_address and remote_address will not overflow. (linux_xfer_osdata_modules): Parse lines using strtok to avoid leaving dependencies unterminated. Parse size as "%u" to match definition.
2013-10-25Remove dead sets/clears of ecs->random signal.Pedro Alves2-9/+5
'*ecs' is always memset by handle_inferior_event's callers, so all these clears are unnecessary. There's one place that sets the flag to true, but, afterwards, before ecs->random_signal is ever read, we reach the part of handle_inferior_even that clears ecs->random_signal, among other things: clear_stop_func (ecs); ecs->event_thread->stepping_over_breakpoint = 0; bpstat_clear (&ecs->event_thread->control.stop_bpstat); ecs->event_thread->control.stop_step = 0; stop_print_frame = 1; ecs->random_signal = 0; stopped_by_random_signal = 0; So all these ecs->random_signal accesses are dead code. Tested on x86_64 Fedora 17. gdb/ 2013-10-22 Pedro Alves <palves@redhat.com> * infrun.c (handle_inferior_event) <thread hop>: Don't clear or set ecs->random signal.
2013-10-25Add missing ChangeLog entries for previous commits.Pedro Alves1-0/+23
2013-10-25infrun.c:keep_going: update comments.Pedro Alves1-35/+31
This function still has comments referring back to when it was a goto label in wait_for_inferior, eons ago. Looking closer, actually most of its comments could use a facelift (contents/formatting/typos). That's what this patch does. gdb/ 2013-10-22 Pedro Alves <palves@redhat.com> * infrun.c (keep_going): Update comments.
2013-10-25remote: Map invalid signal numbers to GDB_SIGNAL_UNKNOWN.Pedro Alves1-4/+14
I realized that remote.c is not validating input here. Currently, if a remote stub sends in an invalid signal number (or put another way, if a future stub sends a new signal an old GDB doesn't know about), GDB will do out of bounds accesses in the signal_pass/signal_stop/signal_program arrays. It'll probably be a long while before we add another signal number (and buggy stubs should just be fixed), but can't hurt to be defensive. Tested on x86_64 Fedora 17, native gdbserver. gdb/ 2013-10-22 Pedro Alves <palves@redhat.com> * remote.c (remote_parse_stop_reply) <'T'/'S'/'X' replies>: Map invalid signal numbers to GDB_SIGNAL_UNKNOWN.
2013-10-25Fix up a couple oddities in GDB's signal names and strings.Pedro Alves2-18/+18
- The Mach exception/signals escaped the TARGET_ -> GDB_ prefix change done a while ago, but there's no real reason for that. I grepped for TARGET_EXC and fixed all found, which unsurprisingly, means darwin-nat.c needed fixing. I think the change there is as obvious and trivial as it can get, so I'd be quite surprised if this broke anything there somehow. - GDB_SIGNAL_LAST's description string was unnecessarily inconsistent with the enum name. Built on x86_64 Fedora 17. gdb/ 2013-10-22 Pedro Alves <palves@redhat.com> * include/gdb/signals.def (TARGET_EXC_BAD_ACCESS): Rename to GDB_EXC_BAD_ACCESS. (TARGET_EXC_BAD_INSTRUCTION): Rename to GDB_EXC_BAD_INSTRUCTION. (TARGET_EXC_ARITHMETIC): Rename to GDB_EXC_ARITHMETIC. (TARGET_EXC_EMULATION): Rename to GDB_EXC_EMULATION. (TARGET_EXC_SOFTWARE): Rename to GDB_EXC_SOFTWARE. (TARGET_EXC_BREAKPOINT): Rename to GDB_EXC_BREAKPOINT. (GDB_SIGNAL_LAST): Change description string. * common/signals.c (gdb_signal_from_host, do_gdb_signal_to_host): Adjust to signal renaming. * darwin-nat.c (darwin_decode_message): Likewise.
2013-10-252013-10-22 Jose E. Marchesi <jose.marchesi@oracle.com>Jose E. Marchesi2-0/+5
* MAINTAINERS (Write After Approval): Add myself to the list.
2013-10-25fix ARI for git migrationTom Tromey1-0/+5
This fixes the ARI script for the git migration. * contrib/ari/create-web-ari-in-src.sh: Update for git.
2013-10-25fix CONTRIBUTE for git migrationTom Tromey1-7/+7
This fixes gdb's CONTRIBUTE file for the git migration. * CONTRIBUTE: Update for git.
2013-10-212013-10-21 Jose E. Marchesi <jose.marchesi@oracle.com>Jose E. Marchesi3-3/+16
PR gdb/15986 * gdb.base/run.c (main): gdb_get_line_number tag added for commands.exp. (factorial): Likewise. * gdb.base/commands.exp (watchpoint_command_test): Use gdb_get_line_number in order to determine the locations in run.c where local_var is detected to go out of scope.
2013-10-212013-10-21 Jose E. Marchesi <jose.marchesi@oracle.com>Jose E. Marchesi2-1/+19
* gdb.base/gnu_vector.exp: Care about endianness when casting scalars to vectors.
2013-10-18 * lib/gdb.exp (build_executable_from_specs): Remove duplicate setTom Tromey2-2/+5
of "binfile".
2013-10-18Hardware watchpoints turned off, inferior not yet started.Andrew Burgess4-9/+55
https://sourceware.org/ml/gdb-patches/2013-10/msg00477.html gdb/ChangeLog * breakpoint.c (update_watchpoint): If hardware watchpoints are forced off, downgrade them to software watchpoints if possible, and error out if not possible. (watch_command_1): Move watchpoint type selection closer to watchpoint creation, and extend the comments. gdb/testsuite/ChangeLog * gdb.base/watchpoints.exp: Add test for setting software watchpoints of different types before starting the inferior.
2013-10-18[gdb/16062] stepi sometimes doesn't make progressPedro Alves5-0/+176
I noticed something odd while doing "stepi" over a fork syscall: ... (gdb) set disassemble-next-line on ... (gdb) si 0x000000323d4ba7c2 131 pid = ARCH_FORK (); 0x000000323d4ba7a4 <__libc_fork+132>: 64 4c 8b 04 25 10 00 00 00 mov %fs:0x10,%r8 0x000000323d4ba7ad <__libc_fork+141>: 31 d2 xor %edx,%edx 0x000000323d4ba7af <__libc_fork+143>: 4d 8d 90 d0 02 00 00 lea 0x2d0(%r8),%r10 0x000000323d4ba7b6 <__libc_fork+150>: 31 f6 xor %esi,%esi 0x000000323d4ba7b8 <__libc_fork+152>: bf 11 00 20 01 mov $0x1200011,%edi 0x000000323d4ba7bd <__libc_fork+157>: b8 38 00 00 00 mov $0x38,%eax => 0x000000323d4ba7c2 <__libc_fork+162>: 0f 05 syscall 0x000000323d4ba7c4 <__libc_fork+164>: 48 3d 00 f0 ff ff cmp $0xfffffffffffff000,%rax 0x000000323d4ba7ca <__libc_fork+170>: 0f 87 2b 01 00 00 ja 0x323d4ba8fb <__libc_fork+475> (gdb) si 0x000000323d4ba7c4 131 pid = ARCH_FORK (); 0x000000323d4ba7a4 <__libc_fork+132>: 64 4c 8b 04 25 10 00 00 00 mov %fs:0x10,%r8 0x000000323d4ba7ad <__libc_fork+141>: 31 d2 xor %edx,%edx 0x000000323d4ba7af <__libc_fork+143>: 4d 8d 90 d0 02 00 00 lea 0x2d0(%r8),%r10 0x000000323d4ba7b6 <__libc_fork+150>: 31 f6 xor %esi,%esi 0x000000323d4ba7b8 <__libc_fork+152>: bf 11 00 20 01 mov $0x1200011,%edi 0x000000323d4ba7bd <__libc_fork+157>: b8 38 00 00 00 mov $0x38,%eax 0x000000323d4ba7c2 <__libc_fork+162>: 0f 05 syscall => 0x000000323d4ba7c4 <__libc_fork+164>: 48 3d 00 f0 ff ff cmp $0xfffffffffffff000,%rax 0x000000323d4ba7ca <__libc_fork+170>: 0f 87 2b 01 00 00 ja 0x323d4ba8fb <__libc_fork+475> (gdb) si 0x000000323d4ba7c4 131 pid = ARCH_FORK (); 0x000000323d4ba7a4 <__libc_fork+132>: 64 4c 8b 04 25 10 00 00 00 mov %fs:0x10,%r8 0x000000323d4ba7ad <__libc_fork+141>: 31 d2 xor %edx,%edx 0x000000323d4ba7af <__libc_fork+143>: 4d 8d 90 d0 02 00 00 lea 0x2d0(%r8),%r10 0x000000323d4ba7b6 <__libc_fork+150>: 31 f6 xor %esi,%esi 0x000000323d4ba7b8 <__libc_fork+152>: bf 11 00 20 01 mov $0x1200011,%edi 0x000000323d4ba7bd <__libc_fork+157>: b8 38 00 00 00 mov $0x38,%eax 0x000000323d4ba7c2 <__libc_fork+162>: 0f 05 syscall => 0x000000323d4ba7c4 <__libc_fork+164>: 48 3d 00 f0 ff ff cmp $0xfffffffffffff000,%rax 0x000000323d4ba7ca <__libc_fork+170>: 0f 87 2b 01 00 00 ja 0x323d4ba8fb <__libc_fork+475> (gdb) si 0x000000323d4ba7ca 131 pid = ARCH_FORK (); 0x000000323d4ba7a4 <__libc_fork+132>: 64 4c 8b 04 25 10 00 00 00 mov %fs:0x10,%r8 0x000000323d4ba7ad <__libc_fork+141>: 31 d2 xor %edx,%edx 0x000000323d4ba7af <__libc_fork+143>: 4d 8d 90 d0 02 00 00 lea 0x2d0(%r8),%r10 0x000000323d4ba7b6 <__libc_fork+150>: 31 f6 xor %esi,%esi 0x000000323d4ba7b8 <__libc_fork+152>: bf 11 00 20 01 mov $0x1200011,%edi 0x000000323d4ba7bd <__libc_fork+157>: b8 38 00 00 00 mov $0x38,%eax 0x000000323d4ba7c2 <__libc_fork+162>: 0f 05 syscall 0x000000323d4ba7c4 <__libc_fork+164>: 48 3d 00 f0 ff ff cmp $0xfffffffffffff000,%rax => 0x000000323d4ba7ca <__libc_fork+170>: 0f 87 2b 01 00 00 ja 0x323d4ba8fb <__libc_fork+475> Notice how the third "si" didn't actually make progress. Turning on infrun and lin-lwp debug, we see: (gdb) infrun: clear_proceed_status_thread (process 5252) infrun: proceed (addr=0xffffffffffffffff, signal=144, step=1) infrun: resume (step=1, signal=0), trap_expected=0, current thread [process 5252] at 0x323d4ba7c4 LLR: Preparing to step process 5252, 0, inferior_ptid process 5252 RC: Not resuming sibling process 5252 (not stopped) LLR: PTRACE_SINGLESTEP process 5252, 0 (resume event thread) sigchld infrun: wait_for_inferior () linux_nat_wait: [process -1], [] LLW: enter LNW: waitpid(-1, ...) returned 5252, No child processes LLW: waitpid 5252 received Child exited (stopped) LLW: Candidate event Child exited (stopped) in process 5252. SEL: Select single-step process 5252 LLW: exit infrun: target_wait (-1, status) = infrun: 5252 [process 5252], infrun: status->kind = stopped, signal = SIGCHLD infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x323d4ba7c4 infrun: random signal 20 infrun: stepi/nexti infrun: stop_stepping So the inferior got a SIGCHLD (because the fork child exited while we're doing 'si'), and since that signal is set to "nostop noprint pass" (by default), it's considered a random signal, so it should not cause a stop. But, it resulted in an immediate a stop_stepping call anyway. So the single-step never really finished. This is a regression caused by: [[PATCH] Do not respawn signals, take 2.] https://sourceware.org/ml/gdb-patches/2012-06/msg00702.html Specifically, caused by this change (as mentioned in the "the lost step issue first" part of that mail): diff --git a/gdb/infrun.c b/gdb/infrun.c index 53db335..3e8dbc8 100644 --- a/gdb/infrun.c +++ b/gdb/infrun.c @@ -4363,10 +4363,8 @@ process_event_stop_test: (leaving the inferior at the step-resume-breakpoint without actually executing it). Either way continue until the breakpoint is really hit. */ - keep_going (ecs); - return; } - + else /* Handle cases caused by hitting a breakpoint. */ { That made GDB fall through to the > /* In all-stop mode, if we're currently stepping but have stopped in > some other thread, we need to switch back to the stepped thread. */ > if (!non_stop) part. However, if we don't have a stepped thread to get back to, we'll now also fall through to all the "stepping" tests. For line stepping, that'll turn out okay, as we'll just end up realizing the thread is still in the stepping range, and needs to be re-stepped. However, for stepi/nexti, we'll reach: if (ecs->event_thread->control.step_range_end == 1) { /* It is stepi or nexti. We always want to stop stepping after one instruction. */ if (debug_infrun) fprintf_unfiltered (gdb_stdlog, "infrun: stepi/nexti\n"); ecs->event_thread->control.stop_step = 1; print_end_stepping_range_reason (); stop_stepping (ecs); return; } and stop, even though the thread actually made no progress. The fix is to restore the keep_going call, but put it after the "switch back to the stepped thread" code, and before the stepping tests. Tested on x86_64 Fedora 17, native and gdbserver. New test included. gdb/ 2013-10-18 Pedro Alves <palves@redhat.com> PR gdb/16062 * infrun.c (handle_inferior_event): Keep going if we got a random signal we should not stop for, instead of falling through to the step tests. gdb/testsuite/ 2013-10-18 Pedro Alves <palves@redhat.com> PR gdb/16062 * gdb.threads/stepi-random-signal.c: New file. * gdb.threads/stepi-random-signal.exp: New file.
2013-10-18gdb/Yao Qi2-2/+6
* c-varobj.c (cplus_number_of_children): Fix indentation.
2013-10-17 * gdb.mi/mi-breakpoint-changed.exp (test_insert_delete_modify):Maciej W. Rozycki3-2/+8
Fix comment typo. * lib/gdb.exp (gdb_init): Likewise.
2013-10-17fix for PR gdb/15995Tom Tromey4-0/+16
This patch fixes PR gdb/15995. The bug here is that gdb's printf command does not flush the output stream. This makes a printf that is not newline-terminated interleave incorrectly with other forms of output, such as that generated via a call to an external program using "shell". I note that the "output" command already does this flushing. The fix is to call gdb_flush in printf_command. Built and regtested on x86-64 Fedora 18. New test case included. PR gdb/15995: * printcmd.c (printcmd): Call gdb_flush. * gdb.base/printcmds.exp (test_printf): Test printf flushing.
2013-10-17remove unused field from struct elfinfoTom Tromey2-5/+5
I noticed that one field in elfread.c:struct elfinfo is unused. This patch removes it. * elfread.c (struct elfinfo) <stabindexsect>: Remove. (elf_locate_sections): Update.
2013-10-17Remove ada-varobj.h.Yao Qi4-63/+22
As a result of previous patch, extern functions in ada-varobj.c can be made static, and ada-varobj.h can be removed too. gdb: 2013-10-17 Yao Qi <yao@codesourcery.com> * Makefile.in (HFILES_NO_SRCDIR): Remove ada-varobj.h. * ada-varobj.c: Remove the include of ada-varobj.h. (ada_varobj_get_number_of_children): Declare. (ada_varobj_get_name_of_child): Make it static. (ada_varobj_get_path_expr_of_child): Likewise. (ada_varobj_get_value_of_child): Likewise. (ada_varobj_get_type_of_child): Likewise. (ada_varobj_get_value_of_array_variable): Likewise. * ada-varobj.h: Remove.
2013-10-17gdb/Yao Qi9-1288/+1383
* Makefile.in (SFILES): Add c-varobj.c and jv-varobj.c. (COMMON_OBS): Add c-varobj.o and jv-varobj.o. * ada-varobj.c: Include "varobj.h". (ada_number_of_children): New. Moved from varobj.c. (ada_name_of_variable, ada_name_of_child): Likewise. (ada_path_expr_of_child, ada_value_of_child): Likewise. (ada_type_of_child, ada_value_of_variable): Likewise. (ada_value_is_changeable_p, ada_value_has_mutated): Likewise. (ada_varobj_ops): New. * c-varobj.c, jv-varobj.c: New file. Moved from varobj.c. * gdbtypes.c (get_target_type): New. Moved from varobj.c. * gdbtypes.h (get_target_type): Declare. * varobj.c: Remove the inclusion of "ada-varobj.h" and "ada-lang.h". (ANONYMOUS_STRUCT_NAME): Move it to c-varobj.c. (ANONYMOUS_UNION_NAME): Likewise. (get_type, get_value_type, get_target_type): Remove declarations. (value_get_print_value, varobj_value_get_print_value): Likewise. (c_number_of_children, c_name_of_variable): Likewise. (c_name_of_child, c_path_expr_of_child): Likewise. (c_value_of_child, c_type_of_child): Likewise. (c_value_of_variable, cplus_number_of_children): Likewise. (cplus_class_num_children, cplus_name_of_variable): Likewise. (cplus_name_of_child, cplus_path_expr_of_child): Likewise. (cplus_value_of_child, cplus_type_of_child): Likewise. (cplus_value_of_variable, java_number_of_children): Likewise. (java_name_of_variable, java_name_of_child): Likewise. (java_path_expr_of_child, java_value_of_child): Likewise. (java_type_of_child, java_value_of_variable): Likewise. (ada_number_of_children, ada_name_of_variable): Likewise. (ada_name_of_child, ada_path_expr_of_child): Likewise. (ada_value_of_child, ada_type_of_child): Likewise. (ada_value_of_variable, ada_value_is_changeable_p): Likewise. (ada_value_has_mutated): Likewise. (struct language_specific): Move it to varobj.h. (CPLUS_FAKE_CHILD): Move it to varobj.h. (restrict_range): Rename it varobj_restrict_range. Make it extern. Callers update. (get_path_expr_parent): Rename it to varobj_get_path_expr_parent. Make it extern. (is_anonymous_child): Move it to c-varobj.c and rename to varobj_is_anonymous_child. Caller update. (get_type): Move it to c-varobj.c. (get_value_type): Rename it varobj_get_value_type. Make it extern. (get_target_type): Move it gdbtypes.c. (varobj_formatted_print_options): New function. (value_get_print_value): Rename it to varobj_value_get_print_value and make it extern. (varobj_value_is_changeable_p): Make it extern. (adjust_value_for_child_access): Move it to c-varobj.c. (default_value_is_changeable_p): Rename it to varobj_default_value_is_changeable_p. Make it extern. (c_number_of_children, c_name_of_variable): Move it to c-varobj.c (c_name_of_child, c_path_expr_of_child): Likewise. (c_value_of_child, c_type_of_child): Likewise. (c_value_of_variable, cplus_number_of_children): Likewise. (cplus_class_num_children, cplus_name_of_variable): Likewise. (cplus_name_of_child, cplus_path_expr_of_child): Likewise. (cplus_value_of_child, cplus_type_of_child): Likewise. (cplus_value_of_variable): Likewise. (java_number_of_children, java_name_of_variable): Move it to jv-varobj.c. (java_name_of_child, java_path_expr_of_child): Likewise. (java_value_of_child, java_type_of_child): Likewise. (java_value_of_variable): Likewise. (ada_number_of_children, ada_name_of_variable): Move it to ada-varobj.c. (ada_name_of_child, ada_path_expr_of_child): Likewise. (ada_value_of_child, ada_type_of_child): Likewise. (ada_value_of_variable, ada_value_is_changeable_p): Likewise. (ada_value_has_mutated): Likewise. * varobj.h (CPLUS_FAKE_CHILD): New macro, moved from varobj.c. (struct lang_varobj_ops): New. Renamed by 'struct language_specific'. (c_varobj_ops, cplus_varobj_ops): Declare. (java_varobj_ops, ada_varobj_ops): Declare. (varobj_default_value_is_changeable_p): Declare. (varobj_value_is_changeable_p): Declare. (varobj_get_value_type, varobj_is_anonymous_child): Declare. (varobj_get_path_expr_parent): Declare. (varobj_value_get_print_value): Declare. (varobj_formatted_print_options): Declare. (varobj_restrict_range): Declare.
2013-10-17 * target/waitstatus.h (target_waitkind): Remove spuriousLuis Machado2-1/+6
character from the comments.
2013-10-17Document the get_longjmp_target gdbarch method.Joel Brobecker3-2/+15
gdb/ChangeLog: * gdbarch.sh (get_longjmp_target): Add method documentation. * gdbarch.h: Regenerate.
2013-10-16 * dbxread.c (read_dbx_symtab) <bss_ext_symbol>: Remove unusedTom Tromey2-1/+5
label.
2013-10-16 * gcore.in: Call GDB using the full path to the gcore script.Luis Machado2-1/+40
Error out if the GDB binary is not found.
2013-10-16There were two functions who were calling "sizeof" twice.Sergio Durigan Junior4-2/+14
The first one, dw2_get_real_path from gdb/dwarf2read.c, was actually making use of OBSTACK_CALLOC which already calls "sizeof" for its third argument. The second, download_tracepoint_1 from gdb/gdbserver/tracepoint.c, was explicitly calling "sizeof" inside another "sizeof". This patch fixed both functions. gdb/ChangeLog 2013-10-16 Sergio Durigan Junior <sergiodj@redhat.com> PR gdb/16014 * dwarf2read.c (dw2_get_real_path): Remove unnecessary call to sizeof. gdb/gdbserver/ChangeLog 2013-10-16 Sergio Durigan Junior <sergiodj@redhat.com> PR gdb/16014 * tracepoint.c (download_tracepoint_1): Remove unnecessary double call to sizeof.
2013-10-16This is a simple bug. target_disable_btrace and target_teardown_btrace,Sergio Durigan Junior2-2/+15
both from gdb/target.c, do a "return" calling another function. But both are marked as void. Despite the fact that the functions being called are void as well, this is wrong. This patch fixes this by calling the functions and then returning in the next line. 2013-10-16 Sergio Durigan Junior <sergiodj@redhat.com> PR gdb/16042 * target.c (target_disable_btrace): Fix invalid return value for void function. (target_teardown_btrace): Likewise.
2013-10-14 * gdb.dwarf2/dwzbuildid.exp (write_dwarf_file): Pass explicit testTom Tromey2-1/+7
name to gdb_test_no_output.
2013-10-14gdb/Yao Qi3-117/+153
* varobj.c (struct varobj): Move most of the fields to varobj.h. (struct varobj_dynamic): New struct. (varobj_get_display_hint) [HAVE_PYTHON]: Adjust. (varobj_has_more): Likewise. (dynamic_varobj_has_child_method): Likewise. (update_dynamic_varobj_children): Likewise. (varobj_get_num_children): Likewise. (varobj_list_children, varobj_pretty_printed_p): Likewise. (install_new_value_visualizer): Likewise. (install_new_value_visualizer, install_new_value): Likewise. (varobj_update, new_variable, free_variable): Likewise. (my_value_of_variable, value_get_print_value): Likewise. (install_visualizer): Change the type of parameter 'var' to 'struct varobjd_dynamic *'. Callers update. * varobj.h (struct varobj): Moved from varobj.c. (struct varobj) <dynamic>: New field.
2013-10-142013-10-13 Sandra Loosemore <sandra@codesourcery.com>Sandra Loosemore7-6/+16
gdb/ * nios2-tdep.c (nios2_reg_names): Use "sstatus" rather than "ba" as the preferred name of r30. * nios2-linux-tdep.c (reg_offsets): Likewise. * features/nios2-cpu.xml: Likewise. * features/nios2-linux.c: Regenerated. * features/nios2.c: Regenerated. * regformats/nios2-linux.dat: Regenerated.
2013-10-13Improve Executable displayed path (PR 15415 regression kind #2)Jan Kratochvil6-1/+71
gdb/ 2013-10-13 Jan Kratochvil <jan.kratochvil@redhat.com> Canonicalize directories for EXEC_FILENAME. * exec.c (exec_file_attach): Use gdb_realpath_keepfile for exec_filename. * utils.c (gdb_realpath_keepfile): New function. * utils.h (gdb_realpath_keepfile): New declaration. gdb/testsuite/ 2013-10-13 Jan Kratochvil <jan.kratochvil@redhat.com> Canonicalize directories for EXEC_FILENAME. * gdb.base/argv0-symlink.exp (kept file symbolic link name for info inferiors): New. (kept directory symbolic link name): Setup kfail. (kept directory symbolic link name for info inferiors): New.
2013-10-11testsuite/ChangeLog:Ulrich Weigand3-0/+478
2013-10-11 Andreas Arnez <arnez@linux.vnet.ibm.com> * gdb.arch/s390-multiarch.exp: New file. * gdb.arch/s390-multiarch.c: New file.
2013-10-11 * Makefile.in (GDBFLAGS): New variable.Doug Evans2-0/+12
(run): New rule.
2013-10-11ChangeLog entries for the previous commit.Joel Brobecker2-0/+14
git-related mistake (added the files to the index, but forgot to commit --amend them before pushing the commit)
2013-10-11Document the -catch-assert and -catch-exception new GDB/MI commands.Joel Brobecker2-0/+102
This patch adds documentation for the new GDB/MI commands "-catch-assert" and "-catch-exception", meant to provide the same functionality as the "catch assert", "catch exception" and "catch exception unhandled" CLI commands. In the GDB Manual, there was already a section for catchpoint comments, so that seemed like a natural place to document the new commands. But commands related to a given concept seem to have traditionally been organized alphabetically, and I didn't want future commands to break down logical pairing of various commands. For instance, "-catch-load" and "-catch-unload" are quite "distant" from each other, and it is easy to imagine a new comment which would alphabetically fall in between, causing them to be separated. So I introduced subsections to prevent that from happening. gdb/ChangeLog: * NEWS: Add entry documenting the new "-catch-assert" and "-catch-exception" GDB/MI commands. gdb/doc/ChangeLog: * gdb.texinfo (Shared Library GDB/MI Catchpoint Commands): New subsection inside which the "-catch-load" and "-catch-unload" commands documentation is now placed. (Ada Exception GDB/MI Catchpoint Commands): New subsection documenting the "-catch-assert" and "-catch-exception" new GDB/MI commands.
2013-10-11Adjust gdb.ada/mi_catch_ex.exp to use GDB/MI catch commands...Joel Brobecker2-4/+18
... in place of the CLI "catch ..." commands. The latter were used because the GDB/MI equivalents were not available at the time. gdb/testsuite/ChangeLog: * gdb.ada/mi_catch_ex.exp: Adjusts all "catch ..." tests to use the appropriate GDB/MI command instead, and verify the test output.
2013-10-11New GDB/MI commands to catch Ada exceptionsJoel Brobecker8-15/+186
This patch introduces two new GDB/MI commands implementing the equivalent of the "catch exception" and "catch assert" GDB/CLI commands. gdb/ChangeLog: * breakpoint.h (init_ada_exception_breakpoint): Add parameter "enabled". * breakpoint.c (init_ada_exception_breakpoint): Add parameter "enabled". Set B->ENABLE_STATE accordingly. * ada-lang.h (ada_exception_catchpoint_kind): Move here from ada-lang.c. (create_ada_exception_catchpoint): Add declaration. * ada-lang.c (ada_exception_catchpoint_kind): Move to ada-lang.h. (create_ada_exception_catchpoint): Make non-static. Add new parameter "disabled". Use it in call to init_ada_exception_breakpoint. (catch_ada_exception_command): Add parameter "enabled" in call to create_ada_exception_catchpoint. (catch_assert_command): Likewise. * mi/mi-cmds.h (mi_cmd_catch_assert, mi_cmd_catch_exception): Add declarations. * mi/mi-cmds.c (mi_cmds): Add the "catch-assert" and "catch-exception" commands. * mi/mi-cmd-catch.c: Add #include "ada-lang.h". (mi_cmd_catch_assert, mi_cmd_catch_exception): New functions.
2013-10-11Add "ada_" prefix to enum ada_exception_catchpoint_kindJoel Brobecker2-70/+77
This is in preparation for making that type public, in order to be able to use make create_ada_exception_catchpoint public as well, making it usable from the GDB/MI implementation. gdb/ChangeLog: * ada-lang.c (enum ada_exception_catchpoint_kind): Renames "enum exception_catchpoint_kind". Replace the "ex_" prefix of all its enumerates with "ada_". Update the rest of this file throughout.
2013-10-11Rework a bit Ada exception catchpoint support (in prep for GDB/MI)Joel Brobecker2-50/+48
This patch reworks a bit how the different steps required to insert an Ada exception catchpoints are organized. They used to be: 1. Call a "decode" function which does: 1.a. Parse the command and its arguments 1.b. Create a SAL & OPS from some of those arguments 2. Call create_ada_exception_catchpoint using SAL as well as some of the arguments extracted above. The bulk of the change consists in integrating step (1.b) into step (2) in order to turn create_ada_exception_catchpoint into a function whose arguments are all user-level concepts. This paves the way from a straightforward implementation of the equivalent commands in the GDB/MI interpreter. gdb/ChangeLog: * ada-lang.c (ada_decode_exception_location): Delete. (create_ada_exception_catchpoint): Remove arguments "sal", "addr_string" and "ops". Add argument "ex_kind" instead. Adjust implementation accordingly, calling ada_exception_sal to get the entities it no longer gets passed as arguments. Document the function's arguments. (catch_ada_exception_command): Use catch_ada_exception_command_split instead of ada_decode_exception_location, and update call to create_ada_exception_catchpoint. (catch_ada_assert_command_split): Renames ada_decode_assert_location. Remove parameters "addr_string" and "ops", and now returns void. Adjust implementation accordingly. Update the function documentation. (catch_assert_command): Use catch_ada_assert_command_split instead of ada_decode_assert_location. Update call to create_ada_exception_catchpoint.
generated by cgit v1.1 at 2024-09-04 21:34:53 +0000