aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2021-07-02Document TUI improvements in the manual & NEWSPedro Alves4-0/+46
gdb/ChangeLog: yyyy-mm-dd Pedro Alves <pedro@palves.net> Hannes Domani <ssbssa@yahoo.de> * NEWS: Add new "TUI Improvements" section and mention mouse support and that unrecognized special keys are now passed to GDB. Mention Python Window.click in the Python improvements section. gdb/doc/ChangeLog: yyyy-mm-dd Pedro Alves <pedro@palves.net> * gdb.texinfo (TUI): <TUI Mouse Support>: New node/section. Co-Authored-By: Hannes Domani <ssbssa@yahoo.de> Change-Id: I0d79a795d8ac561fd28cdc5184bff029ba28bc64
2021-07-01Linux: Access memory even if threads are runningPedro Alves7-47/+706
Currently, on GNU/Linux, if you try to access memory and you have a running thread selected, GDB fails the memory accesses, like: (gdb) c& Continuing. (gdb) p global_var Cannot access memory at address 0x555555558010 Or: (gdb) b main Breakpoint 2 at 0x55555555524d: file access-mem-running.c, line 59. Warning: Cannot insert breakpoint 2. Cannot access memory at address 0x55555555524d This patch removes this limitation. It teaches the native Linux target to read/write memory even if the target is running. And it does this without temporarily stopping threads. We now get: (gdb) c& Continuing. (gdb) p global_var $1 = 123 (gdb) b main Breakpoint 2 at 0x555555555259: file access-mem-running.c, line 62. (The scenarios above work correctly with current GDBserver, because GDBserver temporarily stops all threads in the process whenever GDB wants to access memory (see prepare_to_access_memory / done_accessing_memory). Freezing the whole process makes sense when we need to be sure that we have a consistent view of memory and don't race with the inferior changing it at the same time as GDB is accessing it. But I think that's a too-heavy hammer for the default behavior. I think that ideally, whether to stop all threads or not should be policy decided by gdb core, probably best implemented by exposing something like gdbserver's prepare_to_access_memory / done_accessing_memory to gdb core.) Currently, if we're accessing (reading/writing) just a few bytes, then the Linux native backend does not try accessing memory via /proc/<pid>/mem and goes straight to ptrace PTRACE_PEEKTEXT/PTRACE_POKETEXT. However, ptrace always fails when the ptracee is running. So the first step is to prefer /proc/<pid>/mem even for small accesses. Without further changes however, that may cause a performance regression, due to constantly opening and closing /proc/<pid>/mem for each memory access. So the next step is to keep the /proc/<pid>/mem file open across memory accesses. If we have this, then it doesn't make sense anymore to even have the ptrace fallback, so the patch disables it. I've made it such that GDB only ever has one /proc/<pid>/mem file open at any time. As long as a memory access hits the same inferior process as the previous access, then we reuse the previously open file. If however, we access memory of a different process, then we close the previous file and open a new one for the new process. If we wanted, we could keep one /proc/<pid>/mem file open per inferior, and never close them (unless the inferior exits or execs). However, having seen bfd patches recently about hitting too many open file descriptors, I kept the logic to have only one file open tops. Also, we need to handle memory accesses for processes for which we don't have an inferior object, for when we need to detach a fork-child, and we'd probaly want to handle caching the open file for that scenario (no inferior for process) too, which would probably end up meaning caching for last non-inferior process, which is very much what I'm proposing anyhow. So always having one file open likely ends up a smaller patch. The next step is handling the case of GDB reading/writing memory through a thread that is running and exits. The access should not result in a user-visible failure if the inferior/process is still alive. Once we manage to open a /proc/<lwpid>/mem file, then that file is usable for memory accesses even if the corresponding lwp exits and is reaped. I double checked that trying to open the same /proc/<lwpid>/mem path again fails because the lwp is really gone so there's no /proc/<lwpid>/ entry on the filesystem anymore, but the previously open file remains usable. It's only when the whole process execs that we need to reopen a new file. When the kernel destroys the whole address space, i.e., when the process exits or execs, the reads/writes fail with 0 aka EOF, in which case there's nothing else to do than returning a memory access failure. Note this means that when we get an exec event, we need to reopen the file, to access the process's new address space. If we need to open (or reopen) the /proc/<pid>/mem file, and the LWP we're opening it for exits before we open it and before we reap the LWP (i.e., the LWP is zombie), the open fails with EACCES. The patch handles this by just looking for another thread until it finds one that we can open a /proc/<pid>/mem successfully for. If we need to open (or reopen) the /proc/<pid>/mem file, and the LWP we're opening has exited and we already reaped it, which is the case if the selected thread is in THREAD_EXIT state, the open fails with ENOENT. The patch handles this the same way as a zombie race (EACCES), instead of checking upfront whether we're accessing a known-exited thread, because that would result in more complicated code, because we also need to handle accessing lwps that are not listed in the core thread list, and it's the core thread list that records the THREAD_EXIT state. The patch includes two testcases: #1 - gdb.base/access-mem-running.exp This is the conceptually simplest - it is single-threaded, and has GDB read and write memory while the program is running. It also tests setting a breakpoint while the program is running, and checks that the breakpoint is hit immediately. #2 - gdb.threads/access-mem-running-thread-exit.exp This one is more elaborate, as it continuously spawns short-lived threads in order to exercise accessing memory just while threads are exiting. It also spawns two different processes and alternates accessing memory between the two processes to exercise the reopening the /proc file frequently. This also ends up exercising GDB reading from an exited thread frequently. I confirmed by putting abort() calls in the EACCES/ENOENT paths added by the patch that we do hit all of them frequently with the testcase. It also exits the process's main thread (i.e., the main thread becomes zombie), to make sure accessing memory in such a corner-case scenario works now and in the future. The tests fail on GNU/Linux native before the code changes, and pass after. They pass against current GDBserver, again because GDBserver supports memory access even if all threads are running, by transparently pausing the whole process. gdb/ChangeLog: yyyy-mm-dd Pedro Alves <pedro@palves.net> PR mi/15729 PR gdb/13463 * linux-nat.c (linux_nat_target::detach): Close the /proc/<pid>/mem file if it was open for this process. (linux_handle_extended_wait) <PTRACE_EVENT_EXEC>: Close the /proc/<pid>/mem file if it was open for this process. (linux_nat_target::mourn_inferior): Close the /proc/<pid>/mem file if it was open for this process. (linux_nat_target::xfer_partial): Adjust. Do not fall back to inf_ptrace_target::xfer_partial for memory accesses. (last_proc_mem_file): New. (maybe_close_proc_mem_file): New. (linux_proc_xfer_memory_partial_pid): New, with bits factored out from linux_proc_xfer_partial. (linux_proc_xfer_partial): Delete. (linux_proc_xfer_memory_partial): New. gdb/testsuite/ChangeLog yyyy-mm-dd Pedro Alves <pedro@palves.net> PR mi/15729 PR gdb/13463 * gdb.base/access-mem-running.c: New. * gdb.base/access-mem-running.exp: New. * gdb.threads/access-mem-running-thread-exit.c: New. * gdb.threads/access-mem-running-thread-exit.exp: New. Change-Id: Ib3c082528872662a3fc0ca9b31c34d4876c874c9
2021-06-29gdb: introduce FRAME_SCOPED_DEBUG_ENTER_EXITSimon Marchi5-11/+29
Introduce FRAME_SCOPED_DEBUG_ENTER_EXIT and use it to print enter/exit messages in important frame-related functions. I think this helps understand which lower-level operations are done as part of which higher-level operation. And it helps visually skip over a higher-level operation you are not interested in. Here's an example, combined with some py-unwind messages: [frame] frame_unwind_find_by_frame: enter [frame] frame_unwind_find_by_frame: this_frame=0 [frame] frame_unwind_try_unwinder: trying unwinder "dummy" [frame] frame_unwind_try_unwinder: no [frame] frame_unwind_try_unwinder: trying unwinder "dwarf2 tailcall" [frame] frame_unwind_try_unwinder: no [frame] frame_unwind_try_unwinder: trying unwinder "inline" [frame] frame_unwind_try_unwinder: no [frame] frame_unwind_try_unwinder: trying unwinder "jit" [frame] frame_unwind_try_unwinder: no [frame] frame_unwind_try_unwinder: trying unwinder "python" [py-unwind] pyuw_sniffer: enter [frame] frame_unwind_register_value: enter [frame] frame_unwind_register_value: frame=-1, regnum=7(rsp) [frame] frame_unwind_register_value: -> register=7 bytes=[40ddffffff7f0000] [frame] frame_unwind_register_value: exit [py-unwind] pyuw_sniffer: frame=0, sp=0x7fffffffdd40, pc=0x5555555551ec [frame] frame_id_p: l={stack=<sentinel>,!code,special=0x0000000000000000} -> 1 [frame] frame_id_p: l={stack=<sentinel>,!code,special=0x0000000000000000} -> 1 [frame] frame_id_eq: l={stack=<sentinel>,!code,special=0x0000000000000000}, r={stack=<sentinel>,!code,special=0x0000000000000000} -> 1 [frame] frame_unwind_register_value: enter [frame] frame_unwind_register_value: frame=-1, regnum=6(rbp) [frame] frame_unwind_register_value: -> register=6 bytes=[50ddffffff7f0000] [frame] frame_unwind_register_value: exit [frame] frame_id_p: l={stack=<sentinel>,!code,special=0x0000000000000000} -> 1 [frame] frame_id_eq: l={stack=<sentinel>,!code,special=0x0000000000000000}, r={stack=<sentinel>,!code,special=0x0000000000000000} -> 1 [frame] get_prev_frame: enter [frame] get_prev_frame_always_1: enter [frame] get_prev_frame_always_1: this_frame=-1 [frame] get_prev_frame_always_1: -> {level=0,type=NORMAL_FRAME,unwind=0x5588ee3d17c0,pc=0x5555555551ec,id=<not computed>,func=<unknown>} // cached [frame] get_prev_frame_always_1: exit [frame] get_prev_frame: exit [frame] value_fetch_lazy_register: (frame=0, regnum=6(rbp), ...) -> register=6 bytes=[50ddffffff7f0000] [frame] frame_id_p: l={stack=<sentinel>,!code,special=0x0000000000000000} -> 1 [frame] frame_id_p: l={stack=<sentinel>,!code,special=0x0000000000000000} -> 1 [frame] frame_id_eq: l={stack=<sentinel>,!code,special=0x0000000000000000}, r={stack=<sentinel>,!code,special=0x0000000000000000} -> 1 [frame] frame_unwind_register_value: enter [frame] frame_unwind_register_value: frame=-1, regnum=7(rsp) [frame] frame_unwind_register_value: -> register=7 bytes=[40ddffffff7f0000] [frame] frame_unwind_register_value: exit [frame] frame_id_p: l={stack=<sentinel>,!code,special=0x0000000000000000} -> 1 [frame] frame_id_eq: l={stack=<sentinel>,!code,special=0x0000000000000000}, r={stack=<sentinel>,!code,special=0x0000000000000000} -> 1 [frame] get_prev_frame: enter [frame] get_prev_frame_always_1: enter [frame] get_prev_frame_always_1: this_frame=-1 [frame] get_prev_frame_always_1: -> {level=0,type=NORMAL_FRAME,unwind=0x5588ee3d1824,pc=0x5555555551ec,id=<not computed>,func=<unknown>} // cached [frame] get_prev_frame_always_1: exit [frame] get_prev_frame: exit [frame] value_fetch_lazy_register: (frame=0, regnum=7(rsp), ...) -> register=7 bytes=[40ddffffff7f0000] [frame] frame_id_p: l={stack=<sentinel>,!code,special=0x0000000000000000} -> 1 [frame] frame_id_p: l={stack=<sentinel>,!code,special=0x0000000000000000} -> 1 [frame] frame_id_eq: l={stack=<sentinel>,!code,special=0x0000000000000000}, r={stack=<sentinel>,!code,special=0x0000000000000000} -> 1 [frame] frame_unwind_register_value: enter [frame] frame_unwind_register_value: frame=-1, regnum=16(rip) [frame] frame_unwind_register_value: -> register=16 bytes=[ec51555555550000] [frame] frame_unwind_register_value: exit [frame] frame_id_p: l={stack=<sentinel>,!code,special=0x0000000000000000} -> 1 [frame] frame_id_eq: l={stack=<sentinel>,!code,special=0x0000000000000000}, r={stack=<sentinel>,!code,special=0x0000000000000000} -> 1 [frame] get_prev_frame: enter [frame] get_prev_frame_always_1: enter [frame] get_prev_frame_always_1: this_frame=-1 [frame] get_prev_frame_always_1: -> {level=0,type=NORMAL_FRAME,unwind=0x5588ee3d1888,pc=0x5555555551ec,id=<not computed>,func=<unknown>} // cached [frame] get_prev_frame_always_1: exit [frame] get_prev_frame: exit [frame] value_fetch_lazy_register: (frame=0, regnum=16(rip), ...) -> register=16 bytes=[ec51555555550000] [py-unwind] pyuw_sniffer: frame claimed by unwinder test unwinder [py-unwind] pyuw_sniffer: exit [frame] frame_unwind_try_unwinder: yes [frame] frame_unwind_find_by_frame: exit gdb/ChangeLog: * frame.h (FRAME_SCOPED_DEBUG_ENTER_EXIT): New. * frame.c (compute_frame_id, get_prev_frame_always_1, get_prev_frame): Use FRAME_SCOPED_DEBUG_ENTER_EXIT. * frame-unwind.c (frame_unwind_find_by_frame): Likewise. (frame_unwind_register_value): Likewise. Change-Id: I45b69b4ed962e70572bc55b8adfb211483c1eeed
2021-06-29gdb: add names to unwinders, add debug messages when looking for unwinderSimon Marchi78-5/+133
I wrote this while debugging a problem where the expected unwinder for a frame wasn't used. It adds messages to show which unwinders are considered for a frame, why they are not selected (if an exception is thrown), and finally which unwinder is selected in the end. To be able to show a meaningful, human-readable name for the unwinders, add a "name" field to struct frame_unwind, and update all instances to include a name. Here's an example of the output: [frame] frame_unwind_find_by_frame: this_frame=0 [frame] frame_unwind_try_unwinder: trying unwinder "dummy" [frame] frame_unwind_try_unwinder: no [frame] frame_unwind_try_unwinder: trying unwinder "dwarf2 tailcall" [frame] frame_unwind_try_unwinder: no [frame] frame_unwind_try_unwinder: trying unwinder "inline" [frame] frame_unwind_try_unwinder: no [frame] frame_unwind_try_unwinder: trying unwinder "jit" [frame] frame_unwind_try_unwinder: no [frame] frame_unwind_try_unwinder: trying unwinder "python" [frame] frame_unwind_try_unwinder: no [frame] frame_unwind_try_unwinder: trying unwinder "amd64 epilogue" [frame] frame_unwind_try_unwinder: no [frame] frame_unwind_try_unwinder: trying unwinder "i386 epilogue" [frame] frame_unwind_try_unwinder: no [frame] frame_unwind_try_unwinder: trying unwinder "dwarf2" [frame] frame_unwind_try_unwinder: yes gdb/ChangeLog: * frame-unwind.h (struct frame_unwind) <name>: New. Update instances everywhere to include this field. * frame-unwind.c (frame_unwind_try_unwinder, frame_unwind_find_by_frame): Add debug messages. Change-Id: I813f17777422425f0d08b22499817b23922e8ddb
2021-06-29gdb: introduce frame_debug_printfSimon Marchi7-251/+177
Introduce frame_debug_printf, to convert the "frame" debug messages to the new system. Replace fprint_frame with a frame_info::to_string method that returns a string, like what was done with frame_id::to_string. This makes it easier to use with frame_debug_printf. gdb/ChangeLog: * frame.h (frame_debug_printf): New. * frame.c: Use frame_debug_printf throughout when printing frame debug messages. * amd64-windows-tdep.c: Likewise. * value.c: Likewise. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-reg-undefined.exp: Update regexp. Change-Id: I3c230b0814ea81c23af3e1aca1aac8d4ba91d726
2021-06-29gdb: make frame_debug a booleanSimon Marchi3-6/+13
gdb/ChangeLog: * frame.h (frame_debug): Change type to bool. * frame.c (frame_debug): Change type to bool. (_initialize_frame): Adjust. Change-Id: I27b5359a25ad53ac42618b5708a025c348a1eeda
2021-06-29gdb: remove duplicate declaration of 'find_thread_ptid'Tankut Baris Aktemur2-4/+4
There are two declarations of 'find_thread_ptid' in gdbthread.h with the same signature: /* Find (non-exited) thread PTID of inferior INF. */ extern thread_info *find_thread_ptid (inferior *inf, ptid_t ptid); and /* Search function to lookup a (non-exited) thread by 'ptid'. Only searches in threads of INF. */ extern struct thread_info *find_thread_ptid (inferior *inf, ptid_t ptid); Retain the former, remove the latter. Tested by rebuilding. gdb/ChangeLog: 2021-06-29 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * gdbthread.h (find_thread_ptid): Remove the duplicate declaration.
2021-06-28gdb: use gdb_bfd_count_sections in macho_symfile_offsetsSimon Marchi2-1/+7
When loading a mach-o (macOS) executable and trying to set a breakpoint, a GDB built with ASan or -D_GLIBCXX_DEBUG will crash with an out-of-bound vector access. This can be reproduced on Linux using the repro files in bug 28017 [1]: $ ./gdb -nx --data-directory=data-directory -q repro/test -ex "b main" -batch /usr/include/c++/11.1.0/debug/vector:445: In function: std::__debug::vector<_Tp, _Allocator>::const_reference std::__debug::vector<_Tp, _Allocator>::operator[](std::__debug::vector<_Tp, _Allocator>::size_type) const [with _Tp = long unsigned int; _Allocator = std::allocator<long unsigned int>; std::__debug::vector<_Tp, _Allocator>::const_reference = const long unsigned int&; std::__debug::vector<_Tp, _Allocator>::size_type = long unsigned int] Error: attempt to subscript container with out-of-bounds index 13, but container only holds 13 elements. Objects involved in the operation: sequence "this" @ 0x0x61300000a590 { type = std::__debug::vector<unsigned long, std::allocator<unsigned long> >; } The out-of-bound access happens here: #0 0x00007ffff6405d22 in raise () from /usr/lib/libc.so.6 #1 0x00007ffff63ef862 in abort () from /usr/lib/libc.so.6 #2 0x00007ffff664e21e in __gnu_debug::_Error_formatter::_M_error() const [clone .cold] from /usr/lib/libstdc++.so.6 #3 0x000055555699e5ff in std::__debug::vector<unsigned long, std::allocator<unsigned long> >::operator[] (this=0x61300000a590, __n=13) at /usr/include/c++/11.1.0/debug/vector:445 #4 0x0000555556a58c17 in objfile::section_offset (this=0x61300000a4c0, section=0x55555bbe4ac0 <_bfd_std_section>) at /home/simark/src/binutils-gdb/gdb/objfiles.h:644 #5 0x0000555556a58cac in obj_section::offset (this=0x62100016d2a8) at /home/simark/src/binutils-gdb/gdb/objfiles.h:838 #6 0x0000555556a58cfa in obj_section::addr (this=0x62100016d2a8) at /home/simark/src/binutils-gdb/gdb/objfiles.h:850 #7 0x000055555779f5f7 in sort_cmp (sect1=0x62100016d2a8, sect2=0x62100016d170) at /home/simark/src/binutils-gdb/gdb/objfiles.c:902 #8 0x00005555577aae35 in __gnu_cxx::__ops::_Iter_comp_iter<bool (*)(obj_section const*, obj_section const*)>::operator()<obj_section**, obj_section**> (this=0x7fffffffa9e0, __it1=0x60c000015970, __it2=0x60c000015940) at /usr/include/c++/11.1.0/bits/predefined_ops.h:158 #9 0x00005555577aa2b8 in std::__insertion_sort<obj_section**, __gnu_cxx::__ops::_Iter_comp_iter<bool (*)(obj_section const*, obj_section const*)> > (__first=0x60c000015940, __last=0x60c0000159c0, __comp=...) at /usr/include/c++/11.1.0/bits/stl_algo.h:1826 #10 0x00005555577a8e26 in std::__final_insertion_sort<obj_section**, __gnu_cxx::__ops::_Iter_comp_iter<bool (*)(obj_section const*, obj_section const*)> > (__first=0x60c000015940, __last=0x60c0000159c0, __comp=...) at /usr/include/c++/11.1.0/bits/stl_algo.h:1871 #11 0x00005555577a723c in std::__sort<obj_section**, __gnu_cxx::__ops::_Iter_comp_iter<bool (*)(obj_section const*, obj_section const*)> > (__first=0x60c000015940, __last=0x60c0000159c0, __comp=...) at /usr/include/c++/11.1.0/bits/stl_algo.h:1957 #12 0x00005555577a50f4 in std::sort<obj_section**, bool (*)(obj_section const*, obj_section const*)> (__first=0x60c000015940, __last=0x60c0000159c0, __comp=0x55555779f4e7 <sort_cmp(obj_section const*, obj_section const*)>) at /usr/include/c++/11.1.0/bits/stl_algo.h:4875 #13 0x00005555577a147e in update_section_map (pspace=0x61200001d2c0, pmap=0x6030000d40b0, pmap_size=0x6030000d40b8) at /home/simark/src/binutils-gdb/gdb/objfiles.c:1165 #14 0x00005555577a19a0 in find_pc_section (pc=0x100003fa0) at /home/simark/src/binutils-gdb/gdb/objfiles.c:1212 #15 0x00005555576dd39e in lookup_minimal_symbol_by_pc_section (pc_in=0x100003fa0, section=0x0, prefer=lookup_msym_prefer::TEXT, previous=0x0) at /home/simark/src/binutils-gdb/gdb/minsyms.c:750 #16 0x00005555576de552 in lookup_minimal_symbol_by_pc (pc=0x100003fa0) at /home/simark/src/binutils-gdb/gdb/minsyms.c:986 #17 0x0000555557d44b54 in find_pc_sect_line (pc=0x100003fa0, section=0x62100016d170, notcurrent=0) at /home/simark/src/binutils-gdb/gdb/symtab.c:3163 #18 0x0000555557d489fa in find_function_start_sal_1 (func_addr=0x100003fa0, section=0x62100016d170, funfirstline=true) at /home/simark/src/binutils-gdb/gdb/symtab.c:3650 #19 0x0000555557d49015 in find_function_start_sal (sym=0x621000191670, funfirstline=true) at /home/simark/src/binutils-gdb/gdb/symtab.c:3706 #20 0x0000555557485283 in symbol_to_sal (result=0x7fffffffbb30, funfirstline=1, sym=0x621000191670) at /home/simark/src/binutils-gdb/gdb/linespec.c:4460 #21 0x00005555574728c2 in convert_linespec_to_sals (state=0x7fffffffc390, ls=0x7fffffffc3e0) at /home/simark/src/binutils-gdb/gdb/linespec.c:2335 #22 0x0000555557475a8e in parse_linespec (parser=0x7fffffffc360, arg=0x60200007a550 "main", match_type=symbol_name_match_type::WILD) at /home/simark/src/binutils-gdb/gdb/linespec.c:2716 #23 0x0000555557479027 in event_location_to_sals (parser=0x7fffffffc360, location=0x606000097be0) at /home/simark/src/binutils-gdb/gdb/linespec.c:3173 #24 0x00005555574798f7 in decode_line_full (location=0x606000097be0, flags=1, search_pspace=0x0, default_symtab=0x0, default_line=0, canonical=0x7fffffffcca0, select_mode=0x0, filter=0x0) at /home/simark/src/binutils-gdb/gdb/linespec.c:3253 #25 0x0000555556b4949f in parse_breakpoint_sals (location=0x606000097be0, canonical=0x7fffffffcca0) at /home/simark/src/binutils-gdb/gdb/breakpoint.c:9134 #26 0x0000555556b6ce95 in create_sals_from_location_default (location=0x606000097be0, canonical=0x7fffffffcca0, type_wanted=bp_breakpoint) at /home/simark/src/binutils-gdb/gdb/breakpoint.c:13819 #27 0x0000555556b645a6 in bkpt_create_sals_from_location (location=0x606000097be0, canonical=0x7fffffffcca0, type_wanted=bp_breakpoint) at /home/simark/src/binutils-gdb/gdb/breakpoint.c:12631 #28 0x0000555556b4badf in create_breakpoint (gdbarch=0x621000152d10, location=0x606000097be0, cond_string=0x0, thread=0, extra_string=0x0, force_condition=false, parse_extra=1, tempflag=0, type_wanted=bp_breakpoint, ignore_count=0, pending_break_support=AUTO_BOOLEAN_AUTO, ops=0x55555bd728a0 <bkpt_breakpoint_ops>, from_tty=0, enabled=1, internal=0, flags=0) at /home/simark/src/binutils-gdb/gdb/breakpoint.c:9410 #29 0x0000555556b4d3b1 in break_command_1 (arg=0x7fffffffe291 "", flag=0, from_tty=0) at /home/simark/src/binutils-gdb/gdb/breakpoint.c:9590 #30 0x0000555556b4dc1b in break_command (arg=0x7fffffffe28d "main", from_tty=0) at /home/simark/src/binutils-gdb/gdb/breakpoint.c:9660 #31 0x0000555556d24ca9 in do_const_cfunc (c=0x61100003a240, args=0x7fffffffe28d "main", from_tty=0) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:102 #32 0x0000555556d2fcd3 in cmd_func (cmd=0x61100003a240, args=0x7fffffffe28d "main", from_tty=0) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2160 #33 0x0000555557e84e93 in execute_command (p=0x7fffffffe290 "n", from_tty=0) at /home/simark/src/binutils-gdb/gdb/top.c:674 #34 0x00005555575a9933 in catch_command_errors (command=0x555557e84043 <execute_command(char const*, int)>, arg=0x7fffffffe28b "b main", from_tty=0, do_bp_actions=true) at /home/simark/src/binutils-gdb/gdb/main.c:523 #35 0x00005555575a9fdb in execute_cmdargs (cmdarg_vec=0x7fffffffd910, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffd5b0) at /home/simark/src/binutils-gdb/gdb/main.c:618 #36 0x00005555575ad48a in captured_main_1 (context=0x7fffffffdd00) at /home/simark/src/binutils-gdb/gdb/main.c:1322 #37 0x00005555575ada9c in captured_main (data=0x7fffffffdd00) at /home/simark/src/binutils-gdb/gdb/main.c:1343 #38 0x00005555575adb31 in gdb_main (args=0x7fffffffdd00) at /home/simark/src/binutils-gdb/gdb/main.c:1368 #39 0x000055555681e179 in main (argc=8, argv=0x7fffffffde78) at /home/simark/src/binutils-gdb/gdb/gdb.c:32 The section being dealt with at that moment is the special *COM* section: (top-gdb) p section.name $1 = 0x55555a1bbe60 "*COM*" (top-gdb) p section $2 = (bfd_section *) 0x55555bbe4ac0 <_bfd_std_section> I'm not too sure what this section is for, but this is one of four special BFD sections that GDB puts after the regular sections in the objfile::sections and objfile::section_offsets lists. You can check gdb_bfd_section_index to see how they are handled. gdb_bfd_count_sections returns "+ 4" to account for those sections. The problem is that macho_symfile_offsets uses bfd_count_sections instead of gdb_bfd_count_sections when allocating the objfile::section_offsets vector. The vector will therefore contain, say, 13 elements instead of 17. When trying to access the section offset of the *COM* section, the first after the regular sections, we access section_offsets[13], which is out of bounds. Fix that by using gdb_bfd_count_sections instead of bfd_count_sections. I'm fairly confident that this is correct, as this is what default_symfile_offsets does. With this patch, the command shown above terminates normally: $ ./gdb -nx --data-directory=data-directory -q repro/test -ex "b main" -batch Breakpoint 1 at 0x100003fad: file test.c, line 2. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=28017 gdb/ChangeLog: PR gdb/28017 * machoread.c (macho_symfile_offsets): Use gdb_bfd_count_sections to allocate objfile::section_offsets. Change-Id: Ic3a56f46f7232e9f24581f8255fc1ab981935450
2021-06-28gdb: convert obj_section macros to methodsSimon Marchi22-102/+134
Convert these three macros to methods of obj_section. The problem fixed by the following patch is caused by an out of bound access of the objfile::section_offsets vector. Since this is deep in macros, we don't get a clear backtrace and it's difficult to debug. Changing that to methods means we can step in them and break on them. Because their implementation requires knowing about struct objfile, move struct obj_section below struct objfile in objfiles.h. The obj_section_offset was used in one place as an lvalue to set offsets, in machoread.c. Replace that with a set_offset method. Add the objfile::section_offset and objfile::set_section_offset methods to improve encapsulation (reduce other objects poking into struct objfile's internals). gdb/ChangeLog: * objfiles.h (struct obj_section): Move down. <offset, set_offset, addr, endaddr>: New. (obj_section_offset, obj_section_addr, obj_section_endaddr), replace all users to use obj_section methods. (struct objfile) <section_offset, set_section_offset>: New. Change-Id: I97e8fcae93ab2353fbdadcb4a5ec10d7949a7334
2021-06-28gdb: add .flake8 fileSimon Marchi2-0/+6
Add a .flake8 file, which is used to set default options to the flake8 Python linter. Use it to disable these two kinds of diagnostics, which we don't care about since formatting is handled by black. This reduces the amount of noise when running flake8 on Python files. ./python/lib/gdb/function/caller_is.py:30:80: E501 line too long (81 > 79 characters) ./python/lib/gdb/command/frame_filters.py:468:17: W503 line break before binary operator gdb/ChangeLog: * .flake8: New. Change-Id: I2b41379fdd1f6e8bf2a784d55a10b406e4d1c828
2021-06-28Sanitize the address before working with allocation tagsLuis Machado2-2/+17
Remove the logical tag/top byte from the address whenever we have to work with allocation tags. gdb/ChangeLog: 2021-06-28 Luis Machado <luis.machado@linaro.org> * aarch64-linux-tdep.c (aarch64_linux_memtag_matches_p): Remove the top byte. (aarch64_linux_set_memtags): Likewise. (aarch64_linux_get_memtag): Likewise. (aarch64_linux_report_signal_info): Likewise.
2021-06-28Fix FFR register size for core files.Luis Machado2-1/+6
The FFR register has a size of VL bits, not 32 bits. This causes issues when writing core files with the gcore command and when reading them. The FFR register sometimes shows up with garbage data. gdb/ChangeLog: 2021-06-28 Luis Machado <luis.machado@linaro.org> * aarch64-linux-tdep.c (aarch64_linux_iterate_over_regset_sections): Fix FFR register size.
2021-06-28Fix tag_ctl register size in the core file.Luis Machado3-3/+11
This register should be 64 bits in size, but the current code only saves 32 bits. This is due to an early assumption that tag_ctl would be 32 bits in size. gdb/ChangeLog: 2021-06-28 Luis Machado <luis.machado@linaro.org> * aarch64-linux-tdep.c (aarch64_linux_iterate_over_regset_sections): Update tag_ctl register size. * aarch64-linux-tdep.h (AARCH64_LINUX_SIZEOF_MTE_REGSET): Set to 8 and update comments.
2021-06-28gdb: remove gdbarch_info_initSimon Marchi18-92/+43
While reviewing another patch, I realized that gdbarch_info_init could easily be removed in favor of initializing gdbarch_info fields directly in the struct declaration. The only odd part is the union. I don't know if it's actually important for it to be zero-initialized, but I presume it is. I added a constructor to gdbarch_info to take care of that. A proper solution would be to use std::variant. Or, these could also be separate fields, the little extra space required wouldn't matter. gdb/ChangeLog: * gdbarch.sh (struct gdbarch_info): Initialize fields, add constructor. * gdbarch.h: Re-generate. * arch-utils.h (gdbarch_info_init): Remove, delete all usages. * arch-utils.c (gdbarch_info_init): Remove. Change-Id: I7502e08fe0f278d84eef1667a072e8a97bda5ab5
2021-06-28gdb: remove gdbarch_info::tdep_infoSimon Marchi4-14/+6
This field is not actually used, remove it. gdb/ChangeLog: * gdbarch.sh (struct gdbarch_info) <tdep_info>: Remove. (gdbarch_find_by_info): Remove print. * gdbarch.c, gdbarch.h: Re-generate. Change-Id: I00af4681b8e1a27727441cbadc3827f5914bd8eb
2021-06-28gdb/remote: Use true/false instead of 1/0Andrew Burgess2-4/+9
The remote_state::starting_up member variable is already of type bool, but in some places we still write to it using 1 and 0. This commit just updates things to use true and false. There should be no user visible change after this commit. gdb/ChangeLog: * remote.c (remote_target::start_remote): Set 'starting_up' using boolean values instead of integers.
2021-06-28gdb/fortran: Add type info of formal parameter for clang.Bhuvanendra Kumar N1-7/+29
Additional compiler generated formal parameter exist with clang and type information for the same is added accordingly. Also few kind parameter printing are removed which is not default for clang. Note: More details about this kind parameter omission while printing can be found with similar patch commit 0a709cba00d36d490482d0e8673e323ac1e897a6 Author Alok Kumar Sharma (alokkumar.sharma@amd.com) gdb/testsuite/ChangeLog: * gdb.fortran/ptype-on-functions.exp: Add type info of formal parameter for clang. Also removed the kind parameter for clang.
2021-06-25gdb/guile: use return values of add_setshow functions in add_setshow_genericSimon Marchi2-88/+76
Use the set_show_commands objects returned by the add_setshow functions in add_setshow_generic. This lets us avoid looking up the commands after creating them, instead using the return objects directly. Make add_setshow_generic return a set_show_commands object, which is a bit nicer than returning both commands by parameter. Finally, store using that object in param_smob. Equivalent of 7bd22f56a3cf ("gdb/python: use return values of add_setshow functions in add_setshow_generic"), but for guile. gdb/ChangeLog: * guile/scm-param.c (struct param_smob) <set_command, show_command>: Remove. <commands>: New. (pascm_is_valid): Adjust. (add_setshow_generic): Use return values of add_setshow functions, return a set_show_commands. (gdbscm_register_parameter_x): Adjust. Change-Id: I18ed9e7dd5646529491c86749a5cb20763acd1f0
2021-06-25gdb: remove context parameter from add_setshow_enum_cmdSimon Marchi4-31/+48
I propose removing the context parameter from add_setshow_enum_cmd. It was useful before add_setshow_enum_cmd returned both created commands, as the caller couldn't easily set the context itself. But now, I think it's fine to just let the caller do it. gdb/ChangeLog: * command.h (add_setshow_enum_cmd): Remove context parameter. * cli/cli-decode.c (add_setshow_enum_cmd): Likewise, and don't set context. * cli/cli-style.c (cli_style_option::add_setshow_commands): Set context here. Change-Id: I377c4e6820ec9d5069492ed28f4cba342ce1336e
2021-06-25gdb: add assert in cmd_list_element::set_contextSimon Marchi2-1/+9
If something tries to set a context pointer on a cmd_list_element and m_context is not nullptr, it's likely that two parts of the code are trying to set different contexts, and one will overwrite the other. This is almost guaranteed to lead to bad behavior or a crash, as one of the spots will not be using the data it expects. This happened to me during development, so I think having this assert would be useful to catch this problem earlier. gdb/ChangeLog: * cli/cli-decode.h (struct cmd_list_element) <set_context>: Add assert. Change-Id: I1f2e9fda1bf2bec1b732c9b90e7d7910a97f2ac6
2021-06-25gdb: add context getter/setter to cmd_list_elementSimon Marchi17-62/+69
Straightforward replacement of get_cmd_context / set_cmd_context with cmd_list_element methods. gdb/ChangeLog: * cli/cli-decode.h (struct cmd_list_element) <set_context, context>: New. <context>: Rename to... <m_context>: ... this. * cli/cli-decode.c (set_cmd_context, get_cmd_context): Remove. * command.h (set_cmd_context, get_cmd_context): Remove, use cmd_list_element::set_context and cmd_list_element::context everywhere instead. Change-Id: I5016b0079014e3f17d1aa449ada7954473bf2b5d
2021-06-25gdb: change info sources to group results by objfileAndrew Burgess11-81/+342
Currently the 'info sources' command lists all of the known source files together, regardless of their source, e.g. here is a session debugging a test application that makes use of a shared library: (gdb) info sources Source files for which symbols have been read in: /tmp/info-sources/test.c, /usr/include/stdc-predef.h, /tmp/info-sources/header.h, /tmp/info-sources/helper.c Source files for which symbols will be read in on demand: (gdb) In this commit I change the format of the 'info sources' results so that the results are grouped by the object file that uses that source file. Here's the same session with the new output format: (gdb) info sources /tmp/info-sources/test.x: /tmp/info-sources/test.c, /usr/include/stdc-predef.h, /tmp/info-sources/header.h /lib64/ld-linux-x86-64.so.2: (Objfile has no debug information.) system-supplied DSO at 0x7ffff7fcf000: (Objfile has no debug information.) /tmp/info-sources/libhelper.so: /tmp/info-sources/helper.c, /usr/include/stdc-predef.h, /tmp/info-sources/header.h /lib64/libc.so.6: (Objfile has no debug information.) (gdb) Notice that in the new output some source files are repeated, e.g. /tmp/info-sources/header.h, as multiple objfiles use this source file. Further, some object files are tagged with the message '(Objfile has no debug information.)', it is also possible to see the message '(Full debug information has not yet been read for this file.)', which is printed when some symtabs within an objfile have not yet been expanded. All of the existing regular expression based filtering still works. An original version of this patch added the new format as an option to 'info sources', however, it was felt that the new layout was so much better than the old style that GDB should just switch to the new result format completely. gdb/ChangeLog: * NEWS: Mention changes to 'info sources'. * symtab.c (info_sources_filter::print): Delete. (struct output_source_filename_data) <print_header>: Delete declaration. <printed_filename_p>: New member function. (output_source_filename_data::print_header): Delete. (info_sources_worker): Update group-by-objfile style output to make it CLI suitable, simplify non-group-by-objfile now this is only used from the MI. (info_sources_command): Make group-by-objfile be the default for CLI info sources command. * symtab.h (struct info_sources_filter) <print>: Delete. gdb/doc/ChangeLog: * gdb.texinfo (Symbols): Document new output format for 'info sources'. gdb/testsuite/ChangeLog: * gdb.base/info_sources_2-header.h: New file. * gdb.base/info_sources_2-lib.c: New file. * gdb.base/info_sources_2-test.c: New file. * gdb.base/info_sources_2.exp: New file.
2021-06-25gdb/mi: add new --group-by-objfile flag for -file-list-exec-source-filesAndrew Burgess9-13/+192
This commit adds a new option '--group-by-objfile' to the MI command -file-list-exec-source-files. With this option the output format is changed; instead of a single list of source files the results are now a list of objfiles. For each objfile all of the source files associated with that objfile are listed. Here is an example of the new output format taken from the documentation (the newlines are added just for readability): -file-list-exec-source-files --group-by-objfile ^done,files=[{filename="/tmp/info-sources/test.x", debug-info="fully-read", sources=[{file="test.c", fullname="/tmp/info-sources/test.c", debug-fully-read="true"}, {file="/usr/include/stdc-predef.h", fullname="/usr/include/stdc-predef.h", debug-fully-read="true"}, {file="header.h", fullname="/tmp/info-sources/header.h", debug-fully-read="true"}]}, {filename="/lib64/ld-linux-x86-64.so.2", debug-info="none", sources=[]}, {filename="system-supplied DSO at 0x7ffff7fcf000", debug-info="none", sources=[]}, {filename="/tmp/info-sources/libhelper.so", debug-info="fully-read", sources=[{file="helper.c", fullname="/tmp/info-sources/helper.c", debug-fully-read="true"}, {file="/usr/include/stdc-predef.h", fullname="/usr/include/stdc-predef.h", debug-fully-read="true"}, {file="header.h", fullname="/tmp/info-sources/header.h", debug-fully-read="true"}]}, {filename="/lib64/libc.so.6", debug-info="none", sources=[]}] In the above output the 'debug-info' field associated with each objfile will have one of the values 'none', 'partially-read', or 'fully-read'. For example, /lib64/libc.so.6 has the value 'none', this indicates that this object file has no debug information associated with it, unsurprisingly then, the sources list of this object file is empty. An object file that was compiled with debug, for example /tmp/info-sources/libhelper.so, has the value 'fully-read' above indicating that this object file does have debug information, and the information is fully read into GDB. At different times this field might have the value 'partially-read' indicating that that the object file has debug information, but it has not been fully read into GDB yet. Source files can appear at most once for any single objfile, but can appear multiple times in total, if the same source file is part of multiple objfiles, for example /tmp/info-sources/header.h in the above output. The new output format is hidden behind a command option to ensure that the default output is unchanged, this ensures backward compatibility. The behaviour of the CLI "info sources" command is unchanged after this commit. gdb/ChangeLog: * NEWS: Mention additions to -file-list-exec-source-files. * mi/mi-cmd-file.c (mi_cmd_file_list_exec_source_files): Add --group-by-objfile option. * symtab.c (isrc_flag_option_def): Rename to... (isrc_match_flag_option_def): ...this. (info_sources_option_defs): Rename to... (info_sources_match_option_defs): ...this, and update to rename of isrc_flag_option_def. (struct filename_grouping_opts): New struct. (isrc_grouping_flag_option_def): New type. (info_sources_grouping_option_defs): New static global. (make_info_sources_options_def_group): Update to return two option groups. (info_sources_command_completer): Update for changes to make_info_sources_options_def_group. (info_sources_worker): Add extra parameter, use this to display alternative output format. (info_sources_command): Pass extra parameter to info_sources_worker. (_initialize_symtab): Update for changes to make_info_sources_options_def_group. * symtab.h (info_sources_worker): Add extra parameter. gdb/doc/ChangeLog: * gdb.texinfo (GDB/MI File Commands): Document --group-by-objfile extension for -file-list-exec-source-files. gdb/testsuite/ChangeLog: * gdb.mi/mi-info-sources.exp: Add additional tests.
2021-06-25gdb/mi: add regexp filtering to -file-list-exec-source-filesAndrew Burgess13-149/+521
This commit extends the existing MI command -file-list-exec-source-files to provide the same regular expression based filtering that the equivalent CLI command "info sources" provides. The new command syntax is: -file-list-exec-source-files [--basename | --dirname] [--] [REGEXP] All options are optional, which ensures the command is backward compatible. As part of this work I have unified the CLI and MI code. As a result of the unified code I now provide additional information in the MI command output, there is now a new field 'debug-fully-read' included with each source file. This field which has the values 'true' or 'false', indicates if the source file is from a compilation unit that has had its debug information fully read. However, as this is additional information, a well written front-end should just ignore this field if it doesn't understand it, so things should still be backward compatible. gdb/ChangeLog: * NEWS: Mention additions to -file-list-exec-source-files. * mi/mi-cmd-file.c (print_partial_file_name): Delete. (mi_cmd_file_list_exec_source_files): Rewrite to handle command options, and make use of info_sources_worker. * symtab.c (struct info_sources_filter): Moved to symtab.h. (info_sources_filter::print): Take uiout argument, produce output through uiout. (struct output_source_filename_data) <output_source_filename_data>: Take uiout argument, store into m_uiout. <output>: Rewrite comment, add additional arguments to declaration. <operator()>: Send more arguments to output. <m_uiout>: New member variable. (output_source_filename_data::output): Take extra arguments, produce output through m_uiout, and structure for MI. (output_source_filename_data::print_header): Produce output through m_uiout. (info_sources_worker): New function, the implementation is taken from info_sources_command, but modified so produce output through a ui_out. (info_sources_command): The second half of this function has gone to become info_sources_worker. * symtab.h (struct info_sources_filter): Moved from symtab.c, add extra parameter to print member function. (info_sources_worker): Declare. gdb/doc/ChangeLog: * gdb.texinfo (GDB/MI File Commands): Document extensions to -file-list-exec-source-files. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-filename.exp: Update expected results. * gdb.mi/mi-file.exp: Likewise. * gdb.mi/mi-info-sources-base.c: New file. * gdb.mi/mi-info-sources.c: New file. * gdb.mi/mi-info-sources.exp: New file.
2021-06-25gdb: make struct output_source_filename_data more C++ likeAndrew Burgess2-106/+247
In a future commit I'm going to be making some changes to the 'info sources' command. While looking at the code I noticed that things could be improved by making struct output_source_filename_data more C++ like (private member variables, and more member functions). That's what this commit does. The 'info sources' filename filtering is split out into a separate class in this commit. In a future commit this new filter class (info_sources_filter) will move into the header file and be used from the MI code. There should be no user visible changes after this commit. gdb/ChangeLog: * symtab.c (struct info_sources_filter): New. (info_sources_filter::info_sources_filter): New function. (info_sources_filter::matches): New function. (info_sources_filter::print): New function. (struct filename_partial_match_opts): Moved to later in the file and update the comment. (struct output_source_filename_data) <output_source_filename_data>: New constructor. <regexp>: Delete, this is now in info_sources_filter. <c_regexp>: Delete, this is now in info_sources_filter. <reset_output>: New member function. <filename_seen_cache>: Rename to m_filename_seen_cache, change from being a pointer, to being an actual object. <first>: Rename to m_first. <print_header>: New member function. <partial_match>: Delete. (output_source_filename_data::output): Update now m_filename_seen_cache is no longer a pointer, and for other member variable name changes. Add a header comment. (print_info_sources_header): Renamed to... (output_source_filename_data::print_header): ...this. Update now it's a member function and to take account of member variable renaming. (info_sources_command): Add a header comment, delete stack local filename_seen_cache, initialization of output_source_filename_data is now done by the constructor. Call print_header member function instead of print_info_sources_header, call reset_output member function instead of manually performing the reset.
2021-06-25gdb: add new function quick_symbol_functions::has_unexpanded_symbolsAndrew Burgess7-0/+95
Adds a new function to the quick_symbol_functions API to let us know if there are any unexpanded symbols. This functionality is required by a later commit. After this commit the functionality is unused, and untested. The new function objfile::has_unexpanded_symtabs is added to the symfile-debug.c file which is a little strange, but this is (currently) where many of the other objfile::* functions (that call onto the quick_symbol_functions) are defined, so I'm reluctant to break this pattern. There should be no user visible changes after this commit. gdb/ChangeLog: * dwarf2/read.c (struct dwarf2_base_index_functions) <has_unexpanded_symtabs>: Declare. (dwarf2_base_index_functions::has_unexpanded_symtabs): Define new function. * objfiles.h (struct objfile) <has_unexpanded_symtabs>: Declare. * psympriv.h (struct psymbol_functions) <has_unexpanded_symtabs>: Declare. * psymtab.c (psymbol_functions::has_unexpanded_symtabs): Define new function. * quick-symbol.h (struct quick_symbol_functions) <has_unexpanded_symtabs>: Declare. * symfile-debug.c (objfile::has_unexpanded_symtabs): Define new function.
2021-06-25gdb: fix invalid arg coercion when calling static member functionsAndrew Burgess5-2/+28
In this commit: commit 7022349d5c86bae74b49225515f42d2e221bd368 Date: Mon Sep 4 20:21:13 2017 +0100 Stop assuming no-debug-info functions return int A new if case was added to call_function_by_hand_dummy to decide if a function should be considered prototyped or not. Previously the code was structured like this: if (COND_1) ACTION_1 else if (COND_2) ACTION_2 else ACTION_3 With the new block the code now looks like this: if (COND_1) ACTION_1 if (NEW_COND) NEW_ACTION else if (COND_2) ACTION_2 else ACTION_3 Notice the new block was added as and 'if' not 'else if'. I'm running into a case where GDB executes ACTION_1 and then ACTION_2. Prior to the above commit GDB would only have executed ACTION_1. The actions in the code in question are trying to figure out if a function should be considered prototyped or not. When a function is not prototyped some arguments will be coerced, e.g. floats to doubles. The COND_1 / ACTION_1 are a very broad, any member function should be considered prototyped, however, after the above patch GDB is now executing the later ACTION_2 which checks to see if the function's type has the 'prototyped' flag set - this is not the case for the member functions I'm testing, and so GDB treats the function as unprototyped and casts the float argument to a double. I believe that adding the new check as 'if' rather than 'else if' was a mistake, and so in this commit I add in the missing 'else'. gdb/ChangeLog: * infcall.c (call_function_by_hand_dummy): Add missing 'else' when setting prototyped flag. gdb/testsuite/ChangeLog: * gdb.cp/method-call-in-c.cc (struct foo_type): Add static member function static_method. (global_var): New global. (main): Use new static_method to ensure it is compiled in. * gdb.cp/method-call-in-c.exp: Test calls to static member function.
2021-06-25gdb: use gdb::optional instead of passing a pointer to gdb::array_viewAndrew Burgess12-34/+65
Following on from the previous commit, this commit changes the API of value_struct_elt to take gdb::optional<gdb::array_view<value *>> instead of a pointer to the gdb::array_view. This makes the optional nature of the array_view parameter explicit. This commit is purely a refactoring commit, there should be no user visible change after this commit. I have deliberately kept this refactor separate from the previous two commits as this is a more extensive change, and I'm not 100% sure that using gdb::optional for the parameter type, instead of a pointer, is going to be to everyone's taste. If there's push back on this patch then this one can be dropped from the series. gdb/ChangeLog: * ada-lang.c (desc_bounds): Use '{}' instead of NULL to indicate an empty gdb::optional when calling value_struct_elt. (desc_data): Likewise. (desc_one_bound): Likewise. * eval.c (structop_base_operation::evaluate_funcall): Pass gdb::array_view, not a gdb::array_view* to value_struct_elt. (eval_op_structop_struct): Use '{}' instead of NULL to indicate an empty gdb::optional when calling value_struct_elt. (eval_op_structop_ptr): Likewise. * f-lang.c (fortran_structop_operation::evaluate): Likewise. * guile/scm-value.c (gdbscm_value_field): Likewise. * m2-lang.c (eval_op_m2_high): Likewise. (eval_op_m2_subscript): Likewise. * opencl-lang.c (opencl_structop_operation::evaluate): Likewise. * python/py-value.c (valpy_getitem): Likewise. * rust-lang.c (rust_val_print_str): Likewise. (rust_range): Likewise. (rust_subscript): Likewise. (eval_op_rust_structop): Likewise. (rust_aggregate_operation::evaluate): Likewise. * valarith.c (value_user_defined_op): Likewise. * valops.c (search_struct_method): Change parameter type, update function body accordingly, and update header comment. (value_struct_elt): Change parameter type, update function body accordingly. * value.h (value_struct_elt): Update declaration.
2021-06-25gdb: replace NULL terminated array with array_viewAndrew Burgess8-45/+70
After the previous commit, this commit updates the value_struct_elt function to take an array_view rather than a NULL terminated array of values. The requirement for a NULL terminated array of values actually stems from typecmp, so the change from an array to array_view needs to be propagated through to this function. While making this change I noticed that this fixes another bug, in value_x_binop and value_x_unop GDB creates an array of values which doesn't have a NULL at the end. An array_view of this array is passed to value_user_defined_op, which then unpacks the array_view and passed the raw array to value_struct_elt, but only if the language is not C++. As value_x_binop and value_x_unop can only request member functions with the names of C++ operators, then most of the time, assuming the inferior is not a C++ program, then GDB will not find a matching member function with the call to value_struct_elt, and so typecmp will never be called, and so, GDB will avoid undefined behaviour. However, it is worth remembering that, when GDB's language is set to "auto", the current language is selected based on the language of the current compilation unit. As C++ programs usually link against libc, which is written in C, then, if the inferior is stopped in libc GDB will set the language to C. And so, it is possible that we will end up using value_struct_elt to try and lookup, and match, a C++ operator. If this occurs then GDB will experience undefined behaviour. I have extended the test added in the previous commit to also cover this case. Finally, this commit changes the API from passing around a pointer to an array to passing around a pointer to an array_view. The reason for this is that we need to be able to distinguish between the cases where we call value_struct_elt with no arguments, i.e. we are looking up a struct member, but we either don't have the arguments we want to pass yet, or we don't expect there to be any need for GDB to use the argument types to resolve any overloading; and the second case where we call value_struct_elt looking for a function that takes no arguments, that is, the argument list is empty. NOTE: While writing this I realise that if we pass an array_view at all then it will always have at least one item in it, the `this' pointer for the object we are planning to call the method on. So we could, I guess, pass an empty array_view to indicate the case where we don't know anything about the arguments, and when the array_view is length 1 or more, it means we do have the arguments. However, though we could do this, I don't think this would be better, the length 0 vs length 1 difference seems a little too subtle, I think that there's a better solution... I think a better solution would be to wrap the array_view in a gdb::optional, this would make the whole, do we have an array view or not question explicit. I haven't done this as part of this commit as making that change is much more extensive, every user of value_struct_elt will need to be updated, and as this commit already contains a bug fix, I wanted to keep the large refactoring in a separate commit, so, check out the next commit for the use of gdb::optional. gdb/ChangeLog: PR gdb/27994 * eval.c (structop_base_operation::evaluate_funcall): Pass array_view instead of array to value_struct_elt. * valarith.c (value_user_defined_op): Likewise. * valops.c (typecmp): Change parameter type from array pointer to array_view. Update header comment, and update body accordingly. (search_struct_method): Likewise. (value_struct_elt): Likewise. * value.h (value_struct_elt): Update declaration. gdb/testsuite/ChangeLog: PR gdb/27994 * gdb.cp/method-call-in-c.cc (struct foo_type): Add operator+=, change initial value of var member variable. (main): Make use of foo_type's operator+=. * gdb.cp/method-call-in-c.exp: Test use of operator+=.
2021-06-25gdb: fix regression in evaluate_funcall for non C++ like casesAndrew Burgess6-4/+121
This regression, as it is exposed by the test added in this commit, first became noticable with this commit: commit d182f2797922a305fbd1ef6a483cc39a56b43e02 Date: Mon Mar 8 07:27:57 2021 -0700 Convert c-exp.y to use operations But, this commit only added converted the C expression parser to make use of code that was added in this commit: commit a00b7254fb614af557de7ae7cc0eb39a0ce0e408 Date: Mon Mar 8 07:27:57 2021 -0700 Implement function call operations And it was this second commit that actually introduced the bugs (there are two). In structop_base_operation::evaluate_funcall we build up an argument list in the vector vals. Later in this function the argument list might be passed to value_struct_elt. Prior to commit a00b7254fb614 the vals vector (or argvec as it used to be called) stored the value for the function callee in the argvec at index 0. This 'callee' value is what ends up being passed to evaluate_subexp_do_call, and represents the function to be called, the value contents are the address of the function, and the value type is the function signature. The remaining items held in the argvec were the values to pass to the function. For a non-static member function the `this' pointer would be at index 1 in the array. After commit a00b7254fb614 this callee value is now held in a separate variable, not the vals array. So, for non-static member functions, the `this' pointer is now at index 0, with any other arguments after that. What this means is that previous, when we called value_struct_elt we would pass the address of argvec[1] as this was the first argument. But now we should be passing the address of vals[0]. Unfortunately, we are still passing vals[1], effectively skipping the first argument. The second issue is that, prior to commit a00b7254fb614, the argvec array was NULL terminated. This is required as value_struct_elt calls search_struct_method, which calls typecmp, and typecmp requires that the array have a NULL at the end. After commit a00b7254fb614 this NULL has been lost, and we are therefore violating the API requirements of typecmp. This commit fixes both of these regressions. I also extended the header comments on search_struct_method and value_struct_elt to make it clearer that the array required a NULL marker at the end. You will notice in the test attached to this commit that I test calling a non-static member function, but not calling a static member function. The reason for this is that calling static member functions is currently broken due to a different bug. That will be fixed in a later patch in this series, at which time I'll add a test for calling a static member function. gdb/ChangeLog: PR gdb/27994 * eval.c (structop_base_operation::evaluate_funcall): Add a nullptr to the end of the args array, which should not be included in the argument array_view. Pass all the arguments through to value_struct_elt. * valops.c (search_struct_method): Update header comment. (value_struct_elt): Likewise. gdb/testsuite/ChangeLog: PR gdb/27994 * gdb.cp/method-call-in-c.cc: New file. * gdb.cp/method-call-in-c.exp: New file.
2021-06-25Change how .debug_aranges padding is skippedTom Tromey6-16/+93
When GCC emits .debug_aranges, it adds padding to align the contents to two times the address size. GCC has done this for many years -- but there is nothing in the DWARF standard that says this should be done, and LLVM does not seem to add this padding. It's simple to detect if the padding exists, though: if the contents of one .debug_aranges CU (excluding the header) are not a multiple of the alignment that GCC uses, then anything extra must be padding. This patch changes gdb to correctly read both styles. It removes the requirement that the padding bytes be zero, as this seemed unnecessarily pedantic to me. gdb/ChangeLog 2021-06-25 Tom Tromey <tom@tromey.com> * dwarf2/read.c (create_addrmap_from_aranges): Change padding logic. gdb/testsuite/ChangeLog 2021-06-25 Tom Tromey <tom@tromey.com> * lib/gdb.exp (add_gdb_index, ensure_gdb_index): Add "style" parameter. * gdb.rust/dwindex.exp: New file. * gdb.rust/dwindex.rs: New file.
2021-06-25Remove dwarf2_cu::languageTom Tromey4-148/+176
dwarf2_cu has a 'language' value, but dwarf2_per_cu_data also holds a value of this same type. There doesn't seem to be any reason to keep two copies of this value. This patch removes the field from dwarf2_cu, and arranges to set the value in the per-CU object instead. Note that the value must still be set when expanding the full CU. This is needed because the CUs will not be scanned when a DWARF index is in use. gdb/ChangeLog 2021-06-25 Tom Tromey <tom@tromey.com> * dwarf2/read.c (process_psymtab_comp_unit): Don't set 'lang'. (scan_partial_symbols, partial_die_parent_scope) (add_partial_symbol, add_partial_subprogram) (compute_delayed_physnames, rust_union_quirks) (process_full_comp_unit, process_full_type_unit) (process_imported_unit_die, process_die, dw2_linkage_name) (dwarf2_compute_name, dwarf2_physname, read_import_statement) (read_file_scope, queue_and_load_dwo_tu, read_func_scope) (read_variable, dwarf2_get_subprogram_pc_bounds) (dwarf2_attach_fields_to_type, dwarf2_add_member_fn) (dwarf2_attach_fn_fields_to_type) (quirk_ada_thick_pointer_struct, read_structure_type) (handle_struct_member_die, process_structure_scope) (read_array_type, read_array_order, prototyped_function_p) (read_subroutine_type, dwarf2_init_complex_target_type) (read_base_type, read_subrange_type, read_unspecified_type) (load_partial_dies, partial_die_info::fixup, set_cu_language) (new_symbol, need_gnat_info, determine_prefix, typename_concat) (dwarf2_canonicalize_name, follow_die_offset) (prepare_one_comp_unit): Update. * dwarf2/cu.c (dwarf2_cu::start_symtab): Update.
2021-06-25Consolidate CU language settingTom Tromey2-34/+48
The DWARF reader currently sets the CU's language in two different spots. It is primarily done in prepare_one_comp_unit, but read_file_scope also checks the producer and may change the language based on the result. This patch consolidates all language-setting into prepare_one_comp_unit. set_cu_language is renamed and changed not to set language_defn; instead that is done in prepare_one_comp_unit after the correct language enum value is chosen. This fixes a minor latent bug, which is that read_file_scope could set the language enum value to language_opencl, but then neglected to reset language_defn in this case. gdb/ChangeLog 2021-06-25 Tom Tromey <tom@tromey.com> * dwarf2/read.c (read_file_scope): Don't call set_cu_language. (dwarf_lang_to_enum_language): Rename from set_cu_language. Don't set language_defn. Handle DW_LANG_OpenCL. (prepare_one_comp_unit): Check producer and set language_defn.
2021-06-25gdb/python: allow for catchpoint type breakpoints in pythonAndrew Burgess8-1/+108
This commit adds initial support for catchpoints to the python breakpoint API. This commit adds a BP_CATCHPOINT constant which corresponds to GDB's internal bp_catchpoint. The new constant is documented in the manual. The user can't create breakpoints with type BP_CATCHPOINT after this commit, but breakpoints that already exist, obtained with the `gdb.breakpoints` function, can now have this type. Additionally, when a stop event is reported for hitting a catchpoint, GDB will now report a BreakpointEvent with the attached breakpoint being of type BP_CATCHPOINT - previously GDB would report a generic StopEvent in this situation. gdb/ChangeLog: * NEWS: Mention Python BP_CATCHPOINT feature. * python/py-breakpoint.c (pybp_codes): Add bp_catchpoint support. (bppy_init): Likewise. (gdbpy_breakpoint_created): Likewise. gdb/doc/ChangeLog: * python.texinfo (Breakpoints In Python): Add BP_CATCHPOINT description. gdb/testsuite/ChangeLog: * gdb.python/py-breakpoint.c (do_throw): New function. (main): Call do_throw. * gdb.python/py-breakpoint.exp (test_catchpoints): New proc.
2021-06-25gdb/guile: allow for catchpoint type breakpoints in guileAndrew Burgess6-1/+63
This commit adds initial support for catchpoints to the guile breakpoint API. This commit adds a BP_CATCHPOINT constant which corresponds to GDB's internal bp_catchpoint. The new constant is documented in the manual. The user can't create breakpoints with type BP_CATCHPOINT after this commit, but breakpoints that already exist, obtained with the (breakpoints) function, can now have this type. gdb/ChangeLog: * guile/scm-breakpoint.c (bpscm_type_to_string): Handle bp_catchpoint. (bpscm_want_scm_wrapper_p): Likewise. (gdbscm_make_breakpoint): Likewise. (breakpoint_integer_constants): Likewise. gdb/doc/ChangeLog: * guile.texinfo (Breakpoints In Guile): Add BP_CATCHPOINT description. gdb/testsuite/ChangeLog: * gdb.guile/scm-breakpoint.exp (test_catchpoints): New proc.
2021-06-25gdb/guile: improve the errors when creating breakpointsAndrew Burgess4-1/+29
When creating a breakpoint using the guile API, if an invalid breakpoint type number was used then the error would report the wrong argument position, like this: (gdb) guile (define wp2 (make-breakpoint "result" #:wp-class WP_WRITE #:type 999)) ERROR: In procedure make-breakpoint: ERROR: In procedure gdbscm_make_breakpoint: Out of range: invalid breakpoint type in position 3: 999 Error while executing Scheme code. (gdb) The 'position 3' here is actually pointing at WP_WRITE, when it should say 'position 5' and point to the 999. This commit fixes this. However, you also get errors like this: (gdb) guile (define wp2 (make-breakpoint "result" #:wp-class WP_WRITE #:type BP_NONE)) ERROR: In procedure make-breakpoint: ERROR: In procedure gdbscm_make_breakpoint: Out of range: invalid breakpoint type in position 3: 0 Error while executing Scheme code. The BP_NONE is a valid breakpoint type, it's just not valid for creating breakpoints through the 'make-breakpoint' API. The use of '0' in the error message (which is the value of BP_NONE) is not great. This commit changes the error in this case to: (gdb) guile (define wp2 (make-breakpoint "result" #:wp-class WP_WRITE #:type BP_NONE)) ERROR: In procedure make-breakpoint: ERROR: In procedure gdbscm_make_breakpoint: unsupported breakpoint type in position 5: "BP_NONE" Error while executing Scheme code. Which seems better; we now use the name of the type, and report that this type is unsupported. gdb/ChangeLog: * guile/scm-breakpoint.c (gdbscm_make_breakpoint): Split the error for invalid breakpoint numbers, and unsupported breakpoint numbers. gdb/testsuite/ChangeLog: * gdb.guile/scm-breakpoint.exp (test_watchpoints): Add new tests.
2021-06-25Add ISA 3.1 check to powerpc-plxv-norel.expCarl Love3-2/+55
This patch adds a file with the ISA 3.1 check. The ISA 3.1 check is added to the test to ensure the test is only run on ISA 3.1 or newer. gdb/testsuite/ChangeLog 2021-06-25 Carl Love <cel@us.ibm.com> * gdb.arch/powerpc-plxv-norel.exp: Add call to skip_power_isa_3_1_tests. * lib/gdb.exp(skip_power_isa_3_1_tests): New gdb_caching_proc test.
2021-06-25Use gdb::function_view in addrmap_foreachTom Tromey5-93/+86
While working on the DWARF psymtab replacement, I needed addrmap_foreach to accept a gdb::function_view. This seemed like a worthwhile change on its own, so I've written it separately for submission. Regression tested on x86-64 Fedora 32. gdb/ChangeLog 2021-06-25 Tom Tromey <tom@tromey.com> * dwarf2/index-write.c (struct addrmap_index_data): Add initializers. <operator()>: Declare. (addrmap_index_data::operator()): Rename from add_address_entry_worker. Remove 'datap' parameter. (write_address_map): Update. * psymtab.c (struct dump_psymtab_addrmap_data): Remove (dump_psymtab_addrmap_1): Remove 'data' parameter, add other parameters. (dump_psymtab_addrmap): Update. * addrmap.c (struct addrmap_funcs) <foreach>: Remove 'data' parameter. (addrmap_foreach, addrmap_fixed_foreach): Likewise. (struct mutable_foreach_data): Remove. (addrmap_mutable_foreach_worker): Update. (addrmap_mutable_foreach): Remove 'data' parameter. * addrmap.h (addrmap_foreach_fn): Use gdb::function_view. (addrmap_foreach): Remove 'data' parameter.
2021-06-25Decode Ada types in Python layerTom Tromey4-0/+22
GNAT emits encoded type names, but these aren't usually of interest to users. The Ada language code in gdb hides this oddity -- but the Python layer does not. This patch changes the Python code to use the decoded Ada type name, when appropriate. I looked at decoding Ada type names during construction, as that would be cleaner. However, the Ada support in gdb relies on the encodings at various points, so this isn't really doable right now. 2021-06-25 Tom Tromey <tromey@adacore.com> * python/py-type.c (typy_get_name): Decode an Ada type name. gdb/testsuite/ChangeLog 2021-06-25 Tom Tromey <tromey@adacore.com> * gdb.ada/py_range.exp: Add type name test cases.
2021-06-25Add non-wrapping mode to ada_decodeTom Tromey3-6/+16
When ada_decode encounters a name that it cannot decode, it simply wraps it in <...>, which is used elsewhere in the Ada code to indicate that a verbatim match should be done. A subequent patch needed the ability to suppress this wrapping, so this patch adds a new mode to ada_decode. 2021-06-25 Tom Tromey <tromey@adacore.com> * ada-lang.c (ada_decode): Add wrap parameter. * ada-lang.h (ada_decode): Add wrap parameter.
2021-06-25Update the core file architecture if a target description is presentLuis Machado2-0/+20
At the moment, the core target has its own gdbarch (m_core_gdbarch), and that gets set from the core_bfd on the core target's constructor. That gdbarch doesn't contain a target description because it is constructed before we get a chance to fetch the target description. As a result, some hooks that depend on the target description being set are not set, and that leads to problems. One of the examples is gdbarch_report_signal_info, which is used to show AArch64 tag violation information. Fix this by reading the target description before fetching the core file's gdbarch. gdb/ChangeLog: 2021-06-25 Luis Machado <luis.machado@linaro.org> * corelow.c (core_target::core_target) Update to read target description.
2021-06-24[gdb/testsuite] Fix duplicate in gdb.base/info-macros.expTom de Vries2-2/+9
When running test-case gdb.base/info-macros.exp, I run into: ... PASS: gdb.base/info-macros.exp: info macro -- PASS: gdb.base/info-macros.exp: info macro -- DUPLICATE: gdb.base/info-macros.exp: info macro -- PASS: gdb.base/info-macros.exp: info macro -- ... These messages come from gdb_test calls using the following commands: - "info macro --" - "info macro -- " - "info macro -- ". Apparantly the test names get stripped of trailing whitespace, and the first two end up identical. Fix this by explicitly specifying an <EOL> after the trailing whitespace in the test name, such that we have: ... PASS: gdb.base/info-macros.exp: info macro -- PASS: gdb.base/info-macros.exp: info macro -- <EOL> PASS: gdb.base/info-macros.exp: info macro -- <EOL> ... Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-06-24 Tom de Vries <tdevries@suse.de> * gdb.base/info-macros.exp: Add <EOL> after trailing whitespace in test names.
2021-06-24[gdb/testsuite] Fix duplicate in gdb.base/argv0-symlink.expTom de Vries2-55/+68
I found the following duplicates in gdb.base/argv0-symlink.exp: ... DUPLICATE: gdb.base/argv0-symlink.exp: set print repeats 10000 DUPLICATE: gdb.base/argv0-symlink.exp: set print elements 10000 ... Fix these by using with_test_prefix "file symlink" / "dir symlink". Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-06-24 Tom de Vries <tdevries@suse.de> * gdb.base/argv0-symlink.exp: Use with_test_prefix.
2021-06-23[gdb/testsuite] Rewrite gdb_test_linesTom de Vries5-80/+47
On Ubuntu 20.04, when the debug info package for libc is not installed, I get: FAIL: gdb.base/info-types-c++.exp: info types FAIL: gdb.base/info-types-c.exp: info types The reason is that the output of info types is exactly: (gdb) info types All defined types: File /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/info-types.c: 52: typedef enum {...} anon_enum_t; 45: typedef struct {...} anon_struct_t; 68: typedef union {...} anon_union_t; 28: typedef struct baz_t baz; 31: typedef struct baz_t * baz_ptr; 21: struct baz_t; double 33: enum enum_t; float int 38: typedef enum enum_t my_enum_t; 17: typedef float my_float_t; 16: typedef int my_int_t; 54: typedef enum {...} nested_anon_enum_t; 47: typedef struct {...} nested_anon_struct_t; 70: typedef union {...} nested_anon_union_t; 30: typedef struct baz_t nested_baz; 29: typedef struct baz_t nested_baz_t; 39: typedef enum enum_t nested_enum_t; 19: typedef float nested_float_t; 18: typedef int nested_int_t; 62: typedef union union_t nested_union_t; 56: union union_t; unsigned int (gdb) The lines we expect in the test contain an empty line at the end: ... "62:\[\t \]+typedef union union_t nested_union_t;" \ "56:\[\t \]+union union_t;" \ "--optional" "\[\t \]+unsigned int" \ ""] This is written with the supposition that other files will be listed, so an empty line will be included to separate the symbols from this file from the next one. This empty line is not included when info-types.c is the only file listed. Fix this by rewriting gdb_test_lines to accept a single, plain tcl multiline regexp, such that we can write: ... "62:\[\t \]+typedef union union_t nested_union_t;" \ "56:\[\t \]+union union_t;(" \ "\[\t \]+unsigned int)?" \ "($|\r\n.*)"] ... Tested affected test-cases: - gdb.base/info-types-c.exp - gdb.base/info-types-c++.exp - gdb.base/info-macros.exp - gdb.cp/cplusfuncs.exp on x86_64-linux (openSUSE Leap 15.2), both with check and check-read1. Also tested the first two with gcc-4.8. Also tested on ubuntu 18.04. gdb/testsuite/ChangeLog: 2021-06-23 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (gdb_test_lines): Rewrite to accept single multiline tcl regexp. * gdb.base/info-types.exp.tcl: Update. Make empty line at end of regexp optional. * gdb.base/info-macros.exp: Update. * gdb.cp/cplusfuncs.exp: Update.
2021-06-22gdb: fix python/lib/gdb/__init__.py formattingSimon Marchi2-3/+7
Run black to fix this formatting. gdb/ChangeLog: * python/lib/gdb/__init__.py: Format. Change-Id: I68ea306d1991bf7243b2c8aeeb11719d668851e5
2021-06-22gdb: remove unnecessary parameter wait_ptid from do_target_waitSimon Marchi2-7/+10
do_target_wait has a wait_ptid parameter, to filter what ptid we wait on. The sole caller of do_target_wait passes minus_one_ptid, meaning "all ptids". So in practice, this parameter is not needed, remove it. gdb/ChangeLog: * infrun.c (do_target_wait): Remove wait_ptid parameter. (fetch_inferior_event): Adjust. Change-Id: I54119beb43db678e4b2081dc490f89e7ff878e74
2021-06-22gdb/python: print name of unwinder that claimed frame in debug messageSimon Marchi3-11/+46
If we have multiple registered unwinders, this will helps identify which unwinder was chosen and make it easier to track down potential problems. Unwinders have a mandatory name argument, which we can use in the message. First, make gdb._execute_unwinders return a tuple containing the name, in addition to the UnwindInfo. Then, make pyuw_sniffer include the name in the debug message. I moved the debug message earlier. I think it's good to print it as early as possible, so that we see it in case an assert is hit in the loop below, for example. gdb/ChangeLog: * python/lib/gdb/__init__.py (_execute_unwinders): Return tuple with name of chosen unwinder. * python/py-unwind.c (pyuw_sniffer): Print name of chosen unwinder in debug message. Change-Id: Id603545b44a97df2a39dd1872fe1f38ad5059f03
2021-06-22gdb: Support DW_LLE_start_endAndreas Schwab6-1/+235
Without that it is impossible to debug on riscv64. gdb/ PR symtab/27999 * dwarf2/loc.c (decode_debug_loclists_addresses): Support DW_LLE_start_end. gdb/testsuite/ PR symtab/27999 * lib/dwarf.exp (start_end): New proc inside loclists. * gdb.dwarf2/loclists-start-end.exp: New file. * gdb.dwarf2/loclists-start-end.c: New file.
2021-06-22[gdb/testsuite] Add gdb.dwarf2/imported-unit-c.expTom de Vries2-0/+114
This test-case is intended to excercise this code in process_imported_unit_die: ... /* We're importing a C++ compilation unit with tag DW_TAG_compile_unit into another compilation unit, at root level. Regard this as a hint, and ignore it. */ if (die->parent && die->parent->parent == NULL && per_cu->unit_type == DW_UT_compile && per_cu->lang == language_cplus) return; ... in the sense that the test-case should fail if the "per_cu->lang == language_cplus" clause is removed. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-06-22 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/imported-unit-c.exp: New file.
2021-06-22gdb/remote: handle target dying just before a stepiAndrew Burgess4-14/+73
I randomly hit a situation where gdbserver crashed immediately before I issued a 'stepi' to GDB, it turns out that this causes GDB itself to crash. What happens is that as part of the stepi we try to insert some breakpoints into the inferior, so from insert_breakpoints we figure out what we want to insert, then, eventually, try to send some packets to the remote to get the breakpoints inserted. It is only at this point that GDB realises that the target has gone away. This causes GDB to then enter this call stack: unpush_and_perror remote_unpush_target generic_mourn_inferior breakpoint_init_inferior delete_breakpoint update_global_location_list So, we realise the target is gone and so delete the breakpoints associated with that target. GDB then throws a TARGET_CLOSE_ERROR from unpush_and_error. This error is caught in insert_breakpoints where we then try to print a nice error saying something like: Cannot insert breakpoint %d: some error text here... To fill in the '%d' we try to read properties of the breakpoint object. Which was deleted due to the delete_breakpoint call above. And so GDB dies... My proposal in this commit is that, should we catch a TARGET_CLOSE_ERROR in insert_breakpoints, then we just rethrow the error. This will cause the main event loop to print something like: Remote connection closed Which I think is fine, I don't think the user will care much which particular breakpoint GDB was operating on when the connection closed, just knowing that the connection closed should be enough I think. I initially added a test to 'gdb.server/server-kill.exp' for this issue, however, my first attempt was not good enough, the test was passing even without my fix. Turns out that the server-kill.exp test actually kills the PID of the inferior, not the PID of the server. This means that gdbserver is actually able to send a packet to GDB saying that the inferior has exited prior to gdbserver itself shutting down. This extra information was enough to prevent the bug I was seeing manifest. So, I have extended server-kill.exp to run all of the tests twice, the first time we still kill the inferior. On the second run we hard kill the gdbserver itself, this prevents the server from sending anything to GDB before it exits. My new test is only expected to fail in this second mode of operation (killing gdbserver itself), and without my fix, that is what I see. gdb/ChangeLog: * breakpoint.c (insert_bp_location): If we catch a TARGET_CLOSE_ERROR just rethrow it, the breakpoints might have been deleted. gdb/testsuite/ChangeLog: * gdb.server/server-kill.exp: Introduce global kill_pid_of, and make use of this in prepare to select which pid we should kill. Run all the tests twice with a different kill_pid_of value. (prepare): Make use of kill_pid_of. (test_stepi): New proc.
generated by cgit v1.1 at 2024-12-26 19:52:51 +0000