aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2016-09-18Automatic date update in version.inGDB Administrator1-1/+1
2016-09-17Automatic date update in version.inGDB Administrator1-1/+1
2016-09-16Backport lastest POWER9 support to match final ISA 3.0 documentation.Peter Bergner5-87/+48
opcodes/ Apply from master. 2016-09-14 Peter Bergner <bergner@vnet.ibm.com> * ppc-opc.c (powerpc_opcodes) <slbiag>: New mnemonic. <addex., brd, brh, brw, lwzmx, nandxor, rldixor, setbool, xor3>: Delete mnemonics. <cp_abort>: Rename mnemonic from ... <cpabort>: ...to this. <setb>: Change to a X form instruction. <sync>: Change to 1 operand form. <copy>: Delete mnemonic. <copy_first>: Rename mnemonic from ... <copy>: ...to this. <paste, paste.>: Delete mnemonics. <paste_last>: Rename mnemonic from ... <paste.>: ...to this. gas/ Apply from master. 2016-09-14 Peter Bergner <bergner@vnet.ibm.com> * testsuite/gas/ppc/power9.d <slbiag, cpabort> New tests. <addex., brd, brh, brw, lwzmx, nandxor, rldixor, setbool, xor3, cp_abort, copy_first, paste, paste_last, sync>: Remove tests. <copy, paste.>: Update tests. * testsuite/gas/ppc/power9.s: Likewise.
2016-09-16Automatic date update in version.inGDB Administrator1-1/+1
2016-09-15Automatic date update in version.inGDB Administrator1-1/+1
2016-09-14Automatic date update in version.inGDB Administrator1-1/+1
2016-09-13Automatic date update in version.inGDB Administrator1-1/+1
2016-09-12Automatic date update in version.inGDB Administrator1-1/+1
2016-09-11Automatic date update in version.inGDB Administrator1-1/+1
2016-09-10Automatic date update in version.inGDB Administrator1-1/+1
2016-09-09Automatic date update in version.inGDB Administrator1-1/+1
2016-09-08Automatic date update in version.inGDB Administrator1-1/+1
2016-09-07Automatic date update in version.inGDB Administrator1-1/+1
2016-09-06new-ui command: gdb internal errors if input is already pendingPedro Alves6-3/+194
I noticed that if input is already pending on the new-ui TTY, gdb internal-errors. E.g., create /dev/pts/2, and type anything there (even just <return> is sufficient). Now start GDB creating a new UI on that TTY, while at the same time, running a synchronous execution command. Something like: $ gdb program -ex "new-ui console /dev/pts/2" -ex "start" Back on /dev/pts/2, we get: (gdb) .../src/gdb/event-top.c:360: internal-error: double prompt A problem internal to GDB has been detected, further debugging may prove unreliable. While the main UI was waiting for "start" to finish, gdb kepts pumping events, including the input fd of the extra console. The problem is that stdin_event_handler doesn't restore the current UI back to what it was, assuming that it's only ever called from the top level event loop. However, in this case, it's being called from the nested event loop from within maybe_wait_sync_command_done. When finally the "start" command is done, we reach the code that prints the prompt in the main UI, just before starting the main event loop. Since now the current UI is pointing at the extra console (by mistake), we find ourselves printing a double prompt on the extra console. This is caught by the assertion that fails, as shown above. Since other event handlers also don't restore the UI (e.g., signal event handlers), I think it's better if whatever is pumping events to take care to restore the UI, if it cares. That's what this patch does. New test included. gdb/ChangeLog: 2016-09-06 Pedro Alves <palves@redhat.com> * top.c (wait_sync_command_done): Don't assume current_ui doesn't change across events. Restore the current UI before returning. (gdb_readline_wrapper): Restore the current UI before returning. gdb/testsuite/ChangeLog: 2016-09-06 Pedro Alves <palves@redhat.com> * gdb.base/new-ui-pending-input.c: New file. * gdb.base/new-ui-pending-input.exp: New file. * gdb.exp (clear_gdb_spawn_id): New procedure. (with_spawn_id): Check whether gdb_spawn_id exists before referencing it. If gdb_spawn_id didn't exist on entry, clear it on exit.
2016-09-06Introduce make_cleanup_restore_current_uiPedro Alves6-8/+27
Just a tidy, no functional changes. gdb/ChangeLog: 2016-09-06 Pedro Alves <palves@redhat.com> * event-top.c (restore_ui_cleanup): Now static. (make_cleanup_restore_current_ui): New function. (switch_thru_all_uis_init): Use it. * infcall.c (call_thread_fsm_should_stop): Use it. * infrun.c (fetch_inferior_event): Use it. * top.c (new_ui_command): Use it. * top.h (restore_ui_cleanup): Delete declaration. (make_cleanup_restore_current_ui): New declaration.
2016-09-06Automatic date update in version.inGDB Administrator1-1/+1
2016-09-05Automatic date update in version.inGDB Administrator1-1/+1
2016-09-04Automatic date update in version.inGDB Administrator1-1/+1
2016-09-03Automatic date update in version.inGDB Administrator1-1/+1
2016-09-02Automatic date update in version.inGDB Administrator1-1/+1
2016-09-01Automatic date update in version.inGDB Administrator1-1/+1
2016-08-31Fix lwp_suspend/unsuspend imbalance in linux_wait_1Antoine Tremblay2-18/+23
This patch fixes imbalanced lwp_suspend/unsuspend calls caused by the premature choosing of another event for fairness. select_event_lwp would switch the event before a call to unsuspend_all_lwps, thus it would be called with the wrong event. This caused an assertion failure: unsuspend LWP xx, suspended=-1 when testing gdb.threads/non-stop-fair-events.exp with ARM range stepping in GDBServer. This patch moves the switch of event after the unsuspend/unstop calls. No regressions, tested on ubuntu 14.04 ARMv7 and x86. With gdbserver-native. gdb/gdbserver/ChangeLog: * linux-low.c (linux_wait_1): Move event switch after unsuspend_lwps.
2016-08-31Automatic date update in version.inGDB Administrator1-1/+1
2016-08-30Fix order of inferiors in "thread apply all"Andreas Arnez4-1/+15
This inserts missing parentheses in the calculation of the comparison result between two different inferior numbers. The problem was found by Philipp Rudo. gdb/ChangeLog: * thread.c (tp_array_compar): Insert missing parentheses. gdb/testsuite/ChangeLog: * gdb.multi/tids.exp: Test "thread apply all".
2016-08-30Automatic date update in version.inGDB Administrator1-1/+1
2016-08-29gdb.base/default.exp regressionJan Kratochvil2-2/+4
tty^M (gdb) FAIL: gdb.base/default.exp: tty gdb/testsuite/ChangeLog 2016-08-29 Jan Kratochvil <jan.kratochvil@redhat.com> * gdb.base/default.exp (tty): Remove.
2016-08-29Automatic date update in version.inGDB Administrator1-1/+1
2016-08-28Automatic date update in version.inGDB Administrator1-1/+1
2016-08-27Automatic date update in version.inGDB Administrator1-1/+1
2016-08-26xtensa: Avoid designated inits, for C++ complianceAndreas Arnez2-49/+55
C++ does not officially support designators in initializer lists. Thus some compilers may issue errors when encountering them. Modern versions of GCC seem to allow them by default, as a GCC extension, even though the GCC documentation explicitly states otherwise: "[...] This extension is not implemented in GNU C++." But some older GCC versions (like 4.4.7) did indeed emit an error instead, like this: .../gdb/xtensa-config.c:219: error: expected primary-expression before ‘.’ token This patch removes the only such instance I've seen when building with '--enable-targets=all'. gdb/ChangeLog: * xtensa-tdep.h (XTENSA_GDBARCH_TDEP_INSTANTIATE): Replace designated initializer list by plain initializer list, for C++ compliance.
2016-08-26Automatic date update in version.inGDB Administrator1-1/+1
2016-08-25Sync proc_service definition with GLIBCAdhemerval Zanella22-20/+49
GLIBC BZ#20311 [1] proc_service.h install patch also remove 'const' attributes from ps_get_thread_area and comment #15 discuss why to remove the const attribute (basically since it a callback with the struct ps_prochandle owned by the client it should be able to modify it if it the case). On default build this is not the issue and current g++ does not trigger any issue with this mismatch declaration. However, on some bootstrap build configuration where gdbserver is build with gcc instead this triggers: error: conflicting types for 'ps_get_thread_area' This patch fixes it by syncing the declaration with GLIBC. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=20311 gdb/ChangeLog: 2016-08-25 Adhemerval Zanella <adhemerval.zanella@linaro.org> * aarch64-linux-nat.c (ps_get_thread_area): Remove const from struct ps_prochandle. * amd64-linux-nat.c (ps_get_thread_area): Likewise. * arm-linux-nat.c (ps_get_thread_area): Likewise. * gdb_proc_service.h (ps_get_thread_area): Likewise. * i386-linux-nat.c (ps_get_thread_area): Likewise. * m68klinux-nat.c (ps_get_thread_area): Likewise. * mips-linux-nat.c (ps_get_thread_area): Likewise. * nat/aarch64-linux.c (aarch64_ps_get_thread_area): Likewise. * nat/aarch64-linux.h (aarch64_ps_get_thread_area): Likewise. * xtensa-linux-nat.c (ps_get_thread_area): Likewise. gdb/gdbserver/ChangeLog: 2016-08-25 Adhemerval Zanella <adhemerval.zanella@linaro.org> PR server/20491 * gdb_proc_service.h (ps_get_thread_area): Remove const from struct ps_prochandle. * linux-aarch64-low.c (ps_get_thread_area): Likewise. * linux-arm-low.c (ps_get_thread_area): Likewise. * linux-crisv32-low.c (ps_get_thread_area): Likewise. * linux-m68k-low.c (ps_get_thread_area): Likewise. * linux-mips-low.c (ps_get_thread_area): Likewise. * linux-nios2-low.c (ps_get_thread_area): Likewise. * linux-tic6x-low.c (ps_get_thread_area): Likewise. * linux-x86-low.c (ps_get_thread_area): Likewise. * linux-xtensa-low.c (ps_get_thread_area): Likewise.
2016-08-25Automatic date update in version.inGDB Administrator1-1/+1
2016-08-24Allow resetting an empty inferior-ttySimon Marchi7-9/+98
This patch allows the user to set the inferior-tty to "empty", in order to come back to the default behaviour of using the same tty as gdb is using. This is already supported in MI (and tested in gdb.mi/mi-basics.exp). I added a new test, set-inferior-tty.exp, where I test only the setting and unsetting of the parameter. It would be nice to actually test that the inferior output properly goes to the separate tty, but that will be for another day. gdb/ChangeLog: * infcmd.c (set_inferior_io_terminal): Set inferior terminal to NULL if terminal_name is an empty string. (_initialize_infcmd): Make the argument of "set inferior-tty" optional, mention it in the help doc. gdb/doc/ChangeLog: * gdb.texinfo (Input/Output): Mention possibility to unset inferior-tty. gdb/testsuite/ChangeLog: * gdb.base/set-inferior-tty.exp: New file. * gdb.base/set-inferior-tty.c: New file.
2016-08-24Automatic date update in version.inGDB Administrator1-1/+1
2016-08-23x32: Fix gdb.trace/mi-trace-frame-collected.expPedro Alves2-2/+17
gdb.trace/mi-trace-frame-collected.exp has a couple failures on x32: FAIL: gdb.trace/mi-trace-frame-collected.exp: live: -trace-frame-collected (register) FAIL: gdb.trace/mi-trace-frame-collected.exp: tfile: -trace-frame-collected (register) gdb.log: -trace-frame-collected ^done,explicit-variables=[{name="gdb_char_test",value="0 '\\000'"}],computed-expressions=[],registers=[{number="16",value="0x4004dc"},{number="204",value="0x4004dc"}],tvars =[],memory=[{address="0x00601060",length="1"}] (gdb) FAIL: gdb.trace/mi-trace-frame-collected.exp: live: -trace-frame-collected (register) [...] -trace-frame-collected ^done,explicit-variables=[{name="gdb_char_test",value="0 '\\000'"}],computed-expressions=[],registers=[{number="16",value="0x4004dc"},{number="204",value="0x4004dc"}],tvars =[],memory=[{address="0x00601060",length="1"}] (gdb) FAIL: gdb.trace/mi-trace-frame-collected.exp: tfile: -trace-frame-collected (register) This test only collects the PC, and thus expects to only see one register in the output of -trace-frame-collected. However, while on the 64-bit ABI gdb only exposes 64-bit $pc/$rip (register 16 above), on x32, GDB exposes 32-bit $eip as well, as a pseudo-register (register 204 above). Thus, collecting $pc/$rip automatically always collects $eip as well. gdb/testsuite/ChangeLog: 2016-08-23 Pedro Alves <palves@redhat.com> * gdb.trace/mi-trace-frame-collected.exp (test_trace_frame_collected): On x32, expect two registers.
2016-08-23x32: gdb: Fix 'call' insn relocation with qRelocInsnPedro Alves2-5/+42
Running the fast tracepoints tests against x32 gdbserver exposes a latent bug. E.g.,: (gdb) continue Continuing. Reading /media/sf_host-pedro/gdb/mygit/build-ubuntu-x32/gdb/testsuite/outputs/gdb.trace/change-loc/change-loc-2.sl from remote target... Thread 1 "change-loc" received signal SIGSEGV, Segmentation fault. func4 () at /home/pedro/gdb/src/gdb/testsuite/gdb.trace/change-loc.h:24 24 } (gdb) FAIL: gdb.trace/change-loc.exp: 1 ftrace: continue to marker 2 The test sets a fast tracepoint on a shared library. On x32, shared libraries end up loaded somewhere in the upper 2GB of the 4GB address space x32 has access to. When gdbserver needs to copy an instruction to execute it in the jump pad, it asks gdb to relocate/adjust it, with the qRelocInsn packet. gdb converts "call" instructions into a "push $<2GB-4GB addr> + jmp" sequence, however, the "pushq" instruction sign extends its operand, so later when the called function returns, it returns to an incorrectly sign-extended address. E.g., 0xfffffffffabc0000 instead of 0xfabc0000, resulting in the segmentation fault. Fix this by converting calls at such addresses to "sub + mov + jmp" sequences instead. gdb/ChangeLog: 2016-08-23 Pedro Alves <palves@redhat.com> * amd64-tdep.c (amd64_relocate_instruction) <callq>: Handle return addresses over 0x7fffffff.
2016-08-23x32: gdbserver's agent bytecode JIT: fix "call" emissionPedro Alves2-0/+6
Running fast tracepoint tests on x32 exposes a latent bug in the agent bytecode jitting. There's a code path that forgets to emit the call opcode... Whoops. Fixes a bunch of gdb.trace/trace-condition.exp FAILs, like: (gdb) continue Continuing. Thread 1 "trace-condition" received signal SIGSEGV, Segmentation fault. 0x7ffec016 in ?? () (gdb) FAIL: gdb.trace/trace-condition.exp: ftrace: $rip == *set_point: advance through tracing gdb/gdbserver/ChangeLog: 2016-08-23 Pedro Alves <palves@redhat.com> * linux-x86-low.c (amd64_emit_call): Emit missing call opcode.
2016-08-23x32: Avoid unsigned long when installing fast tracepoint jump padsPedro Alves2-3/+8
We're casting through unsigned long to write a 64-bit immediate operand of movabs (the comment said movl, but that was incorrect). The problem is that unsigned long is 32-bit on x32, so we were writing fewer bytes than necessary. Fix this by using an 8 byte memcpy like in other similar places in the function. gdb/gdbserver/ChangeLog: 2016-08-23 Pedro Alves <palves@redhat.com> * linux-x86-low.c (amd64_install_fast_tracepoint_jump_pad): Fix comment. Use memcpy instead of casting through unsigned long.
2016-08-23x32 Fast tracepoints: Customize jump pad addressPedro Alves2-4/+53
MAP_32BIT is ignored on x32, meaning the jump pad can end up somewhere between 2GB and 4GB, too far away from the executable for 5-byte relative jumps (JMP rel32). So on x32, try explicitly placing the jump pad near the middle of the available address space. gdb/gdbserver/ChangeLog: 2016-08-23 Pedro Alves <palves@redhat.com> * linux-amd64-ipa.c (alloc_jump_pad_buffer) [__ILP32__]: Try allocating around 0x80000000.
2016-08-23x32 Fast tracepoints: IPA target descriptionsPedro Alves6-5/+98
Building GDB for x32 fails building the IPA, with: .../src/gdb/gdbserver/linux-amd64-ipa.c: In function ‘const target_desc* get_ipa_tdesc(int)’: .../src/gdb/gdbserver/linux-amd64-ipa.c:182:14: error: ‘tdesc_amd64_avx_linux’ was not declared in this scope return tdesc_amd64_avx_linux; ^ .../src/gdb/gdbserver/linux-amd64-ipa.c:184:14: error: ‘tdesc_amd64_mpx_linux’ was not declared in this scope return tdesc_amd64_mpx_linux; ^ .../src/gdb/gdbserver/linux-amd64-ipa.c:186:14: error: ‘tdesc_amd64_avx_mpx_linux’ was not declared in this scope return tdesc_amd64_avx_mpx_linux; ^ [...] The problem is that the IPA is trying to use the 64-bit descriptions, when it should be using the x32 ones. gdb/gdbserver/ChangeLog: 2016-08-23 Pedro Alves <palves@redhat.com> PR gdb/20415 * Makefile.in (x32-linux-ipa.o, x32-avx-linux-ipa.o) (x32-avx512-linux-ipa.o): New rules. * configure.ac (x86_64-*-linux*): New x32 check. * configure.srv (ipa_x32_linux_regobj): New. (x86_64-*-linux*): Use $ipa_x32_linux_regobj if building for x32. * linux-amd64-ipa.c (get_ipa_tdesc) [__ILP32__]: Return x32 descriptions. (initialize_low_tracepoint) [__ILP32__]: Initialize x32 descriptions. * configure: Regenerate.
2016-08-23Fix PR20494 - User input stops being echoed in CLIPedro Alves7-47/+206
This patch fixes a problem that problem triggers if you start an inferior, e.g., with the "start" command, in a UI created with the new-ui command, and then run a foreground execution command in the main UI. Once the program stops for the latter command, typing in the main UI no longer echoes back to the user. The problem revolves around this: - gdb_has_a_terminal computes its result lazily, on first call. that is what saves gdb's initial main UI terminal state (the UI associated with stdin): our_terminal_info.ttystate = serial_get_tty_state (stdin_serial); This is the state that target_terminal_ours() restores. - In this scenario, the gdb_has_a_terminal function happens to be first ever called from within the target_terminal_init call in startup_inferior: (top-gdb) bt #0 gdb_has_a_terminal () at src/gdb/inflow.c:157 #1 0x000000000079db22 in child_terminal_init_with_pgrp () at src/gdb/inflow.c:217 [...] #4 0x000000000065bacb in target_terminal_init () at src/gdb/target.c:456 #5 0x00000000004676d2 in startup_inferior () at src/gdb/fork-child.c:531 [...] #7 0x000000000046b168 in linux_nat_create_inferior () at src/gdb/linux-nat.c:1112 [...] #9 0x00000000005f20c9 in start_command (args=0x0, from_tty=1) at src/gdb/infcmd.c:657 If the command to start the inferior is issued on the main UI, then readline will have deprepped the terminal when we reach the above, and the problem doesn't appear. If however the command is issued on a non-main UI, then when we reach that gdb_has_a_terminal call, the main UI's terminal state is still set to whatever readline has sets it to in rl_prep_terminal, which happens to have echo disabled. Later, when the following synchronous execution command finishes, we'll call target_terminal_ours to restore gdb's the main UI's terminal settings, and that restores the terminal state with echo disabled... Conceptually, the fix is to move the gdb_has_a_terminal call earlier, to someplace during GDB initialization, before readline/ncurses have had a chance to change terminal settings. Turns out that "set_initial_gdb_ttystate" is exactly such a place. I say conceptually, because the fix actually inlines the gdb_has_a_terminal part that saves the terminal state in set_initial_gdb_ttystate and then simplifies gdb_has_a_terminal, since there's no point in making gdb_has_a_terminal do lazy computation. gdb/ChangeLog: 2016-08-23 Pedro Alves <palves@redhat.com> PR gdb/20494 * inflow.c (our_terminal_info, initial_gdb_ttystate): Update comments. (enum gdb_has_a_terminal_flag_enum, gdb_has_a_terminal_flag): Delete. (set_initial_gdb_ttystate): Record our_terminal_info here too, instead of ... (gdb_has_a_terminal): ... here. Reimplement in terms of initial_gdb_ttystate. Make static. * terminal.h (gdb_has_a_terminal): Delete declaration. (set_initial_gdb_ttystate): Add comment. * top.c (show_interactive_mode): Use input_interactive_p instead of gdb_has_a_terminal. gdb/testsuite/ChangeLog: 2016-08-23 Pedro Alves <palves@redhat.com> PR gdb/20494 * gdb.base/new-ui-echo.c: New file. * gdb.base/new-ui-echo.exp: New file.
2016-08-23Fix signals-state-child.exp in remote testingYao Qi2-6/+29
Remote testing isn't considered in signals-state-child.exp, so the it fails like shell diff -s /scratch/yao/gdb/build-git/aarch64-linux-gnu/gdb/testsuite/outputs/gdb.base/signals-state-child/standalone.txt /scratch/yao/gdb/build-git/aarch64-linux-gnu/gdb/testsuite/outputs/gdb.base/signals-state-child/gdb.txt^M diff: /scratch/yao/gdb/build-git/aarch64-linux-gnu/gdb/testsuite/outputs/gdb.base/signals-state-child/standalone.txt: No such file or directory^M (gdb) FAIL: gdb.base/signals-state-child.exp: signals states are identical This patch is to fix it. gdb/testsuite: 2016-08-23 Yao Qi <yao.qi@linaro.org> * gdb.base/signals-state-child.exp: Set variables gdb_txt and standalone_txt. Delete gdb_txt and standalone_txt on host and target. Spawn the binary on target. Copy files from target to host.
2016-08-23Automatic date update in version.inGDB Administrator1-1/+1
2016-08-22Fix PR gdb/20505 - Make vDSO detection work with core filesPedro Alves4-29/+97
Loading a core dump that was either generated on a system running pristine glibc master, or on a Fedora/RHEL system with LD_DEBUG=unused set in the environment, solib-svr4.c:svr4_current_sos fails to filter out the vDSO, resulting in: (gdb) core-file corefile.core^M [New LWP 2362]^M warning: Could not load shared library symbols for linux-vdso.so.1.^M Do you need "set solib-search-path" or "set sysroot"?^M Core was generated by `build-gdb/gdb/testsuite/outputs/gdb.base/corefile/'.^M ... The problem is that gdbarch_vsyscall_range does not support core inferiors at all. When live debugging, we're finding the vDSO's start address with auxv/AT_SYSINFO_EHDR, and then we find the vDSO's size by look for the corresponding mapping, by parsing /proc/PID/maps. When debugging a core dump, we can also determine the starting address from auxv/AT_SYSINFO_EHDR. However, we obviously can't read the core mappings out of the host's /proc. But we can instead look for a corresponding load segment in the core's bfd. gdb/ChangeLog: 2016-08-22 Pedro Alves <palves@redhat.com> PR gdb/20505 * linux-tdep.c (linux_vsyscall_range_raw): For core inferiors, find the vDSO's start address with AT_SYSINFO_EHDR too, and determine the vDSO's size by finding the PT_LOAD segment that matches AT_SYSINFO_EHDR. gdb/testsuite/ChangeLog: 2016-08-22 Pedro Alves <palves@redhat.com> PR gdb/20505 * gdb.base/vdso-warning.exp: Test core dumps too. Use with_test_prefix. Factor out bits to ... (test_no_vdso): ... this new procedure.
2016-08-22Automatic date update in version.inGDB Administrator1-1/+1
2016-08-21Automatic date update in version.inGDB Administrator1-1/+1
2016-08-20Automatic date update in version.inGDB Administrator1-1/+1
2016-08-19[AArch64] Match instruction "STP with base register" in prologueYao Qi2-2/+8
Nowadays, we only match pre-indexed STP in prologue. Due to the change in gcc, https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01933.html, it may generate "STP with base register" in prologue, which GDB doesn't handle. That is to say, previously GCC generates prologue like this, sub sp, sp, #490 stp x29, x30, [sp, #-96]! mov x29, sp with the gcc patch above, GCC generates prologue like like this, sub sp, sp, #4f0 stp x29, x30, [sp] mov x29, sp This patch is to teach GDB to recognize this instruction in prologue analysis. gdb: 2016-08-19 Yao Qi <yao.qi@linaro.org> * aarch64-tdep.c (aarch64_analyze_prologue): Handle register based STP instruction.
2016-08-19null-terminate string in linespec_location_completerYao Qi2-1/+7
If I build gdb with -fsanitize=address and run tests, I get error, malformed linespec error: unexpected colon^M (gdb) PASS: gdb.linespec/ls-errs.exp: lang=C: break : break :=================================================================^M ==3266==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000051451 at pc 0x2b5797a972a8 bp 0x7fffd8e0f3c0 sp 0x7fffd8e0f398^M READ of size 2 at 0x602000051451 thread T0 #0 0x2b5797a972a7 in __interceptor_strlen (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x322a7)^M #1 0x7bd004 in compare_filenames_for_search(char const*, char const*) /home/yao/SourceCode/gnu/gdb/git/gdb/symtab.c:316^M #2 0x7bd310 in iterate_over_some_symtabs(char const*, char const*, int (*)(symtab*, void*), void*, compunit_symtab*, compunit_symtab*) /home/yao/SourceCode/gnu/gdb/git/gdb/symtab.c:411^M #3 0x7bd775 in iterate_over_symtabs(char const*, int (*)(symtab*, void*), void*) /home/yao/SourceCode/gnu/gdb/git/gdb/symtab.c:481^M #4 0x7bda15 in lookup_symtab(char const*) /home/yao/SourceCode/gnu/gdb/git/gdb/symtab.c:527^M #5 0x7d5e2a in make_file_symbol_completion_list_1 /home/yao/SourceCode/gnu/gdb/git/gdb/symtab.c:5635^M #6 0x7d61e1 in make_file_symbol_completion_list(char const*, char const*, char const*) /home/yao/SourceCode/gnu/gdb/git/gdb/symtab.c:5684^M #7 0x88dc06 in linespec_location_completer /home/yao/SourceCode/gnu/gdb/git/gdb/completer.c:288 .... 0x602000051451 is located 0 bytes to the right of 1-byte region [0x602000051450,0x602000051451)^M mallocated by thread T0 here: #0 0x2b5797ab97ef in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x547ef)^M #1 0xbbfb8d in xmalloc /home/yao/SourceCode/gnu/gdb/git/gdb/common/common-utils.c:43^M #2 0x88dabd in linespec_location_completer /home/yao/SourceCode/gnu/gdb/git/gdb/completer.c:273^M #3 0x88e5ef in location_completer(cmd_list_element*, char const*, char const*) /home/yao/SourceCode/gnu/gdb/git/gdb/completer.c:531^M #4 0x8902e7 in complete_line_internal /home/yao/SourceCode/gnu/gdb/git/gdb/completer.c:964^ The code in question is here file_to_match = (char *) xmalloc (colon - text + 1); strncpy (file_to_match, text, colon - text + 1); it is likely that file_to_match is not null-terminated. The patch is to strncpy 'colon - text' bytes and explicitly set '\0'. gdb: 2016-08-19 Yao Qi <yao.qi@linaro.org> * completer.c (linespec_location_completer): Make file_to_match null-terminated.
generated by cgit v1.1 at 2025-09-22 11:07:22 +0000