Commit Graph

39311 Commits

Author SHA1 Message Date
John Baldwin 4b654465bf Read signal information from FreeBSD core dumps.
FreeBSD recently added a new ELF core note which dumps the entire LWP
info structure (the same structure returned by the ptrace PT_LWPINFO
operation) for each thread.  The plan is for this note to eventually
supplant the older "thrmisc" ELF core note as it contains more
information and it permits new information to be exported via both
ptrace() and core dumps using the same structure.

For signal information, the implementation is similar to the native
implementation for FreeBSD processes.  The PL_FLAG_SI flag must be
checked to determine if the embedded siginfo_t structure is valid, and
if so it is transferred into the caller's buffer.

gdb/ChangeLog:

	* fbsd-tdep.c (LWPINFO_OFFSET, LWPINFO_PL_FLAGS)
	(LWPINFO64_PL_SIGINFO, LWPINFO32_PL_SIGINFO, PL_FLAG_SI)
	(SIZE64_SIGINFO_T, SIZE32_SIGINFO_T, fbsd_core_xfer_siginfo): New.
	(fbsd_init_abi): Install gdbarch "core_xfer_siginfo" method.
2017-07-07 16:12:42 -07:00
John Baldwin 2af9fc4432 Use the thread_section_name helper class in fbsd_core_thread_name.
gdb/ChangeLog:

	* fbsd-tdep.c (fbsd_core_thread_name): Use thread_section_name.
2017-07-07 16:09:13 -07:00
John Baldwin 382b69bbb7 Add a new gdbarch method to fetch signal information from core files.
Previously the core_xfer_partial method used core_get_siginfo to handle
TARGET_OBJECT_SIGNAL_INFO requests.  However, core_get_siginfo looked for
Linux-specific sections in the core file.  To support fetching siginfo
from cores on other systems, add a new gdbarch method (`core_xfer_siginfo`)
and move the body of the existing core_get_siginfo into a
linux_core_xfer_siginfo implementation of this method in linux-tdep.c.

gdb/ChangeLog:

	* corelow.c (get_core_siginfo): Remove.
	(core_xfer_partial): Use the gdbarch "core_xfer_siginfo" method
	instead of get_core_siginfo.
	* gdbarch.sh (core_xfer_siginfo): New gdbarch callback.
	* gdbarch.h: Re-generate.
	* gdbarch.c: Re-generate.
	* linux-tdep.c (linux_core_xfer_siginfo): New.
	(linux_init_abi): Install gdbarch "core_xfer_siginfo" method.
2017-07-07 16:08:33 -07:00
John Baldwin 6e5eab33ab Move the thread_section_name class to gdbcore.h.
This allows it to be used outside of corelow.c.
2017-07-07 16:06:45 -07:00
John Baldwin 929edea98d Fetch signal information for native FreeBSD processes.
Use the `pl_siginfo' field in the `struct ptrace_lwpinfo' object returned
by the PT_LWPINFO ptrace() request to supply the current contents of
$_siginfo for each thread.  Note that FreeBSD does not supply a way to
modify the signal information for a thread, so $_siginfo is read-only for
FreeBSD.

To handle 32-bit processes on a 64-bit host, define types for 32-bit
compatible siginfo_t and convert the 64-bit siginfo_t to the 32-bit
equivalent when supplying information for a 32-bit process.

gdb/ChangeLog:

	* fbsd-nat.c [PT_LWPINFO && __LP64__] (union sigval32)
	(struct siginfo32): New.
	[PT_LWPINFO] (fbsd_siginfo_size, fbsd_convert_siginfo): New.
	(fbsd_xfer_partial) [PT_LWPINFO]: Handle TARGET_OBJECT_SIGNAL_INFO
	via ptrace(PT_LWPINFO).
2017-07-07 16:05:47 -07:00
John Baldwin 762c974a09 Implement the "get_siginfo_type" gdbarch method for FreeBSD architectures.
As with Linux architectures, cache the created type in the gdbarch when it
is first created.  Currently FreeBSD uses an identical siginfo type on
all architectures, so there is no support for architecture-specific fields.

gdb/ChangeLog:

	* fbsd-tdep.c (fbsd_gdbarch_data_handle, struct fbsd_gdbarch_data)
	(init_fbsd_gdbarch_data, get_fbsd_gdbarch_data)
	(fbsd_get_siginfo_type): New.
	(fbsd_init_abi): Install gdbarch "get_siginfo_type" method.
	(_initialize_fbsd_tdep): New.
