aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2015-04-01Add support for writing unwinders in Python.Sasha Smundak21-2/+1808
gdb/ChangeLog: * Makefile.in (SUBDIR_PYTHON_OBJS): Add py-unwind.o. (SUBDIR_PYTHON_SRCS): Add py-unwind.c. (py-unwind.o): New recipe. * NEWS: mention Python frame unwinding. * data-directory/Makefile.in (PYTHON_FILE_LIST): Add gdb/unwinder.py and gdb/command/unwinder.py * python/lib/gdb/__init__.py (packages): Add frame_unwinders list. (execute_unwinders): New function. * python/lib/gdb/command/unwinders.py: New file. * python/lib/gdb/unwinder.py: New file. * python/py-objfile.c (objfile_object): Add frame_unwinders field. (objfpy_dealloc): Decrement frame_unwinders reference count. (objfpy_initialize): Create frame_unwinders list. (objfpy_get_frame_unwinders): New function. (objfpy_set_frame_unwinders): Ditto. (objfile_getset): Add frame_unwinders attribute to Objfile. * python/py-progspace.c (pspace_object): Add frame_unwinders field. (pspy_dealloc): Decrement frame_unwinders reference count. (pspy_initialize): Create frame_unwinders list. (pspy_get_frame_unwinders): New function. (pspy_set_frame_unwinders): Ditto. (pspy_getset): Add frame_unwinders attribute to gdb.Progspace. * python/py-unwind.c: New file. * python/python-internal.h (pspy_get_name_unwinders): New prototype. (objpy_get_frame_unwinders): New prototype. (gdbpy_initialize_unwind): New prototype. * python/python.c (gdbpy_apply_type_printers): Call gdbpy_initialize_unwind. gdb/doc/ChangeLog: * doc/python.texi (Writing a Frame Unwinder in Python): Add section. gdb/testsuite/ChangeLog: * gdb.python/py-unwind-maint.c: New file. * gdb.python/py-unwind-maint.exp: New test. * gdb.python/py-unwind-maint.py: New file. * gdb.python/py-unwind.c: New file. * gdb.python/py-unwind.exp: New test. * gdb.python/py-unwind.py: New test.
2015-04-01infrun.c:resume: currently_stepping after clearing stepped_breakpointPedro Alves2-1/+9
My all-stop-on-top-of-non-stop series manages to shows regressions due to this latent bug. currently_stepping returns true if stepped_breakpoint is set. Obviously we should clear it before checking currently_stepping, not after. Tested on x86_64 Fedora 20. gdb/ChangeLog: 2015-04-01 Pedro Alves <palves@redhat.com> * infrun.c (resume): Check currently_stepping after clearing stepped_breakpoint, not before.
2015-04-01gdb.threads/manythreads.exp: can't read "test": no such variablePedro Alves2-1/+6
If interrupt_and_wait manages to trigger the FAIL path, we get: ERROR OCCURED: can't read "test": no such variable gdb/testsuite/ChangeLog: 2015-04-01 Pedro Alves <palves@redhat.com> * gdb.threads/manythreads.exp (interrupt_and_wait): Pass $message to fail instead of non-existent $test.
2015-04-01Fix gdb_spawn_with_cmdline_opts with non-empty GDBFLAGSPedro Alves2-0/+8
Running attach.exp with a DejaGnu board that sets GDBFLAGS, like e.g.,: set GDBFLAGS "-ex \"set displaced off\"" fails with (line breaks added for clarity): (gdb) PASS: gdb.base/attach.exp: starting with --pid Executing on build: kill -9 3537 (timeout = 300) spawn -ignore SIGHUP kill -9 3537 spawn of build/gdb/gdb -nw -nx \ -data-directory build/gdb/testsuite/../data-directory \ -ex "set displaced off"-iex "set height 0" -iex "set width 0" \ ^^^^^^^^ --pid=4468 -ex "start" failed ERROR: Spawning build/gdb/gdb failed. UNRESOLVED: gdb.base/attach.exp: cmdline attach run: run to prompt gdb/testsuite/ChangeLog: 2015-04-01 Pedro Alves <palves@redhat.com> * lib/gdb.exp (gdb_spawn_with_cmdline_opts): Append space to GDBFLAGS if not empty.
2015-04-01Make print_target_wait_results print the whole ptidPedro Alves2-2/+12
Makes "set debug infrun 1" a bit clearer. Before: infrun: target_wait (-1, status) = infrun: 6299 [Thread 0x7ffff7fc1700 (LWP 6340)], after: infrun: target_wait (-1.0.0, status) = infrun: 7233.7237.0 [Thread 0x7ffff7fc1700 (LWP 7237)], gdb/ChangeLog: 2015-04-01 Pedro Alves <palves@redhat.com> * infrun.c (print_target_wait_results): Print all the ptid elements.
2015-04-01keep_going: Add missing discard_cleanups callPedro Alves2-0/+6
By inspection, I noticed a path where we return without discarding the cleanups. gdb/ChangeLog: 2015-04-01 Pedro Alves <palves@redhat.com> * infrun.c (keep_going): Also discard cleanups if inserting breakpoints fails.
2015-04-01wait_for_inferior and errors thrown from target_waitPedro Alves2-9/+15
Noticed that if an error is thrown out of target_wait, we miss running finish_thread_state_cleanup. Tested on x86_64 Fedora 20, with "maint set target-async off". gdb/ChangeLog: 2015-04-01 Pedro Alves <palves@redhat.com> * infrun.c (wait_for_inferior): Install the finish_thread_state_cleanup cleanup across the whole function, not just around handle_inferior_event.
2015-04-01Use do_target_resume when stepping past permanent breakpoint tooPedro Alves2-7/+7
We can use the recently added do_target_resume do simplify the code a bit here. Tested on x86_64 Fedora 20. gdb/ChangeLog: 2015-04-01 Pedro Alves <palves@redhat.com> * infrun.c (resume) <step past permanent breakpoint>: Use do_target_resume.
2015-04-01linux_nat.c: Mark new thread running even if momentarily pausingPedro Alves2-1/+8
My all-stop-on-top-of-non-stop series manages to trip on a bug in the linux-nat.c backend while running the testsuite. If a thread is discovered while threads are being momentarily paused (without the core's intervention), the thread ends up stuck in THREAD_STOPPED state, even though from the user's perspective, the thread is running even while it is paused. From inspection, in the current sources, this can happen if we call stop_and_resume_callback, though there's no way to test that with current Linux kernels. (While trying to come up with test to exercise this, I stumbled on: https://sourceware.org/ml/gdb-patches/2015-03/msg00850.html ... which does include a non-trivial test, so I think I can still claim I come out net positive. :-) ) Tested on x86_64 Fedora 20. gdb/ChangeLog: 2015-04-01 Pedro Alves <palves@redhat.com> * linux-nat.c (linux_handle_extended_wait): Always call set_running.
2015-04-01Share the "multi_line" helper among all testcasesPierre-Marie de Rodat20-161/+130
gdb/testsuite/ChangeLog: * gdb.ada/complete.exp: Remove "multi_line". * gdb.ada/info_exc.exp: Remove "multi_line". * gdb.ada/packed_tagged.exp: Remove "multi_line". * gdb.ada/ptype_field.exp: Remove "multi_line". * gdb.ada/sym_print_name.exp: Remove "multi_line". * gdb.ada/tagged.exp: Remove "multi_line". * gdb.btrace/buffer-size.exp: Replace [join [list ...]] with [multi_line ...] * gdb.btrace/delta.exp: Likewise. * gdb.btrace/exception.exp: Likewise. * gdb.btrace/function_call_history.exp: Likewise. * gdb.btrace/instruction_history.exp: Likewise. * gdb.btrace/nohist.exp: Likewise. * gdb.btrace/record_goto.exp: Likewise. * gdb.btrace/segv.exp: Likewise. * gdb.btrace/stepi.exp: Likewise. * gdb.btrace/tailcall.exp: Likewise. * gdb.btrace/unknown_functions.exp: Likewise. * gdb.dwarf2/dw2-undefined-ret-addr.exp: Likewise. * lib/gdb.exp: Add the "multi_line" helper.
2015-04-01Add myself as a write-after-approval GDB maintainerPierre-Marie de Rodat2-0/+5
gdb/ChangeLog: * MAINTAINERS (Write After Approval): Add "Pierre-Marie de Rodat".
2015-04-01Crash on thread id wrap aroundPedro Alves5-2/+245
On GNU/Linux, if the target reuses the TID of a thread that GDB still has in its list marked as THREAD_EXITED, GDB crashes, like: (gdb) continue Continuing. src/gdb/thread.c:789: internal-error: set_running: Assertion `tp->state != THREAD_EXITED' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) FAIL: gdb.threads/tid-reuse.exp: continue to breakpoint: after_reuse_time (GDB internal error) Here: (top-gdb) bt #0 internal_error (file=0x953dd8 "src/gdb/thread.c", line=789, fmt=0x953da0 "%s: Assertion `%s' failed.") at src/gdb/common/errors.c:54 #1 0x0000000000638514 in set_running (ptid=..., running=1) at src/gdb/thread.c:789 #2 0x00000000004bda42 in linux_handle_extended_wait (lp=0x16f5760, status=0, stopping=0) at src/gdb/linux-nat.c:2114 #3 0x00000000004bfa24 in linux_nat_filter_event (lwpid=20570, status=198015) at src/gdb/linux-nat.c:3127 #4 0x00000000004c070e in linux_nat_wait_1 (ops=0xe193d0, ptid=..., ourstatus=0x7fffffffd2c0, target_options=1) at src/gdb/linux-nat.c:3478 #5 0x00000000004c1015 in linux_nat_wait (ops=0xe193d0, ptid=..., ourstatus=0x7fffffffd2c0, target_options=1) at src/gdb/linux-nat.c:3722 #6 0x00000000004c92d2 in thread_db_wait (ops=0xd80b60 <thread_db_ops>, ptid=..., ourstatus=0x7fffffffd2c0, options=1) at src/gdb/linux-thread-db.c:1525 #7 0x000000000066db43 in delegate_wait (self=0xd80b60 <thread_db_ops>, arg1=..., arg2=0x7fffffffd2c0, arg3=1) at src/gdb/target-delegates.c:116 #8 0x000000000067e54b in target_wait (ptid=..., status=0x7fffffffd2c0, options=1) at src/gdb/target.c:2206 #9 0x0000000000625111 in fetch_inferior_event (client_data=0x0) at src/gdb/infrun.c:3275 #10 0x0000000000648a3b in inferior_event_handler (event_type=INF_REG_EVENT, client_data=0x0) at src/gdb/inf-loop.c:56 #11 0x00000000004c2ecb in handle_target_event (error=0, client_data=0x0) at src/gdb/linux-nat.c:4655 I managed to come up with a test that reliably reproduces this. It spawns enough threads for the pid number space to wrap around, so could potentially take a while. On my box that's 4 seconds; on gcc110, a PPC box which has max_pid set to 65536, it's over 10 seconds. So I made the test compute how long that would take, and cap the time waited if it would be unreasonably long. Tested on x86_64 Fedora 20. gdb/ChangeLog: 2015-04-01 Pedro Alves <palves@redhat.com> * linux-thread-db.c (record_thread): Readd the thread to gdb's list if it was marked exited. gdb/testsuite/ChangeLog: 2015-04-01 Pedro Alves <palves@redhat.com> * gdb.threads/tid-reuse.c: New file. * gdb.threads/tid-reuse.exp: New file.
2015-04-01Regenerate configure in bfd/binutils/gas/gdbH.J. Lu2-2/+8
bfd/ 2015-04-01 H.J. Lu <hongjiu.lu@intel.com> * configure: Regenerated. binutils/ 2015-04-01 H.J. Lu <hongjiu.lu@intel.com> * configure: Regenerated. gas/ 2015-04-01 H.J. Lu <hongjiu.lu@intel.com> * configure: Regenerated. gdb/ 2015-04-01 H.J. Lu <hongjiu.lu@intel.com> * configure: Regenerated.
2015-04-01GDBServer: give more complete usage informationPedro Alves2-7/+39
--attach/--multi are currently only mentioned on the usage info first lines, the meaning of PROG is completely absent and the COMM text does not mention '-/stdio'. A few options are missing: . --disable-randomization / --no-disable-randomization is not mentioned. Although the manual has a comment saying these are superceded by QDisableRandomization, that only makes sense for "run" in extended-remote mode. When we start gdbserver passing it a PROG, --disable-randomization / --no-disable-randomization do take effect. So I think we should document these. . We show --debug / --remote-debug, so might as well show --disable-packet too. GDB's --help has this "For more information, consult the GDB manual" blurb that is missing in GDBserver's --help. Then shuffle things around a bit into "Operating modes", "Other options" and "Debug options" sections, similarly to GDB's --help structure. Before: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ $ ./gdbserver/gdbserver --help Usage: gdbserver [OPTIONS] COMM PROG [ARGS ...] gdbserver [OPTIONS] --attach COMM PID gdbserver [OPTIONS] --multi COMM COMM may either be a tty device (for serial debugging), or HOST:PORT to listen for a TCP connection. Options: --debug Enable general debugging output. --debug-format=opt1[,opt2,...] Specify extra content in debugging output. Options: all none timestamp --remote-debug Enable remote protocol debugging output. --version Display version information and exit. --wrapper WRAPPER -- Run WRAPPER to start new programs. --once Exit after the first connection has closed. Report bugs to "<http://www.gnu.org/software/gdb/bugs/>". ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ After: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ $ ./gdbserver/gdbserver --help Usage: gdbserver [OPTIONS] COMM PROG [ARGS ...] gdbserver [OPTIONS] --attach COMM PID gdbserver [OPTIONS] --multi COMM COMM may either be a tty device (for serial debugging), HOST:PORT to listen for a TCP connection, or '-' or 'stdio' to use stdin/stdout of gdbserver. PROG is the executable program. ARGS are arguments passed to inferior. PID is the process ID to attach to, when --attach is specified. Operating modes: --attach Attach to running process PID. --multi Start server without a specific program, and only quit when explicitly commanded. --once Exit after the first connection has closed. --help Print this message and then exit. --version Display version information and exit. Other options: --wrapper WRAPPER -- Run WRAPPER to start new programs. --disable-randomization Run PROG with address space randomization disabled. --no-disable-randomization Don't disable address space randomization when starting PROG. Debug options: --debug Enable general debugging output. --debug-format=opt1[,opt2,...] Specify extra content in debugging output. Options: all none timestamp --remote-debug Enable remote protocol debugging output. --disable-packet=opt1[,opt2,...] Disable support for RSP packets or features. Options: vCont, Tthread, qC, qfThreadInfo and threads (disable all threading packets). For more information, consult the GDB manual (available as on-line info or a printed manual). Report bugs to "<http://www.gnu.org/software/gdb/bugs/>". ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ gdb/gdbserver/ChangeLog: 2015-04-01 Pedro Alves <palves@redhat.com> Cleber Rosa <crosa@redhat.com> * server.c (gdbserver_usage): Reorganize and extend the usage message.
2015-03-31Implement support for checking /proc/PID/coredump_filterSergio Durigan Junior8-28/+765
This patch, as the subject says, extends GDB so that it is able to use the contents of the file /proc/PID/coredump_filter when generating a corefile. This file contains a bit mask that is a representation of the different types of memory mappings in the Linux kernel; the user can choose to dump or not dump a certain type of memory mapping by enabling/disabling the respective bit in the bit mask. Currently, here is what is supported: bit 0 Dump anonymous private mappings. bit 1 Dump anonymous shared mappings. bit 2 Dump file-backed private mappings. bit 3 Dump file-backed shared mappings. bit 4 (since Linux 2.6.24) Dump ELF headers. bit 5 (since Linux 2.6.28) Dump private huge pages. bit 6 (since Linux 2.6.28) Dump shared huge pages. (This table has been taken from core(5), but you can also read about it on Documentation/filesystems/proc.txt inside the Linux kernel source tree). The default value for this file, used by the Linux kernel, is 0x33, which means that bits 0, 1, 4 and 5 are enabled. This is also the default for GDB implemented in this patch, FWIW. Well, reading the file is obviously trivial. The hard part, mind you, is how to determine the types of the memory mappings. For that, I extended the code of gdb/linux-tdep.c:linux_find_memory_regions_full and made it rely *much more* on the information gathered from /proc/<PID>/smaps. This file contains a "verbose dump" of the inferior's memory mappings, and we were not using as much information as we could from it. If you want to read more about this file, take a look at the proc(5) manpage (I will also write a blog post soon about everything I had to learn to get this patch done, and when I it is ready I will post it here). With Oleg Nesterov's help, we could improve the current algorithm for determining whether a memory mapping is anonymous/file-backed, private/shared. GDB now also respects the MADV_DONTDUMP flag and does not dump the memory mapping marked as so, and will always dump "[vsyscall]" or "[vdso]" mappings (just like the Linux kernel). In a nutshell, what the new code is doing is: - If the mapping is associated to a file whose name ends with " (deleted)", or if the file is "/dev/zero", or if it is "/SYSV%08x" (shared memory), or if there is no file associated with it, or if the AnonHugePages: or the Anonymous: fields in the /proc/PID/smaps have contents, then GDB considers this mapping to be anonymous. There is a special case in this, though: if the memory mapping is a file-backed one, but *also* contains "Anonymous:" or "AnonHugePages:" pages, then GDB considers this mapping to be *both* anonymous and file-backed, just like the Linux kernel does. What that means is simple: this mapping will be dumped if the user requested anonymous mappings *or* if the user requested file-backed mappings to be present in the corefile. It is worth mentioning that, from all those checks described above, the most fragile is the one to see if the file name ends with " (deleted)". This does not necessarily mean that the mapping is anonymous, because the deleted file associated with the mapping may have been a hard link to another file, for example. The Linux kernel checks to see if "i_nlink == 0", but GDB cannot easily do this check (as it has been discussed, GDB would need to run as root, and would need to check the contents of the /proc/PID/map_files/ directory in order to determine whether the deleted was a hardlink or not). Therefore, we made a compromise here, and we assume that if the file name ends with " (deleted)", then the mapping is indeed anonymous. FWIW, this is something the Linux kernel could do better: expose this information in a more direct way. - If we see the flag "sh" in the VmFlags: field (in /proc/PID/smaps), then certainly the memory mapping is shared (VM_SHARED). If we have access to the VmFlags, and we don't see the "sh" there, then certainly the mapping is private. However, older Linux kernels (see the code for more details) do not have the VmFlags field; in that case, we use another heuristic: if we see 'p' in the permission flags, then we assume that the mapping is private, even though the presence of the 's' flag there would mean VM_MAYSHARE, which means the mapping could still be private. This should work OK enough, however. Finally, it is worth mentioning that I added a new command, 'set use-coredump-filter on/off'. When it is 'on', it will read the coredump_filter' file (if it exists) and use its value; otherwise, it will use the default value mentioned above (0x33) to decide which memory mappings to dump. gdb/ChangeLog: 2015-03-31 Sergio Durigan Junior <sergiodj@redhat.com> Jan Kratochvil <jan.kratochvil@redhat.com> Oleg Nesterov <oleg@redhat.com> PR corefiles/16092 * linux-tdep.c: Include 'gdbcmd.h' and 'gdb_regex.h'. New enum identifying the various options of the coredump_filter file. (struct smaps_vmflags): New struct. (use_coredump_filter): New variable. (decode_vmflags): New function. (mapping_is_anonymous_p): Likewise. (dump_mapping_p): Likewise. (linux_find_memory_regions_full): New variables 'coredumpfilter_name', 'coredumpfilterdata', 'pid', 'filterflags'. Removed variable 'modified'. Read /proc/<PID>/smaps file; improve parsing of its information. Implement memory mapping filtering based on its contents. (show_use_coredump_filter): New function. (_initialize_linux_tdep): New command 'set use-coredump-filter'. * NEWS: Mention the possibility of using the '/proc/PID/coredump_filter' file when generating a corefile. Mention new command 'set use-coredump-filter'. gdb/doc/ChangeLog: 2015-03-31 Sergio Durigan Junior <sergiodj@redhat.com> PR corefiles/16092 * gdb.texinfo (gcore): Mention new command 'set use-coredump-filter'. (set use-coredump-filter): Document new command. gdb/testsuite/ChangeLog: 2015-03-31 Sergio Durigan Junior <sergiodj@redhat.com> PR corefiles/16092 * gdb.base/coredump-filter.c: New file. * gdb.base/coredump-filter.exp: Likewise.
2015-03-31Catch exception on solib_svr4_r_ldsomapSergio Durigan Junior2-6/+20
When loading a corefile that has some inaccessible memory region(s), GDB complains about it: (gdb) core /my/corefile [New LWP 28468] Cannot access memory at address 0x355fc21148 Cannot access memory at address 0x355fc21140 (gdb) However, despite not seeing the message "Core was generated by...", it is still possible to inspect the corefile using regular GDB commands. The reason for that is because read_memory_unsigned_integer throws an exception when it cannot read the memory region, but solib_svr4_r_ldsomap was not catching it. The fix is to catch the exception and act accordingly. Tested on Fedora 20 x86_64, no regressions found. gdb/ChangeLog: 2015-03-31 Sergio Durigan Junior <sergiodj@redhat.com> * solib-svr4.c (solib_svr4_r_ldsomap): Catch possible exception by read_memory_unsigned_integer.
2015-03-31Add --with-system-zlib in gdbH.J. Lu7-101/+39
This patch adds --with-system-zlib and removes --with-zlib in gdb. * Makefile.in (ZLIB): New. (ZLIBINC): Likewise. (INTERNAL_CFLAGS_BASE): Add $(ZLIBINC). (CLIBS): Add $(ZLIB). * acinclude.m4: (GDB_AC_CHECK_BFD): Add $zlibdir to LDFLAGS. Add -lz to LIBS. * gdb_bfd.c: Don't check HAVE_ZLIB_H to include <zlib.h>. * top.c (print_gdb_configuration): Remove --with-zlib and --without-zlib. * config.in: Regenerated. * configure: Likewise.
2015-03-31dwarf.exp: Allow generating a stub .debug_line sectionPetr Machata2-1/+150
Example of use: Dwarf::assemble "foo.s" { build_id 0102030405060708 declare_labels L; cu {is_64 0 version 4 addr_size 8} { DW_TAG_compile_unit { {DW_AT_stmt_list $L DW_FORM_sec_offset} } { DW_TAG_subprogram { # We can now reference the source file. {DW_AT_decl_file 1 DW_FORM_data1} } } } lines {is_64 0 version 2 addr_size 8} L { include_dir "foo" include_dir "bar" file_name "foo.c" 1 file_name "bar.c" 1 file_name "baz.c" 2 } } Signed-off-by: Petr Machata <pmachata@redhat.com>
2015-03-31Add cpu information to the info os command on linux.Antoine Tremblay5-73/+199
This patch adds cpu information on linux based on /proc/cpuinfo as : cpus Listing of all cpus/cores on the system This patch also reorders the info os commands so that they are listed in alphabetical order. gdb/ChangeLog: * NEWS: Mention info os cpus support. * gdb/nat/linux-osdata.c (linux_xfer_osdata_cpus): New function. (struct osdata_type): Add cpus entry, reorder the entries in alphabetical order. gdb/doc/ChangeLog: * gdb.texinfo (Operating System Auxiliary Information): Add info os cpus documentation, reorder the info os entries in alphabetical order.
2015-03-31Fix the triplet regexp to recognize triplets, not only quadrupletsMatthias Klose2-1/+8
This allows triplets where the vendor is not set. gdb/ChangeLog: 2015-03-31 Matthias Klose <doko@ubuntu.com> * compile/compile.c (compile_to_object): Allow triplets with or without vendor set.
2015-03-30PR c++/18141Doug Evans2-2/+11
gdb/ChangeLog: PR c++/18141 * cp-namespace.c (cp_search_static_and_baseclasses): Always look for klass in VAR_DOMAIN.
2015-03-30Remove three redundant wrapper functions in remote.cGary Benson2-27/+15
gdb/ChangeLog: * remote.c (remote_mourn_1): Remove function. Update all callers to use remote_mourn. (extended_remote_mourn_1): Remove function. Update all callers to use extended_remote_mourn. (extended_remote_attach_1): Remove function. Update all callers to use extended_remote_attach.
2015-03-28gdb: ft32: new portJames Bowman5-1/+595
FT32 is a new high performance 32-bit RISC core developed by FTDI for embedded applications.
2015-03-27Revert: Code cleanup: Move print_command_1 expr variable scopeJan Kratochvil2-2/+8
Simon Marchi: I think this patch is wrong. Starting with that commit (f30d5c7), some tests (e.g. mi-break.exp) started to fail for me, because of gdb segfaulting. The address of expr is passed to the cleanup. When the cleanup is ran, expr is no longer in scope, so what is at that address is probably not safe to use anymore. That's my guess. gdb/ChangeLog 2015-03-27 Jan Kratochvil <jan.kratochvil@redhat.com> Revert: 2015-03-26 Jan Kratochvil <jan.kratochvil@redhat.com> Code cleanup. * printcmd.c (print_command_1): Move expr variable scope.
2015-03-27Initialize EXPR in dtrace-probe::dtrace_process_dof_probeJoel Brobecker2-1/+5
GCC 4.4.7 generates the following warning: | cc1: warnings being treated as errors | dtrace-probe.c: In function ‘dtrace_process_dof_probe’: | dtrace-probe.c:416: error: ‘expr’ may be used uninitialized in this function | make[2]: *** [dtrace-probe.o] Error 1 Later versions (GCC 5) do a better job and don't generate the warning, but it does not hurt to pre-initialize "expr" to NULL. gdb/ChangeLog: * dtrace-probe.c (dtrace_process_dof_probe): Initialize expr to NULL.
2015-03-27Fix gdb_bfd_section_index for special sectionsAndrzej Kaczmarek2-4/+9
Indexes returned for special sections are off by one, i.e. with N+4 sections last one has index N+4 returned which is outside allocated obstack (at the same time index N is not used at all). In worst case, if sections obstack is allocated up to end of chunk, writing last section data will cause buffer overrun and some data corruption. Here's output from Valgrind:: ==14630== Invalid write of size 8 ==14630== at 0x551B1A: add_to_objfile_sections_full (objfiles.c:225) ==14630== by 0x552768: allocate_objfile (objfiles.c:324) ==14630== by 0x4E8E2E: symbol_file_add_with_addrs (symfile.c:1171) ==14630== by 0x4E9453: symbol_file_add_from_bfd (symfile.c:1280) ==14630== by 0x4E9453: symbol_file_add (symfile.c:1295) ==14630== by 0x4E94B7: symbol_file_add_main_1 (symfile.c:1320) ==14630== by 0x514246: catch_command_errors_const (main.c:398) ==14630== by 0x5150AA: captured_main (main.c:1061) ==14630== by 0x51123C: catch_errors (exceptions.c:240) ==14630== by 0x51569A: gdb_main (main.c:1164) ==14630== by 0x408824: main (gdb.c:32) ==14630== Address 0x635f3b8 is 8 bytes after a block of size 4,064 alloc'd ==14630== at 0x4C2ABA0: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==14630== by 0x60F797: xmalloc (common-utils.c:41) ==14630== by 0x5E787FB: _obstack_begin (obstack.c:184) ==14630== by 0x552679: allocate_objfile (objfiles.c:294) ==14630== by 0x4E8E2E: symbol_file_add_with_addrs (symfile.c:1171) ==14630== by 0x4E9453: symbol_file_add_from_bfd (symfile.c:1280) ==14630== by 0x4E9453: symbol_file_add (symfile.c:1295) ==14630== by 0x4E94B7: symbol_file_add_main_1 (symfile.c:1320) ==14630== by 0x514246: catch_command_errors_const (main.c:398) ==14630== by 0x5150AA: captured_main (main.c:1061) ==14630== by 0x51123C: catch_errors (exceptions.c:240) ==14630== by 0x51569A: gdb_main (main.c:1164) ==14630== by 0x408824: main (gdb.c:32) gdb/ChangeLog: * gdb_bfd.c (gdb_bfd_section_index): Fix off-by-one for special sections.
2015-03-26testsuite: Don't set SYMBOL_PREFIX for x86_64_*_cygwinJon Turney2-1/+6
Exactly like x86_64-*-mingw, SYMBOL_PREFIX should not be set to "_" for x86_64_*_cygwin gdb/testuite/ChangeLog: * lib/gdb.exp (gdb_target_symbol_prefix_flags): Don't set SYMBOL_PREFIX for x86_64-*-cygwin.
2015-03-26dtrace-probe: Handle error while parsing probe argument.Joel Brobecker4-2/+45
The debugger on Solaris has been broken since the introduction of DTrace probe support: (gdb) start Temporary breakpoint 1 at 0x80593bc: file simple_main.adb, line 4. Starting program: /[...]/simple_main [Thread debugging using libthread_db enabled] No definition of "mutex_t" in current context. The problem occurs while trying to parse a probe's argument, and the exception propagates all the way to the top. This patch fixes the issue by containing the exception and falling back on using the "long" builtin type if the argument's type could not be determined. Also, the parsing should be done using the C language parser. gdb/ChangeLog: * dtrace-probe.c (dtrace_process_dof_probe): Contain any exception raised while parsing the probe arguments. Force parsing to be done using the C language parser. * expression.h (parse_expression_with_language): Declare. * parse.c (parse_expression_with_language): New function.
2015-03-26Add myself as a write-after-approval GDB maintainerJon Turney2-0/+5
gdb/ChangeLog: * MAINTAINERS (Write After Approval): Add "Jon Turney".
2015-03-26Fix copy-paste typo in -data-write-memory-bytes docSimon Marchi2-1/+6
* gdb.texinfo (GDB/MI Data Manipulation): Fix copy-paste typo in -data-write-memory-bytes.
2015-03-26Properly intern constants into psymtabAndy Wingo5-3/+115
Variables with a DW_AT_const_value but without a DW_AT_location were not getting added to the partial symbol table. They are added to the full symbol table, however, when the compilation unit's psymtabs are expanded. Before: (gdb) p one No symbol "one" in current context. (gdb) mt flush-symbol-cache (gdb) mt expand one.c (gdb) p one $1 = 1 After: (gdb) p one $1 = 1 To the user it's pretty strange, as depending on whether tab completion has forced expansion of all CUs or not the lookup might succeed, or not if the failure was already added to the symbol cache. This commit simply makes sure to add constants to the partial symbol tables. gdb/testsuite/ChangeLog: PR symtab/18148 * gdb.dwarf2/dw2-intercu.S (one, two): Add variables that have a const_value but not a location. * gdb.dwarf2/dw2-intercu.exp: Add tests that constants without location defined in non-main CUs are visible. gdb/ChangeLog: PR symtab/18148 * dwarf2read.c (struct partial_die_info): Add has_const_value member. (add_partial_symbol): Don't punt on symbols that have const_value attributes. (read_partial_die): Detect DW_AT_const_value.
2015-03-26Code cleanup: Move print_command_1 expr variable scopeJan Kratochvil2-1/+7
gdb/ChangeLog 2015-03-26 Jan Kratochvil <jan.kratochvil@redhat.com> Code cleanup. * printcmd.c (print_command_1): Move expr variable scope.
2015-03-26Code cleanup: Make validate_format parameter constJan Kratochvil2-1/+6
gdb/ChangeLog 2015-03-26 Jan Kratochvil <jan.kratochvil@redhat.com> Code cleanup. * printcmd.c (validate_format): Make the parameter cmdname const.
2015-03-26Clarify comment on the purpose of the assertion loop in _initialize_remote.Don Breazeal2-1/+6
gdb/ChangeLog: 2015-03-26 Don Breazeal <donb@codesourcery.com> * remote.c (_initialize_remote): Update comment.
2015-03-26Don't set breakpoints on import stubs on Windows amd64Pedro Alves2-13/+32
On Windows amd64, setting a breakpoint on a symbol imported from a shared library after that library is loaded creates a breakpoint with two locations, one on the import stub, and another in the shared library, while on i386, the breakpoint is only set in the shared library. This is due to the minimal symbol for the import stub not being correctly given the type mst_solib_trampoline on Windows amd64, unlike Windows i386. As currently written, coff_symfile_read is always skipping over the character after the "__imp_" (amd64) or "_imp_" (i386) prefix, assuming that it is '_'. However, while i386 is an underscored target, amd64 is not. On x86_64-pc-cygwin, it fixes: - FAIL: gdb.base/solib-symbol.exp: foo in libmd + PASS: gdb.base/solib-symbol.exp: foo in libmd Unfortunately, several other tests which passed now fail but that's because this issue was masking other problems. No change on i686-pc-cygwin. gdb/ChangeLog: 2015-03-26 Pedro Alves <palves@redhat.com> Jon TURNEY <jon.turney@dronecode.org.uk> * coffread.c (coff_symfile_read): When constructing the name of an import stub symbol from import symbol for amd64, only skip the char after _imp_ if the target is underscored (like i386) and the char is indeed the target's leading char.
2015-03-26Handle the effect of skipping prologueYao Qi3-0/+36
break-asm-file.exp has some manually written dwarf to create some line number entries like this, [0x0000013d] Extended opcode 2: set Address to 0x40053f [0x00000144] Advance Line by 4 to 7 [0x00000146] Copy [0x00000147] Extended opcode 2: set Address to 0x400541 [0x0000014e] Advance Line by 1 to 8 [0x00000150] Copy [0x00000151] Extended opcode 2: set Address to 0x400547 [0x00000158] Extended opcode 1: End of Sequence 0x40053f is the start address of function func, and is mapped to line 7. 0x400541 is within function func, and is mapped to line 8. (gdb) disassemble /r 0x40053f,+8 Dump of assembler code from 0x40053f to 0x400547: 0x000000000040053f <func+0>: 00 00 add %al,(%rax) 0x0000000000400541 <func+2>: 00 00 add %al,(%rax) 0x0000000000400543 <func+4>: 00 00 add %al,(%rax) 0x0000000000400545 <func+6>: 00 00 add %al,(%rax) in the following test, (gdb) break a/break-asm-file0.s:func Breakpoint 1 at 0x40053f: file a/break-asm-file0.s, line 7. As we can see, breakpoint is set at the start address of function func on x86, which means no prologue is skipped. On other targets, such as arm and aarch64, breakpoint is set at the address *after* the start address, which is mapped to line 8. Then test fails. In fact, it is lucky this test doesn't fail on x86 and x86_64, whose gdbarch method skip_prologue doesn't reply on skip_prologue_using_sal if producer isn't clang. if (find_pc_partial_function (start_pc, NULL, &func_addr, NULL)) { CORE_ADDR post_prologue_pc = skip_prologue_using_sal (gdbarch, func_addr); struct compunit_symtab *cust = find_pc_compunit_symtab (func_addr); /* Clang always emits a line note before the prologue and another one after. We trust clang to emit usable line notes. */ if (post_prologue_pc && (cust != NULL && COMPUNIT_PRODUCER (cust) != NULL && startswith (COMPUNIT_PRODUCER (cust), "clang "))) return max (start_pc, post_prologue_pc); } so it doesn't return and go further to prologue analyser. Since ".int 0" isn't an instruction of prologue, nothing is skipped, starting address is used, and test passes. however, on targets which don't have such producer checking, the first line number entry is skipped, and skip_prologue_using_sal returns sal represents the second line number entry. The idea of this patch is to force GDB stop at somewhere which is stilled mapped to line 7 after skipping prologue. I choose to add a new line number entry for the following instruction but mapped to the same line (7), because I see the comments in dwarf2read.c, ... fact that two consecutive line number entries for the same line is a heuristic used by gcc to denote the end of the prologue. then the line table becomes: [0x000000d4] Extended opcode 2: set Address to 0x400529 [0x000000db] Advance Line by 4 to 7 [0x000000dd] Copy [0x000000de] Extended opcode 2: set Address to 0x40052a [0x000000e5] Advance Line by 0 to 7 [0x000000e7] Copy [0x000000e8] Extended opcode 2: set Address to 0x40052b [0x000000ef] Advance Line by 1 to 8 [0x000000f1] Copy [0x000000f2] Extended opcode 2: set Address to 0x40052c [0x000000f9] Extended opcode 1: End of Sequence gdb/testsuite: 2015-03-26 Yao Qi <yao.qi@linaro.org> PR testsuite/18139 * gdb.linespec/break-asm-file0.s (func): New label .Lfunc_2. Add a line number entry for the same line. * gdb.linespec/break-asm-file1.s (func): New label .Lfunc_2. Add a line number entry for the same line.
2015-03-26Remove some hard-coded stuff in testsYao Qi3-10/+23
There are some hard-coded stuff in .s files, such as .int 0 and address offset, which isn't portable. This patch is to replace ".int 0" with nop and address offset with labels. gdb/testsuite: 2015-03-26 Yao Qi <yao.qi@linaro.org> * gdb.linespec/break-asm-file0.s (func2): Use nop instead of .int 0. (func): Likewise. Add .Lfunc_1 label. Use .Lfunc_1 label. * gdb.linespec/break-asm-file1.s (func3): Use nop instead of .int 0. (func): Likewise. Use .Lfunc_1 label.
2015-03-26Compile break-asm-file{0,1}.s without debug infoYao Qi2-5/+24
If I add some nop into break-asm-file1.s like this, --- INDEX:/gdb/testsuite/gdb.linespec/break-asm-file1.s +++ WORKDIR:/gdb/testsuite/gdb.linespec/break-asm-file1.s @@ -31,8 +31,8 @@ _func: .type func, %function func: .Lbegin_func: - .int 0 - .int 0 + nop + nop .Lend_func: .size func, .-func .Lend_text1: I get the following error: Running gdb/testsuite/gdb.linespec/break-asm-file.exp ... gdb/testsuite/gdb.linespec/break-asm-file1.s: Assembler messages:^M gdb/testsuite/gdb.linespec/break-asm-file1.s: Fatal error: duplicate .debug_line sections break-asm-file0.s and break-asm-file1.s have already had debug information (written manually), so don't need to generate debug infor for them. gdb/testsuite: 2015-03-26 Yao Qi <yao.qi@linaro.org> * gdb.linespec/break-asm-file.exp: Don't call prepare_for_testing. Call gdb_compile instead to compile each .s files without debug information.
2015-03-26Relax pattern to match the output of "info frame" in gdb.base/savedregs.expYao Qi2-1/+6
Hi, I see the following two fails in gdb.base/savedregs.exp on aarch64-linux, info frame 2^M Stack frame at 0x7ffffffa60:^M pc = 0x40085c in thrower (/home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.base/savedregs.c:49); saved pc = 0x400898^M called by frame at 0x7ffffffa70, caller of frame at 0x7fffffe800^M source language c.^M Arglist at 0x7ffffffa60, args: ^M Locals at 0x7ffffffa60, Previous frame's sp is 0x7ffffffa60^M (gdb) FAIL: gdb.base/savedregs.exp: Get thrower info frame info frame 2^M Stack frame at 0x7fffffe800:^M pc = 0x400840 in catcher (/home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.base/savedregs.c:42); saved pc = 0x7fb7ffc350^M called by frame at 0x7fffffe800, caller of frame at 0x7fffffe7e0^M source language c.^M Arglist at 0x7fffffe7f0, args: sig=11^M Locals at 0x7fffffe7f0, Previous frame's sp is 0x7fffffe800 (gdb) FAIL: gdb.base/savedregs.exp: Get catcher info frame looks the test expects to match "Saved registers:" from the output of "info frame", but no registers are saved on these two frames, because thrower and catcher are simple and leaf functions. (gdb) disassemble thrower Dump of assembler code for function thrower: 0x0000000000400858 <+0>: mov x0, #0x0 // #0 0x000000000040085c <+4>: strb wzr, [x0] 0x0000000000400860 <+8>: ret End of assembler dump. (gdb) disassemble catcher Dump of assembler code for function catcher: 0x0000000000400838 <+0>: sub sp, sp, #0x10 0x000000000040083c <+4>: str w0, [sp,#12] 0x0000000000400840 <+8>: adrp x0, 0x410000 0x0000000000400844 <+12>: add x0, x0, #0xb9c 0x0000000000400848 <+16>: mov w1, #0x1 // #1 0x000000000040084c <+20>: str w1, [x0] 0x0000000000400850 <+24>: add sp, sp, #0x10 0x0000000000400854 <+28>: ret There are two ways to fix these fails, one is to modify functions to force some registers saved (for example, doing function call in them), and the other one is to relax the pattern to optionally match "Saved registers:". I did both, and feel that the latter is simple, so here is it. gdb/testsuite: 2015-03-26 Yao Qi <yao.qi@linaro.org> * gdb.base/savedregs.exp (process_saved_regs): Make "Saved registers:" optional in the pattern.
2015-03-25btrace: fix tests for 32-bitMarkus Metzger17-428/+1057
The x86-record_goto.S assembly source file does not build on 32-bit. This breaks many tests that use this file. Split it into x86_64-record_goto.S and i686-record_goto.S. Luckily, we can use either one with the same test .exp file. It further turned out that most tests do not really need a fixed binary; they should work pretty well with a newly-compiled C program. The one thing that breaks this is the heavy use of "record goto" to navigate inside the recorded execution. Combine step.exp, next,exp, and finish.exp into a single test step.exp and use normal stepping and reverse-stepping commands for navigation. testsuite/ * gdb.btrace/next.exp: Merged into step.exp. * gdb.btrace/finish.exp: Merged into step.exp. * gdb.btrace/nexti.exp: Merged into stepi.exp. * gdb.btrace/step.exp: Use record_goto.c as test file. Avoid using "record goto" and checking the exact replay position. * gdb.btrace/stepi.exp: Choose test file based on target. Do not check for "Recording format" in "info record" output. * gdb.btrace/record_goto.exp: Choose test file based on target. * gdb.btrace/x86-record_goto.S: Renamed into ... * gdb.btrace/x86_64-record_goto.S: ... this. * gdb.btrace/i686-record_goto.S: New. * gdb.btrace/x86-tailcall.S: Renamed into ... * gdb.btrace/x86_64-tailcall.S: ... this. * gdb.btrace/i686-tailcall.S: New. * gdb.btrace/x86-tailcall.c: Renamed into ... * gdb.btrace/tailcall.c: ... this. Split "return ++answer" into two separate statements. Update test. * gdb.btrace/delta.exp: Use record_goto.c as test file. * gdb.btrace/gcore.exp: Use record_goto.c as test file. * gdb.btrace/nohist.exp: Use record_goto.c as test file. * gdb.btrace/tailcall.exp: Choose test file based on target. * gdb.btrace/Makefile.in: Remove next, finish, and nexti.
2015-03-25btrace: increase buffer size for exception testMarkus Metzger2-0/+6
The trace for throwing and catching an exception can be quite big. Increase the buffer size to avoid spurious fails. testsuite/ * gdb.btrace/exception.exp: Increase BTS buffer size.
2015-03-25Simplify target_async hook interfacePedro Alves9-68/+70
All callers of target_async pass it the same callback (inferior_event_handler). Since both common code and target backends need to be able to put the target in and out of target async mode at any given time, there's really no way that a different callback could be passed. This commit simplifies things, and removes the indirection altogether. Bonus: with this, gdb's target_async method ends up with the same signature as gdbserver's. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ChangeLog: 2015-03-25 Pedro Alves <palves@redhat.com> * target.h <to_async>: Replace 'callback' and 'context' parameters with boolean 'enable' parameter. (target_async): Replace CALLBACK and CONTEXT parameters with boolean ENABLE parameter. * inf-loop.c (inferior_event_handler): Adjust. * linux-nat.c (linux_nat_attach, linux_nat_resume) (linux_nat_resume): Adjust. (async_client_callback, async_client_context): Delete. (handle_target_event): Call inferior_event_handler directly. (linux_nat_async): Replace 'callback' and 'context' parameters with boolean 'enable' parameter. Adjust. Remove references to async_client_callback and async_client_context. (linux_nat_close): Adjust. * record-btrace.c (record_btrace_async): Replace 'callback' and 'context' parameters with boolean 'enable' parameter. Adjust. (record_btrace_resume): Adjust. * record-full.c (record_full_async): Replace 'callback' and 'context' parameters with boolean 'enable' parameter. Adjust. (record_full_resume, record_full_core_resume): Adjust. * remote.c (struct remote_state) <async_client_callback, async_client_context>: Delete fields. (remote_start_remote, extended_remote_attach_1, remote_resume) (extended_remote_create_inferior): Adjust. (remote_async_serial_handler): Call inferior_event_handler directly. (remote_async): Replace 'callback' and 'context' parameters with boolean 'enable' parameter. Adjust. * top.c (gdb_readline_wrapper_cleanup, gdb_readline_wrapper): Adjust. * target-delegates.c: Regenerate.
2015-03-25Associate target_ops with target_fileio file descriptorsGary Benson2-52/+132
Various target_fileio_* functions use integer file descriptors to refer to open files. File operation functions are looked up from the target stack as they are used, which causes problems if the target stack changes after the file is opened. For example, if a file is opened on a remote target and the remote target disconnects or closes the remote target will be popped off the stack. If target_fileio_close is then called on that file and "set auto-connect-native-target" is "on" (the default) then the native target's close method will be called. If the file opened on the remote happens to share the same number with a file open in GDB then that file will be closed by mistake. This commit changes target_fileio_open to store newly opened file descriptors in a table together with the target_ops used to open them. The index into the table is returned and used as the file descriptor argument to all target_fileio_* functions that accept file descriptor arguments. gdb/ChangeLog: * target.c (fileio_ft_t): New typedef, define object vector. (fileio_fhandles): New static variable. (is_closed_fileio_fh): New macro. (lowest_closed_fd): New static variable. (acquire_fileio_fd): New function. (release_fileio_fd): Likewise. (fileio_fd_to_fh): New macro. (target_fileio_open): Wrap the file descriptor on success. (target_fileio_pwrite): Updated to use wrapped file descriptor. (target_fileio_pread): Likewise. (target_fileio_close): Likewise.
2015-03-24Fix "thread apply all" with exited threadsPedro Alves4-5/+23
I noticed that "thread apply all" sometimes crashes. The problem is that thread_apply_all_command doesn take exited threads into account, and we qsort and then walk more elements than there really ever were put in the array. Valgrind shows: The current thread <Thread ID 3> has terminated. See `help thread'. (gdb) thread apply all p 1 Thread 1 (Thread 0x7ffff7fc2740 (LWP 29579)): $1 = 1 ==29576== Use of uninitialised value of size 8 ==29576== at 0x639CA8: set_thread_refcount (thread.c:1337) ==29576== by 0x5C2C7B: do_my_cleanups (cleanups.c:155) ==29576== by 0x5C2CE8: do_cleanups (cleanups.c:177) ==29576== by 0x63A191: thread_apply_all_command (thread.c:1477) ==29576== by 0x50374D: do_cfunc (cli-decode.c:105) ==29576== by 0x506865: cmd_func (cli-decode.c:1893) ==29576== by 0x7562CB: execute_command (top.c:476) ==29576== by 0x647DA4: command_handler (event-top.c:494) ==29576== by 0x648367: command_line_handler (event-top.c:692) ==29576== by 0x7BF7C9: rl_callback_read_char (callback.c:220) ==29576== by 0x64784C: rl_callback_read_char_wrapper (event-top.c:171) ==29576== by 0x647CB5: stdin_event_handler (event-top.c:432) ==29576== ... This can happen easily today as linux-nat.c/linux-thread-db.c are forgetting to purge non-current exited threads. But even with that fixed, we can always do "thread apply all" with an exited thread selected, which won't be deleted until the user switches to another thread. That's what the test added by this commit exercises. Tested on x86_64 Fedora 20. gdb/ChangeLog: 2015-03-24 Pedro Alves <palves@redhat.com> * thread.c (thread_apply_all_command): Take exited threads into account. gdb/testsuite/ChangeLog: 2015-03-24 Pedro Alves <palves@redhat.com> * gdb.threads/no-unwaited-for-left.exp: Test "thread apply all".
2015-03-24Fix switch_back_to_stepped_thread comment referencesPedro Alves2-4/+9
Whoops, switch_back_to_stepping doesn't exist... gdb/ 2015-03-24 Pedro Alves <palves@redhat.com> * infrun.c (resume, proceed): Mention switch_back_to_stepped_thread, not switch_back_to_stepping.
2015-03-24Shuffle user_visible_resume_ptidPedro Alves3-17/+29
... and move comment to declaration. gdb/ChangeLog: 2015-03-24 Pedro Alves <palves@redhat.com> * infrun.c (user_visible_resume_ptid): Rewrite going from most-locked to unlocked instead of the opposite. Move comment ... * infrun.h (user_visible_resume_ptid): ... here.
2015-03-24Debug output tweaks in the Linux target backendsPedro Alves4-25/+73
This adds/tweaks a few debug logs I found useful recently. gdb/gdbserver/ChangeLog: 2015-03-24 Pedro Alves <palves@redhat.com> * linux-low.c (check_stopped_by_breakpoint): Tweak debug log output. Also dump TRAP_TRACE. (linux_low_filter_event): In debug output, distinguish a resume_stop SIGSTOP from a delayed SIGSTOP. gdb/ChangeLog: 2015-03-24 Pedro Alves <palves@redhat.com> * linux-nat.c (linux_nat_resume): Output debug logs before trying to resume the event lwp. Use the lwp's ptid instead of the passed in (maybe wildcard) ptid. (stop_wait_callback): Tweak debug log output. (check_stopped_by_breakpoint): Tweak debug log output. Also dump TRAP_TRACE. (linux_nat_filter_event): In debug output, distinguish a resume_stop SIGSTOP from a delayed SIGSTOP. Output debug logs before trying to resume the lwp.
2015-03-24Do not make "prop" field of struct dynamic_prop_list a pointer.Joel Brobecker3-5/+11
struct dynamic_prop_list is declared as follow: struct dynamic_prop_list { [...] /* The dynamic property itself. */ struct dynamic_prop *prop; [...] }; In this case, the pointer indirection is unnecessary and costing us, for each dynamic property, the memory needed to store one pointer. This patch removes this pointer indirection, savin us a tiny bit of memory, as well as reduces a bit the complexity by removing the need to allocate memory for the property, as the allocation is now part of the struct itself. gdb/ChangeLog: * gdbtypes.h (struct dynamic_prop_list) <prop>: Remove pointer indirection. * gdbtypes.c (get_dyn_prop): Adjust, following change above. (add_dyn_prop, copy_dynamic_prop_list): Likewise. Tested on x86_64-linux.
2015-03-24GDB: rename DYN_ATTR_DATA_LOCATION into DYN_PROP_DATA_LOCATION.Joel Brobecker3-3/+12
The terminology we've been using is (dynamic) "property" rather than "attribute", so this patch renames an enum to use the same terminology. No behavior change. gdb/ChangeLog: * gdbtypes.h (enum dynamic_prop_node_kind) <DYN_PROP_DATA_LOCATION>: Renames DYN_ATTR_DATA_LOCATION. (TYPE_DATA_LOCATION): Use DYN_PROP_DATA_LOCATION instead of DYN_ATTR_DATA_LOCATION. * dwarf2read.c (set_die_type): Use DYN_PROP_DATA_LOCATION instead of DYN_ATTR_DATA_LOCATION. Tested on x86_64-linux.
2015-03-24Remove 'step' parameters from 'proceed' and 'resume'Pedro Alves8-57/+105
The "step" parameters of 'proceed' and 'resume' aren't really useful as indication of whether run control wants to single-step the target, as that information must already be retrievable from currently_stepping. In fact, if currently_stepping disagrees with whether we single-stepped the target, then things break. Thus instead of having the same information in two places, this patch removes those parameters. Setting 'step_start_function' is the only user of proceed's 'step' argument, other than passing the 'step' argument down to 'resume' and debug log output. Move that instead to set_step_frame, where we already set other related fields. clear_proceed_status keeps its "step" parameter for now because it needs to know which set of threads should have their state cleared, and is called before the "stepping_command" flag is set. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ChangeLog: 2015-03-24 Pedro Alves <palves@redhat.com> * breakpoint.c (until_break_command): Adjust call to proceed. * gdbthread.h (struct thread_control_state) <stepping_command>: New field. * infcall.c (run_inferior_call): Adjust call to proceed. * infcmd.c (run_command_1, proceed_thread_callback, continue_1): Adjust calls to proceed. (set_step_frame): Set the current thread's step_start_function here. (step_once): Adjust calls to proceed. (jump_command, signal_command, until_next_command) (finish_backward, finish_forward, proceed_after_attach_callback) (attach_command_post_wait): Adjust calls to proceed. * infrun.c (proceed_after_vfork_done): Adjust call to proceed. (do_target_resume): New function, factored out from ... (resume): ... here. Remove 'step' parameter. Instead, check currently_stepping to determine whether the thread should be single-stepped. (proceed): Remove 'step' parameter and don't set the thread's step_start_function here. Adjust call to 'resume'. (handle_inferior_event): Adjust calls to 'resume'. (switch_back_to_stepped_thread): Use do_target_resume instead of 'resume'. (keep_going): Adjust calls to 'resume'. * infrun.h (proceed): Remove 'step' parameter. (resume): Likewise. * windows-nat.c (do_initial_windows_stuff): Adjust call to 'resume'. * mi/mi-main.c (proceed_thread): Adjust call to 'proceed'.
generated by cgit v1.1 at 2025-09-18 19:13:30 +0000