On GNU/Linux, if the running kernel supports clone events, then
linux-thread-db.c defers thread listing to the target beneath:
static void
thread_db_update_thread_list (struct target_ops *ops)
{
...
if (target_has_execution && !thread_db_use_events ())
ops->beneath->to_update_thread_list (ops->beneath);
else
thread_db_update_thread_list_td_ta_thr_iter (ops);
...
}
However, when live debugging, the target beneath, linux-nat.c, does
not implement the to_update_thread_list method. The result is that if
a thread is marked exited (because it can't be deleted right now,
e.g., it was the selected thread), then it won't ever be deleted,
until the process exits or is killed/detached.
A similar thing happens with the remote.c target. Because its
target_update_thread_list implementation skips exited threads when it
walks the current thread list looking for threads that no longer exits
on the target side, using ALL_NON_EXITED_THREADS_SAFE, stale exited
threads are never deleted.
This is not a big deal -- I can't think of any way this might be user
visible, other than gdb's memory growing a tiny bit whenever a thread
gets stuck in exited state. Still, might as well clean things up
properly.
All other targets use prune_threads, so are unaffected.
The fix adds a ALL_THREADS_SAFE macro, that like
ALL_NON_EXITED_THREADS_SAFE, walks the thread list and allows deleting
the iterated thread, and uses that in places that are walking the
thread list in order to delete threads. Actually, after converting
linux-nat.c and remote.c to use this, we find the only other user of
ALL_NON_EXITED_THREADS_SAFE is also walking the list to delete
threads. So we convert that too, and end up deleting
ALL_NON_EXITED_THREADS_SAFE.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/ChangeLog
2015-04-07 Pedro Alves <palves@redhat.com>
* gdbthread.h (ALL_NON_EXITED_THREADS_SAFE): Rename to ...
(ALL_THREADS_SAFE): ... this, and don't skip exited threads.
(delete_exited_threads): New declaration.
* infrun.c (follow_exec): Use ALL_THREADS_SAFE.
* linux-nat.c (linux_nat_update_thread_list): New function.
(linux_nat_add_target): Install it.
* remote.c (remote_update_thread_list): Use ALL_THREADS_SAFE.
* thread.c (prune_threads): Use ALL_THREADS_SAFE.
(delete_exited_threads): New function.
Although not currently possible in practice when we get here,
'resume_ptid' can also be a wildcard throughout this function. It's
clearer to fetch the regcache using the thread's ptid.
gdb/ChangeLog:
2015-04-07 Pedro Alves <pedro@codesourcery.com>
* infrun.c (resume) <displaced stepping debug output>: Get the
leader thread's regcache, not resume_ptid's.
gdb/ChangeLog:
* symtab.c (hash_symbol_entry): Hash STRUCT_DOMAIN symbols as
VAR_DOMAIN.
(symbol_cache_lookup): Clarify use of bsc_ptr, slot_ptr parameters.
Include symbol domain in debugging output.
Currently building gdb is impossible without an installed termcap or
curses library. But, GDB already has a very minimal termcap in the
tree to handle this situation for Windows -- gdb/stub-termcap.c. This
patch makes that the fallback for all hosts.
Testing this on GNU/Linux (by simply hacking away the termcap/curses
detection in gdb/configure.ac), we trip on:
../readline/libreadline.a(terminal.o): In function `_rl_init_terminal_io':
/home/pedro/gdb/mygit/src/readline/terminal.c:527: undefined reference to `PC'
/home/pedro/gdb/mygit/src/readline/terminal.c:528: undefined reference to `BC'
/home/pedro/gdb/mygit/src/readline/terminal.c:529: undefined reference to `UP'
/home/pedro/gdb/mygit/src/readline/terminal.c:538: undefined reference to `PC'
/home/pedro/gdb/mygit/src/readline/terminal.c:539: undefined reference to `BC'
/home/pedro/gdb/mygit/src/readline/terminal.c:540: undefined reference to `UP'
These are globals that are normally defined by termcap (or ncurses'
termcap emulation).
Now, we could just define replacements in stub-termcap.c, but
readline/terminal.c (at least the copy in our tree) has this:
#if !defined (__linux__) && !defined (NCURSES_VERSION)
# if defined (__EMX__) || defined (NEED_EXTERN_PC)
extern
# endif /* __EMX__ || NEED_EXTERN_PC */
char PC, *BC, *UP;
#endif /* !__linux__ && !NCURSES_VERSION */
which can result in readline defining the globals too. That will
usually work out in C, given that "-fcommon" is usually the default
for C compilers, but that won't work for C++, or C with -fno-common
(link fails with "multiple definition" errors)...
Mirroring those #ifdef conditions in the stub termcap screams
"brittle" to me -- I can see them changing in latter readline
versions.
Work around that by simply using __attribute__((weak)).
Windows/PE/COFF's do support weak, but not on gcc 3.4 based toolchains
(4.8.x does work). Given the file never needed the variables while it
was Windows-only, just continue not defining them there. All other
supported hosts should support this.
gdb/ChangeLog:
2015-04-06 Pedro Alves <palves@redhat.com>
Bernd Edlinger <bernd.edlinger@hotmail.de>
* configure.ac: Remove the mingw32-specific stub-termcap.o
fallback, and instead fallback to the stub termcap on all hosts.
* configure: Regenerate.
* stub-termcap.c [!__MINGW32__] (PC, BC, UP): Define as weak
symbols.
This paramater is no longer useful after the previous commit, so remove
it as a cleanup.
gdb/ChangeLog:
* gdbtypes.c (is_dynamic_type_internal): Remove the unused
"top_level" parameter.
(resolve_dynamic_type_internal): Remove the unused "top_level"
parameter. Update call to is_dynamic_type_internal.
(is_dynamic_type): Update call to is_dynamic_type_internal.
(resolve_dynamic_range): Update call to
resolve_dynamic_type_internal.
(resolve_dynamic_union): Likewise.
(resolve_dynamic_struct): Likewise.
(resolve_dynamic_type): Likewise.
Even when referenced types are dynamic, the corresponding referencing
type should not be considered as dynamic: it's only a pointer. This
prevents reference type for values not in memory to be resolved.
gdb/ChangeLog:
* gdbtypes.c (is_dynamic_type_internal): Remove special handling
of TYPE_CODE_REF types so that they are not considered as
dynamic depending on the referenced type.
(resolve_dynamic_type_internal): Likewise.
gdb/testsuite/ChangeLog:
* gdb.ada/funcall_ref.exp: New file.
* gdb.ada/funcall_ref/foo.adb: New file.
This commit makes GDB default to a sysroot of "target:".
One testcase needed updating as a result of this change.
gdb/ChangeLog:
* main.c (captured_main): Set gdb_sysroot to "target:"
if not otherwise set.
gdb/testsuite/ChangeLog:
* gdb.base/break-probes.exp: Cope with "target:" sysroot.
This commit adds support for filenames prefixed with "target:" to
exec_file_attach. This is required to correctly follow inferior
exec* calls when a gdb_sysroot prefixed with "target:" is set.
gdb/ChangeLog:
* exec.c (exec_file_attach): Support "target:" filenames.
This commit updates solib_find to strip the "target:" prefix from
gdb_sysroot when accessing local files. This ensures that the same
search algorithm is used for local files regardless of whether a
"target:" prefix was used or not. It also avoids cluttering GDB's
output with unnecessary "target:" prefixes on paths.
gdb/ChangeLog:
* solib.c (solib_find): Strip "target:" prefix from sysroot
if accessing local files.
symfile_bfd_open handled what were remote files as a special case.
Converting from "remote:" files to "target:" made symfile_bfd_open
look like this:
if remote:
open bfd, check format, etc
return
local-specific stuff
open bfd, check format, etc
return
This commit rearranges symfile_bfd_open to remove the duplicated
code, like this:
if local:
local-specific stuff
open bfd, check format, etc
return
gdb/ChangeLog:
* symfile.c (symfile_bfd_open): Reorder to remove duplicated
checks and error messages.
The functionality of "target:" sysroots is a superset of the
functionality of "remote:" sysroots. This commit causes the
"set sysroot" command to rewrite "remote:" sysroots as "target:"
sysroots and replaces "remote:" specific code with "target:"
specific code where still necessary.
gdb/ChangeLog:
* remote.h (REMOTE_SYSROOT_PREFIX): Remove definition.
(remote_filename_p): Remove declaration.
(remote_bfd_open): Likewise.
* remote.c (remote_bfd_iovec_open): Remove function.
(remote_bfd_iovec_close): Likewise.
(remote_bfd_iovec_pread): Likewise.
(remote_bfd_iovec_stat): Likewise.
(remote_filename_p): Likewise.
(remote_bfd_open): Likewise.
* symfile.h (gdb_bfd_open_maybe_remote): Remove declaration.
* symfile.c (separate_debug_file_exists): Use gdb_bfd_open.
(gdb_bfd_open_maybe_remote): Remove function.
(symfile_bfd_open): Replace remote filename check with
target filename check.
(reread_symbols): Use gdb_bfd_open.
* build-id.c (gdbcore.h): New include.
(build_id_to_debug_bfd): Use gdb_bfd_open.
* infcmd.c (attach_command_post_wait): Remove remote filename
check.
* solib.c (solib_find): Replace remote-specific handling with
target-specific handling. Update comments where necessary.
(solib_bfd_open): Replace remote-specific handling with
target-specific handling.
(gdb_sysroot_changed): New function.
(_initialize_solib): Call the above when gdb_sysroot changes.
* windows-tdep.c (gdbcore.h): New include.
(windows_xfer_shared_library): Use gdb_bfd_open.
This commit updates gdb_bfd_open to access files using target
fileio functions if the supplied path starts with "target:"
and if the local and target filesystems are not the same.
This allows users to specify "set sysroot target:" and have
GDB access files locally or from the remote as appropriate.
The new functions in gdb_bfd.c are copies of functions from
remote.c. This duplication is intentional and will be removed
by the next commit in this series.
gdb/ChangeLog:
* gdb/gdb_bfd.h (TARGET_SYSROOT_PREFIX): New definition.
(is_target_filename): New declaration.
(gdb_bfd_has_target_filename): Likewise.
(gdb_bfd_open): Update documentation comment.
* gdb_bfd.c (target.h): New include.
(gdb/fileio.h): Likewise.
(is_target_filename): New function.
(gdb_bfd_has_target_filename): Likewise.
(fileio_errno_to_host): Likewise.
(gdb_bfd_iovec_fileio_open): Likewise.
(gdb_bfd_iovec_fileio_pread): Likewise.
(gdb_bfd_iovec_fileio_close): Likewise.
(gdb_bfd_iovec_fileio_fstat): Likewise.
(gdb_bfd_open): Use target fileio to access paths prefixed
with "target:" where necessary.
This commit introduces a new target method target_filesystem_is_local
which can be used to determine whether or not the filesystem accessed
by the target_fileio_* methods is the local filesystem.
gdb/ChangeLog:
* target.h (struct target_ops) <to_filesystem_is_local>:
New field.
(target_filesystem_is_local): New macro.
* target-delegates.c: Regenerate.
* remote.c (remote_filesystem_is_local): New function.
(init_remote_ops): Initialize to_filesystem_is_local.
This commit introduces a new target method target_fileio_fstat
which can be used to retrieve information about files opened with
target_fileio_open.
gdb/ChangeLog:
* target.h (struct target_ops) <to_fileio_fstat>: New field.
(target_fileio_fstat): New declaration.
* target.c (target_fileio_fstat): New function.
* inf-child.c (inf_child_fileio_fstat): Likewise.
(inf_child_target): Initialize to_fileio_fstat.
* remote.c (init_remote_ops): Likewise.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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".
... 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.