2017-07-07 16:04:18 -07:00
David Blaikie 33c5cd7587 Fission support for multiple CUs per DWO file
In some cases a compiler may produce a single object file (& thus single
DWO file) representing multiple source files. The most common example of
this is in whole program optimization (such as LLVM's LTO). Fission may
still be a beneficial feature to use here - to avoid the need to
read/link the debug info with system libraries and the like.

This change adds basic support for multiple CUs in a single DWO file to
support LLVM's output in this situation.

There is still outstanding work to design and implement a solution for
cross-CU references (usually using DW_FORM_ref_addr) in this scenario.
For now LLVM works around this by duplicating DIEs rather than making
cross-CU references in DWO files. This degrades debugger
behavior/quality especially for file-local entities.

2017-07-06  David Blaikie  <dblaikie@gmail.com>

	* dwarf2read.c (struct dwo_file): Use a htab of dwo_unit* (rather than
	a singular dwo_unit*) to support multiple CUs in the same way that
	multiple TUs are supported.
	(create_cus_hash_table): Replace create_dwo_cu with a function for
	parsing multiple CUs from a DWO file.
	(open_and_init_dwo_file): Use create_cus_hash_table rather than
	create_dwo_cu.
	(lookup_dwo_cutu): Lookup CU in the hash table in the dwo_file with
	htab_find, rather than comparing the signature to a singleton CU in
	the dwo_file.

2017-07-06  David Blaikie  <dblaikie@gmail.com>

	* gdb.dwarf2/fission-multi-cu.S: Test containing multiple CUs in a DWO,
	built from fissiont-multi-cu{1,2}.c.
	* gdb.dwarf2/fission-multi-cu.exp: Test similar to fission-base.exp,
	except putting 'main' and 'func' in separate CUs in the same DWO file.
	* gdb.dwarf2/fission-multi-cu1.c: First CU for the multi-CU-single-DWO
	test.
	* gdb.dwarf2/fission-multi-cu2.c: Second CU in the multi-CU-single-DWO
	test.
2017-07-06 11:59:39 -07:00
Pedro Alves 8455d26243 Fix Python unwinder frames regression
The gdb.python/py-unwind.exp test is crashing GDB / leaving core dumps
in the test dir, even though it all passes cleanly.  The crash is not
visible in gdb.sum/gdb.log because it happens as side effect of the
"quit" command, while flushing the frame cache.

The problem is simply a typo in a 'for' loop's condition, introduced
by a recent change [4fa847d78e ("Remove MAX_REGISTER_SIZE from
py-unwind.c")], resulting in infinite loop / double-free.

The new test exposes the crash, like:

 Running src/gdb/testsuite/gdb.python/py-unwind.exp ...
 ERROR: Process no longer exists

gdb/ChangeLog:
2017-07-06  Pedro Alves  <palves@redhat.com>

	* python/py-unwind.c (pyuw_dealloc_cache): Fix for loop condition.

gdb/testsuite/ChangeLog:
2017-07-06  Pedro Alves  <palves@redhat.com>

	* gdb.python/py-unwind.exp: Test flushregs.
2017-07-06 00:19:24 +01:00
Pedro Alves 4da3eb35ef Garbage collect TYPE_STATIC and several TYPE_FN_FIELD_x
Nothing uses these.  Most of the TYPE_FN_FIELD_ ones were probably
used by the gcj support.

gdb/ChangeLog:
2017-07-04  Pedro Alves  <palves@redhat.com>

	* gdbtypes.c (recursive_dump_type): Don't reference TYPE_STATIC.
	* gdbtypes.h (TYPE_STATIC): Delete.
	(struct fn_field) <is_public, is_abstract, is_static, is_final,
	is_synchronized, is_native>: Delete.
	<dummy>: Bump.
	(TYPE_FN_FIELD_PUBLIC, TYPE_FN_FIELD_STATIC, TYPE_FN_FIELD_FINAL)
	(TYPE_FN_FIELD_SYNCHRONIZED, TYPE_FN_FIELD_NATIVE)
	(TYPE_FN_FIELD_ABSTRACT): Delete.
2017-07-04 18:40:26 +01:00
Simon Marchi 5bfd255c41 buffer.h: Fix spelling mistakes
gdb/ChangeLog:

	* buffer.h (buffer_finish): Fix spelling mistakes.
2017-07-03 13:59:00 +02:00
Eli Zaretskii 25c5412713 Setup .dir-locals.el to use C-style comments by default
gdb/ChangeLog:
2017-07-01  Eli Zaretskii  <eliz@gnu.org>

	* .dir-locals.el: Automatically switch to C-style comments in
	versions of Emacs that support the feature.
2017-07-01 18:45:57 +03:00
Sergio Durigan Junior dc4bde35d1 PR cli/21688: Detect aliases when issuing python/compile/guile commands (and fix last commit)
My last commit fixed a regression that happened when using
inline/multi-line commands for Python/Compile/Guile, but introduced
another regression: it is now not possible to use aliases for the
commands mentioned above.  The fix is to almost revert the change I've
made and go back to using the 'struct cmd_list_element *', but at the
same time make sure that we advance the 'cmd_name' variable past all
the whitespace characters after the command name.  If, after skipping
the whitespace, we encounter a '\0', it means that the command is not
inline.  Otherwise, it is.

This patch also expands the testcase in order to check for aliases and
for trailing whitespace after the command name.

gdb/ChangeLog:
2017-06-30  Sergio Durigan Junior  <sergiodj@redhat.com>
	    Pedro Alves  <palves@redhat.com>

	PR cli/21688
	* cli/cli-script.c (command_name_equals_not_inline): Remove function.
	(process_next_line): New variable 'inline_cmd'.
	Adjust 'if' clauses for "python", "compile" and "guile" to use
	'command_name_equals' and check for '!inline_cmd'.

gdb/testsuite/ChangeLog:
2017-06-30  Sergio Durigan Junior  <sergiodj@redhat.com>

	PR cli/21688
	* gdb.python/py-cmd.exp (test_python_inline_or_multiline): Add new
	tests for alias commands and trailing whitespace.
2017-06-30 09:31:21 -04:00
Sergio Durigan Junior 51ed89aa0d PR cli/21688: Fix multi-line/inline command differentiation
This bug is a regression caused by the following commit:

  604c4576fd is the first bad commit
  commit 604c4576fd
  Author: Jerome Guitton <guitton@adacore.com>
  Date:   Tue Jan 10 15:15:53 2017 +0100

The problem happens because, on cli/cli-script.c:process_next_line,
GDB is not using the command line string to identify which command to
run, but it instead using the 'struct cmd_list_element *' that is
obtained by using the mentioned string.  The problem with that is that
the 'struct cmd_list_element *' doesn't have any information on
whether the command issued by the user is a multi-line or inline one.

A multi-line command is a command that will necessarily be composed of
more than 1 line.  For example:

  (gdb) if 1
  >python
   >print ('hello')
   >end
  >end

As can be seen in the example above, the 'python' command actually
"opens" a new command line (represented by the change in the
indentation) that will then be used to enter Python code.  OTOH, an
inline command is a command that is "self-contained" in a single line,
for example:

  (gdb) if 1
  >python print ('hello')
  >end

This Python command is a one-liner, and therefore there is no other
Python code that can be entered for this same block.  There is also no
change in the indentation.

So, the fix is somewhat simple: we have to revert the change and use
the full command line string passed to process_next_line in order to
identify whether we're dealing with a multi-line or an inline command.
This commit does just that.  As can be seen, this regression also
affects other languages, like guile or the compile framework.  To make
things clearer, I decided to create a new helper function responsible
for identifying a non-inline command.

Testcase is attached.

gdb/ChangeLog:
2017-06-30  Sergio Durigan Junior  <sergiodj@redhat.com>

	PR cli/21688
	* cli/cli-script.c (command_name_equals_not_inline): New function.
	(process_next_line): Adjust 'if' clauses for "python", "compile"
	and "guile" to use command_name_equals_not_inline.

gdb/testsuite/ChangeLog:
2017-06-30  Sergio Durigan Junior  <sergiodj@redhat.com>

	PR cli/21688
	* gdb.python/py-cmd.exp (test_python_inline_or_multiline): New
	procedure.  Call it.
2017-06-30 07:14:29 -04:00
Pedro Alves eb17d4137d Expression completer should not match explicit location options
This commit fixes a mismatch between what "print" command completer
thinks the command understands, and what the command actually
understands.

The explicit location options are understood by commands that take
(linespecs and) explicit locations as argument.  I.e, breakpoint
commands, and "list".  For example:

 (gdb) b -source file.c -function my_func

So for those commands, it makes sense that the completer
completes:

 "b -sour[TAB]" -> "b -source "
 "b -functi[TAB]" -> "b -function "

etc.

However, completion for commands that take expressions (not
linespecs/locations) as arguments, such as the "print" command, also
completes the explicit location options, even though those switches
aren't really understood by these commands.  Instead, "-foo" is
understood as an expression applying unary minus on a symbol named
"foo" (think "print -1"):

 (gdb) p -func[TAB]
 (gdb) p -function [RET]
 No symbol "function" in current context.

The patch fixes this by having the expression_completer function
bypass the function that completes explicit locations.

New regression tests included.

gdb/ChangeLog:
2017-06-29  Pedro Alves  <palves@redhat.com>

	* completer.c (expression_completer): Call
	linespec_location_completer instead of location_completer.

gdb/testsuite/ChangeLog:
2017-06-29  Pedro Alves  <palves@redhat.com>

	* gdb.base/printcmds.exp: Add tests.
2017-06-29 15:53:48 +01:00
Pedro Alves 195bcdd518 Remove old stale expression_completer hack
The code in question was introduced by:

 https://sourceware.com/ml/gdb-patches/2008-06/msg00143.html

"The fix is to make sure that the entire expression is passed to
expression_completer, then duplicate some logic there in the case
where location_completer is called."

The logic that was duplicated was much later on removed by the
original explicit locations patch:

 commit 87f0e72047
 Author:     Keith Seitz <keiths@redhat.com>
 AuthorDate: Tue Aug 11 17:09:36 2015 -0700
 Commit:     Keith Seitz <keiths@redhat.com>
 CommitDate: Tue Aug 11 17:09:36 2015 -0700

     Explicit locations: add UI features for CLI

 @@ -688,16 +880,6 @@ complete_line_internal (const char *text,
		       rl_completer_word_break_characters =
			 gdb_completer_file_name_break_characters;
		     }
 -                 else if (c->completer == location_completer)
 -                   {
 -                     /* Commands which complete on locations want to
 -                        see the entire argument.  */
 -                     for (p = word;
 -                          p > tmp_command
 -                            && p[-1] != ' ' && p[-1] != '\t';
 -                          p--)
 -                       ;
 -                   }

However this case in expression_completer was left behind.

I couldn't come up with a test where this currently makes any
difference.

gdb/ChangeLog:
2017-06-29  Pedro Alves  <palves@redhat.com>

	* completer.c (expression_completer): Remove code that recomputes
	'text' from 'word'.
2017-06-29 15:52:37 +01:00
Yao Qi adc764e7d2 Use target_desc fields expedite_regs and xmltarget ifndef IN_PROCESS_AGENT
struct target_desc is used by both GDBserver and IPA, but fields
expedite_regs and xmltarget are only used in GDBserver, so this patch wraps
these two fields by ifndef IN_PROCESS_AGENT.  This patch also changes
regformats/regdat.sh to generate .c files in this way too.

gdb/gdbserver:

2017-06-29  Yao Qi  <yao.qi@linaro.org>

	* tdesc.h (struct target_desc) [IN_PROCESS_AGENT] <expedite_regs>:
	Remove.
	[IN_PROCESS_AGENT] <xmltarget>: Likewise.

gdb:

2017-06-29  Yao Qi  <yao.qi@linaro.org>

	* regformats/regdat.sh: Generate code with
	"ifndef IN_PROCESS_AGENT".
2017-06-29 12:41:50 +01:00
Pedro Alves 6e75794e9d gdb/command.h: Include common/scoped_restore.h
command.h depends on scoped_restore:

  extern scoped_restore_tmpl<int> prevent_dont_repeat (void);

But doesn't include the corresponding header
("common/scoped_restore.h").  We haven't noticed a problem because
utils.h includes scoped_restore.h, and defs.h includes utils.h.

However, a patch that makes "symtab.h" include "completer.h", exposed
the issue:
 https://sourceware.org/ml/gdb-patches/2017-06/msg00023.html.

Without this fix that would break building all .o files like this:

 In file included from src/gdb/completer.h:21:0,
                  from src/gdb/symtab.h:28,
                  from src/gdb/language.h:26,
                  from src/gdb/frame.h:72,
                  from src/gdb/gdbarch.h:39,
                  from src/gdb/defs.h:636,
                  from src/gdb/top.c:20:
 src/gdb/command.h:434:8: error: ‘scoped_restore_tmpl’ does not name a type
  extern scoped_restore_tmpl<int> prevent_dont_repeat (void);
         ^
 Makefile:1911: recipe for target 'top.o' failed

because defs.h includes gdbarch.h before it includes utils.h.

gdb/ChangeLog:
2017-06-28  Pedro Alves  <palves@redhat.com>

	* command.h: Include "common/scoped_restore.h".
2017-06-28 15:19:02 +01:00
Yao Qi bc491f2e76 Use obstack_grow_str
We already have macro obstack_grow_str, which is helpful to shorten the
code.

gdb:

2017-06-28  Yao Qi  <yao.qi@linaro.org>

	* mi/mi-cmd-break.c (mi_argv_to_format): Use obstack_grow_str
	instead of obstack_grow.
2017-06-28 15:00:27 +01:00
Doug Gilmore 41664b45ab Fix PR 21337: segfault when re-reading symbols.
Fix issue exposed by commit 3e29f34.

The basic issue is that section data referenced through an objfile
pointer can also be referenced via the program-space data pointer,
although via a separate mapping mechanism, which is set up by
update_section_map.  Thus once section data attached to an objfile
pointer is released, the section map associated with the program-space
data pointer must be marked dirty to ensure that update_section_map is
called to prevent stale data being referenced.  For the matter at hand
this marking is being done via a call to objfiles_changed.

Before commit 3e29f34 objfiles_changed could be called after all of
the objfile pointers were processed in reread_symbols since section
data references via the program-space data pointer would not occur in
the calls of read_symbols performed by reread_symbols.

With commit 3e29f34 MIPS target specific calls to find_pc_section were
added to the code for DWARF information processing, which is called
via read_symbols.  Thus in reread_symbols the call to objfiles_changed
needs to be called before calling read_symbols, otherwise stale
section data can be referenced.

Thanks to Luis Machado for providing text for the main comment
associated with the change.

gdb/
2017-06-28  Doug Gilmore  <Doug.Gilmore@imgtec.com>
    PR gdb/21337
    * symfile.c (reread_symbols): Call objfiles_changed just before
    read_symbols.

gdb/testsuite/
2017-06-28  Doug Gilmore  <Doug.Gilmore@imgtec.com>
    PR gdb/21337
    * gdb.base/reread-readsym.exp: New file.
    * gdb.base/reread-readsym.c: New file.
2017-06-28 02:54:22 +01:00
Pedro Alves 6da67eb10d completion_list_add_name wrapper functions
Replace macros with functions.

gdb/ChangeLog:
2017-06-27  Pedro Alves  <palves@redhat.com>

	* symtab.c (COMPLETION_LIST_ADD_SYMBOL)
	(MCOMPLETION_LIST_ADD_SYMBOL): Delete macros, replace with ...
	(completion_list_add_symbol, completion_list_add_msymbol):
	... these new functions.
	(add_symtab_completions)
	(default_make_symbol_completion_list_break_on_1): Adjust.
2017-06-27 16:32:57 +01:00
Pedro Alves 23732b1e32 objfile_per_bfd_storage non-POD
A following patch will want to add a std::vector to
objfile_per_bfd_storage.  That makes it non-trivially
constructible/destructible.  Since objfile_per_bfd_storage objects are
allocated on an obstack, we need to call their ctors/dtors manually.
This is what this patch does.  And then since we can now rely on
ctors/dtors being run, make objfile_per_bfd_storage::storage_obstack
be an auto_obstack.

gdb/ChangeLog:
2017-06-27  Pedro Alves  <palves@redhat.com>

	* objfiles.c (get_objfile_bfd_data): Call bfd_alloc instead of
	bfd_zalloc.  Call objfile_per_bfd_storage's ctor.
	(free_objfile_per_bfd_storage): Call objfile_per_bfd_storage's
	dtor.
	* objfiles.h (objfile_per_bfd_storage): Add ctor.  Make
	'storage_obstack' field an auto_obstack.  In-class initialize all
	non-bitfield fields.  Make minsyms_read bool.
	* symfile.c (read_symbols): Adjust.
2017-06-27 16:22:08 +01:00
Alan Hayward a4d1e79aaa Remove MAX_REGISTER_SIZE from remote-sim.c
gdb/
	* remote-sim.c (gdbsim_fetch_register): Use byte_vector.
	(gdbsim_store_register): Likewise.
2017-06-27 13:10:16 +01:00
Pedro Alves 8268c77870 Eliminate make_cleanup_obstack_free, introduce auto_obstack
This commit eliminates make_cleanup_obstack_free, replacing it with a
new auto_obstack type that inherits obstack to add cdtors.

These changes in the parsers may not be obvious:

 -  obstack_init (&name_obstack);
 -  make_cleanup_obstack_free (&name_obstack);
 +  name_obstack.clear ();

Here, the 'name_obstack' variable is a global.  The change means that
the obstack's contents from a previous parse will stay around until
the next parsing starts.  I.e., memory won't be reclaimed until then.
I don't think that's a problem, these objects don't really grow much
at all.

The other option I tried was to add a separate type that is like
auto_obstack but manages an external obstack, just for those cases.  I
like the current approach better as that other approach adds more
boilerplate and yet another type to learn.

gdb/ChangeLog:
2017-06-27  Pedro Alves  <palves@redhat.com>

	* c-exp.y (name_obstack): Now an auto_obstack.
	(yylex): Use auto_obstack::clear.
	(c_parse): Use auto_obstack::clear instead of reinitializing and
	freeing the obstack.
	* c-lang.c (evaluate_subexp_c): Use auto_obstack.
	* d-exp.y (name_obstack): Now an auto_obstack.
	(yylex): Use auto_obstack::clear.
	(d_parse): Use auto_obstack::clear instead of reinitializing and
	freeing the obstack.
	* dwarf2loc.c (fetch_const_value_from_synthetic_pointer): Use
	auto_obstack.
	* dwarf2read.c (create_addrmap_from_index)
	(dwarf2_build_psymtabs_hard)
	(update_enumeration_type_from_children): Likewise.
	* gdb_obstack.h (auto_obstack): New type.
	* go-exp.y (name_obstack): Now an auto_obstack.
	(build_packaged_name): Use auto_obstack::clear.
	(go_parse): Use auto_obstack::clear instead of reinitializing and
	freeing the obstack.
	* linux-tdep.c (linux_make_mappings_corefile_notes): Use
	auto_obstack.
	* printcmd.c (printf_wide_c_string, ui_printf): Use auto_obstack.
	* rust-exp.y (work_obstack): Now an auto_obstack.
	(rust_parse, rust_lex_tests): Use auto_obstack::clear instead of
	reinitializing and freeing the obstack.
	* utils.c (do_obstack_free, make_cleanup_obstack_free): Delete.
	(host_char_to_target): Use auto_obstack.
	* utils.h (make_cleanup_obstack_free): Delete declaration.
	* valprint.c (generic_emit_char, generic_printstr): Use
	auto_obstack.
2017-06-27 11:07:14 +01:00
Simon Marchi db665f427c darwin: Do not add a dummy thread
Starting a process on macOS/Darwin currently leads to this error:

/Users/simark/src/binutils-gdb/gdb/darwin-nat.c:383: internal-error: void darwin_check_new_threads(struct inferior *): Assertion `tp' failed.

with the corresponding partial backtrace (sorry, taken with lldb,
because well, gdb is broken :)):

    frame #9: 0x000000010004605a gdb`darwin_check_new_threads(inf=0x0000000100edf670) at darwin-nat.c:383
    frame #10: 0x0000000100045848 gdb`darwin_init_thread_list(inf=0x0000000100edf670) at darwin-nat.c:1710
    frame #11: 0x00000001000452f8 gdb`darwin_ptrace_him(pid=8375) at darwin-nat.c:1792
    frame #12: 0x0000000100041d95 gdb`fork_inferior(...) at fork-inferior.c:440
    frame #13: 0x0000000100043f82 gdb`darwin_create_inferior(...) at darwin-nat.c:1841
    frame #14: 0x000000010034ac32 gdb`run_command_1(args=0x0000000000000000, from_tty=1, tbreak_at_main=1) at infcmd.c:611

The issue was introduced by commit

  "Share fork_inferior et al with gdbserver"

because it changed the place where the dummy thread (pid, 0, 0) is added,
relative to the call to the init_trace_fun callback.  In this callback, darwin
checks for new threads in the program (there should be exactly one) in order to
update this dummy thread with the right tid.  Previously, things happened in
this order:

 - fork_inferior calls fork()
 - fork_inferior adds dummy thread
 - fork_inferior calls init_trace_fun callback, which updates the dummy
   thread info

Following the commit mentioned above, the new thread is added in the
darwin-nat code, after having called fork_inferior (in
darwin_create_inferior).  So gdb tries to do things in this order:

 - fork_inferior calls fork()
 - fork_inferior calls init_trace_fun callback, which tries to update
   the dummy thread info
 - darwin_create_inferior adds the dummy thread

The error happens while trying to update the dummy thread that has not
been added yet.

I don't think this dummy thread is necessary for darwin.  Previously, it
was fork_inferior that was adding this thread, for all targets, so
darwin had to deal with it.  Now that it's done by targets themselves,
we can just skip that on darwin.  darwin_check_new_threads called
indirectly by init_trace_fun/darwin_ptrace_him will simply notice the
new thread and add it with the right information.

My level of testing was: try to start a process and try to attach to a
process, and it seems to work somewhat like it did before.  I tried to
run the testsuite, but it leaves a huge amount of zombie processes that
launchd doesn't seem to reap, leading to exhaustion of system resources
(number of processes).

gdb/ChangeLog:

	* darwin-nat.c (darwin_check_new_threads): Don't handle dummy
	thread.
	(darwin_init_thread_list): Don't update dummy thread.
	(darwin_create_inferior, darwin_attach): Don't add a dummy thread.
2017-06-27 10:56:53 +02:00
Simon Marchi 873c08142c record-full: Remove unused function netorder16
clang shows this warning:

  /home/emaisin/src/binutils-gdb/gdb/record-full.c:2344:1: error: unused function 'netorder16' [-Werror,-Wunused-function]
  netorder16 (uint16_t input)
  ^

Remove this function, which, AFAIK, has never been used.  Note that GCC
doesn't warn about this, because the function is marked as inline.
According to gcc's man page, it should ideed not warn:

  -Wunused-function
    Warn whenever a static function is declared but not defined or a non-inline static function is unused.  This warning is enabled by -Wall.

So it's probably not a GCC bug that it doesn't find this unused function, but a
different definition of "unused".

gdb/ChangeLog:

	* record-full.c (netorder16): Remove.
2017-06-26 16:51:17 +02:00
Simon Marchi 8b5a7a6e8c vec: Silence -Wunused-function warnings on clang
clang has a too aggressive (or broken, depends on how you want to see
it) -Wunused-function warning, which is triggered by the functions
defined by DEF_VEC_* but not used in the current source file.  Normally,
it won't warn about unused static inline functions defined in header
files, because it's expected that a source file won't use all functions
defined in a header file it includes.  However, if the DEF_VEC_* macro
is used in a source file, it considers those functions as defined in the
source file, which leads it to think that we should remove those
functions.  It is therefore missing a check to see whether those
functions are resulting from macro expansion.  A bug already exists for
that:

  https://bugs.llvm.org//show_bug.cgi?id=22712

It's quite easy to silence this warning in a localized way, that is in
the DEF_VEC_* macros.

gdb/ChangeLog:

	* common/diagnostics.h: Define macros for GCC.
	(DIAGNOSTIC_IGNORE_UNUSED_FUNCTION): New macro.
	* common/vec.h: Include diagnostics.h.
	(DIAGNOSTIC_IGNORE_UNUSED_VEC_FUNCTION): New macro.
	(DEF_VEC_I, DEF_VEC_P, DEF_VEC_O): Ignore -Wunused-function
	warning.
2017-06-26 16:51:17 +02:00
Simon Marchi d1435379df ada-lex: Ignore warnings about register keyword
Some older versions of flex (such as the one shipped with macOS) generate
code that use the register keyword, which clang warns about.  This patch
makes the compiler ignore those warnings for the portion of the code
generated by flex.

gdb/ChangeLog:

	* common/diagnostics.h (DIAGNOSTIC_IGNORE_DEPRECATED_REGISTER):
	New macro.
	* ada-lex.l: Ignore deprecated register warnings.
2017-06-26 16:51:17 +02:00
Simon Marchi cc75e0fdae main: Don't add int to string
clang shows this warning:

  /home/emaisin/src/binutils-gdb/gdb/main.c:227:56: error: adding 'int' to a string does not append to the string [-Werror,-Wstring-plus-int]
                char *tmp_sys_gdbinit = xstrdup (SYSTEM_GDBINIT + datadir_len);
                                                 ~~~~~~~~~~~~~~~^~~~~~~~~~~~~
  /home/emaisin/src/binutils-gdb/gdb/main.c:227:56: note: use array indexing to silence this warning
                char *tmp_sys_gdbinit = xstrdup (SYSTEM_GDBINIT + datadir_len);
                                                                ^
                                                 &              [            ]

It's quite easy to get rid of it by using &foo[len] instead of foo + len.
I think this warning is relevant to keep enabled, because it can be an
easy mistake to do.

This warning is already discussed here in GCC bugzilla:

  https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00729.html

and a patch series for it was submitted very recently.

gdb/ChangeLog:

	* main.c (get_init_files): Replace "SYSTEM_GDBINIT +
	datadir_len" with "&SYSTEM_GDBINIT[datadir_len]".
2017-06-25 12:57:13 +02:00
Simon Marchi 07809eafc9 dtrace-probe: Put semicolon after while on its own line
clang shows this warning.

  /home/emaisin/src/binutils-gdb/gdb/dtrace-probe.c:424:52: error: while loop has empty body [-Werror,-Wempty-body]
            while (*p++ != '\0' && p - strtab < strtab_size);
                                                            ^
  /home/emaisin/src/binutils-gdb/gdb/dtrace-probe.c:424:52: note: put the semicolon on a separate line to silence this warning

Putting the semicolon on its own line is not a big sacrifice to get rid of this
warning.  I think it's also useful to keep this, because it can catch errors
like this:

  while (something);
    {
      ...
    }

although gcc would warn about it in a different way (misleading indentation).

This warning is already discussed here in the GCC bugzilla:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62184

gdb/ChangeLog:

	* dtrace-probe.c (dtrace_process_dof_probe): Put semi-colon on
	its own line.
2017-06-25 12:49:19 +02:00
Simon Marchi f076f0349c x86-dregs: Print debug registers one per line
This get around this warning given by clang...

  /home/emaisin/src/binutils-gdb/gdb/nat/x86-dregs.c:209:7: error: variable 'i' is incremented both in the loop header and in the loop body [-Werror,-Wfor-loop-analysis]
        i++;
        ^
  /home/emaisin/src/binutils-gdb/gdb/nat/x86-dregs.c:199:32: note: incremented here
    ALL_DEBUG_ADDRESS_REGISTERS (i)
                               ^

... I decided in the end to simply print the debug registers one per
line.  I don't think it particularly helps readability to have them two
per line anyway.

gdb/ChangeLog:

	* nat/x86-dregs.c (x86_show_dr): Print registers one per line.
2017-06-25 12:40:10 +02:00
Alan Hayward 0dd5cbc563 Add XTENSA_MAX_REGISTER_SIZE
gdb/
	* xtensa-tdep.c (XTENSA_MAX_REGISTER_SIZE): Add.
	(xtensa_register_write_masked): Use XTENSA_MAX_REGISTER_SIZE.
	(xtensa_register_read_masked): Likewise.
2017-06-23 10:21:39 +01:00
Sergio Durigan Junior d4c6ce5b01 Update comment on gdb_environ::unset
gdb_environ::unset iterates using '.end () - 1' now, instead of '.cend
() - 1'.  This obvious patch updates the comment.

gdb/ChangeLog:
2017-06-22  Sergio Durigan Junior  <sergiodj@redhat.com>

	* common/environ.c (gdb_environ::unset): Update comment.
2017-06-22 14:50:24 -04:00
Alan Hayward 16892a0323 Fix cached_frame allocation in py-unwind
gdb/
	* python/py-unwind.c (pyuw_sniffer): Allocate space for
	registers.
2017-06-22 16:30:15 +01:00
Alan Hayward d7dcbefc72 Remove an instance of MAX_REGISTER_SIZE from record-full.c
gdb/
	* record-full.c (record_full_exec_insn): Use byte_vector.
2017-06-22 15:33:18 +01:00
Yao Qi b30ff123fb Regenerate two regformats/i386/.dat files
The self tests which compare pre-generated target descriptions and
dynamically created target descriptions fail, and it turns out that two
pre-generated target descriptions are wrong, so regenerate them.

gdb:

2017-06-22  Yao Qi  <yao.qi@linaro.org>

	* regformats/i386/amd64-avx-mpx-avx512-pku-linux.dat: Regenerated.
	* regformats/i386/amd64-avx-mpx-avx512-pku.dat: Regenerated.
2017-06-22 14:13:57 +01:00
Alan Hayward 4fa847d78e Remove MAX_REGISTER_SIZE from py-unwind.c
gdb/
	* remote.c (cached_reg): Move from here...
	* regcache.h (cached_reg): ...to here.
	* python/py-unwind.c (struct reg_info): Remove.
	(cached_frame_info): Use cached_reg_t.
	(pyuw_prev_register): Likewise.
	(pyuw_sniffer): Use cached_reg_t and allocate registers.
	(pyuw_dealloc_cache): Free all registers.
2017-06-22 14:10:34 +01:00
Pedro Alves f4906a9a74 environ-selftests: Ignore -Wself-move warning
clang gives this warning:

 ..../gdb/unittests/environ-selftests.c:139:7: error: explicitly moving variable of type 'gdb_environ' to itself [-Werror,-Wself-move]
   env = std::move (env);
   ~~~ ^            ~~~

Ignoring the warning locally is the right thing to do, since it warns
about behavior we want to unit test, while an explicit self-move in
real code would likely be a mistake that we'd want to catch.

To avoid cluttering the code with preprocessor conditionals, this
commit adds the file common/diagnostics.h, in which we can put macros
used to control compiler diagnostics.

GCC enhancement request here:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81159

gdb/ChangeLog:
2017-06-22  Pedro Alves  <palves@redhat.com>
	    Simon Marchi  <simon.marchi@ericsson.com>

	* unittests/environ-selftests.c (run_tests): Ignore -Wself-move
	warning.
	* common/diagnostics.h: New file.
2017-06-22 11:18:49 +01:00
Pedro Alves d269dfc64f Add STRINGIFY to gdb/common/preprocessor.h
We have several copies of this common idiom under gdb/ currently.
This commit moves them / factors them out to gdb/common/preprocessor.h.

gdb/ChangeLog:
2017-06-22  Pedro Alves  <palves@redhat.com>

	* common/agent.h: Include "common/preprocessor.h".
	(STRINGIZE_1, STRINGIZE): Delete.
	(IPA_SYM): Use STRINGIFY instead.
	* common/preprocessor.h (STRINGIFY_1, STRINGIFY): New.
	* compile/compile-c-support.c: Include "common/preprocessor.h".
	(STR, STRINGIFY): Delete.
	* ia64-libunwind-tdep.c: Include "common/preprocessor.h".
	(STRINGIFY2, STRINGIFY): Delete.
2017-06-22 10:59:42 +01:00
Pedro Alves b45a120833 common/agent.h: Add missing include guards
gdb/ChangeLog:
2017-06-22  Pedro Alves  <palves@redhat.com>

	* common/agent.h: Add include guards.
2017-06-22 10:57:13 +01:00
Kevin Buettner 75312ae3ab Use noncapturing subpattern/parens in gdb_test implementation
This is the portion of gdb_test which performs the match against
the RE (regular expression) passed to it:

    return [gdb_test_multiple $command $message {
        -re "\[\r\n\]*($pattern)\[\r\n\]+$gdb_prompt $" {
            if ![string match "" $message] then {
                pass "$message"
            }
        }

In a test that I've been working on recently, I wanted to use
a backreference - that's the \1 in the the RE below:

gdb_test "info threads"  \
	{.*[\r\n]+\* +([0-9]+) +Thread[^\r\n]* do_something \(n=\1\) at.*}

Put into English, I wanted to make sure that the value of n passed to
do_something() is the same as the thread number shown in the "info
threads" Id column.  (I've structured the test case so that this
*should* be the case.)

It didn't work though.  It turned out that ($pattern) in the RE
noted above is capturing the attempted backreference.  So, in this
case, the backreference does not refer to ([0-9]+) as intended, but
instead refers to ($pattern).  This is wrong because it's not what I
intended, but is also wrong because, if allowed, it could only match a
string of infinite length.

This problem can be fixed by using parens for a "noncapturing
subpattern".  The way that this is done, syntactically, is to use
(?:$pattern) instead of ($pattern).

My research shows that this feature has been present since tcl8.1 which
was released in 1999.

The current tcl version is 8.6 - at least that's what I have on my
machine.  It appears to me that mingw uses some subversion of tcl8.4
which will also have this feature (since 8.4 > 8.1).

So it seems to me that any platform upon which we might wish to test
GDB will have a version of tcl which has this feature.  That being the
case, my hope is that there won't be any objections to its use.

When I looked at the implementation of gdb_test, I wondered whether
the parens were needed at all.  I've concluded that they are.  In the
event that $pattern is an RE which uses alternation at the top level,
e.g. a|b, we need to make $pattern a subpattern (via parens) to limit
the extend of the alternation.  I.e, we don't want the alternation to
extend to the other portions of the RE which gdb_test uses to match
potential blank lines at the beginning of the pattern or the gdb
prompt at the end.

gdb/testsuite/ChangeLog:

	* gdb.exp (gdb_test): Using noncapturing parens for the $pattern
	subpattern.
2017-06-21 14:44:04 -07:00
Simon Marchi e4da2c6166 Change to_xfer_partial doc to use addressable memory units
The commit

  d309493  target: consider addressable unit size when reading/writing memory

introduced the possibility of reading memory of targets with
non-8-bit-bytes (e.g. memories that store 16 bits at each address).
The documentation of target_read and target_write was updated
accordingly, but to_xfer_partial, which is very related, wasn't updated.
This commit fixes that.

gdb/ChangeLog:

	* target.h (struct target_ops) <to_xfer_partial>: Update doc to
	talk about addressable units instead of bytes.
2017-06-21 13:16:47 +02:00
Sergio Durigan Junior eb83230b4d Fix PR gdb/21606: SYMBOL_FUNCTIONS_DOMAIN misspelled in documentation
Both Python and Guile documentations misspelled
SYMBOL_FUNCTIONS_DOMAIN, writing SYMBOL_FUNCTION_DOMAIN instead.  This
obvious commit fixes it.

gdb/doc/ChangeLog:
2017-06-20  Sergio Durigan Junior  <sergiodj@redhat.com>

	PR gdb/21606
	* python.texi (Python representation of Symbols.): Replace
	SYMBOL_FUNCTION_DOMAIN by SYMBOL_FUNCTIONS_DOMAIN, fixing typo.
	* guile.texi (Guile representation of Symbols.): Likewise.
2017-06-20 21:31:59 -04:00
Simon Marchi a206891ad1 gdbserver/Makefile.in: Sort IPA_OBJS
gdb/gdbserver/ChangeLog:

	* Makefile.in (IPA_OBJS): Sort and format one item per line.
2017-06-20 16:59:03 +02:00
Sergio Durigan Junior 96160d6051 Use '::iterator' instead of '::const_iterator' on environ.c (and fix breakage on early versions of libstdc++)
Even though C++11 supports modifying containers using a const_iterator
(e.g., calling the 'erase' method of a std::vector), early versions of
libstdc++ did not implement that.  Some of our buildslaves are using
these versions (e.g., the AArch64 buildslave uses gcc 4.8.8), and my
previous commit causes a breakage on them.  The solution is simple:
just use a normal iterator, without const.

gdb/ChangeLog:
2017-06-20  Sergio Durigan Junior  <sergiodj@redhat.com>

	* common/environ.c (gdb_environ::unset): Use '::iterator' instead
	of '::const_iterator'.
2017-06-20 09:33:53 -04:00
Sergio Durigan Junior 9a6c7d9c02 C++ify gdb/common/environ.c
As part of the preparation necessary for my upcoming task, I'd like to
propose that we turn gdb_environ into a class.  The approach taken
here is simple: the class gdb_environ contains everything that is
needed to manipulate the environment variables.  These variables are
stored in an std::vector<char *>, which can be converted to a 'char
**' and passed as argument to functions that need it.

The usage has not changed much.  As per Pedro's suggestion, this class
uses a static factory method initialization.  This means that when an
instance is created, it is initially empty.  When needed, it has to be
initialized using the static method 'from_host_environ'.

As mentioned before, this is a preparation for an upcoming work that I
will be posting in the next few weeks or so.  For that work, I'll
probably create another data structure that will contain all the
environment variables that were set by the user using the 'set
environment' command, because I'll need access to them.  This will be
much easier with the class-ification of gdb_environ.

As noted, this has been regression-tested with the new version of
environ.exp and no regressions were found.

gdb/ChangeLog:
2017-06-20  Sergio Durigan Junior  <sergiodj@redhat.com>

	* Makefile.in (SUBDIR_UNITTESTS_SRCS): Add
	'unittests/environ-selftests.c'.
	(SUBDIR_UNITTESTS_OBS): Add 'environ-selftests.o'.
	* charset.c (find_charset_names): Declare object 'iconv_env'.
	Update code to use 'iconv_env' object.  Remove call to
	'free_environ'.
	* common/environ.c: Include <utility>.
	(make_environ): Delete function.
	(free_environ): Delete function.
	(gdb_environ::clear): New function.
	(gdb_environ::operator=): New function.
	(gdb_environ::get): Likewise.
	(environ_vector): Delete function.
	(set_in_environ): Delete function.
	(gdb_environ::set): New function.
	(unset_in_environ): Delete function.
	(gdb_environ::unset): New function.
	(gdb_environ::envp): Likewise.
	* common/environ.h: Include <vector>.
	(struct gdb_environ): Delete; transform into...
	(class gdb_environ): ... this class.
	(free_environ): Delete prototype.
	(init_environ, get_in_environ, set_in_environ, unset_in_environ,
	environ_vector): Likewise.
	* infcmd.c (run_command_1): Update code to call
	'envp' from 'gdb_environ' class.
	(environment_info): Update code to call methods from 'gdb_environ'
	class.
	(unset_environment_command): Likewise.
	(path_info): Likewise.
	(path_command): Likewise.
	* inferior.c (inferior::~inferior): Delete call to 'free_environ'.
	(inferior::inferior): Initialize 'environment' using the host's
	information.
	* inferior.h: Remove forward declaration of 'struct gdb_environ'.
	Include "environ.h".
	(class inferior) <environment>: Change type from 'struct
	gdb_environ' to 'gdb_environ'.
	* mi/mi-cmd-env.c (mi_cmd_env_path): Update code to call
	methods from 'gdb_environ' class.
	* solib.c (solib_find_1): Likewise
	* unittests/environ-selftests.c: New file.

gdb/gdbserver/ChangeLog:
2017-06-20  Sergio Durigan Junior  <sergiodj@redhat.com>

	* linux-low.c (linux_create_inferior): Adjust code to access the
	environment information via 'gdb_environ' class.
	* lynx-low.c (lynx_create_inferior): Likewise.
	* server.c (our_environ): Make it an instance of 'gdb_environ'.
	(get_environ): Return a pointer to 'our_environ'.
	(captured_main): Initialize 'our_environ'.
	* server.h (get_environ): Adjust prototype.
	* spu-low.c (spu_create_inferior): Adjust code to access the
	environment information via 'gdb_environ' class.
2017-06-20 08:59:27 -04:00
Yao Qi 75c554cf9c Adjust the order of 32bit-linux.xml and 32bit-sse.xml in i386/i386-linux.xml
Exchange the order of 32bit-linux.xml and 32bit-sse.xml in
i386/i386-linux.xml, to align with other i386 linux .xml files.

gdb:

2017-06-20  Yao Qi  <yao.qi@linaro.org>

	* features/i386/i386-linux.xml: Exchange the order of including
	32bit-linux.xml and 32bit-sse.xml.
	* features/i386/i386-linux.c: Regenerated.
2017-06-20 12:08:33 +01:00
Yao Qi 72ddacb77e Class-fy tdesc_reg tdesc_type and tdesc_feature
This patch class-fies them, adding ctor, dtor, and deleting
copy ctor and assignment operator.

gdb:

2017-06-20  Yao Qi  <yao.qi@linaro.org>

	* target-descriptions.c (tdesc_reg): Add ctor, dtor.
	Delete copy ctor and assignment operator.
	(tdesc_type): Likewise.
	(tdesc_feature): Likewise.
	(tdesc_free_reg): Remove.
	(tdesc_create_reg): Use new.
	(tdesc_free_type): Remove.
	(tdesc_create_vector): Use new.
	(tdesc_create_union): Likewise.
	(tdesc_create_flags): Likewise.
	(tdesc_create_enum): Likewise.
	(tdesc_free_feature): Delete.
	(free_target_description): Use delete.
2017-06-20 11:29:17 +01:00
John Baldwin 325c9fd4aa Don't throw an error in 'info registers' for unavailable MIPS registers.
'info registers' for MIPS throws an error and when it first encounters
an unavailable register.  This does not match other architectures
which annotate unavailable registers and continue to print out the
values of subsequent registers.  Replace the error by displaying an
aligned "<unavailable>".  This string is truncated to "<unavl>" when
displaying a 32-bit register.

gdb/ChangeLog:

	* mips-tdep.c (print_gp_register_row): Don't error for unavailable
	registers.
2017-06-19 14:40:22 -07:00
Peter Bergner 66953522c9 Update GDB test case for new lnia extended mnemonic.
When I added the new lnia extended mnemonic for addpcis, I updated the
assembler/disassembler test cases, but overlooked the GDB test cases.
This patch fixes that oversight and associated test case failure.

	* gdb.arch/powerpc-power9.exp: Update test case for new lnia
	extended mnemonic.
	* gdb.arch/powerpc-power9.s: Likewise.
2017-06-19 13:04:13 -05:00
Pedro Alves 16b7a71998 .gdb_index writer: close the file before unlinking it
We should close the file before unlinking because on MS-Windows one
cannot delete a file that is still open.

I considered making 'gdb::unlinker::unlinker(const char *)'
'noexcept(true)' and then adding
  static_assert (noexcept (gdb::unlinker (filename.c_str ())), "");

but that doesn't really work because gdb::unlinker has a gdb_assert,
which can throw a QUIT if/when the assertion fails.  'noexcept(true)'
would cause GDB to abruptly terminate if/when the assertion fails.

gdb/ChangeLog:
2017-06-19  Pedro Alves  <palves@redhat.com>

	* dwarf2read.c (write_psymtabs_to_index): Construct file_closer
	after gdb::unlinker.
2017-06-19 12:46:47 +01:00