Kevin Buettner [Sat, 25 Aug 2018 05:22:46 +0000 (22:22 -0700)]
Introduce find_function_entry_range_from_pc and use it in infrun.c
An earlier version of this patch used the returned block in conjunction
with BLOCK_ENTRY_PC to set stop_func_start in fill_in_stop_func() in
infrun.c. While I think this was the correct thing to do, changes
to find_inferior_partial_function could potentially end up with
stop_func_end < stop_func_start, which is definitely wrong. For
this case, we want to set both stop_func_start and stop_func_end
to the start and end of the range containing the function's entry
pc.
I think that this functionality will be useful in many other places
too - it probably ought to be used in all of the various prologue
analyzers in GDB.
The change to infrun.c was simple: the call to
find_pc_partial_function was replaced with a call to
find_function_entry_range_from_pc. The difference between these two
functions is that find_pc_partial_entry_function will (potentially)
return the start and end address corresponding to the range in which
PC is found, but find_function_entry_range_from_pc will (again,
potentially) return the start and end address of the range containing
the entry pc. find_pc_partial_function has the property that
*ADDRESS <= PC < *ENDADDR. This condition does not necessarily hold
for the outputs of find_function_entry_range_from_pc.
It should be noted that for functions which contain only a single
range, the outputs of find_pc_partial_function and
find_function_entry_range_from_pc are identical.
I think it might happen that find_function_entry_range_from_pc will come
to be used in place of many of the calls to find_pc_partial_function
within GDB. Care must be taken in making this change, however, since
some of this code depends on the *ADDRESS <= PC < *ENDADDR property.
Finally, a note regarding the name: I had initially chosen a different
name with a find_pc_partial_ prefix, but Simon suggested the current
name citing the goal of eventually making naming consistent using
the form find_X_from_Y. In this case X is "function_entry_range" and
Y is "pc". Both the name and rationale made sense to me, so that's
how it came to be.
gdb/ChangeLog:
* infrun.c (fill_in_stop_func): Use find_function_entry_range_from_pc
in place of find_pc_partial_function.
* blockframe.c (find_function_entry_range_from_pc): New function.
* symtab.h (find_function_entry_range_from_pc): Declare and document.
Kevin Buettner [Sat, 25 Aug 2018 05:22:46 +0000 (22:22 -0700)]
Use BLOCK_ENTRY_PC in place of most uses of BLOCK_START
This change/patch substitues BLOCK_ENTRY_PC for BLOCK_START in
places where BLOCK_START is used to obtain the address at which
execution should enter the block. Since blocks can now contain
non-contiguous ranges, the BLOCK_START - which is still be the
very lowest address in the block - might not be the same as
BLOCK_ENTRY_PC.
There is a change to infrun.c which is less obvious and less mechanical.
I'm posting it as a separate patch.
gdb/ChangeLog:
* ax-gdb.c (gen_var_ref): Use BLOCK_ENTRY_PC in place of
BLOCK_START.
* blockframe.c (get_pc_function_start): Likewise.
* compile/compile-c-symbols.c (convert_one_symbol): Likewise.
(gcc_symbol_address): Likewise.
* compile/compile-object-run.c (compile_object_run): Likewise.
* compile/compile.c (get_expr_block_and_pc): Likewise.
* dwarf2loc.c (dwarf2_find_location_expression): Likewise.
(func_addr_to_tail_call_list): Likewise.
* findvar.c (default_read_var_value): Likewise.
* inline-frame.c (inline_frame_this_id): Likewise.
(skip-inline_frames): Likewise.
* infcmd.c (until_next_command): Likewise.
* linespec.c (convert_linespec_to_sals): Likewise.
* parse.c (parse_exp_in_context_1): Likewise.
* printcmd.c (build_address_symbolic): likewise.
(info_address_command): Likewise.
symtab.c (find_function_start_sal): Likewise.
(skip_prologue_sal): Likewise.
(find_function_alias_target): Likewise.
(find_gnu_ifunc): Likewise.
* stack.c (find_frame_funname): Likewise.
* symtab.c (fixup_symbol_section): Likewise.
(find_function_start_sal): Likewise.
(skip_prologue_sal): Likewsie.
(find_function_alias_target): Likewise.
(find_gnu_ifunc): Likewise.
* tracepoint.c (info_scope_command): Likewise.
* value.c (value_fn_field): Likewise.
Kevin Buettner [Sat, 25 Aug 2018 05:22:46 +0000 (22:22 -0700)]
Disassemble blocks with non-contiguous ranges
This patch adds support for disassembly of blocks with non-contiguous
ranges. These blocks are printed as follows:
(gdb) disassemble foo
Dump of assembler code for function foo:
Address range 0x401136 to 0x401151:
0x0000000000401136 <+0>: push %rbp
0x0000000000401137 <+1>: mov %rsp,%rbp
0x000000000040113a <+4>: callq 0x401134 <bar>
0x000000000040113f <+9>: mov 0x2eef(%rip),%eax # 0x404034 <e>
0x0000000000401145 <+15>: test %eax,%eax
0x0000000000401147 <+17>: je 0x40114e <foo+24>
0x0000000000401149 <+19>: callq 0x401128 <foo+
4294967282>
0x000000000040114e <+24>: nop
0x000000000040114f <+25>: pop %rbp
0x0000000000401150 <+26>: retq
Address range 0x401128 to 0x401134:
0x0000000000401128 <+-14>: push %rbp
0x0000000000401129 <+-13>: mov %rsp,%rbp
0x000000000040112c <+-10>: callq 0x401126 <baz>
0x0000000000401131 <+-5>: nop
0x0000000000401132 <+-4>: pop %rbp
0x0000000000401133 <+-3>: retq
End of assembler dump.
This is an actual dump from the test case that I constructed for
this work. The ranges are printed in the order encountered in the
debug info. For the above example, note that the second range occupies
lower addresses than the first range.
Functions with contiguous ranges are still printed as follows:
(gdb) disassemble main
Dump of assembler code for function main:
0x0000000000401151 <+0>: push %rbp
0x0000000000401152 <+1>: mov %rsp,%rbp
0x0000000000401155 <+4>: callq 0x401136 <foo>
0x000000000040115a <+9>: mov $0x0,%eax
0x000000000040115f <+14>: pop %rbp
0x0000000000401160 <+15>: retq
End of assembler dump.
gdb/ChangeLog:
* cli/cli-cmds.c (block.h): Include.
(print_disassembly): Handle printing of non-contiguous blocks.
(disassemble_current_function): Likewise.
(disassemble_command): Likewise.
Kevin Buettner [Sat, 25 Aug 2018 05:22:46 +0000 (22:22 -0700)]
Add support for non-contiguous blocks to find_pc_partial_function
This change adds an optional output parameter BLOCK to
find_pc_partial_function. If BLOCK is non-null, then *BLOCK will be
set to the address of the block corresponding to the function symbol
if such a symbol was found during lookup. Otherwise it's set to the
NULL value. Callers may wish to use the block information to
determine whether the block contains any non-contiguous ranges. The
caller may also iterate over or examine those ranges.
When I first started looking at the broken stepping behavior associated
with functions w/ non-contiguous ranges, I found that I could "fix"
the problem by disabling the find_pc_partial_function cache. It would
sometimes happen that the PC passed in would be between the low and
high cache values, but would be in some other function that happens to
be placed in between the ranges for the cached function. This caused
incorrect values to be returned.
So dealing with this cache turns out to be very important for fixing
this problem. I explored three different ways of dealing with the
cache.
My first approach was to clear the cache when a block was encountered
with more than one range. This would cause the non-cache pathway to
be executed on the next call to find_pc_partial_function.
Another approach, which I suspect is slightly faster, checks to see
whether the PC is within one of the ranges associated with the cached
block. If so, then the cached values can be used. It falls back to
the original behavior if there is no cached block.
The current approach, suggested by Simon Marchi, is to restrict the
low/high pc values recorded for the cache to the beginning and end of
the range containing the PC value under consideration. This allows us
to retain the simple (and fast) test for determining whether the
memoized (cached) values apply to the PC passed to
find_pc_partial_function.
Another choice that had to be made regards setting *ADDRESS and
*ENDADDR. There are three possibilities which might make sense:
1) *ADDRESS and *ENDADDR represent the lowest and highest address
of the function.
2) *ADDRESS and *ENDADDR are set to the start and end address of
the range containing the entry pc.
3) *ADDRESS and *ENDADDR are set to the start and end address of
the range in which PC is found.
An earlier version of this patch implemented option #1. I found out
that it's not very useful though and, in fact, returns results that
are incorrect when used in the context of determining the start and
end of the function for doing prologue analysis. While debugging a
function in which the entry pc was in the second range (of a function
containing two non-contiguous ranges), I noticed that
amd64_skip_prologue called find_pc_partial_function - the returned
start address was set to the beginning of the first range. This is
incorrect for this function. What was also interesting was that this
first invocation of find_pc_partial_function correctly set the cache
for the PC on which it had been invoked, but a slightly later call
from skip_prologue_using_sal could not use this cached value because
it was now being used to lookup the very lowest address of the
function - which is in a range not containing the entry pc.
Option #2 is attractive as it would provide a desirable result
when used in the context of prologue analysis. However, many callers,
including some which do prologue analysis want the condition
*ADDRESS <= PC < *ENDADDR to hold. This will not be the case when
find_pc_partial_function is called on a PC that's in a non-entry-pc
range. A later patch to this series adds
find_function_entry_range_from_pc as a wrapper of
find_pc_partial_function.
Option #3 causes the *ADDRESS <= PC < *ENDADDR property to hold. If
find_pc_partial_function is called with a PC that's within entry pc's
range, then it will correctly return the limits of that range. So, if
the result of a minsym search is passed to find_pc_partial_function
to find the limits, then correct results will be achieved. Returned
limits (for prologue analysis) won't be correct when PC is within some
other (non-entry-pc) range. I don't yet know how big of a problem
this might be; I'm guessing that it won't be a serious problem - if a
compiler generates functions which have non-contiguous ranges, then it
also probably generates DWARF2 CFI which makes a lot of the old
prologue analysis moot.
I've implemented option #3 for this version of the patch. I don't see
any regressions for x86-64. Moreover, I don't expect to see
regressions for other targets either simply because
find_pc_partial_function behaves the same as it did before for the
contiguous address range case. That said, there may be some
adjustments needed if GDB encounters a function requiring prologue
analysis which occupies non-contiguous ranges.
gdb/ChangeLog:
* symtab.h (find_pc_partial_function): Add new parameter `block'.
* blockframe.c (cache_pc_function_block): New static global.
(clear_pc_function_cache): Clear cache_pc_function_block.
(find_pc_partial_function): Move comment to symtab.h. Add
support for non-contiguous blocks.
Kevin Buettner [Sat, 25 Aug 2018 05:22:45 +0000 (22:22 -0700)]
Record explicit block ranges from dwarf2read.c
This change sets BLOCK_RANGES for the block under consideration by
calling make_blockranges(). This action is performed in
dwarf2_record_block_ranges().
It should be noted that dwarf2_record_block_ranges() already does some
recording of the range via a call to record_block_range(). The ranges
recorded in that fashion end up in the address map associated with the
blockvector for the compilation unit's symtab. Given an address, the
addrmap provides a fast way of finding the block containing that
address. The address map does not, however, provide a convenient way
of determining which address ranges make up a particular block.
While reading a set of ranges, a vector of pairs is used to collect
the starting and ending addresses for each range in the block. Once
all of the ranges for a block have been collected, make_blockranges()
is called to fill in BLOCK_RANGES for the block.
The ranges are stored for the block in the order that they're read
from the debug info. For DWARF, the starting address of the first
range of the block will be the entry pc in cases where DW_AT_entry_pc
is not present. (Well, that would ideally be the case. At the moment
DW_AT_entry_pc is not being handled.)
gdb/ChangeLog:
* dwarf2read.c (dwarf2_record_block_ranges): Fill in BLOCK_RANGES
for block.
Kevin Buettner [Sat, 25 Aug 2018 05:22:45 +0000 (22:22 -0700)]
Add block range data structure for blocks with non-contiguous address ranges
This patch does the following:
- Introduces a block range data structure which is accessed via
a new field in struct block.
- Defines several macros for accessing block ranges.
- Defines a new function, make_blockrange, which is responsible for
creating the new data structure.
It should be noted that some support for non-contiguous ranges already
existed in GDB in the form of blockvector addrmaps. This support
allowed GDB to quickly find a block containing a particular address
even when the block consists of non-contiguous addresses. See
find_block_in_blockvector() in block.c, dwarf2_record_block_ranges()
in dwarf2read.c, and record_block_range() in buildsym.c.
Addrmaps do not provide a convenient way to examine address ranges
associated with a particular block. This data structure (and its
interface) is set up for quickly finding the value (which in this case
is a block) associated with a particular address. The interface
does not include a method for doing a reverse mapping from blocks to
addresses. A linear time mapping might be attempted via use of the
addrmap's foreach method, but this is not as straightforward as it
might first appear due to the fact that blocks corresponding to inline
function instances and lexical blocks w/ variables end up getting
interspersed in in the set of transitions.
Note: If this approach is deemed to be too expensive in terms of
space, an alternate approach might be to attempt the linear time
mapping noted above. find_pc_partial_function() needs to be able to
quickly know whether there are discontiguous ranges, so a flag for
this property would have to be added to struct block. Also integral
to this set of changes is the concept of an "entry pc" which might be
different from the block's start address. An entry_pc field would
also need to be added to struct block. This does not result in any
space savings in struct block though since the space for the flag and
entry_pc use more space than the blockranges struct pointer that I've
added. There would, however, be some space savings due to the fact
that the new data structures that I've added for this patch would not
need to be allocated. (I happen to like the approach I've come up
with, but I wanted to mention another possibility just in case someone
does not.)
gdb/ChangeLog:
* block.h (blockrange, blockranges): New struct declarations.
(struct block): Add new field named `ranges'.
(BLOCK_RANGES, BLOCK_NRANGES, BLOCK_RANGE, BLOCK_CONTIGUOUS_P)
(BLOCK_RANGE_START, BLOCK_RANGE_END, BLOCK_ENTRY_PC): New
macros for accessing ranges in struct block.
(make_blockranges): New declaration.
block.c (make_blockranges): New function.
GDB Administrator [Sat, 25 Aug 2018 00:01:41 +0000 (00:01 +0000)]
Automatic date update in version.in
Pedro Alves [Fri, 24 Aug 2018 21:24:49 +0000 (22:24 +0100)]
Fix 8.2 regression in gdb.python/py-evthreads.exp w/ gdbserver (PR gdb/23379)
This commit fixes a 8.1->8.2 regression exposed by
gdb.python/py-evthreads.exp when testing with
--target_board=native-gdbserver.
gdb.log shows:
src/gdb/thread.c:93: internal-error: thread_info* inferior_thread(): Assertion `tp' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) FAIL: gdb.python/py-evthreads.exp: run to breakpoint 1 (GDB internal error)
A backtrace shows (frames #2 and #10 highlighted) that the assertion
fails when GDB is setting up the connection to the remote target, in
non-stop mode:
#0 0x0000000000622ff0 in internal_error(char const*, int, char const*, ...) (file=0xc1ad98 "src/gdb/thread.c", line=93, fmt=0xc1ad20 "%s: Assertion `%s' failed.") at src/gdb/common/errors.c:54
#1 0x000000000089567e in inferior_thread() () at src/gdb/thread.c:93
= #2 0x00000000004da91d in get_event_thread() () at src/gdb/python/py-threadevent.c:38
#3 0x00000000004da9b7 in create_thread_event_object(_typeobject*, _object*) (py_type=0x11574c0 <continue_event_object_type>, thread=0x0)
at src/gdb/python/py-threadevent.c:60
#4 0x00000000004bf6fe in create_continue_event_object() () at src/gdb/python/py-continueevent.c:27
#5 0x00000000004bf738 in emit_continue_event(ptid_t) (ptid=...) at src/gdb/python/py-continueevent.c:40
#6 0x00000000004c7d47 in python_on_resume(ptid_t) (ptid=...) at src/gdb/python/py-inferior.c:108
#7 0x0000000000485bfb in std::_Function_handler<void (ptid_t), void (*)(ptid_t)>::_M_invoke(std::_Any_data const&, ptid_t&&) (__functor=..., __args#0=...) at /usr/include/c++/7/bits/std_function.h:316
#8 0x000000000089b416 in std::function<void (ptid_t)>::operator()(ptid_t) const (this=0x12aa600, __args#0=...)
at /usr/include/c++/7/bits/std_function.h:706
#9 0x000000000089aa0e in gdb::observers::observable<ptid_t>::notify(ptid_t) const (this=0x118a7a0 <gdb::observers::target_resumed>, args#0=...)
at src/gdb/common/observable.h:106
= #10 0x0000000000896fbe in set_running(ptid_t, int) (ptid=..., running=1) at src/gdb/thread.c:880
#11 0x00000000007f750f in remote_target::remote_add_thread(ptid_t, bool, bool) (this=0x12c5440, ptid=..., running=true, executing=true) at src/gdb/remote.c:2434
#12 0x00000000007f779d in remote_target::remote_notice_new_inferior(ptid_t, int) (this=0x12c5440, currthread=..., executing=1)
at src/gdb/remote.c:2515
#13 0x00000000007f9c44 in remote_target::update_thread_list() (this=0x12c5440) at src/gdb/remote.c:3831
#14 0x00000000007fb922 in remote_target::start_remote(int, int) (this=0x12c5440, from_tty=0, extended_p=0)
at src/gdb/remote.c:4655
#15 0x00000000007fd102 in remote_target::open_1(char const*, int, int) (name=0x1a4f45e "localhost:2346", from_tty=0, extended_p=0)
at src/gdb/remote.c:5638
#16 0x00000000007fbec1 in remote_target::open(char const*, int) (name=0x1a4f45e "localhost:2346", from_tty=0)
at src/gdb/remote.c:4862
So on frame #10, we're marking a newly-discovered thread as running,
and that causes the Python API to emit a gdb.ContinueEvent.
gdb.ContinueEvent is a gdb.ThreadEvent, and as such includes the event
thread as the "inferior_thread" attribute. The problem is that when
we get to frame #3/#4, we lost all references to the thread that is
being marked as running. create_continue_event_object assumes that it
is the current thread, which is not true in this case.
Fix this by passing down the right thread in
create_continue_event_object. Also remove
create_thread_event_object's default argument and have the only other
caller left pass down the right thread explicitly too.
gdb/ChangeLog:
2018-08-24 Pedro Alves <palves@redhat.com>
Simon Marchi <simon.marchi@ericsson.com>
PR gdb/23379
* python/py-continueevent.c: Include "gdbthread.h".
(create_continue_event_object): Add intro comment. Add 'ptid'
parameter. Use it to find thread to pass to
create_thread_event_object.
(emit_continue_event): Pass PTID down to
create_continue_event_object.
* python/py-event.h (py_get_event_thread): Declare.
(create_thread_event_object): Remove default from 'thread'
parameter.
* python/py-stopevent.c (create_stop_event_object): Use
py_get_event_thread.
* python/py-threadevent.c (get_event_thread): Rename to ...
(py_get_event_thread): ... this, make extern, add 'ptid' parameter
and use it to find the thread.
(create_thread_event_object): Assert that THREAD isn't null.
Don't find the event thread here.
GDB Administrator [Fri, 24 Aug 2018 00:01:01 +0000 (00:01 +0000)]
Automatic date update in version.in
Xavier Roirand [Thu, 23 Aug 2018 15:17:03 +0000 (11:17 -0400)]
Darwin: fix bad loop incrementation
When reading symbols from the vector of oso files on Mac OS X
Darwin, a previous commit introduce a change in the loop and add
an increment at each loop iteration whereas this incrementation is
not needed since the increment or set of the loop control variable
is already done in the loop.
gdb/ChangeLog:
* machoread.c (macho_symfile_read_all_oso): Remove uneeded
incrementation.
Change-Id: I3a5a6deb4e9d834ee7d4217a62d90c2ffb7241bc
GDB Administrator [Thu, 23 Aug 2018 00:02:01 +0000 (00:02 +0000)]
Automatic date update in version.in
Alan Hayward [Wed, 22 Aug 2018 08:22:12 +0000 (09:22 +0100)]
Aarch64 SVE VG is Vector Granule
...not Vector Gradient.
See: DWARF for the ARMĀ® 64-bit Architecture (AArch64) with SVE support
gdb/
* arch/aarch64.h (aarch64_regnum): Update comment.
Alan Hayward [Wed, 22 Aug 2018 08:17:24 +0000 (09:17 +0100)]
Add AArch64 SVE to NEWS and GDB manual
gdb/
* NEWS: Add SVE to 8.2 section.
gdb/doc/
* doc/gdb.texinfo (AArch64 SVE): New subsubsection.
GDB Administrator [Wed, 22 Aug 2018 00:01:19 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Tue, 21 Aug 2018 00:01:49 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Mon, 20 Aug 2018 00:01:09 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Sun, 19 Aug 2018 00:02:17 +0000 (00:02 +0000)]
Automatic date update in version.in
GDB Administrator [Sat, 18 Aug 2018 00:01:42 +0000 (00:01 +0000)]
Automatic date update in version.in
Tom Tromey [Thu, 16 Aug 2018 00:37:00 +0000 (18:37 -0600)]
Remove "repeat" argument from command_line_input
After the previous patch, all callers pass 0 as the repeat argument to
command_line_input. So, this patch removes it.
2018-08-16 Tom Tromey <tom@tromey.com>
* top.c (read_command_file): Update.
(command_line_input): Remove "repeat" argument.
* ada-lang.c (get_selections): Update.
* linespec.c (decode_line_2): Update.
* defs.h (command_line_input): Remove argument.
* cli/cli-script.c (read_next_line): Update.
* python/py-gdb-readline.c: Update.
Tom Tromey [Thu, 16 Aug 2018 00:37:00 +0000 (18:37 -0600)]
Fix use-after-free in number_or_range_parser
-fsanitize=address showed a use-after-free in number_or_range_parser.
The cause was that handle_line_of_input could stash the input into
"saved_command_line", and then this could be freed by reentrant calls.
This fixes the bug by preventing commands that are read by "commands"
from being eligible for repeating.
2018-08-17 Tom Tromey <tom@tromey.com>
* cli/cli-script.c (read_next_line): Pass 0 as repeat argument to
command_line_input.
GDB Administrator [Fri, 17 Aug 2018 00:01:40 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Thu, 16 Aug 2018 00:01:11 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Wed, 15 Aug 2018 00:01:18 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Tue, 14 Aug 2018 00:01:27 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Mon, 13 Aug 2018 00:01:41 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Sun, 12 Aug 2018 00:02:01 +0000 (00:02 +0000)]
Automatic date update in version.in
GDB Administrator [Sat, 11 Aug 2018 00:01:33 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Fri, 10 Aug 2018 00:01:04 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Thu, 9 Aug 2018 00:01:27 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Wed, 8 Aug 2018 00:01:17 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Tue, 7 Aug 2018 00:01:36 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Mon, 6 Aug 2018 00:00:56 +0000 (00:00 +0000)]
Automatic date update in version.in
GDB Administrator [Sun, 5 Aug 2018 00:01:47 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Sat, 4 Aug 2018 00:00:59 +0000 (00:00 +0000)]
Automatic date update in version.in
GDB Administrator [Fri, 3 Aug 2018 00:01:43 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Thu, 2 Aug 2018 00:01:05 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Wed, 1 Aug 2018 00:01:18 +0000 (00:01 +0000)]
Automatic date update in version.in
Simon Marchi [Sat, 14 Jul 2018 02:06:34 +0000 (22:06 -0400)]
Remove struct keyword in range-based for loop
PR gdb/23469
Fix this with gcc 6.3.0:
/home/simark/src/binutils-gdb/gdb/symfile.c: In function 'void set_objfile_default_section_offset(objfile*, const section_addr_info&, CORE_ADDR)':
/home/simark/src/binutils-gdb/gdb/symfile.c:2114:14: error: types may not be defined in a for-range-declaration [-Werror]
for (const struct other_sections *objf_sect : objf_addrs_sorted)
^~~~~~
gdb/ChangeLog:
* symfile.c (set_objfile_default_section_offset): Remove struct
keyword.
(cherry picked from commit
ff27d0737ef0c9433a6a7c83c1e678ac57a27699)
GDB Administrator [Tue, 31 Jul 2018 00:01:53 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Mon, 30 Jul 2018 00:01:10 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Sun, 29 Jul 2018 00:02:13 +0000 (00:02 +0000)]
Automatic date update in version.in
GDB Administrator [Sat, 28 Jul 2018 00:01:25 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Fri, 27 Jul 2018 00:01:44 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Thu, 26 Jul 2018 00:01:42 +0000 (00:01 +0000)]
Automatic date update in version.in
Alan Hayward [Wed, 11 Jul 2018 07:34:50 +0000 (08:34 +0100)]
Rename tdesc_register_size to tdesc_register_bitsize
tdesc_register_size returns number of bits, not bytes.
Rename to make it clearer.
Also, fixed bug in aarch64_get_tdesc_vq which assumed bytes.
gdb/
* target-descriptions.c (tdesc_register_bitsize): Rename.
* target-descriptions.h (tdesc_register_bitsize): Likewise.
* rs6000-tdep.c (rs6000_gdbarch_init): Use new name.
* aarch64-tdep.c (aarch64_get_tdesc_vq): Convert size.
GDB Administrator [Wed, 25 Jul 2018 00:01:22 +0000 (00:01 +0000)]
Automatic date update in version.in
Keith Seitz [Tue, 24 Jul 2018 19:45:51 +0000 (12:45 -0700)]
Set CU language before processing any DIEs (symtab/23010 et al)
This patch is another attempt at really fixing the multitude of assertions
being seen where symbols of one language are being added to symbol lists of
another language.
In this specific case, the backtrace command (thread apply all bt full) that
is looking for the compunit containing the PC of the thread. That calls
get_prev_frame several times. This function calls (eventually)
dwarf2_frame_prev_register. That eventually ends up calling
find_pc_compunit_symtab.
In this function (find_pc_sect_compunit_symtab actually), we loop over all
compunits, calling the "quick" function dw2_find_pc_sect_compunit_symtab.
That function calls dw2_instantiate_symtab to read in all the CU's symbols.
Now the fun begins.
dw2_do_instantiate_symtab queues the per_cu for reading, using a default
"pretend" language of language_minimal with the expectation that this will
be set later.
The DIEs of this (only queued) CU are then processed.
The first DIE is DW_TAG_compile_unit. That's handled by read_file_scope.
(Nearly) The first thing read_file_scope does is:
get_scope_pc_bounds (die, &lowpc, &highpc, cu);
This function loops over the children of the current DIE (a compile_unit),
looking for bounds. The first such child is a subprogram, and we attempt to
get its bounds. We use dwarf2_attr to get at DW_AT_high_pc.
This subprogram has DW_AT_specification set, so dwarf_attr (via
follow_die_ref/follow_die_offset) will follow that, but follow_die_offset
*also* attempts to load the containing CU for the spec DIE. That spec DIE
lives inside a CU that is a partial_unit and has no language attribute. So
it simply inherits the language from the CU that elicited the read. [That
all happens in follow_die_offset.]
The original CU's language is still language_minimal -- we haven't gotten to
the line in read_file_scope that actually sets the language yet!
And that is the cause of these problems. The call to prepare_one_comp_unit
needs to be the *first* thing that is done when reading a CU so that the
CU's language can be recorded (and inherited by any referenced
partial_units).
Since a test reproducer for this has been so elusive, this patch also adds a
wrapper function around add_symbol_to_list which asserts when adding a
symbol of one language to a list containing symbols of a different language.
gdb/ChangeLog:
2017-07-24 Keith Seitz <keiths@redhat.com>
PR symtab/23010
* dwarf2read.c (dw2_add_symbol_to_list): New function.
(fixup_go_packaging, new_symbol): Use dw2_add_symbol_to_list
instead of add_symbol_to_list.
(read_file_scope): Call prepare_one_comp_unit before reading
any other DIEs.
GDB Administrator [Tue, 24 Jul 2018 00:01:21 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Mon, 23 Jul 2018 00:01:55 +0000 (00:01 +0000)]
Automatic date update in version.in
Tom Tromey [Sun, 8 Jul 2018 18:18:09 +0000 (12:18 -0600)]
Pass the correct argument to the observer in reread_symbols
This is actually a patch I found via another route. Joel had asked me
to write a test, but I still have not found the time to do this.
Meanwhile, -Wunused-variable also found this error.
2018-07-22 Tom Tromey <tom@tromey.com>
* symfile.c (reread_symbols): Notify iter, not objfile.
Tom Tromey [Sun, 8 Jul 2018 18:17:51 +0000 (12:17 -0600)]
Fix ravenscar-thread.c to use arch_ops
The change to turn target ops into methods accidentally introduced a
bug in ravenscar-thread.c, changing some calls that were using
"arch_ops" to use the target beneath.
This patch changes ravenscar-thread.c to use these variables where
appropriate.
2018-07-22 Tom Tromey <tom@tromey.com>
* ravenscar-thread.c (ravenscar_thread_target::store_registers):
Use arch_ops.
(ravenscar_thread_target::prepare_to_store): Likewise.
GDB Administrator [Sun, 22 Jul 2018 00:01:52 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Sat, 21 Jul 2018 00:01:38 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Fri, 20 Jul 2018 00:01:19 +0000 (00:01 +0000)]
Automatic date update in version.in
Eli Zaretskii [Thu, 19 Jul 2018 13:54:06 +0000 (16:54 +0300)]
Fix GDB build using mingw.org's MinGW
libiberty/
2018-07-18 Eli Zaretskii <eliz@gnu.org>
PR gdb/23434
* libiberty/simple-object-elf.c (ENOTSUP): If not defined by
errno.h, redirect ENOTSUP to ENOSYS.
(cherry picked from commit
db3410f80f793189d3c8afb8b80951333d3fe007)
GDB Administrator [Thu, 19 Jul 2018 00:02:00 +0000 (00:02 +0000)]
Automatic date update in version.in
GDB Administrator [Wed, 18 Jul 2018 00:01:23 +0000 (00:01 +0000)]
Automatic date update in version.in
Tom Tromey [Fri, 29 Jun 2018 21:10:04 +0000 (15:10 -0600)]
Use scoped_free_pendings in coff_symtab_read
PR gdb/18624 concerns an assertion failure that occurs when setting a
breakpoint in a Go program on Windows.
What happens here is that coff_symtab_read uses buildsym but does not
instantiate scoped_free_pendings. So, the struct pending objects are
never released. Later, dwarf2read.c calls buildsym_init, which
asserts.
This patch fixes the problem by instantiating scoped_free_pendings in
coff_symtab_read.
Tested using the test executable from the PR. I don't know how to
test this more fully.
2018-07-17 Tom Tromey <tom@tromey.com>
PR gdb/18624:
* coffread.c (coff_symtab_read): Use scoped_free_pendings.
GDB Administrator [Tue, 17 Jul 2018 00:01:28 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Mon, 16 Jul 2018 00:01:30 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Sun, 15 Jul 2018 00:01:56 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Sat, 14 Jul 2018 00:00:55 +0000 (00:00 +0000)]
Automatic date update in version.in
GDB Administrator [Fri, 13 Jul 2018 00:01:58 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Thu, 12 Jul 2018 00:01:14 +0000 (00:01 +0000)]
Automatic date update in version.in
Pedro Alves [Wed, 11 Jul 2018 22:40:51 +0000 (23:40 +0100)]
GDB: Work around D;PID handling bug in older GDBservers (PR gdb/23377)
This commit adds a GDB workaround for the GDBserver bug exposed by
commit
f2ffa92bbce9 ("gdb: Eliminate the 'stop_pc' global"), so that
newer GDBs can continue working with older GDBservers.
gdb/ChangeLog:
2018-07-11 Pedro Alves <palves@redhat.com>
PR gdb/23377
* remote.c (remote_target::remote_detach_pid): Call
set_current_process.
Pedro Alves [Wed, 11 Jul 2018 22:40:50 +0000 (23:40 +0100)]
GDBserver: Don't assume a current process in D;PID implementation (PR gdb/23377)
This fixes a gdb.base/multi-forks.exp regression with GDBserver.
Git commit
f2ffa92bbce9 ("gdb: Eliminate the 'stop_pc' global") caused
the regression by exposing a latent bug in gdbserver.
The bug is that GDBserver's implementation of the D;PID packet
incorrectly assumes that the selected thread points to the process
being detached. This happens via the any_persistent_commands call,
which calls current_process:
(gdb) bt
#0 0x000000000040a57e in internal_error(char const*, int, char const*, ...)
(file=0x4a53c0 "src/gdb/gdbserver/inferiors.c", line=212, fmt=0x4a539e "%s:
Assertion `%s' failed.") at src/gdb/gdbserver/../common/errors.c:54
#1 0x0000000000420acf in current_process() () at
src/gdb/gdbserver/inferiors.c:212
#2 0x00000000004226a0 in any_persistent_commands() () at
gdb/gdbserver/mem-break.c:308
#3 0x000000000042cb43 in handle_detach(char*) (own_buf=0x6f0280 "D;62ea") at
src/gdb/gdbserver/server.c:1210
#4 0x0000000000433af3 in process_serial_event() () at
src/gdb/gdbserver/server.c:4055
#5 0x0000000000434878 in handle_serial_event(int, void*) (err=0,
client_data=0x0)
The "eliminate stop_pc" commit exposes the problem because before that
commit, GDB's switch_to_thread always read the newly-selected thread's
PC, and that would end up forcing GDBserver's selected thread to
change accordingly as side effect. After that commit, GDB no longer
reads the thread's PC, and GDBserver does not switch the thread.
Fix this by removing the assumption from GDBserver.
gdb/gdbserver/ChangeLog:
2018-07-11 Pedro Alves <palves@redhat.com>
PR gdb/23377
* mem-break.c (any_persistent_commands): Add process_info
parameter and use it instead of relying on the current process.
Change return type to bool.
* mem-break.h (any_persistent_commands): Add process_info
parameter and change return type to bool.
* server.c (handle_detach): Remove require_running_or_return call.
Look up the process_info for the process we're about to detach.
If not found, return back error to GDB. Adjust
any_persistent_commands call to pass down a process pointer.
Pedro Alves [Wed, 11 Jul 2018 18:57:46 +0000 (19:57 +0100)]
GDBserver: Fix "Cond. jump or move depends on uninit value" in x87 code
Running gdbserver under Valgrind I get:
==26925== Conditional jump or move depends on uninitialised value(s)
==26925== at 0x473E7F: i387_cache_to_xsave(regcache*, void*) (i387-fp.c:579)
==26925== by 0x46E3ED: x86_fill_xstateregset(regcache*, void*) (linux-x86-low.c:418)
==26925== by 0x45E747: regsets_store_inferior_registers(regsets_info*, regcache*) (linux-low.c:5456)
==26925== by 0x45EEF8: linux_store_registers(regcache*, int) (linux-low.c:5731)
==26925== by 0x426441: regcache_invalidate_thread(thread_info*) (regcache.c:89)
==26925== by 0x45CCAF: linux_resume_one_lwp_throw(lwp_info*, int, int, siginfo_t*) (linux-low.c:4447)
==26925== by 0x45CE2A: linux_resume_one_lwp(lwp_info*, int, int, siginfo_t*) (linux-low.c:4519)
==26925== by 0x45E17C: proceed_one_lwp(thread_info*, lwp_info*) (linux-low.c:5216)
==26925== by 0x45DC81: linux_resume_one_thread(thread_info*, bool) (linux-low.c:5031)
==26925== by 0x45DD34: linux_resume(thread_resume*, unsigned long)::{lambda(thread_info*)#2}::operator()(thread_info*) const (linux-low.c:5095)
==26925== by 0x462907: void for_each_thread<linux_resume(thread_resume*, unsigned long)::{lambda(thread_info*)#2}>(linux_resume(thread_resume*, unsigned long)::{lambda(thread_info*)#2}) (gdbthread.h:150)
==26925== by 0x45DE62: linux_resume(thread_resume*, unsigned long) (linux-low.c:5093)
==26925==
==26925== Conditional jump or move depends on uninitialised value(s)
==26925== at 0x473EBD: i387_cache_to_xsave(regcache*, void*) (i387-fp.c:586)
==26925== by 0x46E3ED: x86_fill_xstateregset(regcache*, void*) (linux-x86-low.c:418)
==26925== by 0x45E747: regsets_store_inferior_registers(regsets_info*, regcache*) (linux-low.c:5456)
==26925== by 0x45EEF8: linux_store_registers(regcache*, int) (linux-low.c:5731)
==26925== by 0x426441: regcache_invalidate_thread(thread_info*) (regcache.c:89)
==26925== by 0x45CCAF: linux_resume_one_lwp_throw(lwp_info*, int, int, siginfo_t*) (linux-low.c:4447)
==26925== by 0x45CE2A: linux_resume_one_lwp(lwp_info*, int, int, siginfo_t*) (linux-low.c:4519)
==26925== by 0x45E17C: proceed_one_lwp(thread_info*, lwp_info*) (linux-low.c:5216)
==26925== by 0x45DC81: linux_resume_one_thread(thread_info*, bool) (linux-low.c:5031)
==26925== by 0x45DD34: linux_resume(thread_resume*, unsigned long)::{lambda(thread_info*)#2}::operator()(thread_info*) const (linux-low.c:5095)
==26925== by 0x462907: void for_each_thread<linux_resume(thread_resume*, unsigned long)::{lambda(thread_info*)#2}>(linux_resume(thread_resume*, unsigned long)::{lambda(thread_info*)#2}) (gdbthread.h:150)
==26925== by 0x45DE62: linux_resume(thread_resume*, unsigned long) (linux-low.c:5093)
The problem is a type/width mismatch in code like this, in
gdbserver/i387-fp.c:
/* Some registers are 16-bit. */
collect_register_by_name (regcache, "fctrl", &val);
fp->fctrl = val;
In the above code:
#1 - 'val' is a 64-bit unsigned long.
#2 - "fctrl" is 32-bit in the register cache, thus half of 'val' is
left uninitialized by collect_register_by_name, which works with
an untyped raw buffer output (i.e., void*).
#3 - fp->fctrl is an unsigned short (16-bit). For some such
registers we're masking off the uninitialized bits with 0xffff,
but not in all cases.
We end up in such a fragile situation because
collect_registers_by_name works with an untyped output buffer pointer,
making it easy to pass a pointer to a variable of the wrong size.
Fix this by using regcache_raw_get_unsigned instead (actually a new
regcache_raw_get_unsigned_by_name wrapper), which always returns a
zero-extended ULONGEST register value. It ends up simplifying the
i387-tdep.c code a bit, even.
gdb/gdbserver/ChangeLog:
2018-07-11 Pedro Alves <palves@redhat.com>
* i387-fp.c (i387_cache_to_fsave, cache_to_fxsave)
(i387_cache_to_xsave): Use regcache_raw_get_unsigned_by_name
instead of collect_register_by_name.
* regcache.c (regcache_raw_get_unsigned_by_name): New.
* regcache.h (regcache_raw_get_unsigned_by_name): New.
Sergio Durigan Junior [Sat, 7 Jul 2018 21:16:55 +0000 (17:16 -0400)]
Fix PR c++/23373: GDB hangs when printing a struct with a static member of itself
This patch fixes a failure that happens when a structure has a static
member whose type is the same as itself. From the bug report:
Example code:
struct A
{
static A Empty;
int a;
};
int main(void) {
A a;
return 0;
}
Output:
(gdb) ptype/o A
/* offset | size */ type = struct A {
static struct A {
static struct A {
static struct A {
static struct A {
static struct A {
static struct A {
... # infinite loop
The problem here is that GDB is not taking into account the fact that
static members inside a class/struct are not stored in the
class/struct, and therefore they should not be accounted for during
the display of the offsets/sizes. The fix is simple: we just check if
the field we're dealing with (on
c-typeprint.c:c_type_print_base_struct_union) is static, and if it is
then we don't iterate over it.
This patch also adds a new test for this case, and doesn't introduce
any regressions. I believe it is important enough to be included in
the 8.2 branch.
OK?
gdb/ChangeLog:
2018-07-11 Sergio Durigan Junior <sergiodj@redhat.com>
PR c++/23373
* c-typeprint.c (c_type_print_base_struct_union): Don't print
offsets/sizes for static members of a class/struct.
gdb/testsuite/ChangeLog:
2018-07-11 Sergio Durigan Junior <sergiodj@redhat.com>
PR c++/23373
* gdb.base/ptype-offsets.cc (struct static_member): New
struct.
(main) <stmember>: New variable.
* gdb.base/ptype-offsets.exp: Add test for printing a struct
with a static member in it.
GDB Administrator [Wed, 11 Jul 2018 00:01:28 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Tue, 10 Jul 2018 00:01:34 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Mon, 9 Jul 2018 00:01:42 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Sun, 8 Jul 2018 00:02:21 +0000 (00:02 +0000)]
Automatic date update in version.in
Jan Kratochvil [Sat, 7 Jul 2018 21:02:36 +0000 (23:02 +0200)]
contrib/gdb-add-index.sh -dwarf-5
------------------------------------------------------------------------------
(gdb) help save gdb-index
Save a gdb-index file.
Usage: save gdb-index [-dwarf-5] DIRECTORY
No options create one file with .gdb-index extension for pre-DWARF-5
compatible .gdb_index section. With -dwarf-5 creates two files with
extension .debug_names and .debug_str for DWARF-5 .debug_names section.
------------------------------------------------------------------------------
But gdb-add-index command provided no way how to pass the -dwarf-5 option.
gdb/ChangeLog
2018-07-07 Jan Kratochvil <jan.kratochvil@redhat.com>
* contrib/gdb-add-index.sh ($dwarf5): New, use it.
GDB Administrator [Sat, 7 Jul 2018 00:01:40 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Fri, 6 Jul 2018 00:02:03 +0000 (00:02 +0000)]
Automatic date update in version.in
GDB Administrator [Thu, 5 Jul 2018 00:02:14 +0000 (00:02 +0000)]
Automatic date update in version.in
Joel Brobecker [Wed, 4 Jul 2018 16:17:39 +0000 (09:17 -0700)]
Bump GDB version number to 8.1.90.DATE-git.
gdb/ChangeLog:
* version.in: Set GDB version number to 8.1.90.DATE-git.
* PROBLEMS: Likewise.
Joel Brobecker [Wed, 4 Jul 2018 16:17:30 +0000 (09:17 -0700)]
Document the GDB 8.1.90 release in gdb/ChangeLog
gdb/ChangeLog:
GDB 8.1.90 released.
Joel Brobecker [Wed, 4 Jul 2018 16:04:00 +0000 (09:04 -0700)]
Set GDB version number to 8.1.90.
gdb/ChangeLog:
* version.in: Set GDB version number to 8.1.90.
* PROBLEMS: Likewise.
Joel Brobecker [Wed, 4 Jul 2018 16:02:02 +0000 (09:02 -0700)]
gdb/NEWS: Change "Changes since GDB 8.1" into "Changes in GDB 8.2".
gdb/ChangeLog:
* NEWS: Change "Changes since GDB 8.1" into "Changes in GDB 8.2".
Joel Brobecker [Wed, 4 Jul 2018 15:42:50 +0000 (08:42 -0700)]
Set development mode to "off" by default.
bfd/ChangeLog:
* development.sh (development): Set to false.
Joel Brobecker [Wed, 4 Jul 2018 15:42:21 +0000 (08:42 -0700)]
Bump version to 8.1.90.DATE-git.
Now that the GDB 8.2 branch has been created, we can
bump the version number.
gdb/ChangeLog:
GDB 8.2 branch created (
1b919490e8ba30bf1d6941df0ed112b0e557017e):
* version.in: Bump version to 8.1.90.DATE-git.
Vyacheslav Barinov [Wed, 4 Jul 2018 15:13:29 +0000 (16:13 +0100)]
Warn if /proc is not accessible
There's a buildroot where I want to debug a binary, and I tried to
connect to it from outside, but got very weird errors like
architecture mismatch or protocol errors. At last, after switching on
'--debug' for gdbserver I found a message 'Can't open /proc/pid/'
message and suddenly found that I forgot to mount procfs in my
buildroot.
Make discovering the problem easier by making GDB / GDBserver warn
(even without --debug) if /proc can not be accessed.
Native debugging:
(gdb) start
Temporary breakpoint 1 at 0x400835: file test.c, line 10.
Starting program: /tmp/test
warning: /proc is not accessible.
GDBserver/remote debugging:
$ ./gdbserver :9999 ./gdbserver
gdbserver: /proc is not accessible.
gdb/ChangeLog:
2018-07-04 Vyacheslav Barinov <v.barinov@samsung.com>
Pedro Alves <palves@redhat.com>
* linux-nat.c (linux_init_ptrace): Rename to ...
(linux_init_ptrace_procfs): ... this. Call
linux_proc_init_warnings.
(linux_nat_target::post_attach)
(linux_nat_target::post_startup_inferior): Adjust.
* nat/linux-procfs.c (linux_proc_init_warnings): Define function.
* nat/linux-procfs.h (linux_proc_init_warnings): Declare function.
gdb/gdbserver/ChangeLog:
2018-07-04 Vyacheslav Barinov <v.barinov@samsung.com>
Pedro Alves <palves@redhat.com>
* linux-low.c (initialize_low): Call linux_proc_init_warnings.
H.J. Lu [Wed, 4 Jul 2018 13:27:58 +0000 (06:27 -0700)]
ld: Set non_ir_ref_regular for --undefined SYMBOL
Set non_ir_ref_regular to TRUE for symbols forced into the output file
so that they won't be removed by garbage collection with LTO.
PR ld/23309
* ldlang.c (insert_undefined): Set non_ir_ref_regular to TRUE.
* plugin.c (is_visible_from_outside): Don't scan entry_symbol.
* testsuite/ld-plugin/pr23309.c: New file.
* testsuite/ld-plugin/pr23309.d: Likewise.
H.J. Lu [Wed, 4 Jul 2018 13:22:40 +0000 (06:22 -0700)]
ld: Properly display default for -z separate-code
Check DEFAULT_LD_Z_SEPARATE_CODE to display default for -z separate-code.
PR ld/23358
* lexsup.c (elf_shlib_list_options): Properly display default
for -z separate-code.
H.J. Lu [Wed, 4 Jul 2018 13:18:22 +0000 (06:18 -0700)]
Also install diagnostics.h
Since bfd.h is an installed header, also install diagnostics.h.
* Makefile.am (bfdinclude_HEADERS): Add $(INCDIR)/diagnostics.h.
* Makefile.in: Regenerated.
Tom de Vries [Tue, 3 Jul 2018 22:07:30 +0000 (00:07 +0200)]
[gdb/symtab] Fix version check in dwarf compilation unit header
The version check of the dwarf compilation unit header in
error_check_comp_unit_head is done too late, and consequently dwarf code with
an unsupported version in the compilation unit header is interpreted as dwarf5
code in read_comp_unit_head.
Fixed by moving the check earlier.
Build and reg-tested on x86_64-linux.
2018-07-04 Tom de Vries <tdevries@suse.de>
* dwarf2read.c (error_check_comp_unit_head): Move dwarf version
check ...
(read_comp_unit_head): ... here.
* gdb.dwarf2/dw2-error.exp: Update expected error message.
Tom Tromey [Tue, 5 Jun 2018 16:22:01 +0000 (10:22 -0600)]
Remove VEC from breakpoint
This removes a use of VEC from breakpoint.h, also removing the
now-unnecessary breakpoint_p typedef.
This patch fixes a latent memory leak in
find_matching_tracepoint_location, which neglected to free the vector
returned by all_tracepoints.
Tested by the buildbot.
gdb/ChangeLog
2018-07-03 Tom Tromey <tom@tromey.com>
* tracepoint.c (process_tracepoint_on_disconnect, start_tracing)
(stop_tracing, tstatus_command)
(find_matching_tracepoint_location, merge_uploaded_tracepoints)
(print_one_static_tracepoint_marker): Update.
* breakpoint.c (static_tracepoints_here, all_tracepoints): Return
std::vector.
* breakpoint.h (breakpoint_p): Remove typedef. Don't declare
VEC.
(all_tracepoints, static_tracepoints_here): Return std::vector.
GDB Administrator [Wed, 4 Jul 2018 00:01:24 +0000 (00:01 +0000)]
Automatic date update in version.in
Tom Tromey [Mon, 11 Jun 2018 20:45:22 +0000 (14:45 -0600)]
Remove ptid_equal
Remove ptid_equal in favor of using "==".
gdb/ChangeLog
2018-07-03 Tom Tromey <tom@tromey.com>
* common/ptid.c (ptid_equal): Remove.
* common/ptid.h (ptid_equal): Don't declare.
* ada-tasks.c: Update.
* breakpoint.c: Update.
* common/agent.c: Update.
* corelow.c: Update.
* darwin-nat-info.c: Update.
* darwin-nat.c: Update.
* dcache.c: Update.
* dtrace-probe.c: Update.
* dummy-frame.c: Update.
* fbsd-nat.c: Update.
* frame.c: Update.
* gdbthread.h: Update.
* gnu-nat.c: Update.
* go32-nat.c: Update.
* inf-loop.c: Update.
* inf-ptrace.c: Update.
* infcall.c: Update.
* infcmd.c: Update.
* inflow.c: Update.
* infrun.c: Update.
* linux-fork.c: Update.
* linux-nat.c: Update.
* linux-thread-db.c: Update.
* mi/mi-cmd-var.c: Update.
* mi/mi-interp.c: Update.
* mi/mi-main.c: Update.
* nto-procfs.c: Update.
* ppc-linux-tdep.c: Update.
* procfs.c: Update.
* python/py-inferior.c: Update.
* python/py-record-btrace.c: Update.
* python/py-record.c: Update.
* ravenscar-thread.c: Update.
* regcache.c: Update.
* remote-sim.c: Update.
* remote.c: Update.
* sol-thread.c: Update.
* solib.c: Update.
* target.c: Update.
* tui/tui-stack.c: Update.
* varobj.c: Update.
* windows-nat.c: Update.
* windows-tdep.c: Update.
gdb/gdbserver/ChangeLog
2018-07-03 Tom Tromey <tom@tromey.com>
* linux-low.c: Update.
* lynx-low.c: Update.
* mem-break.c: Update.
* nto-low.c: Update.
* remote-utils.c: Update.
* server.c: Update.
* spu-low.c: Update.
* target.c: Update.
* win32-low.c: Update.
Tom Tromey [Mon, 11 Jun 2018 20:35:00 +0000 (14:35 -0600)]
Remove ptid_match
This removes ptid_match in favor of the ptid_t::matches method.
gdb/ChangeLog
2018-07-03 Tom Tromey <tom@tromey.com>
* common/ptid.c (ptid_match): Remove.
* common/ptid.h (ptid_match): Don't declare.
* fbsd-nat.c: Update.
* infcmd.c: Update.
* infrun.c: Update.
* linux-nat.c: Update.
* record-btrace.c: Update.
* regcache.c: Update.
* remote.c: Update.
gdb/gdbserver/ChangeLog
2018-07-03 Tom Tromey <tom@tromey.com>
* server.c: Update.
Tom Tromey [Mon, 11 Jun 2018 18:22:04 +0000 (12:22 -0600)]
Remove ptid_tid_p
This removes ptid_tid_p in favor of the ptid_t::tid_p method.
gdb/ChangeLog
2018-07-03 Tom Tromey <tom@tromey.com>
* common/ptid.c (ptid_tid_p): Remove.
* common/ptid.h (ptid_tid_p): Don't declare.
* sol-thread.c: Update.
Tom Tromey [Mon, 11 Jun 2018 18:20:11 +0000 (12:20 -0600)]
Remove ptid_lwp_p
This removes ptid_lwp_p in favor of the ptid_t::lwp_p method.
gdb/ChangeLog
2018-07-03 Tom Tromey <tom@tromey.com>
* common/ptid.c (ptid_lwp_p): Remove.
* common/ptid.h (ptid_lwp_p): Don't declare.
* fbsd-nat.c: Update.
* linux-nat.c: Update.
* nat/linux-procfs.c: Update.
* nat/x86-linux-dregs.c: Update.
* sol-thread.c: Update.
Tom Tromey [Mon, 11 Jun 2018 18:18:15 +0000 (12:18 -0600)]
Remove ptid_is_pid
This removes ptid_is_pid in favor of the ptid_t::is_pid method.
gdb/ChangeLog
2018-07-03 Tom Tromey <tom@tromey.com>
* common/ptid.c (ptid_is_pid): Remove.
* common/ptid.h (ptid_is_pid): Don't declare.
* infrun.c: Update.
* linux-nat.c: Update.
* mi/mi-interp.c: Update.
* remote.c: Update.
* thread.c: Update.
gdb/gdbserver/ChangeLog
2018-07-03 Tom Tromey <tom@tromey.com>
* linux-low.c: Update.
Tom Tromey [Mon, 11 Jun 2018 18:14:34 +0000 (12:14 -0600)]
Remove ptid_get_tid
This removes ptid_get_tid in favor of calling the ptid_t::tid method.
gdb/ChangeLog
2018-07-03 Tom Tromey <tom@tromey.com>
* common/ptid.c (ptid_get_tid): Remove.
* common/ptid.h (ptid_get_tid): Don't declare.
* ada-tasks.c: Update.
* aix-thread.c: Update.
* bsd-uthread.c: Update.
* darwin-nat.c: Update.
* fbsd-nat.c: Update.
* i386-darwin-nat.c: Update.
* infrun.c: Update.
* linux-tdep.c: Update.
* nto-procfs.c: Update.
* ppc-ravenscar-thread.c: Update.
* python/py-infthread.c: Update.
* ravenscar-thread.c: Update.
* sol-thread.c: Update.
* sparc-ravenscar-thread.c: Update.
* windows-nat.c: Update.
gdb/gdbserver/ChangeLog
2018-07-03 Tom Tromey <tom@tromey.com>
* target.c: Update.
Tom Tromey [Mon, 11 Jun 2018 18:10:09 +0000 (12:10 -0600)]
Remove ptid_get_lwp
This removes ptid_get_lwp in favor of calling the ptid_t::lwp method.
gdb/ChangeLog
2018-07-03 Tom Tromey <tom@tromey.com>
* common/ptid.c (ptid_get_lwp): Remove.
* common/ptid.h (ptid_get_lwp): Don't declare.
* aarch64-linux-nat.c: Update.
* ada-tasks.c: Update.
* aix-thread.c: Update.
* amd64-linux-nat.c: Update.
* arm-linux-nat.c: Update.
* corelow.c: Update.
* fbsd-nat.c: Update.
* fbsd-tdep.c: Update.
* gnu-nat.c: Update.
* i386-cygwin-tdep.c: Update.
* i386-gnu-nat.c: Update.
* i386-linux-nat.c: Update.
* ia64-linux-nat.c: Update.
* inf-ptrace.c: Update.
* infrun.c: Update.
* linux-fork.c: Update.
* linux-nat.c: Update.
* linux-tdep.c: Update.
* linux-thread-db.c: Update.
* mips-linux-nat.c: Update.
* nat/aarch64-linux-hw-point.c: Update.
* nat/aarch64-linux.c: Update.
* nat/linux-btrace.c: Update.
* nat/linux-osdata.c: Update.
* nat/linux-procfs.c: Update.
* nat/x86-linux-dregs.c: Update.
* obsd-nat.c: Update.
* ppc-fbsd-nat.c: Update.
* ppc-linux-nat.c: Update.
* procfs.c: Update.
* python/py-infthread.c: Update.
* ravenscar-thread.c: Update.
* remote.c: Update.
* s390-linux-nat.c: Update.
* sol-thread.c: Update.
* sol2-tdep.c: Update.
* spu-linux-nat.c: Update.
* x86-linux-nat.c: Update.
* xtensa-linux-nat.c: Update.
gdb/gdbserver/ChangeLog
2018-07-03 Tom Tromey <tom@tromey.com>
* linux-low.c: Update.
* linux-mips-low.c: Update.
* lynx-low.c: Update.
* nto-low.c: Update.
* remote-utils.c: Update.
* server.c: Update.
* spu-low.c: Update.
* target.c: Update.
* thread-db.c: Update.
Tom Tromey [Mon, 11 Jun 2018 18:05:27 +0000 (12:05 -0600)]
Remove ptid_get_pid
This removes ptid_get_pid in favor of calling the ptid_t::pid method.
gdb/ChangeLog
2018-07-03 Tom Tromey <tom@tromey.com>
* common/ptid.c (ptid_get_pid): Remove.
* common/ptid.h (ptid_get_pid): Don't declare.
* aarch64-linux-nat.c: Update.
* ada-lang.c: Update.
* aix-thread.c: Update.
* alpha-bsd-nat.c: Update.
* amd64-fbsd-nat.c: Update.
* amd64-linux-nat.c: Update.
* arm-linux-nat.c: Update.
* arm-nbsd-nat.c: Update.
* auxv.c: Update.
* break-catch-syscall.c: Update.
* breakpoint.c: Update.
* bsd-uthread.c: Update.
* corelow.c: Update.
* ctf.c: Update.
* darwin-nat.c: Update.
* fbsd-nat.c: Update.
* fbsd-tdep.c: Update.
* gcore.c: Update.
* gnu-nat.c: Update.
* hppa-nbsd-nat.c: Update.
* hppa-obsd-nat.c: Update.
* i386-fbsd-nat.c: Update.
* ia64-linux-nat.c: Update.
* inf-ptrace.c: Update.
* infcmd.c: Update.
* inferior.c: Update.
* inferior.h: Update.
* inflow.c: Update.
* infrun.c: Update.
* linux-fork.c: Update.
* linux-nat.c: Update.
* linux-tdep.c: Update.
* linux-thread-db.c: Update.
* m68k-bsd-nat.c: Update.
* mi/mi-interp.c: Update.
* mi/mi-main.c: Update.
* mips-linux-nat.c: Update.
* mips-nbsd-nat.c: Update.
* mips64-obsd-nat.c: Update.
* nat/aarch64-linux-hw-point.c: Update.
* nat/aarch64-linux.c: Update.
* nat/linux-btrace.c: Update.
* nat/linux-osdata.c: Update.
* nat/linux-procfs.c: Update.
* nat/x86-linux-dregs.c: Update.
* nto-procfs.c: Update.
* obsd-nat.c: Update.
* ppc-linux-nat.c: Update.
* ppc-nbsd-nat.c: Update.
* ppc-obsd-nat.c: Update.
* proc-service.c: Update.
* procfs.c: Update.
* python/py-inferior.c: Update.
* python/py-infthread.c: Update.
* ravenscar-thread.c: Update.
* record.c: Update.
* remote-sim.c: Update.
* remote.c: Update.
* rs6000-nat.c: Update.
* s390-linux-nat.c: Update.
* sh-nbsd-nat.c: Update.
* sol-thread.c: Update.
* sparc-nat.c: Update.
* sparc64-tdep.c: Update.
* spu-linux-nat.c: Update.
* spu-tdep.c: Update.
* target-debug.h: Update.
* target.c: Update.
* thread.c: Update.
* tid-parse.c: Update.
* tracefile-tfile.c: Update.
* vax-bsd-nat.c: Update.
* windows-nat.c: Update.
* x86-linux-nat.c: Update.
* x86-nat.c: Update.
gdb/gdbserver/ChangeLog
2018-07-03 Tom Tromey <tom@tromey.com>
* linux-low.c: Update.
* linux-mips-low.c: Update.
* lynx-low.c: Update.
* mem-break.c: Update.
* nto-low.c: Update.
* remote-utils.c: Update.
* server.c: Update.
* spu-low.c: Update.
* target.c: Update.
* tracepoint.c: Update.
Tom Tromey [Mon, 11 Jun 2018 17:25:49 +0000 (11:25 -0600)]
Remove pid_to_ptid
This removes pid_to_ptid in favor of calling the ptid_t constructor
directly.
gdb/ChangeLog
2018-07-03 Tom Tromey <tom@tromey.com>
* common/ptid.c (pid_to_ptid): Remove.
* common/ptid.h (pid_to_ptid): Don't declare.
* aix-thread.c: Update.
* arm-linux-nat.c: Update.
* common/ptid.c: Update.
* common/ptid.h: Update.
* corelow.c: Update.
* ctf.c: Update.
* darwin-nat.c: Update.
* fbsd-nat.c: Update.
* fork-child.c: Update.
* gnu-nat.c: Update.
* go32-nat.c: Update.
* inf-ptrace.c: Update.
* infcmd.c: Update.
* inferior.c: Update.
* infrun.c: Update.
* linux-fork.c: Update.
* linux-nat.c: Update.
* nat/aarch64-linux-hw-point.c: Update.
* nat/fork-inferior.c: Update.
* nat/x86-linux-dregs.c: Update.
* nto-procfs.c: Update.
* obsd-nat.c: Update.
* procfs.c: Update.
* progspace.c: Update.
* remote.c: Update.
* rs6000-nat.c: Update.
* s390-linux-nat.c: Update.
* sol-thread.c: Update.
* spu-linux-nat.c: Update.
* target.c: Update.
* top.c: Update.
* tracefile-tfile.c: Update.
* windows-nat.c: Update.
gdb/gdbserver/ChangeLog
2018-07-03 Tom Tromey <tom@tromey.com>
* linux-low.c: Update.
* linux-ppc-low.c: Update.
* linux-x86-low.c: Update.
* proc-service.c: Update.
* server.c: Update.
* spu-low.c: Update.
* thread-db.c: Update.
* win32-low.c: Update.
Tom Tromey [Mon, 11 Jun 2018 17:18:51 +0000 (11:18 -0600)]
Remove ptid_build
This removes ptid_build in favor of simply calling the ptid_t
constructor directly.
gdb/ChangeLog
2018-07-03 Tom Tromey <tom@tromey.com>
* common/ptid.h (ptid_build): Don't declare.
* common/ptid.c (ptid_build): Remove.
* aix-thread.c: Update.
* bsd-kvm.c: Update.
* bsd-uthread.c: Update.
* common/agent.c: Update.
* common/ptid.c: Update.
* common/ptid.h: Update.
* corelow.c: Update.
* darwin-nat.c: Update.
* fbsd-nat.c: Update.
* gnu-nat.c: Update.
* linux-fork.c: Update.
* linux-nat.c: Update.
* linux-thread-db.c: Update.
* nat/linux-osdata.c: Update.
* nat/linux-procfs.c: Update.
* nto-procfs.c: Update.
* obsd-nat.c: Update.
* proc-service.c: Update.
* procfs.c: Update.
* ravenscar-thread.c: Update.
* remote-sim.c: Update.
* remote.c: Update.
* sol-thread.c: Update.
* target.c: Update.
* windows-nat.c: Update.
gdb/gdbserver/ChangeLog
2018-07-03 Tom Tromey <tom@tromey.com>
* linux-low.c: Update.
* lynx-low.c: Update.
* nto-low.c: Update.
* remote-utils.c: Update.
* spu-low.c: Update.
* thread-db.c: Update.
* win32-low.c: Update.
Tom Tromey [Mon, 2 Jul 2018 15:20:40 +0000 (09:20 -0600)]
Remove exit_inferior_num_silent
The sole caller of exit_inferior_num_silent was getting the inferior's
number to then use the number to look up the inferior again. I think
it's better to simply not have exit_inferior_num_silent; any potential
callers that only have the inferior's number should probably be
converted to pass the inferior itself around instead.
Tested by the buildbot.
gdb/ChangeLog
2018-07-03 Tom Tromey <tom@tromey.com>
* infrun.c (follow_exec): Use exit_inferior_silent.
* inferior.c (exit_inferior_num_silent): Remove.
* inferior.h (exit_inferior_num_silent): Don't declare.