aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2013-10-25Fix changelog.Yao Qi2-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 Alves3-25/+25
- 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-25binutils doc updateTom Tromey3-8/+8
Here's another small patch to lay the groundwork for the git conversion. This one updates the BFD and binutils documentation for the move. bfd: * doc/bfdint.texi (BFD generated files): Mention git, not cvs. binutils: * MAINTAINERS: Mention git, not cvs. * README: Mention git, not cvs.
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-20daily updateAlan Modra1-1/+1
2013-10-19daily updateAlan Modra1-1/+1
2013-10-18daily updateAlan Modra1-1/+1
2013-10-182013-10-18 Chao-ying Fu <Chao-ying.Fu@imgtec.com>Chao-ying Fu5-0/+750
* gas/mips/micromips@msa-branch.d, gas/mips/msa-branch.d, gas/mips/msa-branch.s: New. * gas/mips/mips.exp: Run new tests.
2013-10-182013-10-18 Chao-ying Fu <Chao-ying.Fu@imgtec.com>Chao-ying Fu2-2/+16
* config/tc-mips.c (fpr_read_mask): Test MSA registers. (fpr_write_mask): Test MSA registers. (can_swap_branch_p): Check fpr write followed by fpr read.
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-18 * config/tc-tic6x.c (tic6x_parse_operand): Revert previous delta.Nick Clifton2-1/+5
2013-10-18 * ld-cris/asneed1.d: New test.Hans-Peter Nilsson2-0/+29
2013-10-18 * elf32-cris.c (cris_elf_check_relocs): Don't assumeHans-Peter Nilsson2-5/+15
a registered dynobj means that a .got has been created.
2013-10-18gdb/Yao Qi2-2/+6
* c-varobj.c (cplus_number_of_children): Fix indentation.
2013-10-17daily updateAlan Modra1-1/+1
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-17 PR 16056Alan Modra2-2/+9
* elf.c (copy_elf_program_header): Only consider SEC_ALLOC sections when finding lowest_section.
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-16daily updateAlan Modra1-1/+1
2013-10-162013-10-16 Jan-Benedict Glaw <jbglaw@lug-owl.de>Jan-Benedict Glaw3-3/+31
* ChangeLog: Sync from GCC. * mh-darwin: Ditto. * bootstrap-ubsan.mk: Ditto.
2013-10-162013-10-16 Jan-Benedict Glaw <jbglaw@lug-owl.de>Jan-Benedict Glaw3-0/+25
* configure.ac: Update from GCC. * configure: 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-16merge from gccDJ Delorie9-2/+56