Looking at the current random signal checks:
if (ecs->event_thread->suspend.stop_signal == GDB_SIGNAL_TRAP)
random_signal
= !((bpstat_explains_signal (ecs->event_thread->control.stop_bpstat,
GDB_SIGNAL_TRAP)
!= BPSTAT_SIGNAL_NO)
|| stopped_by_watchpoint
|| ecs->event_thread->control.trap_expected
|| (ecs->event_thread->control.step_range_end
&& (ecs->event_thread->control.step_resume_breakpoint
== NULL)));
else
{
enum bpstat_signal_value sval;
sval = bpstat_explains_signal (ecs->event_thread->control.stop_bpstat,
ecs->event_thread->suspend.stop_signal);
random_signal = (sval == BPSTAT_SIGNAL_NO);
if (sval == BPSTAT_SIGNAL_HIDE)
ecs->event_thread->suspend.stop_signal = GDB_SIGNAL_0;
}
We can observe:
- the stepping checks bit:
...
|| ecs->event_thread->control.trap_expected
|| (ecs->event_thread->control.step_range_end
&& (ecs->event_thread->control.step_resume_breakpoint
== NULL)));
...
is just like currently_stepping:
static int
currently_stepping (struct thread_info *tp)
{
return ((tp->control.step_range_end
&& tp->control.step_resume_breakpoint == NULL)
|| tp->control.trap_expected
|| bpstat_should_step ());
}
except it misses the bpstat_should_step check (***).
It's not really necessary to check bpstat_should_step in the
random signal tests, because software watchpoints always end up in
the bpstat list anyway, which means bpstat_explains_signal with
GDB_SIGNAL_TRAP always returns at least BPSSTAT_SIGNAL_HIDE, but I
think the code is clearer if we reuse currently_stepping.
*** - bpstat_should_step checks to see if there's any software
watchpoint in the breakpoint list, because we need to force the
target to single-step all the way, to evaluate the watchpoint's
value at each step.
- we never hide GDB_SIGNAL_TRAP, even if the bpstat returns
BPSTAT_SIGNAL_HIDE, which is actually the default for all
breakpoints. If we make the default be BPSTAT_SIGNAL_PASS, then
we can merge the two bpstat_explains_signal paths.
gdb/
2013-11-14 Pedro Alves <palves@redhat.com>
* breakpoint.c (bpstat_explains_signal) <Moribund locations>:
Return BPSTAT_SIGNAL_PASS instead of BPSTAT_SIGNAL_HIDE.
(explains_signal_watchpoint): Return BPSTAT_SIGNAL_PASS instead of
BPSTAT_SIGNAL_HIDE.
(base_breakpoint_explains_signal): Return BPSTAT_SIGNAL_PASS
instead of BPSTAT_SIGNAL_HIDE.
* infrun.c (handle_inferior_event): Rework random signal checks.
This goes a step forward in making only TARGET_WAITKIND_STOPPED talk
about signals.
There's no reason for the "catchpoint" TARGET_WAITKIND_XXXs to consult
bpstat about signals -- unlike breakpoints, all these events are
continuable, so we don't need to do a remove-break/step/reinsert-break
-like dance. That means we don't actually need to run them through
process_event_stop_test (for the bpstat_what checks), and can just use
bpstat_causes_stop instead. Note we were already using it in the
TARGET_WAITKIND_(V)FORKED cases.
Then, these "catchpoint" waitkinds don't need to set
ecs->random_signal for anything, because they check it immediately
afterwards (and the value they set is never used again).
gdb/
2013-11-14 Pedro Alves <palves@redhat.com>
* infrun.c (struct execution_control_state): Remove
'random_signal' field.
(handle_syscall_event): Use bpstat_causes_stop instead of
bpstat_explains_signal. Don't set ecs->random_signal.
(handle_inferior_event): New 'random_signal' local.
<TARGET_WAITKIND_FORKED, TARGET_WAITKIND_VFORKED,
TARGET_WAITKIND_EXECD>: Use bpstat_causes_stop instead of
bpstat_explains_signal. Don't set ecs->random_signal.
<TARGET_WAITKIND_STOPPED>: Adjust to use local instead of
ecs->random_signal.
This comment applies to the whole handle_inferior_event flow, top to
bottom. Best move it to the function's intro.
gdb/
2013-11-14 Pedro Alves <palves@redhat.com>
* infrun.c (handle_inferior_event): Move comment from the
function's body to the function's description, adjusted.
Of all the TARGET_WAITKIND_XXXs event kinds other than
TARGET_WAITKIND_STOPPED, TARGET_WAITKIND_LOADED is the only kind that
doesn't end in a return, instead falling through to all the
signal/breakpoint/stepping handling code. But it only falls through
in the STOP_QUIETLY_NO_SIGSTOP and STOP_QUIETLY_REMOTE cases, which
means the
/* This is originated from start_remote(), start_inferior() and
shared libraries hook functions. */
if (stop_soon == STOP_QUIETLY || stop_soon == STOP_QUIETLY_REMOTE)
{
if (debug_infrun)
fprintf_unfiltered (gdb_stdlog, "infrun: quietly stopped\n");
stop_stepping (ecs);
return;
}
bit is eventually reached. All tests before that is reached will
always fail. It's simpler to inline the stop_soon checks close to the
TARGET_WAITKIND_LOADED code, which allows removing the fall through.
Tested on x86_64 Fedora 17, but that doesn't exercise this
TARGET_WAITKIND_LOADED.
Also ran gdb.base/solib-disc.exp on Cygwin/gdbserver, which exercises
reconnection while the inferior is stopped at an solib event, but then
again, gdbserver always replies a regular trap on initial connection,
instead of the last event the program had seen:
Sending packet: $?#3f...Packet received: T0505:4ca72800;04:f8a62800;08:62fcc877;thread:d28;
Sending packet: $Hc-1#09...Packet received: E01
Sending packet: $qAttached#8f...Packet received: 0
Packet qAttached (query-attached) is supported
infrun: clear_proceed_status_thread (Thread 3368)
Sending packet: $qOffsets#4b...Packet received:
infrun: wait_for_inferior ()
infrun: target_wait (-1, status) =
infrun: 42000 [Thread 3368],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x77c8fc62
infrun: quietly stopped
infrun: stop_stepping
So the only way to exercise this would be to hack gdbserver. I didn't
go that far though. I'm reasonably confident this is correct.
gdb/
2013-11-14 Pedro Alves <palves@redhat.com>
* infrun.c (handle_inferior_event) <TARGET_WAITKIND_LOADED>:
Handle STOP_QUIETLY_NO_SIGSTOP and STOP_QUIETLY_REMOTE here.
Assert we never fall through out of the TARGET_WAITKIND_LOADED
case.
While digging into a different memory corruption error, I happened to
notice one coming from the linetable code. In a couple of spots, the
wrong termination condition was used in a loop, leading gdb to read
one element past the end of the linetable.
Built and regtested on x86-64 Fedora 18. Also verified using
valgrind. I'm checking this in.
2013-11-14 Tom Tromey <tromey@redhat.com>
* python/py-linetable.c (ltpy_has_line)
(ltpy_get_all_source_lines): Fix loop termination condition.
Frontend sometimes need to evaluate expressions that are
language-specific. For instance, Eclipse uses the following
expression to determine the size of an address on the target:
-data-evaluate-expression "sizeof (void*)"
Unfortunately, if the main of the program being debugged is not C,
this may not work. For instance, if the main is in Ada, you get...
-data-evaluate-expression "sizeof (void*)"
^error,msg="No definition of \"sizeof\" in current context."
... and apparently decides to stop the debugging session as a result.
The recommendation sent was to specifically set the language to C
before trying to evaluate the expression. Something such as:
1. save current language
2. set language c
3. -data-evaluate-expression "sizeof (void*)"
4. Restore language
This has the same disadvantages as the ones outlined in the "Context
Management" section of the GDB/MI documentation regarding setting
the current thread or the current frame, thus recommending the use of
general command-line switches such as --frame, or --thread instead.
This patch follows the same steps for the language, adding a similar
new command option: --language LANG. Example of use:
-data-evaluate-expression --language c "sizeof (void*)"
^done,value="4"
gdb/ChangeLog:
* mi/mi-parse.h (struct mi_parse) <language>: New field.
* mi/mi-main.c (mi_cmd_execute): Temporarily set language to
PARSE->LANGUAGE during command execution, if set.
* mi/mi-parse.c: Add "language.h" #include.
(mi_parse): Add parsing of "--language" command option.
* NEWS: Add entry mentioning the new "--language" command option.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-language.exp: New file.
gdb/doc/ChangeLog:
* gdb.texinfo (Show): Add xref anchor for "show language" command.
(Context management): Place current subsection text into its own
subsubsection. Add new subsubsection describing the "--language"
command option.
This function provides the exact same functionality as extract_arg,
except that it takes a "const char**" instead of a "char **".
It allows us also to re-implement extract_arg almost as a simple
wrapper around the new function.
gdb/ChangeLog:
Pedro Alves <palves@redhat.com>
Joel Brobecker <brobecker@adacore.com>
* cli/cli-utils.h (extract_arg_const): Add declaration.
* cli/cli-utils.c (extract_arg_const): New function.
(extract_arg): Reimplement using extract_arg_const.
In addition to the fact that language.h depends on a number of struct
types declared in symtab.h, language.h also depends on an enumerated
type (domain_enum). So language.h should #include "symtab.h".
gdb/ChangeLog:
* language.h: Add "symtab.h" #include.
Rather than having -list-features report support for the GDB/MI
commands providing access to Ada exception catchpoints with one entry,
and the GDB/MI command providing the list of Ada exceptions with
a second entry, this patch merges it all within one single entry.
This is OK, because all these commands were added within a short
amount of time, and within the same release cycle; and it reduces
a bit the size of the output.
gdb/ChangeLog:
* mi/mi-main.c (mi_cmd_list_features): Replace "info-ada-exceptions"
entry with "ada-exceptions".
gdb/doc/ChangeLog:
* gdb.texinfo (GDB/MI Miscellaneous Commands): Delete
the documentation of "info-ada-exceptions" in the output
of the "-list-features" command. Add the documentation
of the "ada-exception" entry instead.
This patch aims at fixing the following problem, where the user:
. debugs its program
. makes a modification and rebuilds it *without exiting the debugger*
. returns to its debugging session and restarts the inferior
In that situation, the debugger notices that the underlying executable
has changed and that re-reading its symbols is needed. Shortly after
displaying a message informing the user of the situation, GDB crashes:
(gdb) run
[...]
`/[...]/dest' has changed; re-reading symbols.
zsh: 13434922 segmentation fault (core dumped)
The crash occurs while trying to allocate some memory on the bfd_bfd
obstack. But, at some point in time, the whole obstack data gets
corrupted, nullified. So the memory allocation fails trying to call
a function at a NULL address. (side note: when debugging GDB in GDB,
top-gdb reports a SIGILL, while the shell makes it look like it was
a SIGSEGV - the discrepancy is not critical to the investigation
and therefore was not explored)
The corruption occurred because the region where the per_bfd data
got free'ed nearly after it got allocated! This is what happens,
in chronological order (see reread_symbols):
1. GDB notices that the executable has changed, decides to
re-read its symbols.
2. Opens a new bfd, unrefs the old one
3. Calls set_objfile_per_bfd (objfile);
4. Re-initializes the objfile's obstack:
obstack_init (&objfile->objfile_obstack);
I think that the normal behavior for set_objfile_per_bfd would
be to search for already-allocated shared per_bfd data, and
allocate new one if not found. The critical difference between
a platform such as x86_64-linuxe where it works, and ppc-aix,
where it doesn't lies in the fact that bfd-data sharing is not
activated on ppc-aix, and as a result, the per-bfd data gets
allocated on the objfile's obstack instead of in the bfd objalloc:
/* If the object requires gdb to do relocations, we simply fall
back to not sharing data across users. These cases are rare
enough that this seems reasonable. */
if (abfd != NULL && !gdb_bfd_requires_relocations (abfd))
{
storage = bfd_zalloc (abfd, sizeof (struct objfile_per_bfd_storage));
set_bfd_data (abfd, objfiles_bfd_data, storage);
}
else
storage = OBSTACK_ZALLOC (&objfile->objfile_obstack,
struct objfile_per_bfd_storage);
Allocating that per_bfd storage is of course nearly useless since
we end up free-ing right after in step (4) above. Eventually,
the memory region ends up being re-used, hence the corruption
leading to the crash.
This fix was simply to move the call to set_objfile_per_bfd after
the objfile's obstack re-initialization.
gdb/ChangeLog:
* symfile.c (reread_symbols): Move call to set_objfile_per_bfd
after re-initialization of OBJFILE's obstack.
Upstream GCC's new pass '-fisolate-erroneous-paths' may introduce
traps at places where GCC has determined undefined behavior, e.g. when
passing a NULL pointer to a function that defines this argument as
__attribute__(__nonnull__(...)). In particular this applies to
uniquify_strings(), because it invokes qsort() with NULL when the
'strings' vector is empty. I hit this problem on s390x when trying to
execute "break main" on a C program.
gdb/
2013-11-12 Andreas Arnez <arnez@linux.vnet.ibm.com>
* objc-lang.c (uniquify_strings): Prevent invoking qsort with
NULL.
* dwarf2read.c (read_index_from_section): Update comment.
(struct dw2_symtab_iterator): New member global_seen.
(dw2_symtab_iter_init): Initialize it.
(dw2_symtab_iter_next): Skip duplicate global symbols.
(dw2_expand_symtabs_matching): Ditto.
This patch adds a new command "info exceptions" whose purpose is to
provide the list of exceptions currently defined in the inferior.
The usage is:
(gdb) info exceptions [REGEXP]
Without argument, the command lists all exceptions. Otherwise,
only those whose name match REGEXP are listed.
For instance:
(gdb) info exceptions
All defined Ada exceptions:
constraint_error: 0x613dc0
program_error: 0x613d40
storage_error: 0x613d00
tasking_error: 0x613cc0
global_exceptions.a_global_exception: 0x613a80
global_exceptions.a_private_exception: 0x613ac0
The name of the command, as well as its output is part of a legacy
I inherited long ago. It's output being parsed by frontends such as
GPS, I cannot easily change it. Same for the command name.
The implementation is mostly self-contained, and is written in a way
that should make it easy to implement the GDB/MI equivalent. The
careful reviewer will notice that the code added in ada-lang.h could
normally be made private inside ada-lang.c. But these will be used
by the GDB/MI implementation. Rather than making those private now,
only to move them later, I've made them public right away.
gdb/ChangeLog:
* ada-lang.h: #include "vec.h".
(struct ada_exc_info): New.
(ada_exc_info): New typedef.
(DEF_VEC_O(ada_exc_info)): New vector.
(ada_exceptions_list): Add declaration.
* ada-lang.c (ada_is_exception_sym)
(ada_is_non_standard_exception_sym, compare_ada_exception_info)
(sort_remove_dups_ada_exceptions_list)
(ada_exc_search_name_matches, ada_add_standard_exceptions)
(ada_add_exceptions_from_frame, ada_add_global_exceptions)
(ada_exceptions_list_1, ada_exceptions_list)
(info_exceptions_command): New function.
(_initialize_ada_language): Add "info exception" command.
gdb/testsuite/ChangeLog:
* gdb.ada/info_exc: New testcase.
When using the GDB/MI commands to insert a catchpoint on a specific
Ada exception, any re-evaluation of that catchpoint (for instance
a re-evaluation performed after a shared library got mapped by the
inferior) fails. For instance, with any Ada program:
(gdb)
-catch-exception -e program_error
^done,bkptno="1",bkpt={[...]}
(gdb)
-exec-run
=thread-group-started,id="i1",pid="28315"
=thread-created,id="1",group-id="i1"
^running
*running,thread-id="all"
(gdb)
=library-loaded,[...]
&"warning: failed to reevaluate internal exception condition for catchpoint 1: No definition of \"exec\" in current context.\n"
&"warning: failed to reevaluate internal exception condition for catchpoint 1: No definition of \"exec\" in current context.\n"
[...]
The same is true if using an Ada exception catchpoint.
The problem comes from the fact that that we deallocate the strings
given as arguments to create_ada_exception_catchpoint, while the latter
just makes shallow copies of those strings, thus creating dandling
pointers.
This patch fixes the issue by passing freshly allocated strings to
create_ada_exception_catchpoint, while at the same time updating
create_ada_exception_catchpoint's documentation to make it clear
that deallocating the strings is no longer the responsibility of
the caller.
gdb/ChangeLog:
* ada-lang.c (create_ada_exception_catchpoint): Enhance
the documentation of fields "except_string" and "condition".
* mi/mi-cmd-catch.c (mi_cmd_catch_assert): Reallocate
CONDITION on the heap before passing it to
create_ada_exception_catchpoint.
(mi_cmd_catch_exception): Likewise for EXCEPTION_NAME and
CONDITION.
gdb/testsuite/ChangeLog:
* gdb.ada/mi_ex_cond: New testcase.
Tested on x86_64-linux. The "-break-list" test FAILs without
this patch.
An earlier patch removed the check for "syscall" since the results
were not used in the C code. However, the result was used, via the
cache variable, elsewhere in configure.
This patch fixes the problem by checking for "syscall" at the point at
which HAVE_TKILL_SYSCALL is defined.
2013-11-11 Tom Tromey <tromey@redhat.com>
* config.in, configure: Rebuild.
* configure.ac (HAVE_TKILL_SYSCALL): Check for "syscall".
* dwarf2read.c (dwarf2_read_debug): Change to unsigned int.
(create_debug_types_hash_table): Only print debugging messages for
each TU if dwarf2-read >= 2.
(process_queue): Ditto.
(_initialize_dwarf2_read): Make "set debug dwarf2-read" a zuinteger.
Update doc string.
doc/
* gdb.texinfo (Debugging Output): Update text for
"set debug dwarf2-read".
My grepping around showed that HAVE_MULTIPLE_PROC_FDS is only ever
mentioned in a comment in configure.ac. Since the macro is long dead,
let's remove the last mention.
2013-11-08 Tom Tromey <tromey@redhat.com>
* configure: Rebuild.
* configure.ac: Remove mentions of HAVE_MULTIPLE_PROC_FDS.
Now that the configury needed for the "common" and "target"
directories is in common.m4, some code in gdb's configure.ac is
redundant.
I ran this script after making an "ID" file using mkid:
sed -n 's/^.*\(HAVE_[A-Z0-9_]*\).*$/\1/p' config.in |
while read x; do
echo ===== $x
gid $x | egrep -v '^(testsuite|gnulib|common|target|gdbserver)/'
done
This finds all the spots using HAVE_ defines, and, more importantly,
makes it clear which defines aren't used in the main parts of gdb.
From this I came up with this patch to remove all the unused bits.
There are a few that are subtly used -- for example the configure
script sometimes checks internal configure cache variables, meaning
some checks cannot be removed.
2013-11-08 Tom Tromey <tromey@redhat.com>
* configure, config.in: Rebuild.
* configure.ac: Remove unused configury.
m32c-tdep.c is the last user of HAVE_STRING_H in gdb proper. It
really ought to be using gdb_string.h instead, as the rest of gdb
does.
2013-11-08 Tom Tromey <tromey@redhat.com>
* m32c-tdep.c: Use gdb_string.h.
The removal of solib-sunos.c also removed the last user of various
macros defined by configure.
This patch removes the corresponding configure code.
2013-11-08 Tom Tromey <tromey@redhat.com>
* configure, config.in: Rebuild.
* configure.ac: Remove all link.h-related checks.
It has bothered me for a while that files in common/ use macros
defined via autoconf checks, but rely on each configure.ac doing the
proper checks independently.
This patch introduces common/common.m4 which consolidates the checks
assumed by code in common.
The rule I propose is that if something is needed or used by common,
it should be checked for by common.m4. However, if the check is also
needed by gdb or gdbserver, then it should be duplicated there.
Built and regtested on x86-64 Fedora 18 (though this is hardly the
most strenuous case) and using the Fedora 18 mingw cross compilers. I
also examined the config.in diffs to ensure that symbols did not go
missing.
2013-11-08 Tom Tromey <tromey@redhat.com>
* acinclude.m4: Include common.m4.
* common/common.m4: New file.
* configure, config.in: Rebuild.
* configure.ac: Use GDB_AC_COMMON.
2013-11-08 Tom Tromey <tromey@redhat.com>
* acinclude.m4: Include common.m4, codeset.m4.
* configure, config.in: Rebuild.
* configure.ac: Use GDB_AC_COMMON.
This patch constifies the target_ops method to_detach.
This is a small cleanup, but also, I think, a bug-prevention fix,
since gdb already acts as if the "args" argument here was const.
In particular, top.c:quit_force calls kill_or_detach via
iterate_over_inferiors. kill_or_detach calls target_detach, passing
the same argument each time. So, if one of these methods was not
const-correct, then kill_or_detach would change its behavior in a
strange way.
I could not build every target I modified in this patch. I've
inspected them all by hand, though. Many targets do not use the
"args" parameter; a couple pass it to atoi; and a few pass it on to
the to_detach method of the target beneath. The only code that
required a real change was in linux-nat.c, and that only needed the
introduction of a temporary variable for const-correctness.
2013-11-08 Tom Tromey <tromey@redhat.com>
* aix-thread.c (aix_thread_detach): Update.
* corelow.c (core_detach): Update.
* darwin-nat.c (darwin_detach): Update.
* dec-thread.c (dec_thread_detach): Update.
* gnu-nat.c (gnu_detach): Update.
* go32-nat.c (go32_detach): Update.
* inf-ptrace.c (inf_ptrace_detach): Update.
* inf-ttrace.c (inf_ttrace_detach): Update.
* linux-fork.c (linux_fork_detach): Update.
* linux-fork.h (linux_fork_detach): Update.
* linux-nat.c (linux_nat_detach): Update. Introduce "tem"
local for const-correctness.
* linux-thread-db.c (thread_db_detach): Update.
* monitor.c (monitor_detach): Update.
* nto-procfs.c (procfs_detach): Update.
* procfs.c (procfs_detach): Update.
* record.c (record_detach): Update.
* record.h (record_detach): Update.
* remote-m32r-sdi.c (m32r_detach): Update.
* remote-mips.c (mips_detach): Update.
* remote-sim.c (gdbsim_detach): Update.
* remote.c (remote_detach_1, remote_detach)
(extended_remote_detach): Update.
* sol-thread.c (sol_thread_detach): Update.
* target.c (target_detach): Make "args" const.
(init_dummy_target): Update.
* target.h (struct target_ops) <to_detach>: Make argument const.
(target_detach): Likewise.
* windows-nat.c (windows_detach): Update.
* python/py-breakpoint.c (bppy_get_temporary): New function.
(bppy_init): New keyword: temporary. Parse it and set breakpoint
to temporary if True.
2013-11-07 Phil Muldoon <pmuldoon@redhat.com>
* gdb.python/py-breakpoint.exp: Add temporary breakpoint tests.
2013-11-07 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Breakpoints In Python): Document temporary
option in breakpoint constructor, and add documentation to the
temporary attribute.
This patch does some cleanups, removing some language-related stuff.
Note that mi_cmd_var_info_expression uses varobj_language_string,
which is redundant, because we can get language name from
lang->la_natural_name.
varobj_language_string doesn't have "Ada", which looks like a bug to
me. With this patch applied, this problem doesn't exist, because the
language name is got from the same place (field la_natural_name).
gdb:
2013-11-07 Yao Qi <yao@codesourcery.com>
* mi/mi-cmd-var.c: Include "language.h".
(mi_cmd_var_info_expression): Get language name from
language_defn.
* varobj.c (varobj_language_string): Remove.
(variable_language): Remove declaration.
(languages): Remove.
(varobj_get_language): Change the type of return value.
(variable_language): Remove.
* varobj.h (enum varobj_languages): Remove.
(varobj_language_string): Remove declaration.
(varobj_get_language): Update declaration.
gdb/doc:
2013-11-07 Yao Qi <yao@codesourcery.com>
* gdb.texinfo (GDB/MI Variable Objects): Update doc about the
output of "-var-info-expression".
Hi,
When I add another name of language, I find field 'la_name' can be
'const char *'. This patch is to constify it.
gdb:
2013-11-07 Yao Qi <yao@codesourcery.com>
* language.c (language_str): Return const char *.
(add_language): Add const to 'language_names'
* language.h (struct language_defn) <la_name>: Add const.
(language_str: Update declaration.
When checking for the presence of the TDB regset, the current code
interprets ENODATA from PTRACE_GETREGSET as an indication that the TDB
regset *could* occur on this system, but the inferior stopped outside
a transaction. However, the Linux kernel actually reports ENODATA
even on systems without the transactional execution facility. Thus
the logic is now changed to check the TE field in the HWCAP as well.
This version also checks the existence of the TDB regset -- just to be
on the safe side when running on TE-enabled hardware with a kernel
that does not offer the TDB regset for some reason.
gdb/
* s390-linux-nat.c (s390_read_description): Consider the TE field
in the HWCAP for determining 'have_regset_tdb'.
gdbserver/
* linux-s390-low.c (HWCAP_S390_TE): New define.
(s390_arch_setup): Consider the TE field in the HWCAP for
determining 'have_regset_tdb'.
When reading objects with corrupt debug information it is possible that
the sibling chain can form a loop, which leads to an infinite loop and
memory exhaustion.
Avoid this situation by disregarding and DW_AT_sibling values that point
to a lower address than the current entry.
gdb/ChangeLog:
2013-11-06 Will Newton <will.newton@linaro.org>
PR gdb/12866
* dwarf2read.c (skip_one_die): Sanity check DW_AT_sibling
values. (read_partial_die): Likewise.
We add a new dir gdb.perf in testsuite for all performance tests.
However, current 'make check' logic will either run dejagnu in
directory testsuite or iterate all gdb.* directories which has *.exp
files. Both of them will run tests in gdb.perf. We want to achieve:
1) typical 'make check' should not run performance tests. In each perf
test case, GDB_PERFTEST_MODE is checked. If it doesn't exist, return.
2) run perf tests easily. We add a new makefile target 'check-perf'.
gdb:
2013-11-06 Yao Qi <yao@codesourcery.com>
* Makefile.in (check-perf): New target.
gdb/testsuite:
2013-11-06 Yao Qi <yao@codesourcery.com>
* Makefile.in (check-perf): New target.
* configure.ac (AC_OUTPUT): Output Makefile in gdb.perf.
* configure: Re-generated.
* gdb.perf/Makefile.in: New.
I noticed a large (100MB) restore took hours to complete. The problem
is memory_xfer_partial repeatedly mallocs and memcpys the entire
100MB buffer for breakpoint shadow handling only to find a small
portion of it is actually written.
The testcase that originally took hours now takes 50 seconds.
gdb/
2013-07-29 Anton Blanchard <anton@samba.org>
* target.c (memory_xfer_partial): Cap write to 4KB.
As discussed on the GDB ML[1], libc probes for longjmp were not being
loaded if a custom <arch>_get_longjmp_target function was not
implemented.
This is trivially fixed by moving the 'if (!gdbarch_get_longjmp_target_p
(gdbarch))' down, just bellow libc probe code and above the per-objfile
cache lookup.
While the condition could also be removed altogether with no
side-effects, it is in fact an optimization to avoid searching for
symbols if the arch doesn't provide support for get_longjmp_target().
This has been tested on PPC and PPC64.
[1] https://sourceware.org/ml/gdb/2013-10/msg00191.html
gdb/
2013-11-01 Tiago Stürmer Daitx <tdaitx@linux.vnet.ibm.com>
* breakpoint.c (create_longjmp_master_breakpoint): Allow libc
probe scan even when the arch provides no get_longjmp_target.
IMO, it doesn't make sense to map random syscall, fork, etc. events to
GDB_SIGNAL_TRAP, and possible have the debuggee see that trap. This
just seems conceptually wrong to me - these aren't real signals a
debuggee would ever see. In fact, when stopped for those events, on
Linux, the debuggee isn't in a signal-stop -- there's no way to
resume-and-deliver-signal at that point, for example. E.g., when
stopped at a fork event:
(gdb) catch fork
Catchpoint 2 (fork)
(gdb) c
Continuing.
Catchpoint 2 (forked process 4570), 0x000000323d4ba7c4 in __libc_fork () at ../nptl/sysdeps/unix/sysv/linux/fork.c:131
131 pid = ARCH_FORK ();
(gdb) set debug infrun 1
(gdb) signal SIGTRAP
Continuing with signal SIGTRAP.
infrun: clear_proceed_status_thread (process 4566)
infrun: proceed (addr=0xffffffffffffffff, signal=5, step=0)
infrun: resume (step=0, signal=5), trap_expected=0, current thread [process 4566] at 0x323d4ba7c4
infrun: wait_for_inferior ()
infrun: target_wait (-1, status) =
infrun: 4566 [process 4566],
infrun: status->kind = exited, status = 0
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_EXITED
[Inferior 1 (process 4566) exited normally]
infrun: stop_stepping
(gdb)
Note the signal went nowhere. It was swallowed.
Resuming with a SIGTRAP from a syscall event does queue the signal,
but doesn't deliver it immediately, like "signal SIGTRAP" from a real
signal would. It's still an artificial SIGTRAP:
(gdb) catch syscall
Catchpoint 2 (any syscall)
(gdb) c
Continuing.
Catchpoint 2 (call to syscall clone), 0x000000323d4ba7c4 in __libc_fork () at ../nptl/sysdeps/unix/sysv/linux/fork.c:131
131 pid = ARCH_FORK ();
(gdb) set debug infrun 1
(gdb) signal SIGTRAP
Continuing with signal SIGTRAP.
infrun: clear_proceed_status_thread (process 4622)
infrun: proceed (addr=0xffffffffffffffff, signal=5, step=0)
infrun: resume (step=0, signal=5), trap_expected=0, current thread [process 4622] at 0x323d4ba7c4
infrun: wait_for_inferior ()
infrun: target_wait (-1, status) =
infrun: 4622 [process 4622],
infrun: status->kind = exited syscall
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_SYSCALL_RETURN
infrun: syscall number = '56'
infrun: BPSTAT_WHAT_STOP_NOISY
infrun: stop_stepping
Catchpoint 2 (returned from syscall clone), 0x000000323d4ba7c4 in __libc_fork () at ../nptl/sysdeps/unix/sysv/linux/fork.c:131
131 pid = ARCH_FORK ();
(gdb) c
Continuing.
infrun: clear_proceed_status_thread (process 4622)
infrun: proceed (addr=0xffffffffffffffff, signal=144, step=0)
infrun: resume (step=0, signal=0), trap_expected=0, current thread [process 4622] at 0x323d4ba7c4
infrun: wait_for_inferior ()
infrun: target_wait (-1, status) =
infrun: 4622 [process 4622],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x323d4ba7c4
infrun: random signal 5
Program received signal SIGTRAP, Trace/breakpoint trap.
infrun: stop_stepping
0x000000323d4ba7c4 in __libc_fork () at ../nptl/sysdeps/unix/sysv/linux/fork.c:131
131 pid = ARCH_FORK ();
(gdb)
In all the above, I used 'signal SIGTRAP' to emulate 'handle SIGTRAP
pass'. As described in "keep_going", 'handle SIGTRAP pass' does have
its place:
/* Do not deliver GDB_SIGNAL_TRAP (except when the user
explicitly specifies that such a signal should be delivered
to the target program). Typically, that would occur when a
user is debugging a target monitor on a simulator: the target
monitor sets a breakpoint; the simulator encounters this
breakpoint and halts the simulation handing control to GDB;
GDB, noting that the stop address doesn't map to any known
breakpoint, returns control back to the simulator; the
simulator then delivers the hardware equivalent of a
GDB_SIGNAL_TRAP to the program being debugged. */
... and I've made use of that myself when implementing/debugging
stubs/monitors. But in these cases, treating these events as SIGTRAP
possibly injects signals in the debuggee they'd never see otherwise,
because you need to use ptrace to enable these special events, which
aren't real signals.
There's more. Take this bit of handle_inferior_event, where we
determine whether a real signal (TARGET_WAITKIND_STOPPED) was random
or not:
if (ecs->event_thread->suspend.stop_signal == GDB_SIGNAL_TRAP)
ecs->random_signal
= !((bpstat_explains_signal (ecs->event_thread->control.stop_bpstat,
GDB_SIGNAL_TRAP)
!= BPSTAT_SIGNAL_NO)
|| stopped_by_watchpoint
|| ecs->event_thread->control.trap_expected
|| (ecs->event_thread->control.step_range_end
&& (ecs->event_thread->control.step_resume_breakpoint
== NULL)));
else
{
enum bpstat_signal_value sval;
sval = bpstat_explains_signal (ecs->event_thread->control.stop_bpstat,
ecs->event_thread->suspend.stop_signal);
ecs->random_signal = (sval == BPSTAT_SIGNAL_NO);
if (sval == BPSTAT_SIGNAL_HIDE)
ecs->event_thread->suspend.stop_signal = GDB_SIGNAL_TRAP;
}
Note that the
if (sval == BPSTAT_SIGNAL_HIDE)
ecs->event_thread->suspend.stop_signal = GDB_SIGNAL_TRAP;
bit is only reacheable for signals != GDB_SIGNAL_TRAP. AFAICS, sval
can only be BPSTAT_SIGNAL_HIDE if nothing in the bpstat returns
BPSTAT_SIGNAL_PASS. So that excludes a "catch signal" for the signal
in question in the bpstat. All other catchpoints that aren't based on
breakpoints behind the scenes call process_event_stop_test directly
(don't pass through here) (well, almost all: TARGET_WAITKIND_LOADED
does have a fall through, but only for STOP_QUIETLY or
STOP_QUIETLY_NO_SIGSTOP, which still return before this code is
reached). Catchpoints that are implemented as breakpoints behind the
scenes can only appear in the bpstat if the signal was GDB_SIGNAL_TRAP
(bkpt_breakpoint_hit returns false otherwise). So that leaves a
target reporting a hardware watchpoint hit with a signal other than
GDB_SIGNAL_TRAP. And even then it looks quite wrong to me to
magically convert the signal into a GDB_SIGNAL_TRAP here too -- if the
user has set SIGTRAP to "handle pass", the program will see a trap
that gdb invented, not one the program would ever see without gdb in
the picture.
Tested on x86_64 Fedora 17.
gdb/
2013-10-31 Pedro Alves <palves@redhat.com>
* infrun.c (handle_syscall_event): Don't set or clear stop_signal.
(handle_inferior_event) <TARGET_WAITKIND_FORKED,
TARGET_WAITKIND_VFORKED>: Don't set stop_signal to
GDB_SIGNAL_TRAP, or clear it. Pass GDB_SIGNAL_0 to
bpstat_explains signal, instead of GDB_SIGNAL_TRAP.
<bpstat handling>: If the bpstat chain wants the signal to be
hidden, then set stop_signal to GDB_SIGNAL_0 instead of
GDB_SIGNAL_TRAP.
As suggested before, rename the S/390-related source files (tdep and nat)
such that "-linux-" occurs in the file name, like with other GNU/Linux
targets. Since no other operating system is currently supported by GDB
on this architecture, this isn't strictly necessary. But the old names
sometimes caused GDB contributors to miss these files when performing a
change that affects all GNU/Linux targets. The latest such incident was
observed here:
https://sourceware.org/ml/gdb-patches/2013-09/msg00619.html
gdb/
2013-10-30 Andreas Arnez <arnez@linux.vnet.ibm.com>
* s390-tdep.h: Rename to...
* s390-linux-tdep.h: ...here.
* s390-tdep.c: Rename to...
* s390-linux-tdep.c: ...here. Adjust #include.
* s390-nat.c: Rename to...
* s390-linux-nat.c: ...here. Adjust #include.
* config/s390/s390.mh: Rename to...
* config/s390/linux.mh: ...here. Reflect rename s390-nat.o ->
s390-linux-nat.o.
* configure.host: Reflect host rename "s390" -> "linux".
* configure.tgt: Reflect rename s390-tdep.o -> s390-linux-tdep.o.
* Makefile.in (ALL_TARGET_OBS): Likewise.
(HFILES_NO_SRCDIR): Reflect rename s390-tdep.h ->
s390-linux-tdep.h.
(ALLDEPFILES): Reflect rename of .c files.
gdb/
2013-10-30 Andreas Arnez <arnez@linux.vnet.ibm.com>
* s390-nat.c: Whitespace cleanup.
* s390-tdep.c: Likewise.
* s390-tdep.h: Remove empty line at end of file.
I tried to build gdb on the AIX machine in the GCC compile farm
(gcc111), but it failed in a couple of spots because gdb uses "reg" as
a variable name and the AIX <curses.h> defines "reg" to "register".
I saw that we already had a workaround for this lurking in utils.c, so
I just moved that to gdb_curses.h.
This fixed the problem on AIX and still builds on x86-64 Fedora 18.
2013-10-29 Tom Tromey <tromey@redhat.com>
* utils.c (reg): Move undefinition...
* gdb_curses.h: ... here. Update comment to mention AIX.
https://sourceware.org/ml/gdb-patches/2013-08/msg00171.html
gdb/ChangeLog
* infcmd.c (default_print_one_register_info): Use val_print to
print all values even optimized out or unavailable ones. Don't
try to print a raw form of optimized out or unavailable values.
gdb/testsuite/ChangeLog
* gdb.trace/unavailable.exp (gdb_unavailable_registers_test):
Expect <unavailable> pattern.
In registry.c:registry_clear_data, the registered data is iterated and
invoke each 'free' function with the data passed:
for (registration = data_registry->registrations, i = 0;
i < fields->num_data;
registration = registration->next, i++)
if (fields->data[i] != NULL && registration->data->free != NULL)
adaptor (registration->data->free, container, fields->data[i]);
we can see that data is passed to function 'free' and data is not NULL.
In each usage, we don't have to get the data again through key and
do NULL pointer checking. This patch is to simplify them.
gdb:
2013-10-29 Yao Qi <yao@codesourcery.com>
* auto-load.c (auto_load_pspace_data_cleanup): Get data from
parameter 'arg' instead of from program_space_data.
* objfiles.c (objfiles_pspace_data_cleanup): Likewise.
* solib-darwin.c (darwin_pspace_data_cleanup): Likewise.
* solib-dsbt.c (dsbt_pspace_data_cleanup): Likewise.
* solib-svr4.c (svr4_pspace_data_cleanup): Likewise.
* inflow.c (inflow_inferior_data_cleanup): Get data from
parameter 'arg' instead of inferior_data.
* registry.h: Add comments.
I was reading this, checking the the possible returns, and this
particular path confused a tiny little. Above we do:
if (!stopped_by_watchpoint)
{
...
return 0;
}
so any return after that always return true.
Tested on x86_64 Fedora 17.
gdb/
2013-10-28 Pedro Alves <palves@redhat.com>
* breakpoint.c (watchpoints_triggered)
<!target_stopped_data_address>: Hardcode return 1.
Now that all ecs->random_signal handing is always done before the
'process_event_stop_test' label, we can easily make that a real
function and actually give it a describing comment that somewhat makes
sense.
Reindenting the new function will be handled in a follow up patch.
2013-10-28 Pedro Alves <palves@redhat.com>
* infrun.c (process_event_stop_test): New function, factored out
from handle_inferior_event.
(handle_inferior_event): 'process_event_stop_test' is now a
function instead of a goto label -- adjust.
We only ever call "goto process_event_stop_test;" right after checking
that ecs->random_signal is clear. The code at the
process_event_stop_test label looks like:
/* For the program's own signals, act according to
the signal handling tables. */
if (ecs->random_signal)
{
... random signal handling ...
return;
}
else
{
... the stop tests that actually matter for the goto callers.
}
So this moves the label into the else branch. It'll make converting
process_event_stop_test into a function a bit clearer.
gdb/
2013-10-28 Pedro Alves <palves@redhat.com>
* infrun.c (handle_inferior_event): Move process_event_stop_test
goto label to the else branch of the ecs->random_signal check,
along with FRAME and GDBARCH re-fetching.
I recently added a new ecs->random_signal test after the "switch back to
stepped thread" code, and before the stepping tests. Looking at
making process_event_stop_test a proper function, I realized it'd be
better to keep ecs->random_signal related code together. To do that,
I needed to factor out the "switch back to stepped thread" code to a new
function, and call it in both the "random signal" and "not random
signal" paths.
gdb/
2013-10-28 Pedro Alves <palves@redhat.com>
* infrun.c (switch_back_to_stepped_thread): New function, factored
out from handle_inferior_event.
(handle_inferior_event): Adjust to call
switch_back_to_stepped_thread. Call it also at the tail of the
random signal handling, and return, instead of also handling
random signals just before the stepping tests.
'ecs' is always memset before being passed to handle_inferior_event.
The stop func is only filled in later in the flow. And since "Remove
dead sets/clears of ecs->random signal", nothing ever sets
ecs->random_signal before this part is reached either.
(Also tested with some added assertions in place.)
gdb/
2013-10-28 Pedro Alves <palves@redhat.com>
* infrun.c (clear_stop_func): Delete.
(handle_inferior_event): Don't call clear_stop_func and don't
clear 'ecs->random_signal'.
On 10/25/2013 11:34 AM, Joel Brobecker wrote:
> Also, as a followup, I think it would be beneficial if we renamed
> field "lang" in the varobj_root into "lang_ops". I think it's more
> descriptive, especially since "lang" is used elsewhere with different
> meanings (and types).
Here is the patch to rename 'lang' to 'lang_ops'. Committed as obvious.
gdb:
2013-10-27 Yao Qi <yao@codesourcery.com>
* varobj.c (struct varobj_root) <lang>: Rename to 'lang_ops'.
(varobj_create, varobj_get_path_expr): Update.
(varobj_value_has_mutated, varobj_update): Likewise.
(create_child_with_value, new_root_variable): Likewise.
(number_of_children, name_of_variable): Likewise.
(value_of_child, my_value_of_variable): Likewise.
(varobj_value_is_changeable_p): Likewise.
This is a follow-up series to move language stuff out of varobj.c.
This patch adds a new field la_varobj_ops in struct language_defn so
that each language has varobj-related options. Not every language
supports varobj, and the operations are identical to operations of c
languages.
'struct language_defn' is the ideal place to save all language-related
operations. After this patch, some cleanups can be done in patch 2/2,
which removes language-related stuff completely from varobj.c.
Regression tested on x86_64-linux.
gdb:
2013-10-25 Yao Qi <yao@codesourcery.com>
* language.h (struct lang_varobj_ops): Declare.
(struct language_defn) <la_varobj_ops>: New field.
* ada-lang.c: Include "varobj.h"
(defn ada_language_defn): Initialize field 'la_varobj_ops' by
ada_varobj_ops.
* c-lang.c: Include "varobj.h"
(c_language_defn): Initialize field 'la_varobj_ops' by
c_varobj_ops.
(cplus_language_defn): Initialize field 'la_varobj_ops' by
cplus_varobj_ops.
(asm_language_defn): Initialize field 'la_varobj_ops' by
default_varobj_ops.
(minimal_language_defn): Likewise.
* d-lang.c (d_language_defn): Likewise.
* f-lang.c (f_language_defn): Likewise.
* go-lang.c (go_language_defn): Likewise.
* m2-lang.c (m2_language_defn): Likewise.
* objc-lang.c (objc_language_defn): Likewise.
* opencl-lang.c (opencl_language_defn): Likewise.
* p-lang.c (pascal_language_defn): Likewise.
* language.c (unknown_language_defn): Likewise.
(auto_language_defn): Likewise.
(local_language_defn): Likewise.
* jv-lang.c (java_language_defn): Initialize field
'la_varobj_ops' by java_varobj_ops.
* varobj.c (varobj_create): Update.
* varobj.h (default_varobj_ops): Define macro.
With:
struct static_struct { static int aaa; };
struct static_struct sss;
int main () { return 0; }
We get:
(gdb) p sss
$1 = {static aaa = <optimized out>}
(gdb) p sss.aaa
field aaa is nonexistent or has been optimized out
Note that the "field aaa ..." message is an error being thrown.
GDB is graceful everywhere else when printing optimized out values.
IOW it usually prints an <optimized out> value and puts that in the
value history. I see no reason for here to be different, more so that
when the print the whole "containing" object (well, it's a static
field, so it's not really a container), we already print <optimized
out>.
After the patch:
(gdb) p sss
$1 = {static aaa = <optimized out>}
(gdb) p sss.aaa
$2 = <optimized out>
The value_entirely_optimized_out checks are there to preserve
behavior. Without those, if the static field is a struct/union, GDB
would go and print its fields one by one (and print <optimized out>
for each).
Tested on x86_64 Fedora 17.
gdb/
2013-10-25 Pedro Alves <palves@redhat.com>
* cp-valprint.c (cp_print_value_fields): No longer handle a NULL
static field value.
(cp_print_static_field): If the value is entirely optimized out,
print <optimized out> here.
* jv-valprint.c (java_print_value_fields): No longer handle a NULL
static field value.
* p-valprint.c (pascal_object_print_static_field): If the value is
entirely optimized out, print <optimized out> here.
* valops.c (do_search_struct_field)
(value_struct_elt_for_reference): No longer handle a NULL static
field value.
* value.c (value_static_field): Return an optimized out value
instead of NULL.
gdb/testsuite/
2013-10-25 Pedro Alves <palves@redhat.com>
* gdb.cp/m-static.exp: Adjust expected output of printing a
nonexistent or optimized out static field. Also test printing the
the "container" object.
When I do 'si', I find many 'qXfer:traceframe-info:read' packets are sent,
which is not necessary. It slows down the single step.
(gdb) si
Sending packet: $qTStatus#49...Packet received: T0;tnotrun:0;tframes:0;tcreated:0;tfree:500000;tsize:500000;circular:0;disconn:0;starttime:0;stoptime:0;username:;notes::
Sending packet: $Z0,80483c7,1#b4...Packet received: OK
Sending packet: $Z0,4ce5b6b0,1#6e...Packet received: OK
Sending packet: $QPassSignals:e;10;14;17;1a;1b;1c;21;24;25;2c;4c;#5f...Packet received: OK
Sending packet: $vCont;s:p1b15.1b15;c#20...Packet received: T0505:44efffbf;04:44efffbf;08:d1830408;thread:p1b15.1b15;core:3;
Sending packet: $qXfer:traceframe-info:read::0,fff#0b...Packet received: E01
Sending packet: $mbfffef40,40#c0...Packet received: d183040878efffbf2e840408030000000000a040030000000500000070efffbf07000000010000004984040807000000030000000500000000000000b396e84c
Sending packet: $qXfer:traceframe-info:read::0,fff#0b...Packet received: E01
Sending packet: $qXfer:traceframe-info:read::0,fff#0b...Packet received: E01
Sending packet: $qXfer:traceframe-info:read::0,fff#0b...Packet received: E01
Sending packet: $z0,80483c7,1#d4...Packet received: OK
Sending packet: $z0,4ce5b6b0,1#8e...Packet received: OK
Sending packet: $qXfer:traceframe-info:read::0,fff#0b...Packet received: E01
Sending packet: $qXfer:traceframe-info:read::0,fff#0b...Packet received: E01
Sending packet: $qXfer:traceframe-info:read::0,fff#0b...Packet received: E01
Sending packet: $qXfer:traceframe-info:read::0,fff#0b...Packet received: E01
Sending packet: $qXfer:traceframe-info:read::0,fff#0b...Packet received: E01
Sending packet: $qXfer:traceframe-info:read::0,fff#0b...Packet received: E01
This problem was introduced by this patch
(https://sourceware.org/ml/gdb-patches/2013-04/msg00000.html), in
which get_traceframe_number is not checked before calling
traceframe_available_memory. This patch moves the check to
remote_traceframe_info, say, if GDB doesn't have traceframe selected, GDB
doesn't need to send qXfer:traceframe-info:read packets.
With this patch applied, there is no qXfer:traceframe-info:read sent
out and single step is speed up a little bit.
Here is the experiment I did:
Num of single step Original Patched
single-step cpu_time 10000 8.08 7.57
single-step cpu_time 20000 16.23 14.23
single-step cpu_time 30000 24.19 21.59
single-step cpu_time 40000 32.49 28.0
single-step wall_time 10000 14.1974210739 13.2641420364
single-step wall_time 20000 28.5278921127 25.0541369915
single-step wall_time 30000 42.5864038467 38.0038759708
single-step wall_time 40000 57.2107698917 49.2350611687
single-step vmsize 10000 16128 16388
single-step vmsize 20000 16128 16388
single-step vmsize 30000 16260 16520
single-step vmsize 40000 16444 16704
The patch is tested on x86_64-linux.
gdb:
2013-10-24 Yao Qi <yao@codesourcery.com>
* remote.c (remote_traceframe_info): Return early if
traceframe is not selected.
gdb/
* linux-tdep.c (linux_corefile_thread_callback): Propagate any
failure from register information collection.
gdb/testsuite/
* lib/gdb.exp (gdb_gcore_cmd): Also handle a "Target does not
support core file generation" reply.
Occasionaly we hear about people having problems with GDB not being
able to start programs (with "run"/"start"). GDB spawns a shell to
start the program, and most often, it'll be the case that the problem
is actually with the user's shell setup.
GDB has code to disable the use of the shell to start programs.
That's the STARTUP_WITH_SHELL macro that native targets could set to 0
in their nm.h file (though no target actually uses it nowadays).
This patch makes that setting a run-time knob instead. This will be
useful to quickly diagnose such shell issues, and might also come in
handy at other times (such as when debugging the shell itself, if you
don't have a different shell handy).
gdb/
2013-10-24 Pedro Alves <palves@redhat.com>
* NEWS (New options): Mention set/show startup-with-shell.
* config/alpha/nm-osf3.h (START_INFERIOR_TRAPS_EXPECTED): Set to 2
instead of 3.
* fork-child.c (fork_inferior, startup_inferior): Handle 'set
startup-with-shell'.
(show_startup_with_shell): New function.
(_initialize_fork_child): Register the set/show startup-with-shell
commands.
* inf-ptrace.c (inf_ptrace_create_inferior): Remove comment.
* inf-ttrace.c (inf_ttrace_him): Remove comment.
* procfs.c (procfs_init_inferior): Remove comment.
* infcmd.c (startup_with_shell): New global.
* inferior.h (startup_with_shell): Declare global.
(STARTUP_WITH_SHELL): Delete.
(START_INFERIOR_TRAPS_EXPECTED): Set to 1 by default instead of 2.
gdb/doc/
2013-10-24 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Starting): Document set/show startup-with-shell.
The other day while debugging something related to random signals, I
got confused with "set debug infrun 1" output, for it said:
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x323d4e8b94
infrun: random signal 20
On GNU/Linux, 20 is SIGTSTP. For some reason, it took me a few
minutes to realize that 20 is actually a GDB signal number, not a
target signal number (duh!). In any case, I propose making GDB's
output clearer here:
One way would be to use gdb_signal_to_name, like already used
elsewhere:
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x323d4e8b94
infrun: random signal SIGCHLD (20)
but I think that might confuse someone too ("20? Why does GDB believe
SIGCHLD is 20?"). So I thought of printing the enum string instead:
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x323d4e8b94
infrun: random signal GDB_SIGNAL_CHLD (20)
Looking at a more complete infrun debug log, we had actually printed
the (POSIX) signal name name a bit before:
infrun: target_wait (-1, status) =
infrun: 9300 [Thread 0x7ffff7fcb740 (LWP 9300)],
infrun: status->kind = stopped, signal = SIGCHLD
...
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x323d4e8b94
infrun: random signal 20
So I'm now thinking that it'd be even better to make infrun output
consistently use the enum symbol string, like so:
infrun: clear_proceed_status_thread (Thread 0x7ffff7fca700 (LWP 25663))
infrun: clear_proceed_status_thread (Thread 0x7ffff7fcb740 (LWP 25659))
- infrun: proceed (addr=0xffffffffffffffff, signal=144, step=1)
+ infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT, step=1)
- infrun: resume (step=1, signal=0), trap_expected=0, current thread [Thread 0x7ffff7fcb740 (LWP 25659)] at 0x400700
+ infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0x7ffff7fcb740 (LWP 25659)] at 0x400700
infrun: wait_for_inferior ()
infrun: target_wait (-1, status) =
infrun: 25659 [Thread 0x7ffff7fcb740 (LWP 25659)],
- infrun: status->kind = stopped, signal = SIGCHLD
+ infrun: status->kind = stopped, signal = GDB_SIGNAL_CHLD
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x400700
- infrun: random signal 20
+ infrun: random signal (GDB_SIGNAL_CHLD)
infrun: random signal, keep going
- infrun: resume (step=1, signal=20), trap_expected=0, current thread [Thread 0x7ffff7fcb740 (LWP 25659)] at 0x400700
+ infrun: resume (step=1, signal=GDB_SIGNAL_CHLD), trap_expected=0, current thread [Thread 0x7ffff7fcb740 (LWP 25659)] at 0x400700
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 25659 [Thread 0x7ffff7fcb740 (LWP 25659)],
- infrun: status->kind = stopped, signal = SIGTRAP
+ infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x400704
infrun: stepi/nexti
infrun: stop_stepping
GDB's signal numbers are public and hardcoded (see
include/gdb/signals.h), so there's really no need to clutter the
output with numeric values in some places while others not. Replacing
the magic "144" with GDB_SIGNAL_DEFAULT in "proceed"'s debug output
(see above) I think is quite nice.
I posit that all this makes it clearer to newcomers that GDB has its
own signal numbering (and that there must be some mapping going on).
Tested on x86_64 Fedora 17.
gdb/
2013-10-23 Pedro Alves <palves@redhat.com>
* common/gdb_signals.h (gdb_signal_to_symbol_string): Declare.
* common/signals.c: Include "gdb_assert.h".
(signals): New field 'symbol'.
(SET): Use the 'symbol' parameter.
(gdb_signal_to_symbol_string): New function.
* infrun.c (handle_inferior_event) <random signal>: In debug
output, print the random signal enum as string in addition to its
number.
* target/waitstatus.c (target_waitstatus_to_string): Print the
signal's enum value as string instead of the (POSIX) signal name.
In the first hunk, the format string was off-by-one for cmd, and cmd
itself was larger than the maximum size required. cmd was reduced in
size and the format string adjusted.
In the second hunk, the format string was off-by-one for local_address,
remote_address and extra, although the buffers for the two addresses
were large enough for this not to matter. The specifiers for the two
addresses was corrected, and a number of unused variables including
extra were suppressed from parsing.
In the third hunk, the format string was off-by-one for name,
dependencies and status. This code was rewritten using strtok since
dependencies can be arbitrarily long.
gdb/
2013-10-23 Gary Benson <gbenson@redhat.com>
PR 16013
* common/linux-osdata.c (command_from_pid): Reduced size of cmd
from 32 to 18. Adjusted fscanf format string accordingly.
(Avoids leaving cmd unterminated.)
(print_sockets): Do not parse tlen, inode, sl, timeout, txq, rxq,
trun, retn or extra. (Avoids leaving extra unterminated.) Check
that local_address and remote_address will not overflow.
(linux_xfer_osdata_modules): Parse lines using strtok to avoid
leaving dependencies unterminated. Parse size as "%u" to match
definition.
'*ecs' is always memset by handle_inferior_event's callers, so all
these clears are unnecessary. There's one place that sets the flag to
true, but, afterwards, before ecs->random_signal is ever read, we
reach the part of handle_inferior_even that clears ecs->random_signal,
among other things:
clear_stop_func (ecs);
ecs->event_thread->stepping_over_breakpoint = 0;
bpstat_clear (&ecs->event_thread->control.stop_bpstat);
ecs->event_thread->control.stop_step = 0;
stop_print_frame = 1;
ecs->random_signal = 0;
stopped_by_random_signal = 0;
So all these ecs->random_signal accesses are dead code.
Tested on x86_64 Fedora 17.
gdb/
2013-10-22 Pedro Alves <palves@redhat.com>
* infrun.c (handle_inferior_event) <thread hop>: Don't clear or
set ecs->random signal.
https://sourceware.org/ml/gdb-patches/2013-10/msg00477.html
gdb/ChangeLog
* breakpoint.c (update_watchpoint): If hardware watchpoints are
forced off, downgrade them to software watchpoints if possible,
and error out if not possible.
(watch_command_1): Move watchpoint type selection closer to
watchpoint creation, and extend the comments.
gdb/testsuite/ChangeLog
* gdb.base/watchpoints.exp: Add test for setting software
watchpoints of different types before starting the inferior.
I noticed something odd while doing "stepi" over a fork syscall:
...
(gdb) set disassemble-next-line on
...
(gdb) si
0x000000323d4ba7c2 131 pid = ARCH_FORK ();
0x000000323d4ba7a4 <__libc_fork+132>: 64 4c 8b 04 25 10 00 00 00 mov %fs:0x10,%r8
0x000000323d4ba7ad <__libc_fork+141>: 31 d2 xor %edx,%edx
0x000000323d4ba7af <__libc_fork+143>: 4d 8d 90 d0 02 00 00 lea 0x2d0(%r8),%r10
0x000000323d4ba7b6 <__libc_fork+150>: 31 f6 xor %esi,%esi
0x000000323d4ba7b8 <__libc_fork+152>: bf 11 00 20 01 mov $0x1200011,%edi
0x000000323d4ba7bd <__libc_fork+157>: b8 38 00 00 00 mov $0x38,%eax
=> 0x000000323d4ba7c2 <__libc_fork+162>: 0f 05 syscall
0x000000323d4ba7c4 <__libc_fork+164>: 48 3d 00 f0 ff ff cmp $0xfffffffffffff000,%rax
0x000000323d4ba7ca <__libc_fork+170>: 0f 87 2b 01 00 00 ja 0x323d4ba8fb <__libc_fork+475>
(gdb) si
0x000000323d4ba7c4 131 pid = ARCH_FORK ();
0x000000323d4ba7a4 <__libc_fork+132>: 64 4c 8b 04 25 10 00 00 00 mov %fs:0x10,%r8
0x000000323d4ba7ad <__libc_fork+141>: 31 d2 xor %edx,%edx
0x000000323d4ba7af <__libc_fork+143>: 4d 8d 90 d0 02 00 00 lea 0x2d0(%r8),%r10
0x000000323d4ba7b6 <__libc_fork+150>: 31 f6 xor %esi,%esi
0x000000323d4ba7b8 <__libc_fork+152>: bf 11 00 20 01 mov $0x1200011,%edi
0x000000323d4ba7bd <__libc_fork+157>: b8 38 00 00 00 mov $0x38,%eax
0x000000323d4ba7c2 <__libc_fork+162>: 0f 05 syscall
=> 0x000000323d4ba7c4 <__libc_fork+164>: 48 3d 00 f0 ff ff cmp $0xfffffffffffff000,%rax
0x000000323d4ba7ca <__libc_fork+170>: 0f 87 2b 01 00 00 ja 0x323d4ba8fb <__libc_fork+475>
(gdb) si
0x000000323d4ba7c4 131 pid = ARCH_FORK ();
0x000000323d4ba7a4 <__libc_fork+132>: 64 4c 8b 04 25 10 00 00 00 mov %fs:0x10,%r8
0x000000323d4ba7ad <__libc_fork+141>: 31 d2 xor %edx,%edx
0x000000323d4ba7af <__libc_fork+143>: 4d 8d 90 d0 02 00 00 lea 0x2d0(%r8),%r10
0x000000323d4ba7b6 <__libc_fork+150>: 31 f6 xor %esi,%esi
0x000000323d4ba7b8 <__libc_fork+152>: bf 11 00 20 01 mov $0x1200011,%edi
0x000000323d4ba7bd <__libc_fork+157>: b8 38 00 00 00 mov $0x38,%eax
0x000000323d4ba7c2 <__libc_fork+162>: 0f 05 syscall
=> 0x000000323d4ba7c4 <__libc_fork+164>: 48 3d 00 f0 ff ff cmp $0xfffffffffffff000,%rax
0x000000323d4ba7ca <__libc_fork+170>: 0f 87 2b 01 00 00 ja 0x323d4ba8fb <__libc_fork+475>
(gdb) si
0x000000323d4ba7ca 131 pid = ARCH_FORK ();
0x000000323d4ba7a4 <__libc_fork+132>: 64 4c 8b 04 25 10 00 00 00 mov %fs:0x10,%r8
0x000000323d4ba7ad <__libc_fork+141>: 31 d2 xor %edx,%edx
0x000000323d4ba7af <__libc_fork+143>: 4d 8d 90 d0 02 00 00 lea 0x2d0(%r8),%r10
0x000000323d4ba7b6 <__libc_fork+150>: 31 f6 xor %esi,%esi
0x000000323d4ba7b8 <__libc_fork+152>: bf 11 00 20 01 mov $0x1200011,%edi
0x000000323d4ba7bd <__libc_fork+157>: b8 38 00 00 00 mov $0x38,%eax
0x000000323d4ba7c2 <__libc_fork+162>: 0f 05 syscall
0x000000323d4ba7c4 <__libc_fork+164>: 48 3d 00 f0 ff ff cmp $0xfffffffffffff000,%rax
=> 0x000000323d4ba7ca <__libc_fork+170>: 0f 87 2b 01 00 00 ja 0x323d4ba8fb <__libc_fork+475>
Notice how the third "si" didn't actually make progress.
Turning on infrun and lin-lwp debug, we see:
(gdb)
infrun: clear_proceed_status_thread (process 5252)
infrun: proceed (addr=0xffffffffffffffff, signal=144, step=1)
infrun: resume (step=1, signal=0), trap_expected=0, current thread [process 5252] at 0x323d4ba7c4
LLR: Preparing to step process 5252, 0, inferior_ptid process 5252
RC: Not resuming sibling process 5252 (not stopped)
LLR: PTRACE_SINGLESTEP process 5252, 0 (resume event thread)
sigchld
infrun: wait_for_inferior ()
linux_nat_wait: [process -1], []
LLW: enter
LNW: waitpid(-1, ...) returned 5252, No child processes
LLW: waitpid 5252 received Child exited (stopped)
LLW: Candidate event Child exited (stopped) in process 5252.
SEL: Select single-step process 5252
LLW: exit
infrun: target_wait (-1, status) =
infrun: 5252 [process 5252],
infrun: status->kind = stopped, signal = SIGCHLD
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x323d4ba7c4
infrun: random signal 20
infrun: stepi/nexti
infrun: stop_stepping
So the inferior got a SIGCHLD (because the fork child exited while
we're doing 'si'), and since that signal is set to "nostop noprint
pass" (by default), it's considered a random signal, so it should not
cause a stop. But, it resulted in an immediate a stop_stepping call
anyway. So the single-step never really finished.
This is a regression caused by:
[[PATCH] Do not respawn signals, take 2.]
https://sourceware.org/ml/gdb-patches/2012-06/msg00702.html
Specifically, caused by this change (as mentioned in the "the lost
step issue first" part of that mail):
diff --git a/gdb/infrun.c b/gdb/infrun.c
index 53db335..3e8dbc8 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -4363,10 +4363,8 @@ process_event_stop_test:
(leaving the inferior at the step-resume-breakpoint without
actually executing it). Either way continue until the
breakpoint is really hit. */
- keep_going (ecs);
- return;
}
-
+ else
/* Handle cases caused by hitting a breakpoint. */
{
That made GDB fall through to the
> /* In all-stop mode, if we're currently stepping but have stopped in
> some other thread, we need to switch back to the stepped thread. */
> if (!non_stop)
part. However, if we don't have a stepped thread to get back to,
we'll now also fall through to all the "stepping" tests. For line
stepping, that'll turn out okay, as we'll just end up realizing the
thread is still in the stepping range, and needs to be re-stepped.
However, for stepi/nexti, we'll reach:
if (ecs->event_thread->control.step_range_end == 1)
{
/* It is stepi or nexti. We always want to stop stepping after
one instruction. */
if (debug_infrun)
fprintf_unfiltered (gdb_stdlog, "infrun: stepi/nexti\n");
ecs->event_thread->control.stop_step = 1;
print_end_stepping_range_reason ();
stop_stepping (ecs);
return;
}
and stop, even though the thread actually made no progress. The fix
is to restore the keep_going call, but put it after the "switch back
to the stepped thread" code, and before the stepping tests.
Tested on x86_64 Fedora 17, native and gdbserver. New test included.
gdb/
2013-10-18 Pedro Alves <palves@redhat.com>
PR gdb/16062
* infrun.c (handle_inferior_event): Keep going if we got a random
signal we should not stop for, instead of falling through to the
step tests.
gdb/testsuite/
2013-10-18 Pedro Alves <palves@redhat.com>
PR gdb/16062
* gdb.threads/stepi-random-signal.c: New file.
* gdb.threads/stepi-random-signal.exp: New file.
This patch fixes PR gdb/15995.
The bug here is that gdb's printf command does not flush the output
stream. This makes a printf that is not newline-terminated interleave
incorrectly with other forms of output, such as that generated via a
call to an external program using "shell".
I note that the "output" command already does this flushing.
The fix is to call gdb_flush in printf_command.
Built and regtested on x86-64 Fedora 18.
New test case included.
PR gdb/15995:
* printcmd.c (printcmd): Call gdb_flush.
* gdb.base/printcmds.exp (test_printf): Test printf flushing.
I noticed that one field in elfread.c:struct elfinfo is unused.
This patch removes it.
* elfread.c (struct elfinfo) <stabindexsect>: Remove.
(elf_locate_sections): Update.
As a result of previous patch, extern functions in ada-varobj.c can be
made static, and ada-varobj.h can be removed too.
gdb:
2013-10-17 Yao Qi <yao@codesourcery.com>
* Makefile.in (HFILES_NO_SRCDIR): Remove ada-varobj.h.
* ada-varobj.c: Remove the include of ada-varobj.h.
(ada_varobj_get_number_of_children): Declare.
(ada_varobj_get_name_of_child): Make it static.
(ada_varobj_get_path_expr_of_child): Likewise.
(ada_varobj_get_value_of_child): Likewise.
(ada_varobj_get_type_of_child): Likewise.
(ada_varobj_get_value_of_array_variable): Likewise.
* ada-varobj.h: Remove.
The first one, dw2_get_real_path from gdb/dwarf2read.c, was actually
making use of OBSTACK_CALLOC which already calls "sizeof" for its third
argument.
The second, download_tracepoint_1 from gdb/gdbserver/tracepoint.c, was
explicitly calling "sizeof" inside another "sizeof".
This patch fixed both functions.
gdb/ChangeLog
2013-10-16 Sergio Durigan Junior <sergiodj@redhat.com>
PR gdb/16014
* dwarf2read.c (dw2_get_real_path): Remove unnecessary call to
sizeof.
gdb/gdbserver/ChangeLog
2013-10-16 Sergio Durigan Junior <sergiodj@redhat.com>
PR gdb/16014
* tracepoint.c (download_tracepoint_1): Remove unnecessary double
call to sizeof.
both from gdb/target.c, do a "return" calling another function. But both
are marked as void. Despite the fact that the functions being called are
void as well, this is wrong. This patch fixes this by calling the functions
and then returning in the next line.
2013-10-16 Sergio Durigan Junior <sergiodj@redhat.com>
PR gdb/16042
* target.c (target_disable_btrace): Fix invalid return value for
void function.
(target_teardown_btrace): Likewise.
gdb/
* nios2-tdep.c (nios2_reg_names): Use "sstatus" rather than "ba"
as the preferred name of r30.
* nios2-linux-tdep.c (reg_offsets): Likewise.
* features/nios2-cpu.xml: Likewise.
* features/nios2-linux.c: Regenerated.
* features/nios2.c: Regenerated.
* regformats/nios2-linux.dat: Regenerated.
gdb/
2013-10-13 Jan Kratochvil <jan.kratochvil@redhat.com>
Canonicalize directories for EXEC_FILENAME.
* exec.c (exec_file_attach): Use gdb_realpath_keepfile for
exec_filename.
* utils.c (gdb_realpath_keepfile): New function.
* utils.h (gdb_realpath_keepfile): New declaration.
gdb/testsuite/
2013-10-13 Jan Kratochvil <jan.kratochvil@redhat.com>
Canonicalize directories for EXEC_FILENAME.
* gdb.base/argv0-symlink.exp
(kept file symbolic link name for info inferiors): New.
(kept directory symbolic link name): Setup kfail.
(kept directory symbolic link name for info inferiors): New.
This patch introduces two new GDB/MI commands implementing the equivalent
of the "catch exception" and "catch assert" GDB/CLI commands.
gdb/ChangeLog:
* breakpoint.h (init_ada_exception_breakpoint): Add parameter
"enabled".
* breakpoint.c (init_ada_exception_breakpoint): Add parameter
"enabled". Set B->ENABLE_STATE accordingly.
* ada-lang.h (ada_exception_catchpoint_kind): Move here from
ada-lang.c.
(create_ada_exception_catchpoint): Add declaration.
* ada-lang.c (ada_exception_catchpoint_kind): Move to ada-lang.h.
(create_ada_exception_catchpoint): Make non-static. Add new
parameter "disabled". Use it in call to
init_ada_exception_breakpoint.
(catch_ada_exception_command): Add parameter "enabled" in call
to create_ada_exception_catchpoint.
(catch_assert_command): Likewise.
* mi/mi-cmds.h (mi_cmd_catch_assert, mi_cmd_catch_exception):
Add declarations.
* mi/mi-cmds.c (mi_cmds): Add the "catch-assert" and
"catch-exception" commands.
* mi/mi-cmd-catch.c: Add #include "ada-lang.h".
(mi_cmd_catch_assert, mi_cmd_catch_exception): New functions.
This is in preparation for making that type public, in order to be
able to use make create_ada_exception_catchpoint public as well,
making it usable from the GDB/MI implementation.
gdb/ChangeLog:
* ada-lang.c (enum ada_exception_catchpoint_kind): Renames
"enum exception_catchpoint_kind". Replace the "ex_" prefix
of all its enumerates with "ada_". Update the rest of this
file throughout.
This patch reworks a bit how the different steps required to insert
an Ada exception catchpoints are organized. They used to be:
1. Call a "decode" function which does:
1.a. Parse the command and its arguments
1.b. Create a SAL & OPS from some of those arguments
2. Call create_ada_exception_catchpoint using SAL as well
as some of the arguments extracted above.
The bulk of the change consists in integrating step (1.b) into
step (2) in order to turn create_ada_exception_catchpoint into
a function whose arguments are all user-level concepts. This
paves the way from a straightforward implementation of the equivalent
commands in the GDB/MI interpreter.
gdb/ChangeLog:
* ada-lang.c (ada_decode_exception_location): Delete.
(create_ada_exception_catchpoint): Remove arguments "sal",
"addr_string" and "ops". Add argument "ex_kind" instead.
Adjust implementation accordingly, calling ada_exception_sal
to get the entities it no longer gets passed as arguments.
Document the function's arguments.
(catch_ada_exception_command): Use catch_ada_exception_command_split
instead of ada_decode_exception_location, and update call to
create_ada_exception_catchpoint.
(catch_ada_assert_command_split): Renames
ada_decode_assert_location. Remove parameters "addr_string" and
"ops", and now returns void. Adjust implementation accordingly.
Update the function documentation.
(catch_assert_command): Use catch_ada_assert_command_split
instead of ada_decode_assert_location. Update call to
create_ada_exception_catchpoint.
Consider the following example:
% gdb -q -batch -ex 'source nonexistant-file'
[nothing]
One would have at least expected the debugger to warn about
not finding the file, similar to the error shown when using
a more interactive mode. Eg:
(gdb) source nonexistant-file
nonexistant-file: No such file or directory.
Not raising an error appears to be intentional, presumably in order
to prevent this situation from stoping the execution of a GDB script.
But the lack of at least a warning makes it harder for a user to
diagnose any issue, if the file was expected to be there and readable.
This patch adds a warning in that case:
% gdb -q -batch -ex 'source nonexistant-file'
warning: nonexistant-file: No such file or directory.
gdb/ChangeLog:
* utils.h (perror_warning_with_name): Add declaration.
* utils.c (perror_warning_with_name): New function.
* cli/cli-cmds.c (source_script_with_search): Add call to
perror_warning_with_name if from_tty is nul.
gdb/testsuite/ChangeLog:
* gdb.base/source-nofile.gdb: New file.
* gdb.base/source.exp: Add two tests verifying the behavior when
the "source" command is given a non-existant filename.
The main purpose of this patch is to extract the part of
throw_perror_with_name that computes a string providing the system
error message combined with a prefix string. This will become useful
later on to provide a routine which prints a warning using that
perror_string, rather than throwing an error.
gdb/ChangeLog:
* utils.c (perror_string): New function, extracted out of
throw_perror_with_name.
(throw_perror_with_name): Rework to use perror_string.
If we are running on a Linux platform we should call linux_init_abi
in order to get all the useful hooks it enables.
gdb/ChangeLog:
2013-10-10 Will Newton <will.newton@linaro.org>
* aarch64-linux-tdep.c (aarch64_linux_init_abi): Call
linux_init_abi.
This patch renames the "set/show remotebaud" commands into
"set/show serial baud", and moves its implementation into serial.c.
It also moves the "baud_rate" global from top.c to serial.c, where
the new code is being added (the alternative was to add an include
of target.h).
And to facilitate the transition to the new setting name, this
patch also preserves the old commands, and marks them as deprecated
to alert the users of the change.
gdb/ChangeLog:
* cli/cli-cmds.c (show_baud_rate): Moved to serial.c as
serial_baud_show_cmd.
(_initialize_cli_cmds): Delete the code creating the
"set/show remotebaud" commands.
* serial.c (baud_rate): Move here from top.c.
(serial_baud_show_cmd): Move here from cli/cli-cmds.c.
(_initialize_serial): Create "set/show serial baud" commands.
Add "set/show remotebaud" command aliases.
* top.c (baud_rate): Moved to serial.c.
* NEWS: Document the new "set/show serial baud" commands,
replacing "set/show remotebaud".
gdb/doc/ChangeLog:
* gdb.texinfo: Replace "set remotebaud" and "show remotebaud"
by "set serial baud" and "show serial baud" (resp) throughout.
target_read_memory & friends build on top of target_read (thus on top
of the target_xfer machinery), but turn all errors to EIO, an errno
value. I think we'd better convert all these to return a
target_xfer_error too, like target_xfer_partial in a previous patch.
The patch starts by doing that.
(The patch does not add a enum target_xfer_error value for '0'/no
error, and likewise does not change the return type of several of
these functions to enum target_xfer_error, because different functions
return '0' with different semantics.)
I audited the tree for memory_error calls, EIO checks, places where
GDB hardcodes 'errno = EIO', and also for strerror calls. What I
found is that nowadays there's really no need to handle random errno
values, other than the EIOs gdb itself hardcodes. No doubt errno
values would appear in common code back in the day when
target_xfer_memory was the main interface to access memory, but
nowadays, any errno value that deprecated interface could return is
just absorved by default_xfer_partial:
else if (xfered == 0 && errno == 0)
/* "deprecated_xfer_memory" uses 0, cross checked against
ERRNO as one indication of an error. */
return 0;
else
return -1;
There are two places in the code that check for EIO and print "out of
bounds", and defer to strerror for other errors. That's
c-lang.c:c_get_string, and valprint.c.:val_print_string. AFAICT, the
strerror branch can never be reached nowadays, as the only error
possible to get at those points is EIO, given that it's GDB itself
that set that errno value (in target_read_memory, etc.).
breakpoint.c:insert_bp_location always prints the error val as if an
errno, returned by target_insert_breakpoint, with strerr. Now the
error here is either always EIO for mem-break.c targets (again
hardcoded by the target_read_memory/target_write_memory functions), so
this always prints "Input/output error" or similar (depending on
host), or, for remote targets (and probably others), this gem:
Error accessing memory address 0x80200400: Unknown error -1.
This patch makes these 3 places print the exact same error
memory_error prints. This changes output, but I think this is better,
for making memory error output consistent with other commands, and, it
means we have a central place to tweak for memory errors.
E.g., this changes:
Cannot insert breakpoint 1.
Error accessing memory address 0x5fc660: Input/output error.
to:
Cannot insert breakpoint 1.
Cannot access memory at address 0x5fc660
Which I find pretty much acceptable.
Surprisingly, only py-prettyprint.exp had a regression, for needing an
adjustment. I also grepped the testsuite for the old errors, and
found no other hits.
Now that errno values aren't used anywhere in any of these memory
access related routines, I made memory_error itself take a
target_xfer_error instead of an errno. The new
target_xfer_memory_error function added recently is no longer
necessary, and is thus removed.
Tested on x86_64 Fedora 17, native and gdbserver.
gdb/
2013-10-09 Pedro Alves <palves@redhat.com>
* breakpoint.c (insert_bp_location): Use memory_error_message to
build the memory error string.
* c-lang.c: Include "gdbcore.h".
(c_get_string): Use memory_error to throw error.
(target_xfer_memory_error): Delete.
(memory_error_message): New, factored out from
target_xfer_memory_error.
(memory_error): Change parameter type to target_xfer_error.
Rewrite.
(read_memory): Use memory_error instead of
target_xfer_memory_error.
* gdbcore.h: Include "target.h".
(memory_error): Change parameter type to target_xfer_error.
(memory_error_message): Declare function.
* target.c (target_read_memory, target_read_stack)
(target_write_memory, target_write_raw_memory): Return
TARGET_XFER_E_IO on error. Adjust comments.
(get_target_memory): Pass TARGET_XFER_E_IO to memory_error,
instead of EIO.
* target.h (target_read, target_insert_breakpoint)
(target_remove_breakpoint): Adjust comments.
* valprint.c (partial_memory_read): Rename parameter, and adjust
comment.
(val_print_string): Use memory_error_message to build the memory
error string.
gdb/testsuite/
2013-10-09 Pedro Alves <palves@redhat.com>
* gdb.python/py-prettyprint.exp (run_lang_tests): Adjust expected
output.
gdb/
2013-10-09 Jan Kratochvil <jan.kratochvil@redhat.com>
* common/filestuff.c (gdb_fopen_cloexec): Remove initialization of
result variable. Rename variable fopen_e_ever_failed to
fopen_e_ever_failed_einval. Retry fopen only for errno EINVAL.
This removes another yet instance of a deprecated_xfer_memory user.
Tested by building a --enable-targets=all gdb, on x86-64 Fedora 17.
gdb/
2013-10-09 Pedro Alves <palves@redhat.com>
* monitor.c (monitor_write_memory, monitor_write_memory_bytes)
(monitor_write_memory_longlongs, monitor_write_memory_block):
Constify 'myaddr' parameter.
(monitor_xfer_memory): Adjust interface as monitor_xfer_partial
helper.
(monitor_xfer_partial): New function.
(init_base_monitor_ops): Don't install a deprecated_xfer_memory
hook. Install a to_xfer_partial hook.
* bfd-in2.h: Rebuild.
* opncls.c (bfd_get_alt_debug_link_info): Change type of
buildid_len to bfd_size_type.
gdb
* dwarf2read.c (dwarf2_get_dwz_file): Update for type change in
bfd_get_alt_debug_link_info.
gdb/
2013-10-09 Jan Kratochvil <jan.kratochvil@redhat.com>
New flag OBJF_NOT_FILENAME.
* auto-load.c (auto_load_objfile_script): Check also OBJF_NOT_FILENAME.
* jit.c (jit_object_close_impl): Use OBJF_NOT_FILENAME for
allocate_objfile.
(jit_bfd_try_read_symtab): Use OBJF_NOT_FILENAME for
symbol_file_add_from_bfd.
* jv-lang.c (get_dynamics_objfile): Use OBJF_NOT_FILENAME for
allocate_objfile.
* objfiles.c (allocate_objfile): Assert OBJF_NOT_FILENAME if NAME is
NULL.
* objfiles.h (OBJF_NOT_FILENAME): New.
This patch fixes gdb PR symtab/15597.
The bug is that the .gnu_debugaltlink section includes the build-id of
the alt file, but gdb does not use it.
This patch fixes the problem by changing gdb to do what it ought to
always have done: verify the build id of the file found using the
filename in .gnu_debugaltlink; and if that does not match, try to find
the correct debug file using the build-id and debug-file-directory.
This patch touches BFD. Previously, gdb had its own code for parsing
.gnu_debugaltlink; I changed it to use the BFD functions after those
were introduced. However, the BFD functions are incorrect -- they
assume that .gnu_debugaltlink is formatted like .gnu_debuglink.
However, it it is not. Instead, it consists of a file name followed
by the build-id -- no alignment, and the build-id is not a CRC.
Fixing this properly is a bit of a pain. But, because
separate_alt_debug_file_exists just has a FIXME for the build-id case,
I did not fix it properly. Instead I introduced a hack. This leaves
BFD working just as well as it did before my patch.
I'm willing to do something better here but I could use some guidance
as to what. It seems that the build-id code in BFD is largely punted
on.
FWIW gdb is the only user of bfd_get_alt_debug_link_info outside of
BFD itself.
I moved the build-id logic out of elfread.c and into a new file.
This seemed cleanest to me.
Writing a test case was a bit of a pain. I added a couple new
features to the DWARF assembler to handle this.
Built and regtested on x86-64 Fedora 18.
* bfd-in2.h: Rebuild.
* opncls.c (bfd_get_alt_debug_link_info): Add buildid_len
parameter. Change type of buildid_out. Update.
(get_alt_debug_link_info_shim): New function.
(bfd_follow_gnu_debuglink): Use it.
* Makefile.in (SFILES): Add build-id.c.
(HFILES_NO_SRCDIR): Add build-id.h.
* build-id.c: New file, largely from elfread.c. Modified
most functions.
* build-id.h: New file.
* dwarf2read.c (dwarf2_get_dwz_file): Update for change to
bfd_get_alt_debug_link_info. Verify dwz file's build-id.
Search for dwz file using build-id.
* elfread.c (build_id_bfd_get, build_id_verify)
(build_id_to_debug_filename, find_separate_debug_file): Remove.
* gdb.dwarf2/dwzbuildid.exp: New file.
* lib/dwarf.exp (Dwarf::_section): Add "flags" and "type"
parameters.
(Dwarf::_defer_output): Change "section" parameter to
"section_spec"; update.
(Dwarf::gnu_debugaltlink, Dwarf::_note, Dwarf::build_id): New
procs.
Upon trying to print the value of a variant record, a user noticed
the following problem:
(gdb) print rt
warning: Unknown upper bound, using 1.
warning: Unknown upper bound, using 1.
$1 = (a => ((a1 => (4), a2 => (4)), (a1 => (8), a2 => (8))))
The expected output is:
(gdb) print rt
$1 = (a => ((a1 => (4, 4), a2 => (8, 8)), (a1 => (4, 4),
a2 => (8, 8))))
The problems comes from the fact that components "a1" and "a2" are
defined as arrays whose upper bound is dynamic. To determine the value
of that upper bound, GDB relies on the GNAT encoding and searches
for the parallel ___U variable. Unfortunately, the search fails
while doing a binary search inside the partial symtab of the unit
where the array and its bound (and therefore the parallel ___U variable)
are defined.
It fails because partial symbols are sorted using strcmp_iw_ordered,
while Ada symbol lookups are performed using a different comparison
function (ada-lang.c:compare_names). The two functions are supposed
to be compatible, but a change performed in April 2011 modified
strcmp_iw_ordered, introducing case-sensitivity issues. As a result,
the two functions would now disagree when passed the following
two arguments:
string1="common__inner_arr___SIZE_A_UNIT"
string2="common__inner_arr__T4s___U"
The difference starts at "_SIZE_A_UNIT" vs "T4s___U". So, it's mostly
a matter of comparing '_' with 'T'.
On the one hand, strcmp_iw_ordered would return -1, while compare_names
returned 11. The change that made all the difference is that
strcmp_iw_ordered now performs a case-insensitive comparison,
and only resorts to case-sentitive comparison if the first comparison
finds an equality. This changes everything, because while 'T' (84)
and 't' (116) are on opposite sides of '_' (95).
This patch aims at restoring the compatibility between the two
functions, by adding case-sensitivity handling in the Ada comparison
function.
gdb/ChangeLog:
* ada-lang.c (compare_names_with_case): Renamed from
compare_names, adding a new parameter "casing" and its handling.
New function documentation.
(compare_names): New function, implemented using
compare_names_with_case.
This moves the demangled_names_hash from the objfile into the per-BFD
object. This is part of the objfile splitting project.
The demangled names hash is independent of the program space. And, it
is needed by the symbol tables. Both of these things indicate that it
must be pushed into the per-BFD object, which this patch does.
Built and regtested on x86-64 Fedora 18.
* objfiles.c (free_objfile_per_bfd_storage): Delete the
demangled_names_hash.
(free_objfile): Don't delete the demangled_names_hash.
* objfiles.h (struct objfile_per_bfd_storage)
<demangled_names_hash>: New field.
(struct objfile) <demangled_names_hash>: Move to
objfile_per_bfd_storage.
* symfile.c (reread_symbols): Don't delete the
demangled_names_hash.
* symtab.c (create_demangled_names_hash): Update.
(symbol_set_names): Update.
Right now we always share per-BFD data across objfiles, if there is a
BFD. This works fine. However, we're going to start sharing more
data, and sometimes this data will come directly from sections of the
BFD. If such a section has SEC_RELOC set, then the data coming from
that section will not be truly sharable -- the section will be
program-space-dependent, and re-read by gdb for each objfile.
This patch disallows per-BFD sharing in this case. This is a bit
"heavy" in that we could in theory examine each bit of shared data for
suitability. However, that is more complicated, and SEC_RELOC is rare
enough that I think we needn't bother.
Note that the "no sharing" case is equivalent to "gdb works as it
historically did". That is, the sharing is a new(-ish) optimization.
Built and regtested on x86-64 Fedora 18.
* gdb_bfd.c (struct gdb_bfd_data) <relocation_computed,
needs_relocations>: New fields.
(gdb_bfd_requires_relocations): New function.
* gdb_bfd.h (gdb_bfd_requires_relocations): Declare.
* objfiles.c (get_objfile_bfd_data): Disallow sharing if
the BFD needs relocations applied.
It seems "gone" may confuse people, while that was exactly what it was
trying to avoid. Switch to saying "no longer in the thread list",
which is really the predicate GDB uses.
gdb/
2013-10-07 Pedro Alves <palves@redhat.com>
PR breakpoints/11568
* breakpoint.c (remove_threaded_breakpoints): Say "no longer in
the thread list" instead of "gone".
will hold the signal number when the inferior terminates due to the
uncaught signal.
I've made modifications on infrun.c:handle_inferior_event such that
$_exitcode gets cleared when the inferior signalled, and vice-versa.
This assumption was made because the variables are mutually
exclusive, i.e., when the inferior terminates because of an uncaught
signal it is not possible for it to return. I have also made modifications
such that when a corefile is loaded, $_exitsignal gets set to the uncaught
signal that "killed" the inferior, and $_exitcode is cleared.
The patch also adds a NEWS entry, documentation bits, and a testcase. The
documentation entry explains how to use $_exitsignal and $_exitcode in a
GDB script, by making use of the new $_isvoid convenience function.
gdb/
2013-10-06 Sergio Durigan Junior <sergiodj@redhat.com>
* NEWS: Mention new convenience variable $_exitsignal.
* corelow.c (core_open): Reset exit convenience variables. Set
$_exitsignal to the uncaught signal which generated the corefile.
* infrun.c (handle_inferior_event): Reset exit convenience
variables. Set $_exitsignal for TARGET_WAITKIND_SIGNALLED.
(clear_exit_convenience_vars): New function.
* inferior.h (clear_exit_convenience_vars): New prototype.
gdb/testsuite/
2013-10-06 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.base/corefile.exp: Test whether $_exitsignal is set and
$_exitcode is void when opening a corefile.
* gdb.base/exitsignal.exp: New file.
* gdb.base/segv.c: Likewise.
* gdb.base/normal.c: Likewise.
gdb/doc/
2013-10-06 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.texinfo (Convenience Variables): Document $_exitsignal.
Update entry for $_exitcode.
* NEWS: Mention support for DWP file format version 2.
* dwarf2read.c (dwarf2_section_info): Convert asection field to a
union of asection, containing_section. New fields virtual_offset
and is_virtual. Change type of readin filed from int to char.
(dwo_sections, dwo_file): Tweak comments.
(dwp_v2_section_ids): New enum.
(dwp_sections): New fields abbrev, info, line, loc, macinfo, macro,
str_offsets, types.
(virtual_v1_dwo_sections): Renamed from virtual_dwo_sections.
All uses updated.
(virtual_v2_dwo_sections): New struct.
(dwp_hash_table): New fields version, nr_columns. Change type of
section_pool field to a union.
(dwp_file): New field version.
(dwarf2_has_info): Check for virtual sections.
(get_containing_section): New function.
(get_section_bfd_owner, get_section_bfd_section): Call it.
(dwarf2_locate_sections): Update.
(dwarf2_section_empty_p): Update.
(dwarf2_read_section): Handle virtual sections.
(locate_dwz_sections): Update.
(create_dwp_hash_table): Document and handle V2 format.
(locate_v1_virtual_dwo_sections): Renamed from
locate_virtual_dwo_sections and update. All callers updated.
(create_dwo_unit_in_dwp_v1): Renamed from create_dwo_in_dwp.
Delete arg htab. Rename arg section_index to unit_index.
All callers updated.
(MAX_NR_V1_DWO_SECTIONS): Renamed from MAX_NR_DWO_SECTIONS.
All uses updated.
(create_dwp_v2_section, create_dwo_unit_in_dwp_v2): New functions.
(lookup_dwo_unit_in_dwp): Add V2 support.
(dwarf2_locate_dwo_sections): Update.
(dwarf2_locate_common_dwp_sections): Renamed from
dwarf2_locate_dwp_sections and update. All callers updated.
(dwarf2_locate_v2_dwp_sections): New function.
(open_and_init_dwp_file): Add V2 support.
(read_str_index): New locals str_section, str_offsets_section.
The ptid_t contructors, accessors and predicates are documented in
_three_ places, and each place uses a different wording.
E.g, the descriptions in the .c file of the new ptid_lwp_p, ptid_tid_p
weren't updated in the final revision like the descriptions in the .h
file were. Clearly, switching to a style that has a single central
description avoids such issues.
Worse, some of the existing descriptions are plain wrong, such as:
/* Attempt to find and return an existing ptid with the given PID, LWP,
and TID components. If none exists, create a new one and return
that. */
ptid_t ptid_build (int pid, long lwp, long tid);
The function does nothing that complicated. It's just a simple
constructor.
So this gets rid of all the unnecessary descriptions, leaving only the
ones near the function declarations in the header file, and
fixes/clarifies those that remain.
gdb/
2013-10-04 Pedro Alves <palves@redhat.com>
* common/ptid.c (null_ptid, minus_one_ptid, ptid_build)
(pid_to_ptid, ptid_get_pid, ptid_get_lwp, ptid_get_tid)
(ptid_equal, ptid_is_pid, ptid_lwp_p, ptid_tid_p): Replace
describing comments with references to ptid.h.
* common/ptid.h: Remove intro description of constructors,
accessors and predicates.
(struct ptid): Reformat.
(minus_one_ptid, ptid_build, pid_to_ptid, ptid_get_pid)
(ptid_get_lwp, ptid_get_tid, ptid_equal, ptid_is_pid): Change
describing comments.
This patch fixes a small typo after the BUILD_THREAD -> ptid_build
conversion.
gdb/ChangeLog:
* aix-thread.c (sync_threadlists): Add missing ')' in call
to ptid_build.
We're casting "addr" into "addr_ptr", but this variable is actually
a parameter with that very same type...
gdb/ChangeLog:
* aix-thread.c (ptrace32): Remove cast to addr_ptr.
gdb/ChangeLog:
* mi/mi-main.c (run_one_inferior): Add function description.
Make ARG a pointer to an integer whose value determines whether
we should "run" or "start" the program.
(mi_cmd_exec_run): Add handling of the "--start" option.
Reject all other command-line options.
* NEWS: Add entry for "-exec-run"'s new "--start" option.
gdb/doc/ChangeLog:
* gdb.texinfo (GDB/MI Program Execution): Document "-exec-run"'s
new "--start" option.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-start.c, gdb.mi/mi-start.exp: New files.
This patch moves pending_event to remote_notif_state. All pending
events are destroyed in remote_notif_state_xfree. However,
discard_pending_stop_replies release pending event too, so the pending
event of stop notification is released twice, we need some refactor
here. We add a new function discard_pending_stop_replies_in_queue
which only discard events in stop_reply_queue, and let
remote_notif_state_xfree release pending event for all notif_client.
After this change, discard_pending_stop_replies is only attached to
ifnerior_exit observer, so the INF can't be NULL any more. The
NULL checking is removed too.
gdb:
2013-10-04 Yao Qi <yao@codesourcery.com>
* remote-notif.h (REMOTE_NOTIF_ID): New enum.
(struct notif_client) <pending_event>: Moved
to struct remote_notif_state.
<id>: New field.
(struct remote_notif_state) <pending_event>: New field.
(notif_event_xfree): Declare.
* remote-notif.c (handle_notification): Adjust.
(notif_event_xfree): New function.
(do_notif_event_xfree): Call notif_event_xfree.
(remote_notif_state_xfree): Call notif_event_xfree to free
each element in field pending_event.
* remote.c (discard_pending_stop_replies): Remove declaration.
(discard_pending_stop_replies_in_queue): Declare.
(remote_close): Call discard_pending_stop_replies_in_queue
instead of discard_pending_stop_replies.
(remote_start_remote): Adjust.
(stop_reply_xfree): Call notif_event_xfree.
(notif_client_stop): Adjust initialization.
(remote_notif_remove_all): Rename it to ...
(remove_stop_reply_for_inferior): ... this. Update comments.
Don't check INF is NULL.
(discard_pending_stop_replies): Return early if notif_state is
NULL. Adjust. Don't check INF is NULL.
(remote_notif_get_pending_events): Adjust.
(discard_pending_stop_replies_in_queue): New function.
(remote_wait_ns): Likewise.
Hi,
This FIXME goes into my eyes, when I am about to modify something here,
/* Name is allocated by name_of_child. */
/* FIXME: xstrdup should not be here. */
This FIXME was introduced in the python pretty-pretter patches.
Python pretty-printing [6/6]
https://sourceware.org/ml/gdb-patches/2009-05/msg00467.html
create_child_with_value is called in two paths,
1. varobj_list_children -> create_child -> create_child_with_value,
2. install_dynamic_child -> install_dynamic_child -> varobj_add_child
-> create_child_with_value
In path #1, 'name' is allocated by name_of_child, as the original
comment said, we don't have to duplicate NAME in
create_child_with_value. In path #2, 'name' is got from
PyArg_ParseTuple, and we have to duplicate NAME.
This patch removes the call to xstrdup in create_child_with_value
and call xstrudp in update_dynamic_varobj_children (path #2).
gdb:
2013-10-04 Yao Qi <yao@codesourcery.com>
* varobj.c (create_child_with_value): Remove 'const' from the
type of parameter 'name'.
(varobj_add_child): Likewise.
(install_dynamic_child): Remove 'const' from the type of
parameter 'name'.
(varobj_add_child): Likewise.
(create_child_with_value): Likewise. Update comments. Don't
duplicate 'name'.
(update_dynamic_varobj_children): Duplicate 'name'
and pass it to install_dynamic_child.
* python/py-value.c (convert_value_from_python): Move PyInt_Check
conversion logic to occur after PyLong_Check. Comment on order
change significance.
* python/py-arch.c (archpy_disassemble): Comment on order of
conversion for integers and longs.
If enabling PTRACE_O_TRACEFORK fails, we never test for
PTRACE_O_TRACESYSGOOD support. Before PTRACE_O_TRACESYSGOOD is checked,
we have:
/* First, set the PTRACE_O_TRACEFORK option. If this fails, we
know for sure that it is not supported. */
ret = ptrace (PTRACE_SETOPTIONS, child_pid, (PTRACE_TYPE_ARG3) 0,
(PTRACE_TYPE_ARG4) PTRACE_O_TRACEFORK);
if (ret != 0)
{
ret = ptrace (PTRACE_KILL, child_pid, (PTRACE_TYPE_ARG3) 0,
(PTRACE_TYPE_ARG4) 0);
if (ret != 0)
{
warning (_("linux_check_ptrace_features: failed to kill child"));
return;
}
ret = my_waitpid (child_pid, &status, 0);
if (ret != child_pid)
warning (_("linux_check_ptrace_features: failed "
"to wait for killed child"));
else if (!WIFSIGNALED (status))
warning (_("linux_check_ptrace_features: unexpected "
"wait status 0x%x from killed child"), status);
return; <<<<<<<<<<<<<<<<<
}
Note that early return. If PTRACE_O_TRACEFORK isn't supported, we're
not checking PTRACE_O_TRACESYSGOOD. This didn't use to be a problem
before the unification of this whole detection business in
linux-ptrace.c. Before, the sysgood detection was completely
separate:
static void
linux_test_for_tracesysgood (int original_pid)
{
int ret;
sigset_t prev_mask;
/* We don't want those ptrace calls to be interrupted. */
block_child_signals (&prev_mask);
linux_supports_tracesysgood_flag = 0;
ret = ptrace (PTRACE_SETOPTIONS, original_pid, 0, PTRACE_O_TRACESYSGOOD);
if (ret != 0)
goto out;
linux_supports_tracesysgood_flag = 1;
out:
restore_child_signals_mask (&prev_mask);
}
So we need to get back the decoupling somehow. I think it's cleaner
to split the seperate feature detections to separate functions. This
patch does that. The new functions are named for their counterparts
that existed before this code was moved to linux-ptrace.c.
Note I've used forward declarations for the new functions to make the
patch clearer, as otherwise the patch would look like I'd be adding a
bunch of new code. A reorder can be done in a follow up patch.
Tested on x86_64 Fedora 17.
gdb/
2013-10-03 Pedro Alves <palves@redhat.com>
* common/linux-ptrace.c (linux_check_ptrace_features): Factor out
the PTRACE_O_TRACESYSGOOD and PTRACE_O_TRACEFORK to separate
functions. Always test for PTRACE_O_TRACESYSGOOD even if
PTRACE_O_TRACEFORK is not supported.
(linux_test_for_tracesysgood): New function.
(linux_test_for_tracefork): New function, factored out from
linux_check_ptrace_features, and also don't kill child_pid here.
Currently, in some scenarios, GDB prints <optimized out> when printing
outer frame registers. An <optimized out> register is a confusing
concept. What this really means is that the register is
call-clobbered, or IOW, not saved by the callee. This patch makes GDB
say that instead.
Before patch:
(gdb) p/x $rax $1 = <optimized out>
(gdb) info registers rax
rax <optimized out>
After patch:
(gdb) p/x $rax
$1 = <not saved>
(gdb) info registers rax
rax <not saved>
However, if for some reason the debug info describes a variable as
being in such a register (**), we still want to print <optimized out>
when printing the variable. IOW, <not saved> is reserved for
inspecting registers at the machine level. The patch uses
lval_register+optimized_out to encode the not saved registers, and
makes it so that optimized out variables always end up in
!lval_register values.
** See <https://sourceware.org/ml/gdb-patches/2012-08/msg00787.html>.
Current/recent enough GCC doesn't mark variables/arguments as being in
call-clobbered registers in the ranges corresponding to function
calls, while older GCCs did. Newer GCCs will just not say where the
variable is, so GDB will end up realizing the variable is optimized
out.
frame_unwind_got_optimized creates not_lval optimized out registers,
so by default, in most cases, we'll see <optimized out>.
value_of_register is the function eval.c uses for evaluating
OP_REGISTER (again, $pc, etc.), and related bits. It isn't used for
anything else. This function makes sure to return lval_register
values. The patch makes "info registers" and the MI equivalent use it
too. I think it just makes a lot of sense, as this makes it so that
when printing machine registers ($pc, etc.), we go through a central
function.
We're likely to need a different encoding at some point, if/when we
support partially saved registers. Even then, I think
value_of_register will still be the spot to tag the intention to print
machine register values differently.
value_from_register however may also return optimized out
lval_register values, so at a couple places where we're computing a
variable's location from a dwarf expression, we convert the resulting
value away from lval_register to a regular optimized out value.
Tested on x86_64 Fedora 17
gdb/
2013-10-02 Pedro Alves <palves@redhat.com>
* cp-valprint.c (cp_print_value_fields): Adjust calls to
val_print_optimized_out.
* jv-valprint.c (java_print_value_fields): Likewise.
* p-valprint.c (pascal_object_print_value_fields): Likewise.
* dwarf2loc.c (dwarf2_evaluate_loc_desc_full)
<DWARF_VALUE_REGISTER>: If the register was not saved, return a
new optimized out value.
* findvar.c (address_from_register): Likewise.
* frame.c (put_frame_register): Tweak error string to say the
register was not saved, rather than optimized out.
* infcmd.c (default_print_one_register_info): Adjust call to
val_print_optimized_out. Use value_of_register instead of
get_frame_register_value.
* mi/mi-main.c (output_register): Use value_of_register instead of
get_frame_register_value.
* valprint.c (valprint_check_validity): Likewise.
(val_print_optimized_out): New value parameter. If the value is
lval_register, print <not saved> instead.
(value_check_printable, val_print_scalar_formatted): Adjust calls
to val_print_optimized_out.
* valprint.h (val_print_optimized_out): New value parameter.
* value.c (struct value) <optimized_out>: Extend comment.
(error_value_optimized_out): New function.
(require_not_optimized_out): Use it. Use a different string for
lval_register values.
* value.h (error_value_optimized_out): New declaration.
* NEWS: Mention <not saved>.
gdb/testsuite/
2013-10-02 Pedro Alves <palves@redhat.com>
* gdb.dwarf2/dw2-reg-undefined.exp <pattern_rax_rbx_rcx_print,
pattern_rax_rbx_rcx_info>: Set to "<not saved>".
* gdb.mi/mi-reg-undefined.exp (opt_out_pattern): Delete.
(not_saved_pattern): New.
Replace use of the former with the latter.
gdb/doc/
2013-10-02 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Registers): Expand description of saved registers
in frames. Explain <not saved>.
This avoids duplicating the logic comparing two symbol_search
objects (in search_symbols_equal and compare_search_syms).
gdb/ChangeLog:
* symtab.c (search_symbols_equal): Delete.
(sort_search_symbols_remove_dups): Replace call to
search_symbols_equal by call to compare_search_syms,
adjusting as necessary.
* arm-wince-tdep.c: Remove inclusion of "solib.h" and
"solib-target.h". Include "windows-tdep.h".
(arm_wince_init_abi): Call windows_init_abi. Remove call to
set_solib_ops and set_gdbarch_has_dos_based_file_system.
* configure.tgt (arm*-wince-pe | arm*-*-mingw32ce*): Append
windows-tdep.o to gdb_target_obs.
* amd64-windows-tdep.c: Remove inclusion of "solib.h" and
"solib-target.h".
(amd64_windows_init_abi): Don't call set_solib_ops and
set_gdbarch_iterate_over_objfiles_in_search_order. Call
windows_init_abi instead.
* i386-cygwin-tdep.c: Remove inclusion of "solib.h" and
"solib-target.h".
(i386_cygwin_init_abi): Don't call set_solib_ops,
set_gdbarch_has_dos_based_file_system and
set_gdbarch_iterate_over_objfiles_in_search_order. Call
windows_init_abi instead.
* windows-tdep.c: Include "solib.h" and "solib-target.h".
(windows_init_abi): New function.
(windows_iterate_over_objfiles_in_search_order): Make it
static.
* windows-tdep.h (windows_init_abi): Declare.
(windows_iterate_over_objfiles_in_search_order): Remove
declaration.
So far elinos.py was assuming that the whole ELinOS environment was
around to find the system libraries; if some environment variables
were missing, the script would just abort.
This was a bit extreme. It is possible to do better than that: to get
the core system libraries, one doesn't need to have a full environment
but just the path to the CDK. The path to kernel project is only
needed for the optional Xenomai libs.
gdb/ChangeLog:
* system-gdbinit/elinos.py (get_elinos_environment): Return an
incomplete dictionnary instead of None in case of missing
environment variables.
(elinos_init): in case of an incomplete environment, best
effort to load system libraries instead of abort.
When building the program with the shared GNAT runtime, the debugger
is unable to insert Ada exception catchpoints until that runtime
has been mapped to memory. In other words, we expect the user to start
the program first, before attempting to insert that catchpoint.
The detection mechanism that tries to provide some useful tips to
the user fails when the program itself contains a trampoline symbol
matching the symbol that the catchpoint is trying to use. This
results in the following error message:
(gdb) catch exception
Your Ada runtime appears to be missing some debugging information.
Cannot insert Ada exception catchpoint in this configuration.
Instead, we expected the following error message:
(gdb) catch exception
Unable to insert catchpoint. Try to start the program first.
gdb/ChangeLog:
* ada-lang.c (ada_has_this_exception_support): Ignore
mst_solib_trampoline minimal symbols.
* i386-darwin-nat.c (darwin_complete_target): Install methods for
hardware watchpoint.
(i386_darwin_dr_set): Support 32 and 64 bit states.
(i386_darwin_dr_get): Likewise.
(i386_darwin_dr_set_control): Make static.
(i386_darwin_dr_set_addr, i386_darwin_dr_get_addr)
(i386_darwin_dr_get_status, i386_darwin_dr_get_control): Likewise.
It is possible to have a build of glibc where SYS_perf_event_open is not
defined (because when the glibc was compiled, the syscall did not exist),
but have newer kernel headers installed so that linux/perf_event.h is
available. In this setup, you get a build failure:
./common/linux-btrace.c: In function 'kernel_supports_btrace':
./common/linux-btrace.c:316:23: error: 'SYS_perf_event_open' undeclared (first use in this function)
Update the ifdef check to also see if the syscall is available.
URL: https://bugs.gentoo.org/473522
Reported-by: William Throwe <wtt6@cornell.edu>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
(dwp_file): Split loaded_cutus into loaded_cus, loaded_tus.
All uses updated.
(dwarf2_section_empty_p): Rename arg from "info" to "section".
(dwarf2_read_section): Delete unused local "header". Add section
name to error message.
(create_dwo_in_dwp): Tweak comment.
(MAX_NR_DWO_SECTIONS): Combine count of .debug_macro + .debug_macinfo.
(get_section_bfd_owner, get_section_bfd_section): New functions.
(get_section_name, get_section_file_name): New functions.
(get_section_id, get_section_flags): New functions.
(*): Use new functions to access section fields.
(lookup_dwo_unit_in_dwp): Renamed from lookup_dwo_in_dwp. Remove
arg "htab". All callers updated.
(create_debug_types_hash_table): Remove redundant copy of
abbrev_section.
(create_dwo_in_dwp): Tweak comments.
(read_str_index): Tweak comment. Record dwarf form name in static
local.
I tried debugging a remote Windows program on Linux host, and pointed the
sysroot to "/some/path/" rather than "remote:", and I found GDB couldn't
find the dlls in the sysroot. If the dll name is
"C:/Windows/system32/ntdll.dll", I end up with the sysroot+in_pathname
concatenated this way:
(top-gdb) p temp_pathname
$1 = 0x228b690 "/some/pathC:/Windows/system32/ntdll.dll"
^^
That is, a directory separator is missing. This is a regression.
The problem is that solib_find decides that since the target path has
a drive spec, a separator is not necessary, which is clearly wrong in
this case. That check was added in
<https://sourceware.org/ml/gdb-patches/2013-06/msg00028.html>, to
handle the case of sysroot being "remote:". This patch fixes that
original issue in a different way. Instead of checking whether the
path has a drive spec, check whether the sysroot is "remote:". The
patch adds a table that helps visualize the cases that need a
separator. I also confirmed the original issue is still handled as
expected. That is, that "set sysroot remote:" still does the right
thing.
remote_filename_p returns true if the filename is prefixed with
"remote:". In this case, we need to check whether the filename is
exactly "remote:". I thought of different ways or either changing
remote_filename_p or adding another convenience function to remote.c
to avoid exposing the "remote:" prefix out of remote.c. But all
attempts turned out adding lot of over needless complication. So the
patch just exposes the prefix behind a new macro, which allows using a
straighforward strcmp.
gdb/
2013-09-27 Pedro Alves <palves@redhat.com>
* remote.h (REMOTE_SYSROOT_PREFIX): New define.
(remote_filename_p): Add comment.
* remote.c (remote_filename_p): Adjust to use
REMOTE_SYSROOT_PREFIX.
* solib.c (solib_find): When deciding whether we need to add a
directory separator, check whether the sysroot is "remote:"
instead of checking whether the patch has a drive spec. Add
comments.
I noticed these fields aren't really necessary -- if the T stop reply
indicated any we have any special event, the fallthrough doesn't
really do anything.
Tested on x86_64 Fedora 17 w/ local gdbserver, and also confirmed
"catch load" against a Windows gdbserver running under Wine, which
exercises TARGET_WAITKIND_LOADED, still works as expected.
gdb/
2013-09-27 Pedro Alves <palves@redhat.com>
* remote.c (struct stop_reply) <solibs_changed, replay_event>:
Delete fields.
(remote_parse_stop_reply): Adjust, setting event->ws.kind
directly.
AMD64_R15_REGNUM when a register index is expected.
* amd64-windows-tdep.c (amd64_windows_dummy_call_integer_regs):
Substitute in array.
* amd64-tdep.c (amd64_dwarf_regmap): Ditto.
(amd64_push_arguments): Substitute in integer_regnum array.
* NEWS: Mention "set debug symfile".
* Makefile.in (SFILES): Add symfile-debug.c.
(COMMON_OBS): Add symfile-debug.o.
* elfread.c (elf_symfile_read): Use objfile_set_sym_fns to set the
objfile's symbol functions.
* objfiles.h (objfile_set_sym_fns): Declare.
* symfile-debug.c: New file.
* symfile.c (syms_from_objfile_1): Use objfile_set_sym_fns to set the
objfile's symbol functions.
(reread_symbols): Ditto.
All uses updated.
(add_symtab_fns): Update prototype.
* symfile.c (sym_fns_ptr): Delete. Replace with ...
(registered_sym_fns): ... this.
(symtab_fns): Update.
(add_symtab_fns): New arg "flavour". All callers updated.
(find_sym_fns): Rewrite to use new sym_fns registry.
2013-09-25 Andreas Arnez <arnez@linux.vnet.ibm.com>
PR shlibs/8882
* solib-svr4.c (svr4_read_so_list): Skip the vDSO when reading
link map entries.
testsuite/ChangeLog:
2013-09-25 Andreas Arnez <arnez@linux.vnet.ibm.com>
PR shlibs/8882
* gdb.base/corefile.exp: Add a check to assure warning-free
core-file load.
This is no longer useful, as it was introduced to reuse the funcall
handling code in amd64-tdep.c in the context of x64-windows. But
we have since then changed the implementations to be completely
independent of each other.
This reverts the non-windows-specific part of the change called:
amd64: Integer parameters in function calls on Windows
(the x64-windows portion has already been reverted)
gdb/ChangeLog:
Revert:
* i386-tdep.h (enum amd64_reg_class): New, moved here from
amd64-tdep.c.
(struct gdbarch_tdep): Add fields call_dummy_num_integer_regs,
call_dummy_integer_regs, and classify.
* amd64-tdep.h (amd64_classify): Add declaration.
* amd64-tdep.c (amd64_dummy_call_integer_regs): New static constant.
(amd64_reg_class): Delete, moved to i386-tdep.h.
(amd64_classify): Make non-static. Move declaration to amd64-tdep.h.
Replace call to amd64_classify by call to tdep->classify.
(amd64_push_arguments): Get the list of registers to use for
passing integer parameters from the gdbarch tdep structure,
rather than using a hardcoded one. Replace calls to amd64_classify
by calls to tdep->classify.
(amd64_push_dummy_call): Get the register number used for
the "hidden" argument from tdep->call_dummy_integer_regs.
(amd64_init_abi): Initialize tdep->call_dummy_num_integer_regs
and tdep->call_dummy_integer_regs. Set tdep->classify.
This is no longer useful, as it was introduced to reuse the funcall
handling code in amd64-tdep.c in the context of x64-windows. But
we have since then changed the implementations to be completely
independent of each other.
This reverts the non-windows-specific part of the change called:
amd64-windows: memory args passed by pointer during function calls.
(the x64-windows portion has already been reverted)
gdb/ChangeLog:
Revert:
* i386-tdep.h (gdbarch_tdep): Add field memory_args_by_pointer.
* amd64-tdep.c (amd64_push_arguments): Add handling of architectures
where tdep->memory_args_by_pointer is non-zero.
This is no longer useful, as it was introduced to reuse the funcall
handling code in amd64-tdep.c in the context of x64-windows. But
we have since then changed the implementations to be completely
independent of each other.
This reverts the non-windows-specific part of the change called:
amd64-windows: 32 bytes allocated on stack by caller for integer
parameter regs
(the x64-windows portion has already been reverted)
gdb/ChangeLog:
Revert:
* i386-tdep.h (struct gdbarch_tdep): Add new field
integer_param_regs_saved_in_caller_frame.
* amd64-tdep.c (amd64_push_dummy_call): Allocate some memory on
stack if tdep->integer_param_regs_saved_in_caller_frame is set.
This patch provides a standalone implementation of function calls
on amd64-windows, instead of providing some bits and pieces hooking
into the function call implementation meant for sysV (in amd64-tdep).
It makes better sense to do it this way, because the two ABIs are
actually very different; for instance, the concept of argument
classification, which is so central in the sysV ABI and drove the
the implementation in amd64-tdep, makes no sense for Windows. It
is therefore better for the Windows implementation to be completely
separate, rather than rely on adaptations of the sysV implementation.
gdb/ChangeLog:
* amd64-tdep.c: #include "value.h"
(amd64_windows_classify): Delete.
(amd64_windows_passed_by_integer_register)
(amd64_windows_passed_by_xmm_register)
(amd64_windows_passed_by_pointer)
(amd64_windows_adjust_args_passed_by_pointer)
(amd64_windows_store_arg_in_reg, amd64_windows_push_arguments)
(amd64_windows_push_dummy_call): New functions.
(amd64_windows_init_abi): Remove setting of
tdep->call_dummy_num_integer_regs, tdep->call_dummy_integer_regs,
tdep->classify, tdep->memory_args_by_pointer and
tdep->integer_param_regs_saved_in_caller_frame.
Add call to set_gdbarch_push_dummy_call.
gdb/
2013-09-24 Jan Kratochvil <jan.kratochvil@redhat.com>
* dwarf2read.c (open_and_init_dwp_file): Try open_dwp_file also with
objfile->original_name.
gdb/testsuite/
2013-09-24 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.dwarf2/dwp-symlink.c: New file.
* gdb.dwarf2/dwp-symlink.exp: New file.
gdb/
2013-09-24 Jan Kratochvil <jan.kratochvil@redhat.com>
Pass down original filename for objfile.
* coffread.c (coff_symfile_read): Update symbol_file_add_separate call.
* elfread.c (elf_symfile_read): Likewise.
* jit.c (jit_object_close_impl): Update allocate_objfile call, no
longer set ORIGINAL_NAME.
(jit_bfd_try_read_symtab): Update symbol_file_add_from_bfd call.
* jv-lang.c (get_dynamics_objfile): Update allocate_objfile call.
* machoread.c (macho_add_oso_symfile): Add parameter name. Update
symbol_file_add_from_bfd call.
(macho_symfile_read_all_oso): Update two macho_add_oso_symfile calls.
(macho_check_dsym): Add parameter filenamep. Change function comment.
Set *filenamep.
(macho_symfile_read): New variable dsym_filename. Update
macho_check_dsym call. Use it for symbol_file_add_separate.
* objfiles.c (allocate_objfile): Add parameter name. New comment for
it. Use it for objfile->original_name.
(objfile_name): Return OBFD's filename, if available.
* objfiles.h (allocate_objfile): Add new parameter name.
* solib.c (solib_read_symbols): Update symbol_file_add_from_bfd call.
* symfile-mem.c (symbol_file_add_from_memory): Update
symbol_file_add_from_bfd call.
* symfile.c (read_symbols): Update symbol_file_add_separate call, new
comment for it.
(symbol_file_add_with_addrs): New parameter name, add function comment
for it. Remove variable name. Update allocate_objfile call.
(symbol_file_add_separate): New parameter name, add function comment
for it. Update symbol_file_add_with_addrs call.
(symbol_file_add_from_bfd): New parameter name. Update
symbol_file_add_with_addrs call.
(symbol_file_add): Update symbol_file_add_from_bfd call.
(reread_symbols): New variable original_name. Save
objfile->original_name by it.
* symfile.h (symbol_file_add_from_bfd, symbol_file_add_separate): Add
second parameter.
The recent change to make GDB auto-delete thread-specific breakpoints
when the corresponding thread is deleted
(https://sourceware.org/ml/gdb-patches/2013-09/msg00038.html) caused
gdb.base/nextoverexit.exp to regress.
Breakpoint 1, main () at .../gdb/testsuite/gdb.base/nextoverexit.c:21
21 exit (0);
(gdb) next
[Inferior 1 (process 25208) exited normally]
Thread-specific breakpoint -5 deleted - thread 1 is gone.
Thread-specific breakpoint -6 deleted - thread 1 is gone.
Thread-specific breakpoint -7 deleted - thread 1 is gone.
Thread-specific breakpoint 0 deleted - thread 1 is gone.
(gdb) FAIL: gdb.base/nextoverexit.exp: next over exit (the program exited)
We shouldn't be seeing this for internal or momentary breakpoints. In
fact, we shouldn't even be trying to delete them, as whatever created
them will take care or it, and therefore it's dangerous to delete them
behind the creator's back.
I thought it'd still be good to tag thread-specific internal/momentary
breakpoints such that we'll no longer try to keep them insert in the
target, as they'll cause stops and thread hops in other threads, so I
tried disabling them instead. That caused a problem when following a
child fork, and detaching from the parent, as we try to reset the
step-resume etc. breakpoints to the new child's thread
(breakpoint_re_set_thread), after the parent thread is already gone
(and the breakpoints are marked disabled). I fixed that by
re-enabling internal/momentary breakpoints there, but, that didn't
feel super safe either (maybe we'd need a new flag in struct
breakpoint instead, to tag the thread-specific breakpoint as "not to
be inserted"). It felt like I was heading down a design rat hole,
and, other things will usually delete internal/momentary breakpoints
soon enough, so I left that little optimization for some other day.
So, internal/momentary breakpoints are no longer deleted/disabled at
all, and we end up with a one-liner fix.
Tested on x86_64 Fedora 17.
gdb/
2013-09-19 Pedro Alves <palves@redhat.com>
* breakpoint.c (remove_threaded_breakpoints): Skip non-user
breakpoints.
This removes another instance of a deprecated_xfer_memory user.
gdb/
2013-09-19 Pedro Alves <palves@redhat.com>
Thomas Schwinge <thomas@codesourcery.com>
Yue Lu <hacklu.newborn@gmail.com>
* gnu-nat.c (gnu_read_inferior, gnu_write_inferior): Make static.
Take a gdb_byte pointer instead of a char pointer.
* gnu-nat.c (gnu_xfer_memory): Adjust interface as
gnu_xfer_partial helper.
(gnu_xfer_partial): New function.
(gnu_target): Don't install a deprecated_xfer_memory hook.
Install a to_xfer_partial hook.
gdb/
2013-09-19 Jan Kratochvil <jan.kratochvil@redhat.com>
Constification.
* main.c (captured_main): Replace catch_command_errors by
catch_command_errors_const. Twice.
* symfile.c (symbol_file_add_main_1): Make args parameter const.
(symbol_file_add): Make name parameter const.
(symbol_file_add_main, symbol_file_add_main_1): Make args parameter const.
(symfile_bfd_open): Make name parameter const, rename it to cname. Add
variable name. Change their usage accordingly.
* symfile.h (symbol_file_add, symfile_bfd_open): Make first parameter
const.
(symbol_file_add_main): Make args parameter const.
Ulrich Weigand <uweigand@de.ibm.com>
* xcoffread.c (struct coff_symbol): Use CORE_ADDR as type
of c_value member.
(read_xcoff_symtab): Use CORE_ADDR as type of fcn_start_addr.
2013-09-18 Pedro Alves <palves@redhat.com>
Yue Lu <hacklu.newborn@gmail.com>
* gnu-nat.c (inf_validate_procs, gnu_wait, gnu_resume)
(gnu_create_inferior)
(gnu_attach, gnu_thread_alive, gnu_pid_to_str, cur_thread)
(set_sig_thread_cmd): Use the lwpid field of ptids to
store/extract thread ids instead of the tid field.
* i386gnu-nat.c (gnu_fetch_registers): Adjust.
instead of ptid_t.tid.
In preparation for reusing gnu-nat.c in gdbserver, switch to storing
thread ids in the lwpid field of ptid_t rather than in the tid
field. The Hurd's thread model is 1:1, so it doesn't feel wrong
anyway.
gdb/
2013-09-18 Pedro Alves <palves@redhat.com>
* gnu-nat.c (inf_validate_procs, gnu_wait, gnu_resume)
(gnu_create_inferior)
(gnu_attach, gnu_thread_alive, gnu_pid_to_str, cur_thread)
(set_sig_thread_cmd): Use the lwpid field of ptids to
store/extract thread ids instead of the tid field.
* i386gnu-nat.c (gnu_fetch_registers): Adjust.
https://sourceware.org/ml/gdb-patches/2013-08/msg00170.html
gdb/ChangeLog
* infcmd.c (default_print_one_register_info): Add detection of
optimized out values.
(default_print_registers_info): Switch to using
get_frame_register_value.
gdb/testsuite/ChangeLog
* gdb.dwarf2/dw2-reg-undefined.exp: Change pattern for info
register to "<optimized out>", and also print the registers.
By inspection, I noticed that when I made the gnu-nat use
ptid(pid,0,tid) to represent a thread, instead of using ptid(tid,0,0),
in <https://sourceware.org/ml/gdb-patches/2008-08/msg00175.html>, I
introduced a bug.
The change was:
else
{
- int tid = PIDGET (thread_id_to_pid (atoi (args)));
+ int tid = ptid_get_tid (thread_id_to_pid (atoi (args)));
if (tid < 0)
error (_("Thread ID %s not known. Use the \"info threads\" command to\n"
"see the IDs of currently known threads."), args);
and thread_id_to_pid does:
ptid_t
thread_id_to_pid (int num)
{
struct thread_info *thread = find_thread_id (num);
if (thread)
return thread->ptid;
else
return pid_to_ptid (-1);
}
(pid_to_ptid (-1) is the same as minus_one_ptid.)
So before, we were really looking at the pid, where thread_id_to_pid
stores the -1.
The right fix is to compare the whole ptid to minus_one_ptid, of
course.
Completely untested, but I think it's obvious enough, so I went ahead
and put it in.
gdb/
2013-09-18 Pedro Alves <palves@redhat.com>
* gnu-nat.c (set_sig_thread_cmd): Compare the thread's ptid to
minus_one_ptid instead of looking at the ptid's tid field and
comparing that to -1.
PR gdb/11568 is about thread-specific breakpoints being left behind
when the corresponding thread exits.
Currently:
(gdb) b start thread 2
Breakpoint 3 at 0x400614: file thread-specific-bp.c, line 23.
(gdb) b end
Breakpoint 4 at 0x40061f: file thread-specific-bp.c, line 29.
(gdb) c
Continuing.
[Thread 0x7ffff7fcb700 (LWP 14925) exited]
[Switching to Thread 0x7ffff7fcc740 (LWP 14921)]
Breakpoint 4, end () at thread-specific-bp.c:29
29 }
(gdb) info threads
Id Target Id Frame
* 1 Thread 0x7ffff7fcc740 (LWP 14921) "thread-specific" end () at thread-specific-bp.c:29
(gdb) info breakpoints
Num Type Disp Enb Address What
2 breakpoint keep y 0x0000000000400614 in start at thread-specific-bp.c:23
breakpoint already hit 1 time
3 breakpoint keep y 0x0000000000400614 in start at thread-specific-bp.c:23 thread 2
stop only in thread 2
4 breakpoint keep y 0x000000000040061f in end at thread-specific-bp.c:29
breakpoint already hit 1 time
Note that the thread-specific breakpoint 3 stayed around, even though
thread 2 is gone.
There's no way that breakpoint can trigger again (*), so the PR argues
that the breakpoint should just be removed, like local watchpoints.
I'm ambivalent on this -- it could be reasonable to disable the
breakpoint (kind of like breakpoint in shared library code when the
DSO is unloaded), so the user could still use it as visual template
for creating other breakpoints (copy/paste command lists, etc.), or we
could have a way to change to which thread a breakpoint applies. But,
several people pushed this direction, and I don't plan on arguing...
(*) - actually, there is ... thread numbers are reset on "run", so
the user could do "break foo thread 2", "run", and expect the
breakpoint to hit again on the second thread. But given gdb's thread
numbering can't really be stable, that'd only work sufficiently well
for thread 1, so we'd better call it unsupported.
So with the patch, whenever a thread is deleted from GDB's list, GDB
goes through the thread-specific breakpoints and deletes corresponding
breakpoints. Since this is user-visible, GDB prints out:
Thread-specific breakpoint 3 deleted - thread 2 is gone.
And of course, we end up with:
(gdb) info breakpoints
Num Type Disp Enb Address What
2 breakpoint keep y 0x0000000000400614 in start at thread-specific-bp.c:23
breakpoint already hit 1 time
4 breakpoint keep y 0x000000000040061f in end at thread-specific-bp.c:29
breakpoint already hit 1 time
2013-09-17 Muhammad Waqas <mwaqas@codesourcery.com>
Pedro Alves <palves@redhat.com>
PR gdb/11568
* breakpoint.c (remove_threaded_breakpoints): New function.
(_initialize_breakpoint): Attach remove_threaded_breakpoints
as thread_exit observer.
2013-09-17 Muhammad Waqas <mwaqas@codesourccery.com>
Jan Kratochvil <jan.kartochvil@redhat.com>
Pedro Alves <palves@redhat.com>
PR gdb/11568
* gdb.thread/thread-specific-bp.c: New file.
* gdb.thread/thread-specific-bp.exp: New file.
"info threads" changes the default source for "break" and "list", to
whatever the location of the first/bottom thread in the thread list
is...
(gdb) b start
(gdb) c
...
(gdb) list
*lists "start"*
(gdb) b 23
Breakpoint 3 at 0x400614: file test.c, line 23.
(gdb) info threads
Id Target Id Frame
* 2 Thread 0x7ffff7fcb700 (LWP 1760) "test" start (arg=0x0) at test.c:23
1 Thread 0x7ffff7fcc740 (LWP 1748) "test" 0x000000323dc08e60 in pthread_join (threadid=140737353922304, thread_return=0x0) at pthread_join.c:93
(gdb) b 23
Breakpoint 4 at 0x323dc08d90: file pthread_join.c, line 23.
^^^^^^^^^^^^^^^
(gdb) list
93 lll_wait_tid (pd->tid);
94
95
96 /* Restore cancellation mode. */
97 CANCEL_RESET (oldtype);
98
99 /* Remove the handler. */
100 pthread_cleanup_pop (0);
101
102
The issue is that print_stack_frame always sets the current sal to the
frame's sal. print_frame_info (which print_stack_frame calls to do
most of the work) also sets the last displayed sal, but only if
print_what isn't LOCATION. Now the call in question, from within
thread.c:print_thread_info, does pass in LOCATION as print_what, but
print_stack_frame doesn't have the same check print_frame_info has.
We could consider adding it, but setting these globals depending on
print_what isn't very clean, IMO. What we have is two logically
distinct operations mixed in the same function(s):
#1 - print frame, in the format specified by {print_what,
print_level and print_args}.
#2 - We're displaying a frame to the user, and I want the default
sal to point here, because the program stopped here, or the user
did some context-changing command (up, down, etc.).
So I added a new parameter to print_stack_frame & friends for point
#2, and went through all calls in the tree adjusting as necessary.
Tested on x86_64 Fedora 17.
gdb/
2013-09-17 Pedro Alves <palves@redhat.com>
PR gdb/15911
* ada-tasks.c (task_command_1): Adjust call to print_stack_frame.
* bsd-kvm.c (bsd_kvm_open, bsd_kvm_proc_cmd, bsd_kvm_pcb_cmd):
* corelow.c (core_open):
* frame.h (print_stack_frame, print_frame_info): New
'set_current_sal' parameter.
* infcmd.c (finish_command, kill_command): Adjust call to
print_stack_frame.
* inferior.c (inferior_command): Likewise.
* infrun.c (normal_stop): Likewise.
* linux-fork.c (linux_fork_context): Likewise.
* record-full.c (record_full_goto_entry, record_full_restore):
Likewise.
* remote-mips.c (common_open): Likewise.
* stack.c (print_stack_frame): New 'set_current_sal' parameter.
Use it.
(print_frame_info): New 'set_current_sal' parameter. Set the last
displayed sal depending on the new paremeter instead of looking at
print_what.
(backtrace_command_1, select_and_print_frame, frame_command)
(current_frame_command, up_command, down_command): Adjust call to
print_stack_frame.
* thread.c (print_thread_info, restore_selected_frame)
(do_captured_thread_select): Adjust call to print_stack_frame.
* tracepoint.c (tfind_1): Likewise.
* mi/mi-cmd-stack.c (mi_cmd_stack_list_frames)
(mi_cmd_stack_info_frame): Likewise.
* mi/mi-interp.c (mi_on_normal_stop): Likewise.
* mi/mi-main.c (mi_cmd_exec_return, mi_cmd_trace_find): Likewise.
gdb/testsuite/
* gdb.threads/info-threads-cur-sal-2.c: New file.
* gdb.threads/info-threads-cur-sal.c: New file.
* gdb.threads/info-threads-cur-sal.exp: New file.
"You should provide one parameter..." while it should be saying "... one
argument...". Replaced.
2013-09-16 Sergio Durigan Junior <sergiodj@redhat.com>
* value.c (isvoid_internal_fn): Replace "parameter" with
"argument".
<https://sourceware.org/ml/gdb-patches/2013-09/msg00301.html>
<https://sourceware.org/ml/gdb-patches/2013-09/msg00383.html>
This patch adds a new convenience function called $_isvoid, whose
only purpose is to check whether an expression is void or not.
This became necessary because the new convenience variable
$_exitsignal (not yet approved) has a mutual exclusive behavior
with $_exitcode, i.e., when one is "defined" (i.e., non-void),
the other is cleared (i.e., becomes void). Doug wanted a way to
identify which variable to use, and checking for voidness is the
obvious solution.
It is worth mentioning that my first attempt, after a conversation with
Doug, was to actually implement a new $_isdefined() convenience
function. I would do that (for convenience variables) by calling
lookup_only_internalvar. However, I found a few problems:
- Whenever I called $_isdefined ($variable), $variable became defined
(with a void value), and $_isdefined always returned true.
- Then, I tried to implement $_isdefined ("variable"), and do the "$" +
"variable" inside GDB, thus making it impossible for GDB to create the
convenience variable. However, it was hard to extract the string
without having to mess with values and their idiossincrasies.
Therefore, I decided to abandon this attempt (specially because I
didn't want to spend too much time struggling with it).
Anyway, after talking to Doug again we decided that it would be easier
to implement $_isvoid, and this will probably help in cases like
<http://stackoverflow.com/questions/3744554/testing-if-a-gdb-convenience-variable-is-defined>.
I wrote a NEWS entry for it, and some new lines on the documentation.
gdb/
2013-09-16 Sergio Durigan Junior <sergiodj@redhat.com>
* NEWS: Mention new convenience function $_isvoid.
* value.c (isvoid_internal_fn): New function.
(_initialize_values): Add new convenience function $_isvoid.
gdb/doc/
2013-09-16 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.texinfo (Convenience Functions): Mention new convenience
function $_isvoid.
gdb/testsuite/
2013-09-16 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.base/gdbvars.c (foo_void): New function.
(foo_int): Likewise.
* gdb.base/gdbvars.exp (test_convenience_functions): New
function. Call it.
Remove AT_HWCAP macro definintion as it is provided in
added include file.
* s390-tdep.c: Remove system header <elf.h>
Add "elf/common.h" header for AT_HWCAP definition.
(s390_core_read_description): Use correct CORE_ADDR
for hwcap local variable used as third parameter
of function target_auxv_search.
