aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2014-10-21Automatic date update in version.inGDB Administrator1-1/+1
2014-10-20Automatic date update in version.inGDB Administrator1-1/+1
2014-10-19Automatic date update in version.inGDB Administrator1-1/+1
2014-10-18Automatic date update in version.inGDB Administrator1-1/+1
2014-10-17PR gdb/17471: Repeating a background command makes it foregroundPedro Alves5-53/+224
When we repeat a command, by just pressing <ret>, the input from the previous command is reused for the new command invocation. When an execution command strips the "&" out of its incoming argument string, to detect background execution, we poke a '\0' directly to the incoming argument string. Combine both, and a repeat of a background command loses the "&". This is actually only visible if args other than "&" are specified (e.g., "c 1&" or "next 2&" or "c -a&"), as in the special case of "&" alone (e.g. "c&") doesn't actually clobber the incoming string. Fix this by making strip_bg_char return a new string instead of poking a hole in the input string. New test included. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ 2014-10-17 Pedro Alves <palves@redhat.com> PR gdb/17471 * infcmd.c (strip_bg_char): Change prototype and rewrite. Now returns a copy of the input. (run_command_1, continue_command, step_1, jump_command) (signal_command, until_command, advance_command, finish_command) (attach_command): Adjust and install a cleanup to free the stripped args. gdb/testsuite/ 2014-10-17 Pedro Alves <palves@redhat.com> PR gdb/17471 * gdb.base/bg-execution-repeat.c: New file. * gdb.base/bg-execution-repeat.exp: New file.
2014-10-17PR gdb/17300: Input after "c -a" crashes readline/GDBPedro Alves5-0/+135
If all threads in the target were already running when the user does "c -a", nothing puts the inferior's terminal settings in effect and removes stdin from the event loop, which we must when running a foreground command. The result is that user input afterwards crashes readline/gdb: (gdb) start Temporary breakpoint 1 at 0x4005d4: file continue-all-already-running.c, line 23. Starting program: continue-all-already-running Temporary breakpoint 1, main () at continue-all-already-running.c:23 23 sleep (10); (gdb) c -a& Continuing. (gdb) c -a Continuing. p 1 readline: readline_callback_read_char() called with no handler! Aborted (core dumped) $ Backtrace: Program received signal SIGABRT, Aborted. 0x0000003b36a35877 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); (top-gdb) p 1 $1 = 1 (top-gdb) bt #0 0x0000003b36a35877 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x0000003b36a36f68 in __GI_abort () at abort.c:89 #2 0x0000000000784aa9 in rl_callback_read_char () at readline/callback.c:116 #3 0x0000000000619181 in rl_callback_read_char_wrapper (client_data=0x0) at gdb/event-top.c:167 #4 0x0000000000619557 in stdin_event_handler (error=0, client_data=0x0) at gdb/event-top.c:373 #5 0x000000000061814a in handle_file_event (data=...) at gdb/event-loop.c:763 #6 0x0000000000617631 in process_event () at gdb/event-loop.c:340 #7 0x00000000006176f8 in gdb_do_one_event () at gdb/event-loop.c:404 #8 0x0000000000617748 in start_event_loop () at gdb/event-loop.c:429 #9 0x00000000006191b3 in cli_command_loop (data=0x0) at gdb/event-top.c:182 #10 0x000000000060f538 in current_interp_command_loop () at gdb/interps.c:318 #11 0x0000000000610701 in captured_command_loop (data=0x0) at gdb/main.c:323 #12 0x000000000060c3f5 in catch_errors (func=0x6106e6 <captured_command_loop>, func_args=0x0, errstring=0x9002c1 "", mask=RETURN_MASK_ALL) at gdb/exceptions.c:237 #13 0x0000000000611bff in captured_main (data=0x7fffffffd780) at gdb/main.c:1151 #14 0x000000000060c3f5 in catch_errors (func=0x610afe <captured_main>, func_args=0x7fffffffd780, errstring=0x9002c1 "", mask=RETURN_MASK_ALL) at gdb/exceptions.c:237 #15 0x0000000000611c28 in gdb_main (args=0x7fffffffd780) at gdb/main.c:1159 #16 0x000000000045ef97 in main (argc=5, argv=0x7fffffffd888) at gdb/gdb.c:32 (top-gdb) Tested on x86_64 Fedora 20, native and gdbserver. gdb/ 2014-10-17 Pedro Alves <palves@redhat.com> PR gdb/17300 * infcmd.c (continue_1): If continuing all threads in the foreground, make sure the inferior's terminal settings are put in effect. gdb/testsuite/ 2014-10-17 Pedro Alves <palves@redhat.com> PR gdb/17300 * gdb.base/continue-all-already-running.c: New file. * gdb.base/continue-all-already-running.exp: New file.
2014-10-17PR gdb/17472: With annotations, input while executing in the foreground ↵Pedro Alves7-2/+202
crashes readline/GDB Jan caught an intermittent GDB crash with the annota1.exp test: Starting program: .../gdb/testsuite/gdb.base/annota1 ^M [...] FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout) [...] readline: readline_callback_read_char() called with no handler!^M ERROR: Process no longer exists All we need to is to continue the inferior in the foreground, and type a command while the inferior is running. E.g.: (gdb) set annotate 2 ▒▒pre-prompt (gdb) ▒▒prompt c ▒▒post-prompt Continuing. ▒▒starting ▒▒frames-invalid *inferior is running now* p 1<ret> readline: readline_callback_read_char() called with no handler! Aborted (core dumped) $ When we run a foreground execution command we call target_terminal_inferior to stop GDB from processing input, and to put the inferior's terminal settings in effect. Then we tell readline to hide the prompt with display_gdb_prompt, which clears readline's input callback too. When the target stops, we call target_terminal_ours, which re-installs stdin in the event loop, and then we redisplay the prompt, reinstalling the readline callbacks. However, when annotations are in effect, the "frames-invalid" annotation code calls target_terminal_ours after 'resume' had already called target_terminal_inferior: (top-gdb) bt #0 0x000000000056b82f in annotate_frames_invalid () at gdb/annotate.c:219 #1 0x000000000072e6cc in reinit_frame_cache () at gdb/frame.c:1705 #2 0x0000000000594bb9 in registers_changed_ptid (ptid=...) at gdb/regcache.c:612 #3 0x000000000064cca1 in target_resume (ptid=..., step=1, signal=GDB_SIGNAL_0) at gdb/target.c:2136 #4 0x00000000005f57af in resume (step=1, sig=GDB_SIGNAL_0) at gdb/infrun.c:2263 #5 0x00000000005f6051 in proceed (addr=18446744073709551615, siggnal=GDB_SIGNAL_DEFAULT, step=1) at gdb/infrun.c:2613 And then once we hide the prompt and remove readline's input handler callback, we're in a bad state. We end up with the target running supposedly in the foreground, but with stdin still installed on the event loop. Any input then calls into readline, which aborts because no rl_linefunc callback handler is installed: Program received signal SIGABRT, Aborted. 0x0000003b36a35877 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); (top-gdb) bt #0 0x0000003b36a35877 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x0000003b36a36f68 in __GI_abort () at abort.c:89 During symbol reading, debug info gives source 9 included from file at zero line 0. During symbol reading, debug info gives command-line macro definition with non-zero line 19: _STDC_PREDEF_H 1. #2 0x0000000000784a25 in rl_callback_read_char () at src/readline/callback.c:116 #3 0x0000000000619111 in rl_callback_read_char_wrapper (client_data=0x0) at src/gdb/event-top.c:167 #4 0x00000000006194e7 in stdin_event_handler (error=0, client_data=0x0) at src/gdb/event-top.c:373 #5 0x00000000006180da in handle_file_event (data=...) at src/gdb/event-loop.c:763 #6 0x00000000006175c1 in process_event () at src/gdb/event-loop.c:340 #7 0x0000000000617688 in gdb_do_one_event () at src/gdb/event-loop.c:404 #8 0x00000000006176d8 in start_event_loop () at src/gdb/event-loop.c:429 #9 0x0000000000619143 in cli_command_loop (data=0x0) at src/gdb/event-top.c:182 #10 0x000000000060f4c8 in current_interp_command_loop () at src/gdb/interps.c:318 #11 0x0000000000610691 in captured_command_loop (data=0x0) at src/gdb/main.c:323 #12 0x000000000060c385 in catch_errors (func=0x610676 <captured_command_loop>, func_args=0x0, errstring=0x900241 "", mask=RETURN_MASK_ALL) at src/gdb/exceptions.c:237 #13 0x0000000000611b8f in captured_main (data=0x7fffffffd7b0) at src/gdb/main.c:1151 #14 0x000000000060c385 in catch_errors (func=0x610a8e <captured_main>, func_args=0x7fffffffd7b0, errstring=0x900241 "", mask=RETURN_MASK_ALL) at src/gdb/exceptions.c:237 #15 0x0000000000611bb8 in gdb_main (args=0x7fffffffd7b0) at src/gdb/main.c:1159 #16 0x000000000045ef57 in main (argc=3, argv=0x7fffffffd8b8) at src/gdb/gdb.c:32 The fix is to make the annotation code call target_terminal_inferior again after printing, if the inferior's settings were in effect. While at it, when we're doing output only, instead of target_terminal_ours, we should call target_terminal_ours_for_output. The latter doesn't actually remove stdin from the event loop, and also leaves SIGINT forwarded to the target. New test included. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ 2014-10-17 Pedro Alves <palves@redhat.com> PR gdb/17472 * annotate.c (annotate_breakpoints_invalid): Use target_terminal_our_for_output instead of target_terminal_ours. Give back the terminal to the target. (annotate_frames_invalid): Likewise. gdb/testsuite/ 2014-10-17 Pedro Alves <palves@redhat.com> PR gdb/17472 * gdb.base/annota-input-while-running.c: New file. * gdb.base/annota-input-while-running.exp: New file.
2014-10-17Make common code handle target_terminal_* idempotencyPedro Alves4-14/+81
I found a place that should be giving back the terminal to the target, but only if the target was already owning it. So I need to add a getter for who owns the terminal. The trouble is that several places/target have their own globals to track this state: - inflow.c:terminal_is_ours - remote.c:remote_async_terminal_ours_p - linux-nat.c:async_terminal_is_ours - go32-nat.c:terminal_is_ours While one might think of adding a new target_ops method to query this, conceptually, this state isn't really part of a particular target_ops. Considering multi-target, the core shouldn't have to ask all targets to know whether it's GDB that owns the terminal. There's only one GDB (or rather, only one top level interpreter). So what this comment does is add a new global that is tracked by the core instead. A subsequent pass may later remove the other globals. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ 2014-10-17 Pedro Alves <palves@redhat.com> * target.c (enum terminal_state): New enum. (terminal_state): New global. (target_terminal_init): New function. (target_terminal_inferior): Skip if inferior already owns the terminal. (target_terminal_ours, target_terminal_ours_for_output): New functions. * target.h (target_terminal_init): Convert to function prototype. (target_terminal_ours_for_output): Convert to function prototype and tweak comment. (target_terminal_ours): Convert to function prototype and tweak comment. * windows-nat.c (do_initial_windows_stuff): Call target_terminal_init instead of child_terminal_init_with_pgrp.
2014-10-17Automatic date update in version.inGDB Administrator1-1/+1
2014-10-16Automatic date update in version.inGDB Administrator1-1/+1
2014-10-15PR python/17364Doug Evans6-18/+54
gdb/ChangeLog: * python/lib/gdb/__init__.py (packages): Add "printer". * python/lib/gdb/command/bound_registers.py: Moved to ... * python/lib/gdb/printer/bound_registers.py: ... here. Add printer to global set of builtin printers. Rename printer from "bound" to "mpx_bound128". * python/lib/gdb/printing.py (_builtin_pretty_printers): New global, registered as global "builtin" printer. (add_builtin_pretty_printer): New function. * data-directory/Makefile.in (PYTHON_FILE_LIST): Update, and add gdb/printer/__init__.py.
2014-10-15state->dr_control_mirror == 0 failed assertion in gdbserver on Windows XPJoel Brobecker2-1/+6
When using GDBserver on Windows XP, GDBserver reports an assertion failure after hitting a hardware watchpoint. The problem was reproduced using the sources from gdb.ada/int_deref, but should probably reproduce with any scenario involving hardware watchpoints. In our scenario, we break on line 5, just before the increment, insert a watchhpoint on it, and then continue: (gdb) b foo.adb:5 Breakpoint 1 at 0x4017c2: file foo.adb, line 5. (gdb) cont Continuing. Breakpoint 1, foo () at foo.adb:5 5 Pck.Watch := Pck.Watch + 1; (gdb) watch watch Hardware watchpoint 2: watch (gdb) c Continuing. Remote communication error. Target disconnected.: Invalid argument. The immediate cause for the communication error is easily explained, gdbserver crashes due to a failed assertion: x86_remove_aligned_watchpoint: Assertion `state->dr_control_mirror == 0' failed. The assertion occurs because debug_reg_state.dr_control_mirror gets overwritten by the value read from the inferior, when processing the watchpoint event in win32_wait: win32_wait finds that we stopped, calls get_thread_regcache which causes i386_get_thread_context to get called, which then... if (th->tid == current_event->dwThreadId) { /* Copy dr values from the current thread. */ struct x86_debug_reg_state *dr = &debug_reg_state; [...] dr->dr_control_mirror = th->context.Dr7; } Both should be identical, normally making this a no-op, but it turns out that bits 12-11-10 are documented as being fixed and equal to 001. Our handling of dr_control_mirror does not manage those bits, and leaves them as zeros instead. So, when we overwrite the value from the thread's DR7 register, we accidentally set bit 10, causing state->dr_control_mirror to be 0x400 after we've cleared everything internally. This patch fixes the issue by removing the statement setting state->dr_control_mirror to the thread's DR7 register value. gdb/gdbserver/ChangeLog: PR server/17487 * win32-i386-low.c (i386_get_thread_context): Do not set dr->dr_control_mirror.
2014-10-15Automatic date update in version.inGDB Administrator1-1/+1
2014-10-14Automatic date update in version.inGDB Administrator1-1/+1
2014-10-13Automatic date update in version.inGDB Administrator1-1/+1
2014-10-12Automatic date update in version.inGDB Administrator1-1/+1
2014-10-11Automatic date update in version.inGDB Administrator1-1/+1
2014-10-10Automatic date update in version.inGDB Administrator1-1/+1
2014-10-09Automatic date update in version.inGDB Administrator1-1/+1
2014-10-08Automatic date update in version.inGDB Administrator1-1/+1
2014-10-07Automatic date update in version.inGDB Administrator1-1/+1
2014-10-06Automatic date update in version.inGDB Administrator1-1/+1
2014-10-05Automatic date update in version.inGDB Administrator1-1/+1
2014-10-04Automatic date update in version.inGDB Administrator1-1/+1
2014-10-03Automatic date update in version.inGDB Administrator1-1/+1
2014-10-02Automatic date update in version.inGDB Administrator1-1/+1
2014-10-01Aarch64: Make CPSR a 32-bit register again in the target descriptionPedro Alves3-2/+7
This reverts commit a4d9ba85 - 'AARCH64: Change cpsr type to be 64bit.'. Even though Linux's ptrace exposes CPSR as 64-bit, CPSR is really 32-bit, and basing GDB's fundamentals on a particular OS's ptrace(2) implementation is a bad idea. In addition, while that commit intended to fix big endian Aarch64, it ended up breaking floating point debugging against GDBserver, for both big and little endian, because it changed the CPSR to be 64-bit in the features/aarch64-core.xml file, but missed regenerating the regformats/aarch64.dat file. If we generate it now, we see this: diff --git c/gdb/regformats/aarch64.dat w/gdb/regformats/aarch64.dat index afe1028..0d32183 100644 --- c/gdb/regformats/aarch64.dat +++ w/gdb/regformats/aarch64.dat @@ -35,7 +35,7 @@ expedite:x29,sp,pc 64:x30 64:sp 64:pc -32:cpsr +64:cpsr 128:v0 128:v1 128:v2 IOW, that commit left regformats/aarch64.dat still considering CPSR as 32-bits. regformats/aarch64.dat is used by GDBserver for its internal regcache layout, and for the g/G packet register block. See the generated aarch64.c file in GDBserver's build dir. So the target description xml file that GDBserver reports to GDB is now claiming that CPSR is 64-bit, but what GDBserver actually puts in the g/G register packets is 32-bits. Because GDB thinks CPSR is 64-bit (because that's what the XML description says), GDB will be reading the remaining 32-bit bits of CPSR out of v0 (the register immediately afterwards), and then all the registers that follow CPSR in the register packet end up wrong in GDB, because they're being read from the wrong offsets... gdb/ 2014-10-01 Pedro Alves <palves@redhat.com> * features/aarch64-core.xml (cpsr): Change back to 32-bit. * features/aarch64.c: Regenerate.
2014-10-01Automatic date update in version.inGDB Administrator1-1/+1
2014-09-30Automatic date update in version.inGDB Administrator1-1/+1
2014-09-29Automatic date update in version.inGDB Administrator1-1/+1
2014-09-28Automatic date update in version.inGDB Administrator1-1/+1
2014-09-27Automatic date update in version.inGDB Administrator1-1/+1
2014-09-26Automatic date update in version.inGDB Administrator1-1/+1
2014-09-25Automatic date update in version.inGDB Administrator1-1/+1
2014-09-24Automatic date update in version.inGDB Administrator1-1/+1
2014-09-23Automatic date update in version.inGDB Administrator1-1/+1
2014-09-22Automatic date update in version.inGDB Administrator1-1/+1
2014-09-21Automatic date update in version.inGDB Administrator1-1/+1
2014-09-20Automatic date update in version.inGDB Administrator1-1/+1
2014-09-19Automatic date update in version.inGDB Administrator1-1/+1
2014-09-18Fix regression for Linux vDSO in GDB (PR gdb/17407).Jan Kratochvil2-1/+6
since 5979d6b69b20a8355ea94b75fad97415fce4788c https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=5979d6b69b20a8355ea94b75fad97415fce4788c vdso handling https://sourceware.org/ml/binutils/2014-03/msg00082.html https://sourceware.org/ml/binutils/2014-04/msg00003.html Message-ID: <A78C989F6D9628469189715575E55B230AA884EB@IRSMSX104.ger.corp.intel.com> I get on kernel-3.16.2-200.fc20.x86_64 https://koji.fedoraproject.org/koji/buildinfo?buildID=575860 attaching its vdso.bin.gz GDB (FSF HEAD 5e43d46791c4c66fd83947a12d4f716b561a9103) regression: reproducer: ./gdb -ex start ./gdb actual result / FAIL: Got object file from memory but can't read symbols: File truncated. expected result / PASS: <nothing> or / PASS: warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? That "warning: Could not load shared library..." is mostly harmless (it is a bug in GDB), in the FAIL case it is not printed just because bfd_check_format() fails there. It seems logical to me this way when the 'size' parameter has been already added. Alan Modra: I was wrongly thinking that the section headers were always last when I wrote that code. (They are now! If you relink that vdso with current binutils master you won't hit this problem, but that of course doesn't help existing kernels.) I do not see a regression for add-symbol-file-from-memory for libncurses.so.5 from the original thread above. Start of section headers: 1080 (bytes into file) Size of section headers: 64 (bytes) Number of section headers: 13 Section header string table index: 8 Section Headers: [Nr] Name Type Address Off Size ES Flg Lk Inf Al [ 8] .fake_shstrtab STRTAB 0000000000000780 000780 000076 00 A 0 0 32 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x0000000000000000 0x0000000000000000 0x0012fe 0x0012fe R E 0x1000 size == 0x2000 shdr_end == 0x778 == 1080 + 13 * 64 high_offset == 0x12fe else if (size >= shdr_end) - high_offset = shdr_end; + high_offset = size; But then 0x778 < 0x780 for "Section header string table index" so whole bfd_check_format() fails because section headers were not cleared here: /* If the segments visible in memory didn't include the section headers, then clear them from the file header. */ if (high_offset < shdr_end) bfd/ChangeLog 2014-09-18 Jan Kratochvil <jan.kratochvil@redhat.com> PR gdb/17407 * elfcode.h (bfd_from_remote_memory): Use SIZE for HIGH_OFFSET.
2014-09-18Automatic date update in version.inGDB Administrator1-1/+1
2014-09-17Automatic date update in version.inGDB Administrator1-1/+1
2014-09-16Automatic date update in version.inGDB Administrator1-1/+1
2014-09-15Automatic date update in version.inGDB Administrator1-1/+1
2014-09-14Automatic date update in version.inGDB Administrator1-1/+1
2014-09-13Automatic date update in version.inGDB Administrator1-1/+1
2014-09-12Automatic date update in version.inGDB Administrator1-1/+1
2014-09-11gdb/17347 - Regression: GDB stopped on run with attached processPedro Alves7-10/+115
Doing: gdb --pid=PID -ex run Results in GDB getting a SIGTTIN, and thus ending stopped. That's usually indicative of a missing target_terminal_ours call. E.g., from the PR: $ sleep 1h & p=$!; sleep 0.1; gdb -batch sleep $p -ex run [1] 28263 [1] Killed sleep 1h [2]+ Stopped gdb -batch sleep $p -ex run The workaround is doing: gdb -ex "attach $PID" -ex "run" instead of gdb [-p] $PID -ex "run" With the former, gdb waits for the attach command to complete before moving on to the "run" command, because the interpreter is in sync mode at this point, within execute_command. But for the latter, attach_command is called directly from captured_main, and thus misses that waiting. IOW, "run" is running before the attach continuation has run, before the program stops and attach completes. The broken terminal settings are just one symptom of that. Any command that queries or requires input results in the same. The fix is to wait in catch_command_errors (which is specific to main.c nowadays), just like we wait in execute_command. gdb/ChangeLog: 2014-09-11 Pedro Alves <palves@redhat.com> PR gdb/17347 * main.c: Include "infrun.h". (catch_command_errors, catch_command_errors_const): Wait for the foreground command to complete. * top.c (maybe_wait_sync_command_done): New function, factored out from ... (maybe_wait_sync_command_done): ... here. * top.h (maybe_wait_sync_command_done): New declaration. gdb/testsuite/ChangeLog: 2014-09-11 Pedro Alves <palves@redhat.com> PR gdb/17347 * lib/gdb.exp (gdb_spawn_with_cmdline_opts): New procedure. * gdb.base/attach.exp (test_command_line_attach_run): New procedure. (top level): Call it.
2014-09-11testsuite: refactor spawn and wait for attachPedro Alves8-83/+48
Several places in the testsuite have a copy of a snippet of code that spawns a test program, waits a bit, and then does some PID munging for Cygwin. This is in order to have GDB attach to the spawned program. This refactors all that to a common procedure. (multi-attach.exp wants to spawn multiple processes, so this makes the new procedure's interface work with lists.) Tested on x86_64 Fedora 20. gdb/testsuite/ChangeLog: 2014-09-11 Pedro Alves <palves@redhat.com> * lib/gdb.exp (spawn_wait_for_attach): New procedure. * gdb.base/attach.exp (do_attach_tests, do_call_attach_tests) (do_command_attach_tests): Use spawn_wait_for_attach. * gdb.base/solib-overlap.exp: Likewise. * gdb.multi/multi-attach.exp: Likewise. * gdb.python/py-prompt.exp: Likewise. * gdb.python/py-sync-interp.exp: Likewise. * gdb.server/ext-attach.exp: Likewise.
generated by cgit v1.1 at 2025-09-27 07:19:20 +0000