aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2016-10-28gdb: Import AX_CXX_COMPILE_STDCXX from the GNU Autoconf ArchivePedro Alves2-0/+566
This macro throws C++11 code at the compiler in order to check whether it supports C++11. final/override, rvalue references, static_assert, decltype, auto, constexpr, etc., and adds -std=gnu++11 to CXX if necessary. Nothing uses the macro yet. Simply adding it as separate preliminary step because we'll need local changes. gdb/ChangeLog 2016-10-28 Pedro Alves <palves@redhat.com> * ax_cxx_compile_stdcxx.m4: New file.
2016-10-28gdb/testsuite: Avoid a buffer overrun in `gdb.base/maint.exp'Pedro Alves2-3/+41
Fixes: PASS: gdb.base/maint.exp: maint w/o args ERROR: internal buffer is full. UNRESOLVED: gdb.base/maint.exp: maint info line-table w/o a file name The problem is just many symtabs and long line tables, enough to overflow the expect buffer. Fix this by matching input incrementally. gdb/testsuite/ChangeLog: 2016-10-28 Pedro Alves <palves@redhat.com> * gdb.base/maint.exp <maint info line-table w/o a file name>: Use gdb_test_multiple, tighten regexps and match symtabs and line tables incrementally.
2016-10-28Make gdb.base/foll-exec.exp test pattern more generalLuis Machado2-1/+6
Testing a powerpc toolchain running gdbserver on the other end i noticed a failure in gdb.base/foll-exec.exp. Turns out gdb is outputting a slightly different pattern due to the presence of debug information. -- foll-exec is about to execlp(execd-prog)...^M Continuing.^M process 21222 is executing new program: gdb.d/outputs/gdb.base/foll-exec/execd-prog^M ^M Catchpoint 2 (exec'd gdb.d/outputs/gdb.base/foll-exec/execd-prog), _start () at ../sysdeps/powerpc/powerpc32/dl-start.S:32^M -- Notice the presence of source file information. Now, on my local machine, i get this: -- foll-exec is about to execlp(execd-prog)...^M Continuing.^M process 9285 is executing new program: gdb/testsuite/outputs/gdb.base/foll-exec/execd-prog^M ^M Catchpoint 2 (exec'd gdb/testsuite/outputs/gdb.base/foll-exec/execd-prog), 0x00007ffff7dd7cc0 in ?? () from /lib64/ld-linux-x86-64.so.2^M -- So the output differs slightly and the testcase is actually expecting only the second form with the "in" anchor. This patch removes the "in" pattern and lets the test match both kinds of output. gdb/testsuite/ChangeLog: 2016-10-28 Luis Machado <lgustavo@codesourcery.com> * gdb.base/foll-exec.exp (do_exec_tests): Make test pattern more general.
2016-10-28Fix gdb.base/maint.exp regressionsPedro Alves2-0/+11
This commit fixes these regressions: FAIL: gdb.base/maint.exp: mt set per on for expand-symtabs FAIL: gdb.base/maint.exp: maint set per-command on caused by commit 1e3b796d58ac ("Change command stats reporting to use class"). gdb.log shows that the command stats are now printing garbage: (gdb) mt set per on Command execution time: -6.-419590 (cpu), 1467139648.-7706296840 (wall) Space used: 9809920 (-33276528 for this command) (gdb) FAIL: gdb.base/maint.exp: mt set per on for expand-symtabs while there should have been no output at all. The stats printing is done from within the scoped_command_stats's destructor, depending on whether some flags in the object are set. The problem is simply that scoped_command_stats's ctor misses clearing those flags on some paths. Since scoped_command_stats objects are allocated on the stack, whether you'll see the regression simply depends on whatever happens to already be on the stack space the object occupies. gdb/ChangeLog: 2016-10-28 Pedro Alves <palves@redhat.com> * maint.c (scoped_command_stats::scoped_command_stats): Clear m_space_enabled, m_time_enabled and m_symtab_enabled.
2016-10-28btrace: bridge gapsMarkus Metzger2-18/+425
Most of the time, the trace should be in one piece. This case is handled fine by GDB. In some cases, however, there may be gaps in the trace. They result from trace decode errors or from overflows. A gap in the trace means we lost an unknown amount of trace. Gaps can be very small, such as a few instructions in the same function, or they can be rather big. We may, for example, lose a few function calls or returns. The trace may continue in a different function and we likely don't know how we got there. Even though we can't say how the program executed across a gap, higher levels may not be impacted too much by it. Let's assume we have functions a-e and a trace that looks roughly like this: a \ b b \ / c <gap> c / d d \ / e Even though we can't say for sure, it is likely that b and c are the same function instance before and after the gap. This patch is trying to connect the c and b function segments across the gap. This will add a to the back trace of b on the right hand side. The changes are reflected in GDB's internal representation of the trace and will improve: - the output of "record function-call-history /c" - the output of "backtrace" in replay mode - source stepping in replay mode will be improved indirectly via the improved back trace I don't have an automated test for this patch; decode errors will be fixed and overflows occur sporadically and are quite rare. I tested it by hacking GDB to provoke a decode error and on the expected gap in the gdb.btrace/dlopen.exp test. The issue is that we can't predict where we will be able to re-sync in case of errors. For the expected decode error in gdb.btrace/dlopen.exp, for example, we may be able to re-sync somewhere in dlclose, in test, in main, or not at all. Here's one example run of gdb.btrace/dlopen.exp with and without this patch. (gdb) info record Active record target: record-btrace Recording format: Intel Processor Trace. Buffer size: 16kB. warning: Non-contiguous trace at instruction 66608 (offset = 0xa83, pc = 0xb7fdcc31). warning: Non-contiguous trace at instruction 66652 (offset = 0xa9b, pc = 0xb7fdcc31). warning: Non-contiguous trace at instruction 66770 (offset = 0xacb, pc = 0xb7fdcc31). warning: Non-contiguous trace at instruction 66966 (offset = 0xb60, pc = 0xb7ff5ee4). warning: Non-contiguous trace at instruction 66994 (offset = 0xb74, pc = 0xb7ff5f24). warning: Non-contiguous trace at instruction 67334 (offset = 0xbac, pc = 0xb7ff5e6d). warning: Non-contiguous trace at instruction 69022 (offset = 0xc04, pc = 0xb7ff60b3). warning: Non-contiguous trace at instruction 69116 (offset = 0xc1c, pc = 0xb7ff60b3). warning: Non-contiguous trace at instruction 69504 (offset = 0xc74, pc = 0xb7ff605d). warning: Non-contiguous trace at instruction 83648 (offset = 0xecc, pc = 0xb7ff6134). warning: Decode error (-13) at instruction 83876 (offset = 0xf48, pc = 0xb7fd6380): no memory mapped at this address. warning: Non-contiguous trace at instruction 83876 (offset = 0x11b7, pc = 0xb7ff1c70). Recorded 83948 instructions in 912 functions (12 gaps) for thread 1 (process 12996). (gdb) record instruction-history 83876, +2 83876 => 0xb7fec46f <call_init.part.0+95>: call *%eax [decode error (-13): no memory mapped at this address] [disabled] 83877 0xb7ff1c70 <_dl_close_worker.part.0+1584>: nop Without the patch, the trace is disconnected and the backtrace is short: (gdb) record goto 83876 #0 0xb7fec46f in call_init.part () from /lib/ld-linux.so.2 (gdb) backtrace #0 0xb7fec46f in call_init.part () from /lib/ld-linux.so.2 #1 0xb7fec5d0 in _dl_init () from /lib/ld-linux.so.2 #2 0xb7ff0fe3 in dl_open_worker () from /lib/ld-linux.so.2 Backtrace stopped: not enough registers or memory available to unwind further (gdb) record goto 83877 #0 0xb7ff1c70 in _dl_close_worker.part.0 () from /lib/ld-linux.so.2 (gdb) backtrace #0 0xb7ff1c70 in _dl_close_worker.part.0 () from /lib/ld-linux.so.2 #1 0xb7ff287a in _dl_close () from /lib/ld-linux.so.2 #2 0xb7fc3d5d in dlclose_doit () from /lib/libdl.so.2 #3 0xb7fec354 in _dl_catch_error () from /lib/ld-linux.so.2 #4 0xb7fc43dd in _dlerror_run () from /lib/libdl.so.2 #5 0xb7fc3d98 in dlclose () from /lib/libdl.so.2 #6 0x0804860a in test () #7 0x08048628 in main () With the patch, GDB is able to connect the trace pieces and we get a full backtrace. (gdb) record goto 83876 #0 0xb7fec46f in call_init.part () from /lib/ld-linux.so.2 (gdb) backtrace #0 0xb7fec46f in call_init.part () from /lib/ld-linux.so.2 #1 0xb7fec5d0 in _dl_init () from /lib/ld-linux.so.2 #2 0xb7ff0fe3 in dl_open_worker () from /lib/ld-linux.so.2 #3 0xb7fec354 in _dl_catch_error () from /lib/ld-linux.so.2 #4 0xb7ff02e2 in _dl_open () from /lib/ld-linux.so.2 #5 0xb7fc3c65 in dlopen_doit () from /lib/libdl.so.2 #6 0xb7fec354 in _dl_catch_error () from /lib/ld-linux.so.2 #7 0xb7fc43dd in _dlerror_run () from /lib/libdl.so.2 #8 0xb7fc3d0e in dlopen@@GLIBC_2.1 () from /lib/libdl.so.2 #9 0xb7ff28ee in _dl_runtime_resolve () from /lib/ld-linux.so.2 #10 0x0804841c in ?? () #11 0x08048470 in dlopen@plt () #12 0x080485a3 in test () #13 0x08048628 in main () (gdb) record goto 83877 #0 0xb7ff1c70 in _dl_close_worker.part.0 () from /lib/ld-linux.so.2 (gdb) backtrace #0 0xb7ff1c70 in _dl_close_worker.part.0 () from /lib/ld-linux.so.2 #1 0xb7ff287a in _dl_close () from /lib/ld-linux.so.2 #2 0xb7fc3d5d in dlclose_doit () from /lib/libdl.so.2 #3 0xb7fec354 in _dl_catch_error () from /lib/ld-linux.so.2 #4 0xb7fc43dd in _dlerror_run () from /lib/libdl.so.2 #5 0xb7fc3d98 in dlclose () from /lib/libdl.so.2 #6 0x0804860a in test () #7 0x08048628 in main () It worked nicely in this case but it may, of course, also lead to weird connections; it is a heuristic, after all. It works best when the gap is small and the trace pieces are long. gdb/ * btrace.c (bfun_s): New typedef. (ftrace_update_caller): Print caller in debug dump. (ftrace_get_caller, ftrace_match_backtrace, ftrace_fixup_level) (ftrace_compute_global_level_offset, ftrace_connect_bfun) (ftrace_connect_backtrace, ftrace_bridge_gap, btrace_bridge_gaps): New. (btrace_compute_ftrace_bts): Pass vector of gaps. Collect gaps. (btrace_compute_ftrace_pt): Likewise. (btrace_compute_ftrace): Split into this, ... (btrace_compute_ftrace_1): ... this, and ... (btrace_finalize_ftrace): ... this. Call btrace_bridge_gaps.
2016-10-28btrace: preserve function level for unexpected returnsMarkus Metzger2-9/+18
When encountering a return for which we have not seen a corresponding call, GDB starts a new back trace from level -1, i.e. from the level of the first function in the trace. In the presence of trace gaps, this may cause some rather big jump. (gdb) record function-call-history /c 192, +8 192 sbrk 193 brk 194 __x86.get_pc_thunk.bx 195 brk 196 __kernel_vsyscall 197 [disabled] 198 __kernel_vsyscall 199 brk 200 sbrk This doesn't help to make things more clear. Let's remain on the same level instead. (gdb) record function-call-history /c 192, +8 192 sbrk 193 brk 194 __x86.get_pc_thunk.bx 195 brk 196 __kernel_vsyscall 197 [disabled] 198 __kernel_vsyscall 199 brk 200 sbrk In this case it will look like we were able to connect the trace parts across the disabled gap. We were not. More work is required to achieve this. In the general case, the function-call history for the two trace parts won't match. They may be off by a few levels or they may be entirely different. All this patch does is to preserve the indentation level of the record function-call-history command. The disabled gap is caused by a sysenter not returning to the next instruction. (gdb) record function-call-history /i 196, +1 196 __kernel_vsyscall inst 66515,66519 (gdb) record instruction-history 66515 66515 0xb7fdcbf8 <__kernel_vsyscall+0>: push %ecx 66516 0xb7fdcbf9 <__kernel_vsyscall+1>: push %edx 66517 0xb7fdcbfa <__kernel_vsyscall+2>: push %ebp 66518 0xb7fdcbfb <__kernel_vsyscall+3>: mov %esp,%ebp 66519 0xb7fdcbfd <__kernel_vsyscall+5>: sysenter [disabled] 66520 0xb7fdcc08 <__kernel_vsyscall+16>: pop %ebp 66521 0xb7fdcc09 <__kernel_vsyscall+17>: pop %edx 66522 0xb7fdcc0a <__kernel_vsyscall+18>: pop %ecx 66523 0xb7fdcc0b <__kernel_vsyscall+19>: ret 66524 0xb7e8e09e <brk+30>: xchg %ecx,%ebx (gdb) disassemble 0xb7fdcbf8, 0xb7fdcc0c Dump of assembler code from 0xb7fdcbf8 to 0xb7fdcc0c: 0xb7fdcbf8 <__kernel_vsyscall+0>: push %ecx 0xb7fdcbf9 <__kernel_vsyscall+1>: push %edx 0xb7fdcbfa <__kernel_vsyscall+2>: push %ebp 0xb7fdcbfb <__kernel_vsyscall+3>: mov %esp,%ebp 0xb7fdcbfd <__kernel_vsyscall+5>: sysenter 0xb7fdcbff <__kernel_vsyscall+7>: nop 0xb7fdcc00 <__kernel_vsyscall+8>: nop 0xb7fdcc01 <__kernel_vsyscall+9>: nop 0xb7fdcc02 <__kernel_vsyscall+10>: nop 0xb7fdcc03 <__kernel_vsyscall+11>: nop 0xb7fdcc04 <__kernel_vsyscall+12>: nop 0xb7fdcc05 <__kernel_vsyscall+13>: nop 0xb7fdcc06 <__kernel_vsyscall+14>: int $0x80 0xb7fdcc08 <__kernel_vsyscall+16>: pop %ebp 0xb7fdcc09 <__kernel_vsyscall+17>: pop %edx 0xb7fdcc0a <__kernel_vsyscall+18>: pop %ecx 0xb7fdcc0b <__kernel_vsyscall+19>: ret End of assembler dump. I've seen this on 32-bit Fedora 23. I have not investigated what causes this and whether we can avoid the gap in the first place. Let's first try to make GDB handle such gaps more gracefully. gdb/ * btrace.c (ftrace_new_return): Start from the previous function's level if we can't find a matching call for a return.
2016-10-28btrace: update tail call heuristicMarkus Metzger2-2/+13
An unconditional jump to the start of a function typically indicates a tail call. If we can't determine the start of the function at the destination address, we used to treat it as a tail call, as well. This results in lots of tail calls for code for which we don't have symbol information. Restrict the heuristic to only consider jumps as tail calls that switch functions in the case where we can't determine the start of a function. This effectively disables tail call detection for code without symbol information. gdb/ * btrace.c (ftrace_update_function): Update tail call heuristic.
2016-10-28btrace: allow leading trace gapsMarkus Metzger3-31/+61
GDB ignores trace gaps from decode errors or overflows at the beginning of the trace. There isn't really a gap in the trace; the trace just starts a bit later than expected. In cases where there is no trace at all or where the trace is smaller than expected, this may hide the reason for the missing trace. Allow leading trace gaps. They will be shown as decode warnings and by the record function-call-history command. (gdb) info record Active record target: record-btrace Recording format: Intel Processor Trace. Buffer size: 16kB. warning: Decode error (-6) at instruction 0 (offset = 0x58, pc = 0x0): unexpected packet context. warning: Decode error (-6) at instruction 0 (offset = 0xb0, pc = 0x0): unexpected packet context. warning: Decode error (-6) at instruction 0 (offset = 0x168, pc = 0x0): unexpected packet context. warning: Decode error (-6) at instruction 54205 (offset = 0xe08, pc = 0x0): unexpected packet context. warning: Decode error (-6) at instruction 54205 (offset = 0xe60, pc = 0x0): unexpected packet context. warning: Decode error (-6) at instruction 54205 (offset = 0xed8, pc = 0x0): unexpected packet context. Recorded 91582 instructions in 1111 functions (6 gaps) for thread 1 (process 15710). (gdb) record function-call-history /c 1 1 [decode error (-6): unexpected packet context] 2 [decode error (-6): unexpected packet context] 3 [decode error (-6): unexpected packet context] 4 _dl_addr 5 ?? 6 _dl_addr 7 ?? 8 ?? 9 ?? 10 ?? Leading trace gaps will not be shown by the record instruction-history command without further changes. gdb/ * btrace.c (btrace_compute_ftrace_bts, ftrace_add_pt): Allow leading gaps. * record-btrace.c (record_btrace_single_step_forward) (record_btrace_single_step_backward): Jump back to last instruction if step ends at a gap. (record_btrace_goto_begin): Skip gaps.
2016-10-28btrace: fix gap indicationMarkus Metzger2-19/+43
Trace gaps due to overflows or non-contiguous trace are ignored in the 'info record' command. Fix that. Also add a warning when decoding the trace and print the instruction number preceding the trace gap in that warning message. It looks like this: (gdb) info record Active record target: record-btrace Recording format: Intel Processor Trace. Buffer size: 16kB. warning: Decode error (-13) at instruction 101044 (offset = 0x29f0, pc = 0x7ffff728a642): no memory mapped at this address. Recorded 101044 instructions in 2093 functions (1 gaps) for thread 1 (process 5360). (gdb) record instruction-history 101044 101044 0x00007ffff728a640: pop %r13 [decode error (-13): no memory mapped at this address] Remove the dead code that was supposed to print a gaps warning at the end of trace decode. This isn't really needed since we now print a warning for each gap. gdb/ * btrace.c (ftrace_add_pt): Fix gap indication. Add warning for non- contiguous trace and overflow. Rephrase trace decode warning and print instruction number. Remove dead gaps warning. (btrace_compute_ftrace_bts): Rephrase warnings and print instruction number.
2016-10-28Automatic date update in version.inGDB Administrator1-1/+1
2016-10-27Enable range stepping if software single step is supportedYao Qi2-0/+7
If the target can do software single step, it can do range stepping. gdb/gdbserver: 2016-10-27 Yao Qi <yao.qi@linaro.org> * linux-low.c (linux_supports_agent): Return true if can_software_single_step return true.
2016-10-27Get pending events in randomYao Qi4-2/+61
Nowadays, we select events to be reported to GDB in random, however that is not enough when many GDBserver internal events (not reported to GDB) are generated. GDBserver pulls all events out of kernel via waitpid, and leave them pending. When goes through threads which have pending events, GDBserver uses find_inferior to find the first thread which has pending event, and consumes it. Note that find_inferior always iterate threads in a fixed order. If multiple threads keep hitting GDBserver breakpoints, range stepping with single-step breakpoint for example, threads in the head of the thread list are more likely to be processed and threads in the tail are starved. This causes some timeout fails in gdb.threads/non-stop-fair-events.exp when range stepping is enabled on arm-linux. This patch fixes this issue by randomly selecting pending events. It adds a new function find_inferior_in_random, which iterates threads which have pending events randomly. gdb/gdbserver: 2016-10-27 Yao Qi <yao.qi@linaro.org> * inferiors.c (find_inferior_in_random): New function. * inferiors.h (find_inferior_in_random): Declare. * linux-low.c (linux_wait_for_event_filtered): Call find_inferior_in_random instead of find_inferior.
2016-10-27Remove single-step breakpoint for GDBserver internal eventYao Qi2-9/+28
This patch removes single-step breakpoints if the event is only GDBserver internal, IOW, isn't reported back to GDB. gdb/gdbserver: 2016-10-27 Yao Qi <yao.qi@linaro.org> * linux-low.c (linux_wait_1): If single-step breakpoints are inserted, remove them.
2016-10-27gas/arc: Don't rely on bfd list of cpu type for cpu selectionAndrew Burgess5-108/+135
In the ARC assembler, when a cpu type is specified using the .cpu directive, we rely on the bfd list of arc machine types in order to validate the cpu name passed in. This validation is only used in order to check that the cpu type passed to the .cpu directive matches any machine type selected earlier on the command line. Once that initial check has passed a full check is performed using the assemblers internal list of know cpu types. The problem is that the assembler knows about more cpu types than bfd, some cpu types known by the assembler are actually aliases for a base cpu type plus a specific set of assembler extensions. One such example is NPS400, though more could be added later. This commit removes the need for the assembler to use the bfd list of machine types for validation. Instead the error checking, to ensure that any value passed to a '.cpu' directive matches any earlier command line selection, is moved into the function arc_select_cpu. I have taken the opportunity to bundle the 4 separate static globals that describe the currently selected machine type into a single structure (called selected_cpu). gas/ChangeLog: * config/tc-arc.c (arc_target): Delete. (arc_target_name): Delete. (arc_features): Delete. (arc_mach_type): Delete. (mach_type_specified_p): Delete. (enum mach_selection_type): New enum. (mach_selection_mode): New static global. (selected_cpu): New static global. (arc_eflag): Rename to ... (arc_initial_eflag): ...this, and make const. (arc_select_cpu): Update comment, new parameter, check how previous machine type selection was made, and record this selection. Use selected_cpu instead of old globals. (arc_option): Remove use of arc_get_mach, instead use arc_select_cpu to validate machine type selection. Use selected_cpu over old globals. (allocate_tok): Use selected_cpu over old globals. (find_opcode_match): Likewise. (assemble_tokens): Likewise. (arc_cons_fix_new): Likewise. (arc_extinsn): Likewise. (arc_extcorereg): Likewise. (md_begin): Update default machine type selection, use selected_cpu over old globals. (md_parse_option): Update machine type selection option handling, use selected_cpu over old globals. * testsuite/gas/arc/nps400-0.s: Add .cpu directive. bfd/ChangeLog: * cpu-arc.c (arc_get_mach): Delete.
2016-10-27Automatic date update in version.inGDB Administrator1-1/+1
2016-10-26PR 20569, segv in follow_execSandra Loosemore14-119/+275
The following testcases make GDB crash whenever an invalid sysroot is provided, when GDB is unable to find a valid path to the symbol file: gdb.base/catch-syscall.exp gdb.base/execl-update-breakpoints.exp gdb.base/foll-exec-mode.exp gdb.base/foll-exec.exp gdb.base/foll-vfork.exp gdb.base/pie-execl.exp gdb.multi/bkpt-multi-exec.exp gdb.python/py-finish-breakpoint.exp gdb.threads/execl.exp gdb.threads/non-ldr-exc-1.exp gdb.threads/non-ldr-exc-2.exp gdb.threads/non-ldr-exc-3.exp gdb.threads/non-ldr-exc-4.exp gdb.threads/thread-execl.exp The immediate cause of the segv is that follow_exec is passing a NULL argument (the result of exec_file_find) to strlen. However, the problem is deeper than that: follow_exec simply isn't prepared for the case where sysroot translation fails to locate the new executable. Actually all callers of exec_file_find have bugs due to confusion between host and target pathnames. This commit attempts to fix all that. In terms of the testcases that were formerly segv'ing, GDB now prints a warning but continues execution of the new program, so that the tests now mostly FAIL instead. You could argue the FAILs are due to a legitimate problem with the test environment setting up the sysroot translation incorrectly. A new representative test is added which exercises the ne wwarning code path even with native testing. Tested on x86_64 Fedora 23, native and gdbserver. gdb/ChangeLog: 2016-10-25 Sandra Loosemore <sandra@codesourcery.com> Luis Machado <lgustavo@codesourcery.com> Pedro Alves <palves@redhat.com> PR gdb/20569 * exceptions.c (exception_print_same): Moved here from exec.c. * exceptions.h (exception_print_same): Declare. * exec.h: Include "symfile-add-flags.h". (try_open_exec_file): New declaration. * exec.c (exception_print_same): Moved to exceptions.c. (try_open_exec_file): New function. (exec_file_locate_attach): Rename exec_file and full_exec_path variables to avoid confusion between target and host pathnames. Move pathname processing logic to exec_file_find. Do not return early if pathname lookup fails; Call try_open_exec_file. * infrun.c (follow_exec): Split and rename execd_pathname variable to avoid confusion between target and host pathnames. Warn if pathname lookup fails. Pass target pathname to target_follow_exec, not hostpathname. Call try_open_exec_file. * main.c (symbol_file_add_main_adapter): New function. (captured_main_1): Use it. * solib-svr4.c (open_symbol_file_object): Adjust to pass symfile_add_flags to symbol_file_add_main. * solib.c (exec_file_find): Incorporate fallback logic for relative pathnames formerly in exec_file_locate_attach. * symfile.c (symbol_file_add_main, symbol_file_add_main_1): Replace 'from_tty' parameter with a symfile_add_file. (symbol_file_command): Adjust to pass symfile_add_flags to symbol_file_add_main. * symfile.h (symbol_file_add_main): Replace 'from_tty' parameter with a symfile_add_file. gdb/testsuite/ChangeLog: 2016-10-25 Luis Machado <lgustavo@codesourcery.com> * gdb.base/exec-invalid-sysroot.exp: New file.
2016-10-26Make symfile_add_flags and objfile->flags strongly typedPedro Alves19-129/+257
This makes these flag types be "enum flag" types. The benefit is making use of C++'s stronger typing -- mixing the flags types by mistake errors at compile time. This caught one old bug in symbol_file_add_main_1 already, fixed by this patch as well: @@ -1318,7 +1326,7 @@ symbol_file_add_main_1 (const char *args, int from_tty, int flags) what is frameless. */ reinit_frame_cache (); - if ((flags & SYMFILE_NO_READ) == 0) + if ((add_flags & SYMFILE_NO_READ) == 0) set_initial_language (); } Above, "flags" are objfile flags, not symfile_add_flags. So that was actually checking for "flag & OBJF_PSYMTABS_READ", which has the same value as SYMFILE_NO_READ... I moved the flags definitions to separate files to break circular dependencies. Built with --enable-targets=all and tested on x86-64 Fedora 23. gdb/ChangeLog: 2016-10-26 Pedro Alves <palves@redhat.com> * coffread.c (coff_symfile_read): Use symfile_add_flags. * dbxread.c (dbx_symfile_read): Ditto. * elfread.c (elf_symfile_read): Ditto. * inferior.h: Include symfile-add-flags.h. (struct inferior) <symfile_flags>: Now symfile_add_flags. * machoread.c (macho_add_oso_symfile, macho_symfile_read_all_oso) (macho_symfile_read, mipscoff_symfile_read): Use symfile_add_flags. * objfile-flags.h: New file. * objfiles.c (allocate_objfile): Use objfile_flags. * objfiles.h: Include objfile-flags.h. (struct objfile) <flags>: Now an objfile_flags. (OBJF_REORDERED, OBJF_SHARED, OBJF_READNOW, OBJF_USERLOADED) (OBJF_PSYMTABS_READ, OBJF_MAINLINE, OBJF_NOT_FILENAME): Delete. Converted to an enum-flags in objfile-flags.h. (allocate_objfile): Use objfile_flags. * python/py-objfile.c (objfpy_add_separate_debug_file): Remove unnecessary local. * solib.c (solib_read_symbols, solib_add) (reload_shared_libraries_1): Use symfile_add_flags. * solib.h: Include "symfile-add-flags.h". (solib_read_symbols): Use symfile_add_flags. * symfile-add-flags.h: New file. * symfile-debug.c (debug_sym_read): Use symfile_add_flags. * symfile-mem.c (symbol_file_add_from_memory): Use symfile_add_flags. * symfile.c (read_symbols, syms_from_objfile_1) (syms_from_objfile, finish_new_objfile): Use symfile_add_flags. (symbol_file_add_with_addrs): Use symfile_add_flags and objfile_flags. (symbol_file_add_separate): Use symfile_add_flags. (symbol_file_add_from_bfd, symbol_file_add): Use symfile_add_flags and objfile_flags. (symbol_file_add_main_1): : Use objfile_flags. Fix add_flags vs flags confusion. (symbol_file_command): Use objfile_flags. (add_symbol_file_command): Use symfile_add_flags and objfile_flags. (clear_symtab_users): Use symfile_add_flags. * symfile.h: Include "symfile-add-flags.h" and "objfile-flags.h". (struct sym_fns) <sym_read>: Use symfile_add_flags. (clear_symtab_users): Use symfile_add_flags. (enum symfile_add_flags): Delete, moved to symfile-add-flags.h and converted to enum-flags. (symbol_file_add, symbol_file_add_from_bfd) (symbol_file_add_separate): Use symfile_add_flags. * xcoffread.c (xcoff_initial_scan): Use symfile_add_flags.
2016-10-26gdb: Coalesce/aggregate (async) vCont packets/actionsPedro Alves9-34/+599
Currently, with "maint set target-non-stop on", that is, when gdb connects with the non-stop/asynchronous variant of the remote protocol, even with "set non-stop off", GDB always sends one vCont packet per thread resumed. This patch makes GDB aggregate and coalesce vCont packets, so we send vCont packets like "vCont;s:p1.1;c" in non-stop mode too. Basically, this is done by: - Adding a new target method target_commit_resume that is called after calling target_resume one or more times. When resuming a batch of threads, we'll only call target_commit_resume once after calling target_resume for all threads. - Making the remote target defer sending the actual vCont packet to target_commit_resume. Special care must be taken to avoid sending a vCont action with a "wildcard" thread-id (all threads of process / all threads) when that would resume threads/processes that should not be resumed. See remote_commit_resume comments for details. Unlike all-stop's remote_resume implementation, this handles the case of too many actions resulting in a too-big vCont packet, by flushing the vCont packet and starting a new one. E.g., imagining that the "c" action in: vCont;s:1;c overflows the packet buffer, we split the actions like: vCont;s:1 vCont;c Tested on x86_64 Fedora 20, with and without "maint set target-non-stop on". Also tested with a hack that makes remote_commit_resume flush the vCont packet after every action appended (which caught a few bugs). gdb/ChangeLog: 2016-10-26 Pedro Alves <palves@redhat.com> * inferior.h (ALL_NON_EXITED_INFERIORS): New macro. * infrun.c (do_target_resume): Call target_commit_resume. (proceed): Defer target_commit_resume while looping over threads, resuming them. Call target_commit_resume at the end. * record-btrace.c (record_btrace_commit_resume): New function. (init_record_btrace_ops): Install it as to_commit_resume method. * record-full.c (record_full_commit_resume): New function. (record_full_wait_1): Call the beneath target's to_commit_resume method. (init_record_full_ops): Install record_full_commit_resume as to_commit_resume method. * remote.c (struct private_thread_info) <last_resume_step, last_resume_sig, vcont_resumed>: New fields. (remote_add_thread): Set the new thread's vcont_resumed flag. (demand_private_info): Delete. (get_private_info_thread, get_private_info_ptid): New functions. (remote_update_thread_list): Adjust. (process_initial_stop_replies): Clear the thread's vcont_resumed flag. (remote_resume): If connected in non-stop mode, record the resume request and return early. (struct private_inferior): New. (struct vcont_builder): New. (vcont_builder_restart, vcont_builder_flush) (vcont_builder_push_action): New functions. (MAX_ACTION_SIZE): New macro. (remote_commit_resume): New function. (thread_pending_fork_status, is_pending_fork_parent_thread): New functions. (check_pending_event_prevents_wildcard_vcont_callback) (check_pending_events_prevent_wildcard_vcont): New functions. (process_stop_reply): Adjust. Clear the thread's vcont_resumed flag. (init_remote_ops): Install remote_commit_resume. * target-delegates.c: Regenerate. * target.c (defer_target_commit_resume): New global. (target_commit_resume, make_cleanup_defer_target_commit_resume): New functions. * target.h (struct target_ops) <to_commit_resume>: New field. (target_resume): Update comments. (target_commit_resume): New declaration.
2016-10-26gdbserver: Leave already-vCont-resumed threads as they werePedro Alves5-1/+114
Currently GDB never sends more than one action per vCont packet, when connected in non-stop mode. A follow up patch will change that, and it exposed a gdbserver problem with the vCont handling. For example, this in non-stop mode: => vCont;s:p1.1;c <= OK Should be equivalent to: => vCont;s:p1.1 <= OK => vCont;c <= OK But gdbserver currently doesn't handle this. In the latter case, "vCont;c" makes gdbserver clobber the previous step request. This patch fixes that. Note the server side must ignore resume actions for the thread that has a pending %Stopped notification (and any other threads with events pending), until GDB acks the notification with vStopped. Otherwise, e.g., the following case is mishandled: #1 => g (or any other packet) #2 <= [registers] #3 <= %Stopped T05 thread:p1.2 #4 => vCont s:p1.1;c #5 <= OK Above, the server must not resume thread p1.2 when it processes the vCont. GDB can't know that p1.2 stopped until it acks the %Stopped notification. (Otherwise it wouldn't send a default "c" action.) (The vCont documentation already specifies this.) Finally, special care must also be given to handling fork/vfork events. A (v)fork event actually tells us that two processes stopped -- the parent and the child. Until we follow the fork, we must not resume the child. Therefore, if we have a pending fork follow, we must not send a global wildcard resume action (vCont;c). We can still send process-wide wildcards though. (The comments above will be added as code comments to gdb in a follow up patch.) gdb/gdbserver/ChangeLog: 2016-10-26 Pedro Alves <palves@redhat.com> * linux-low.c (handle_extended_wait): Link parent/child fork threads. (linux_wait_1): Unlink them. (linux_set_resume_request): Ignore resume requests for already-resumed and unhandled fork child threads. * linux-low.h (struct lwp_info) <fork_relative>: New field. * server.c (in_queued_stop_replies_ptid, in_queued_stop_replies): New functions. (handle_v_requests) <vCont>: Don't call require_running. * server.h (in_queued_stop_replies): New declaration.
2016-10-26gdb/doc: Clarify vCont packet descriptionPedro Alves2-11/+27
Specifically, what happens with multiple actions that could match a thread, and what happens when we get a vCont action that matches a thread that was already running. E.g., what does: "vCont;s:2" "vCont;s:1;c" mean for thread 2. (Thread 2 continues stepping.) gdb/doc/ChangeLog: 2016-10-26 Pedro Alves <palves@redhat.com> * gdb.texinfo (Packets): Clarify vCont packets with multiple actions that match a thread, and what happens when an action matches a thread that is already running.
2016-10-26gdb: Free inferior->priv when inferior exitsPedro Alves2-0/+7
(Where "exits" includes being killed or detached.) Nothing is clearing inferior->priv currently. This is a problem if we change the inferior's process_stratum targets in a single debug session. This field is currently only used by darwin-nat.c, but a follow up patch will make remote.c use it too. Without the fix, remote.c might end up mistaking the priv object allocated by darwin-nat.c with its own. (Found by inspection.) gdb/ChangeLog: 2016-10-26 Pedro Alves <palves@redhat.com> * inferior.c (exit_inferior_1): Free 'priv'.
2016-10-26gdb: Clean up remote.c:remote_resumePedro Alves2-51/+71
Just some refactoring / TLC. Mainly split the old c/s/C/S packet handling to a separate function. gdb/ChangeLog: 2016-10-26 Pedro Alves <palves@redhat.com> * remote.c (remote_resume_with_hc): New function, factored out from ... (remote_resume): ... this. Always try vCont first. (remote_vcont_resume): Rename to ... (remote_resume_with_vcont): ... this. Bail out if execution direction is reverse.
2016-10-26Revert "bison warning fixes"Alan Modra3-2/+8
This reverts commit 95e61695c199a07c832153cea25ae9c331d16a3c. People still want to use older versions of bison, apparently. Revert 2016-10-06 Alan Modra <amodra@gmail.com> * config/rl78-parse.y: Do use old %name-prefix syntax. * config/rx-parse.y: Likewise.
2016-10-26Automatic date update in version.inGDB Administrator1-1/+1
2016-10-25Make dwarf_expr_context's destructor virtualPedro Alves2-1/+6
Ref: https://sourceware.org/ml/gdb-patches/2016-10/msg00662.html $ make WERROR_CFLAGS="-Wnon-virtual-dtor" dwarf2expr.o ... In file included from .../src/gdb/dwarf2expr.c:28:0: .../src/gdb/dwarf2expr.h:68:8: warning: ‘struct dwarf_expr_context’ has virtual functions and accessible non-virtual destructor [-Wnon-virtual-dtor] struct dwarf_expr_context ^~~~~~~~~~~~~~~~~~ Happens to not be a problem in practice currently because concrete subclasses are allocated on the stack. I.e., we don't ever delete objects of types that derive from dwarf_expr_context through pointers to dwarf_expr_context. gdb/ChangeLog: 2016-10-25 Pedro Alves <palves@redhat.com> * dwarf2expr.h (struct dwarf_expr_context) <~dwarf_expr_context>: Make virtual.
2016-10-25Fix gdb C++ compilation on Solaris (PR build/20712)Rainer Orth5-71/+127
gdb 7.12 doesn't compile as C++ (tried with g++ 4.9) on Solaris (tried 10 and 12, sparc and x86). The following patch (relative to the 7.12 release, though I expect most if not all issues to be present on trunk, too) fixes this. Only a few of the changes bear explanation: * Initially, compilation failed whereever defs.h. was included: In file included from /vol/src/gnu/gdb/gdb-7.12/gdb/gdb.c:19:0: /vol/src/gnu/gdb/gdb-7.12/gdb/defs.h:630:33: error: 'double atof(const char*)' conflicts with a previous declaration extern double atof (const char *); /* X3.159-1989 4.10.1.1 */ ^ In file included from /usr/include/stdlib.h:17:0, from build-gnulib/import/stdlib.h:36, from /vol/src/gnu/gdb/gdb-7.12/gdb/common/common-defs.h:32, from /vol/src/gnu/gdb/gdb-7.12/gdb/defs.h:28, from /vol/src/gnu/gdb/gdb-7.12/gdb/gdb.c:19: /vol/gcc-4.9/lib/gcc/i386-pc-solaris2.10/4.9.0/include-fixed/iso/stdlib_iso.h:119:15: note: previous declaration 'double std::atof(const char*)' extern double atof(const char *); ^ This is due to this gem in gdb/defs.h which seems to have been present like forever: #ifndef atof extern double atof (const char *); /* X3.159-1989 4.10.1.1 */ #endif In the Solaris headers, the appropriate functions are in namespace std, thus the conflict. I've wrapped the defs.h declaration in !__cplusplus to avoid this; perhaps it can go completely instead. * All the casts are necessary to appease g++ and should be pretty obvious. * The sol-thread.c changes are here to handle /vol/src/gnu/gdb/gdb-7.12/gdb/sol-thread.c: In function 'void _initialize_sol_thread()': /vol/src/gnu/gdb/gdb-7.12/gdb/sol-thread.c:1252:36: error: invalid conversion from 'void*' to 'void (*)(int)' [-fpermissive] if (!(p_##X = dlsym (dlhandle, #X))) \ ^ /vol/src/gnu/gdb/gdb-7.12/gdb/sol-thread.c:1255:3: note: in expansion of macro 'resolve' resolve (td_log); ^ and are modeled after linux-thread-db.c (try_thread_db_load_1). The patch allowed both 32 and 64-bit C++ builds on sparc-sun-solaris2.10 and i386-pc-solaris2.10 to complete. The resulting binary hasn't seen more than a smoke test (invoke it on itself, b main, run) yet. When investigating the failure to detect -static-libstdc++ support (more below), I found two more issues which only show up with -Werror: /vol/src/gnu/gdb/gdb/local/gdb/procfs.c: In function 'ssd* proc_get_LDT_entry(procinfo*, int)': /vol/src/gnu/gdb/gdb/local/gdb/procfs.c:2487:19: error: variable 'old_chain' set but not used [-Werror=unused-but-set-variable] struct cleanup *old_chain = NULL; ^ Unless I'm mistaken, you need to run do_cleanups on every return from the function. Afterwards, I ran a 32-bit compilation, which (after adding --disable-largefile to avoid In file included from /usr/include/sys/procfs.h:28:0, from /vol/src/gnu/gdb/gdb/local/gdb/i386-sol2-nat.c:23: /usr/include/sys/old_procfs.h:39:2: error: #error "Cannot use procfs in the large file compilation environment" #error "Cannot use procfs in the large file compilation environment" ^ and two more instances) revealed /vol/src/gnu/gdb/gdb/local/gdb/top.c: In function 'void gdb_safe_append_history()': /vol/src/gnu/gdb/gdb/local/gdb/top.c:1170:59: error: format '%d' expects argument of type 'int', but argument 3 has type 'pid_t {aka long int}' [-Werror=format=] = xstrprintf ("%s-gdb%d~", history_filename, getpid ()); ^ Fixed by casting pid_t to long and printing it as such.
2016-10-25common/common-defs.h: Define __STDC_FORMAT_MACROS as wellPedro Alves2-2/+14
Ref: https://sourceware.org/ml/gdb-patches/2016-10/msg00694.html gdb/ChangeLog: 2016-10-25 Pedro Alves <palves@redhat.com> * common/common-defs.h (__STDC_FORMAT_MACROS): Define.
2016-10-25new-op.c: Add comment about -fsanitize=addressPedro Alves2-0/+10
gdb/ChangeLog: 2016-10-25 Pedro Alves <palves@redhat.com> * common/new-op.c: Add comment about -fsanitize=address.
2016-10-25Define __STDC_CONSTANT_MACROS/__STDC_LIMIT_MACROS again.Pedro Alves2-0/+18
Revert commit f6abaf7a4088 (gdb: no longer define __STDC_CONSTANT_MACROS/__STDC_LIMIT_MACROS), with the tweak suggested in that commit's log: the macros are now defined before any system header is included. This should fix AIX: https://sourceware.org/ml/gdb-patches/2016-10/msg00682.html gdb/ChangeLog: 2016-10-25 Pedro Alves <palves@redhat.com> * common/common-defs.h (__STDC_CONSTANT_MACROS) (__STDC_LIMIT_MACROS): Define.
2016-10-25Don't override operator new if GDB is built with -fsanitize=addressYao Qi2-0/+13
Nowadays, if we build GDB with -fsanitize=address, we can get the asan error below, (gdb) quit ================================================================= ==9723==ERROR: AddressSanitizer: alloc-dealloc-mismatch (malloc vs operator delete) on 0x60200003bf70 #0 0x7f88f3837527 in operator delete(void*) (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x55527) #1 0xac8e13 in __gnu_cxx::new_allocator<void (*)()>::deallocate(void (**)(), unsigned long) /usr/include/c++/4.9/ext/new_allocator.h:110 #2 0xac8cc2 in __gnu_cxx::__alloc_traits<std::allocator<void (*)()> >::deallocate(std::allocator<void (*)()>&, void (**)(), unsigned long) /usr/include/c++/4.9/ext/alloc_traits.h:185 .... 0x60200003bf70 is located 0 bytes inside of 8-byte region [0x60200003bf70,0x60200003bf78) allocated by thread T0 here: #0 0x7f88f38367ef in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x547ef) #1 0xbd2762 in operator new(unsigned long) /home/yao/SourceCode/gnu/gdb/git/gdb/common/new-op.c:42 #2 0xac8edc in __gnu_cxx::new_allocator<void (*)()>::allocate(unsigned long, void const*) /usr/include/c++/4.9/ext/new_allocator.h:104 #3 0xac8d81 in __gnu_cxx::__alloc_traits<std::allocator<void (*)()> >::allocate(std::allocator<void (*)()>&, unsigned long) /usr/include/c++/4.9/ext/alloc_traits.h:182 The reason for this is that we override operator new but don't override operator delete. This patch does the override if the code is NOT compiled with asan. gdb: 2016-10-25 Yao Qi <yao.qi@linaro.org> PR gdb/20716 * common/new-op.c (__has_feature): New macro. Don't override operator new if asan is used.
2016-10-25elfxx-mips: Correct STUB_JALR's descriptionMaciej W. Rozycki2-1/+5
bfd/ * elfxx-mips.c (STUB_JALR): Correct description.
2016-10-25Automatic date update in version.inGDB Administrator1-1/+1
2016-10-24Fix potential NULL pointer dereferenceLuis Machado2-1/+7
This patch addresses a potential NULL pointer dereference when we try to duplicate a string. The input pointer can be NULL and that may lead to crashes. We simply add a check for that case. gdb/ChangeLog: 2016-10-24 Luis Machado <lgustavo@codesourcery.com> * exec.c (exec_file_locate_attach): Prevent NULL pointer dereference when duplicating a string.
2016-10-24Fix obvious gotcha in string comparisonLuis Machado2-1/+6
This patch fixes a gotcha when comparing exception's messages in exception_print_same. It should've used the statically-allocated string versions msg1 and msg2 instead. As is, it could lead to crashes. gdb/ChangeLog: 2016-10-24 Luis Machado <lgustavo@codesourcery.com> * exec.c (exception_print_same): Fix string comparison to use statically-allocated ones.
2016-10-24testsuite: Fix false FAIL for gdb.base/morestack.expJan Kratochvil2-1/+9
Since [commit] [testsuite patch] Fix gcc_compiled for gcc 6 & 7 https://sourceware.org/ml/gdb-patches/2016-10/msg00620.html there has started running again Running gdb/testsuite/gdb.base/morestack.exp ... +FAIL: gdb.base/morestack.exp: continue +PASS: gdb.base/morestack.exp: up 3000 but as you can see it FAILs now - on Fedora 24 x86_64 (although for example it still PASSes on CentOS-7.2 x86_64). Program received signal SIGSEGV, Segmentation fault. 0x00007ffff787c7bb in malloc_consolidate (av=av@entry=0x7ffff7bbcb00 <main_arena>) at malloc.c:4181 4181 unlink(av, nextchunk, bck, fwd); (gdb) bt [...] [...] This apparently is due to - man gcc - -fsplit-stack: When code compiled with -fsplit-stack calls code compiled without -fsplit-stack, there may not be much stack space available for the latter code to run. If compiling all code, including library code, with -fsplit-stack is not an option, then the linker can fix up these calls so that the code compiled without -fsplit-stack always has a large stack. Support for this is implemented in the gold linker in GNU binutils release 2.21 and later. gdb/testsuite/ChangeLog 2016-10-24 Jan Kratochvil <jan.kratochvil@redhat.com> * gdb.base/morestack.exp: Try to build it using -fuse-ld=gold first.
2016-10-24[GDBserver] Fix conversion warningYao Qi2-1/+7
I got the following warning if I build GDBserver for aarch64_be-linux-gnu, git/gdb/gdbserver/linux-aarch64-low.c:1539:39: error: invalid conversion from 'void*' to 'uint32_t* {aka unsigned int*}' [-fpermissive] uint32_t *le_buf = xmalloc (byte_len); ^ The patch is to fix the warning. gdb/gdbserver: 2016-10-24 Yao Qi <yao.qi@linaro.org> PR server/20733 * linux-aarch64-low.c (append_insns): Cast the return value to 'uint32_t *'.
2016-10-24Automatic date update in version.inGDB Administrator1-1/+1
2016-10-23Automatic date update in version.inGDB Administrator1-1/+1
2016-10-22Automatic date update in version.inGDB Administrator1-1/+1
2016-10-21Make some dwarf_expr_context methods pure virtualTom Tromey3-31/+63
This patch changes some dwarf_expr_context to be pure virtual, as mentioned during the discussion of an earlier patch in this series. 2016-10-21 Tom Tromey <tom@tromey.com> * dwarf2expr.h (class dwarf_expr_context) <get_frame_base, get_frame_cfa, get_tls_address, dwarf_call, push_dwarf_block_entry_value, get_addr_index, get_object_address>: Now pure virtual. * dwarf2-frame.c (class dwarf_expr_executor) <get_frame_base, get_frame_cfa, get_tls_address, dwarf_call, push_dwarf_block_entry_value, get_addr_index, get_object_address>: New methods. <invalid>: New method.
2016-10-21Change minimal_symbol_reader::record_full to take a boolTom Tromey4-21/+32
This changes an "int" to a "bool" in the signature for minimal_symbol_reader::record_full, and then fixes the callers. 2016-10-21 Tom Tromey <tom@tromey.com> * minsyms.h (minimal_symbol_reader::record_full): "copy_name" now a bool. (record, record_with_info): Update. * minsyms.c (record): Fix indentation. (record_full): Fix indentation. Update for type change. * elfread.c (record_minimal_symbol): "copy_name" now a bool. (elf_symtab_read): "copy_names" now a bool. (elf_rel_plt_read, elf_read_minimal_symbols): Update.
2016-10-21Remove last cleanup from captured_main_1Tom Tromey2-53/+46
An earlier patch split captured_main into two parts. This patch removes the last remaining cleanup from captured_main_1, and also replaces a second hand-rolled VEC-like array with a std::vector. 2016-10-21 Tom Tromey <tom@tromey.com> * main.c: Include <vector>. (cmdarg_s): Remove typedef. Don't define VEC. (captured_main_1): Use vector, not VEC. Remove cleanups.
2016-10-21Convert dwarf_expr_context_funcs to methodsTom Tromey5-605/+464
This patch converts the function pointers in dwarf_expr_context_funcs into methods on dwarf_expr_context, and then updates the various implementations and callers to follow. NB this patch uses "override" (which caught a couple of renaming bugs during development) -- but this is C++11, so this patch at least has to wait for Pedro's patch that adds the OVERRIDE macro. After this patch it would be possible to do one more, that makes various members of dwarf_expr_context "protected"; but I haven't done this. 2016-10-21 Tom Tromey <tom@tromey.com> * dwarf2loc.c (struct dwarf_expr_context_funcs): Don't declare. (dwarf_expr_read_addr_from_reg, dwarf_expr_get_reg_value) (dwarf_expr_read_mem, dwarf_expr_frame_base): Rename; turn into methods. (get_frame_pc_for_per_cu_dwarf_call): New function. (dwarf_expr_frame_cfa, dwarf_expr_frame_pc) (dwarf_expr_tls_address): Rename; turn into methods. (per_cu_dwarf_call): Remove arguments. Use get_frame_pc_for_per_cu_dwarf_call. (dwarf_evaluate_loc_desc): New class. (dwarf_expr_dwarf_call, dwarf_expr_context) (dwarf_expr_push_dwarf_reg_entry_value) (dwarf_expr_get_addr_index, dwarf_expr_get_obj_addr): Rename; turn into methods. (dwarf_expr_ctx_funcs): Remove. (dwarf2_evaluate_loc_desc_full): Update. (dwarf2_locexpr_baton_eval): Update. (symbol_needs_eval_context): New class. (symbol_needs_read_addr_from_reg, symbol_needs_get_reg_value) (symbol_needs_read_mem, symbol_needs_frame_base) (symbol_needs_frame_cfa, symbol_needs_tls_address) (symbol_needs_dwarf_call, needs_dwarf_reg_entry_value): Rename; turn into methods. (needs_get_addr_index, needs_get_obj_addr): Remove; turn into methods. (symbol_needs_ctx_funcs): Remove. (dwarf2_loc_desc_get_symbol_read_needs): Update. * dwarf2expr.h (struct dwarf_expr_context_funcs): Remove; turn contents into methods. (struct dwarf_expr_context) <baton, funcs>: Remove. <read_addr_from_reg, get_reg_value, read_mem, get_frame_base, get_frame_cfa, get_frame_pc, get_tls_address, dwarf_call, impl_get_base_type, push_dwarf_block_entry_value, get_addr_index, get_object_address>: Declare new methods. (ctx_no_get_frame_base, ctx_no_get_frame_cfa) (ctx_no_get_frame_pc, ctx_no_get_tls_address, ctx_no_dwarf_call) (ctx_no_get_base_type, ctx_no_push_dwarf_reg_entry_value) (ctx_no_get_addr_index): Don't declare. * dwarf2expr.c (get_base_type): Use impl_get_base_type. (execute_stack_op): Update. (ctx_no_get_frame_base, ctx_no_get_frame_cfa) (ctx_no_get_frame_pc, ctx_no_get_tls_address, ctx_no_dwarf_call) (ctx_no_get_base_type, ctx_no_push_dwarf_reg_entry_value) (ctx_no_get_addr_index): Remove; now methods on dwarf_expr_context. * dwarf2-frame.c (read_addr_from_reg): Take a frame_info, not a baton. (class dwarf_expr_executor): New class. (get_reg_value, read_mem): Rename, turn into methods. (execute_stack_op): Use dwarf_expr_executor.
2016-10-21Convert DWARF expr functions to methodsTom Tromey5-229/+246
This converts various DWARF expr functions to be members on dwarf_expr_context, then fixes up the various users. This results in somewhat less wordy code and sets the stage for the next patch. 2016-10-21 Tom Tromey <tom@tromey.com> * dwarf2loc.c (per_cu_dwarf_call) (dwarf_expr_push_dwarf_reg_entry_value) (dwarf2_evaluate_loc_desc_full, dwarf2_locexpr_baton_eval) (needs_dwarf_reg_entry_value) (dwarf2_loc_desc_get_symbol_read_needs): Update. * dwarf2expr.h (dwarf_expr_context) <push_address, eval, fetch, fetch_address, fetch_in_stack_memory, address_type, grow_stack, push, stack_empty_p, add_piece, get_base_type, execute_stack_op, pop>: New method declarations. (dwarf_expr_push_address, dwarf_expr_eval, dwarf_expr_fetch) (dwarf_expr_fetch_address, dwarf_expr_fetch_in_stack_memory): Don't declare. * dwarf2expr.c (address_type, grow_stack, push, push_address) (pop, fetch, fetch_address, fetch_in_stack_memory) (stack_empty_p, add_piece, eval, get_base_type) (execute_stack_op): Rename. Turn into methods. * dwarf2-frame.c (execute_stack_op): Update.
2016-10-21Initial conversion of dwarf_expr_ctxTom Tromey5-117/+110
This is the first step in the conversion of dwarf_expr_ctx to a C++ class. This conversion is done in steps to make the patches, and the reviews, a bit simpler. This patch changes dwarf_expr_ctx to be stack-allocated and removes the associated cleanup. 2016-10-21 Tom Tromey <tom@tromey.com> * dwarf2loc.c (dwarf2_evaluate_loc_desc_full): Stack-allocate dwarf_expr_context. Remove cleanups. (dwarf2_locexpr_baton_eval) (dwarf2_loc_desc_get_symbol_read_needs): Likewise. * dwarf2expr.h (dwarf_expr_context, ~dwarf_expr_context): Add constructors and destructors. (new_dwarf_expr_context, free_dwarf_expr_context) (make_cleanup_free_dwarf_expr_context): Don't declare. * dwarf2-frame.c (execute_stack_op): Stack-allocate dwarf_expr_context. Remove cleanups. (dwarf_expr_context): Rename from new_dwarf_expr_context. Turn into constructor. (free_dwarf_expr_context, free_dwarf_expr_context_cleanup): Remove. (~dwarf_expr_context): Rename from make_cleanup_free_dwarf_expr_context. Turn into destructor.
2016-10-21Some cleanup removal in dwarf2loc.cTom Tromey2-44/+31
This removes some cleanups and manual allocation handling in dwarf2loc.c with std::vector. Note that this patch has a case where the vector would normally fall into the "use gdb::unique_ptr" guidelines -- but here because the vector is immediately initialized, I moved the initialization into the constructor call, for further code savings. 2016-10-21 Tom Tromey <tom@tromey.com> * dwarf2loc.c: Include <vector>. (read_pieced_value, write_pieced_value) (dwarf2_compile_expr_to_ax): Use std::vector.
2016-10-21Remove make_cleanup_restore_current_uioutTom Tromey6-38/+16
This removes make_cleanup_restore_current_uiout in favor of an RAII-based class. 2016-10-21 Tom Tromey <tom@tromey.com> * stack.c (print_stack_frame_to_uiout): Use scoped_restore. * ui-out.c (make_cleanup_restore_current_uiout) (restore_current_uiout_cleanup): Remove. * infrun.c (print_stop_event): Use scoped_restore. * ui-out.h (make_cleanup_restore_current_uiout): Don't declare.
2016-10-21Use gdb::unique_ptr in elf_read_minimal_symbolsTom Tromey2-8/+7
This changes elf_read_minimal_symbols to use gdb::unique_ptr rather than an explicit allocation. This removes a cleanup. 2016-10-21 Tom Tromey <tom@tromey.com> * elfread.c (elf_read_minimal_symbols): Use gdb::unique_ptr.
2016-10-21Replace two xmallocs with unique_ptrTom Tromey2-11/+13
This replaces a couple of uses of xmalloc with gdb::unique_ptr, also removing a couple of cleanups. 2016-10-21 Tom Tromey <tom@tromey.com> * cli/cli-dump.c (dump_memory_to_file): Use gdb::unique_ptr. (restore_binary_file): Likewise.
2016-10-21Change command stats reporting to use classTom Tromey5-97/+104
This removes make_command_stats_cleanup in favor of an RAII class. The patch is reasonably straightforward, but keeping the same semantics without excessive reindentation required splitting captured_main in two. 2016-10-21 Tom Tromey <tom@tromey.com> * maint.h (scoped_command_stats): New class. (make_command_stats_cleanup): Don't declare. * maint.c (struct cmd_stats): Remove. (~scoped_command_stats): Rename from report_command_stats. Now a destructor. (scoped_command_stats): Rename from make_command_stats_cleanup. Now a constructor. * main.c (captured_main_1): New function. Use scoped_command_stats. (captured_main): Call captured_main_1. * event-top.c (command_handler): Use scoped_command_stats.
generated by cgit v1.1 at 2024-12-24 14:06:13 +0000