Valgrind reports leaks like the below in various tests,
e.g. gdb.threads/attach-slow-waitpid.exp, gdb.ada/task_switch_in_core.exp, ...
Fix the leak by clearing the regcache when detaching from an inferior.
Note that these leaks are 'created' when GDB exits,
when the regcache::current_regcache is destroyed : the elements
of the forward_list are pointers, and the 'pointed to' memory is not
deleted by the forward_list destructor.
Nevertheless, fixing this leak is good as it makes a bunch of
tests 'leak clean'.
Also, it seems strange to keep a register cache for a process from
which GDB detached : it is not clear if this cache is still valid
after detach. And effectively, when clearing only the regcache,
(and not the frame cache), then the frame cache was still 'pointing'
at this regcache and was used when switching to the child process
in the test gdb.threads/watchpoint-fork.exp, which seems strange.
So, we solve the leak and avoid possible accesses to the regcache
and frame cache of the detached inferior, by clearing both the
regcache and the frame cache.
Tested on debian/amd64, natively, under Valgrind,
and with make check RUNTESTFLAGS="--target_board=native-gdbserver".
==27679== VALGRIND_GDB_ERROR_BEGIN
==27679== 1,123 (72 direct, 1,051 indirect) bytes in 1 blocks are definitely lost in loss record 2,942 of 3,400
==27679== at 0x4C2C4CC: operator new(unsigned long) (vg_replace_malloc.c:344)
==27679== by 0x5CDF71: get_thread_arch_aspace_regcache(ptid_t, gdbarch*, address_space*) (regcache.c:330)
==27679== by 0x5CE12A: get_thread_regcache (regcache.c:366)
==27679== by 0x5CE12A: get_current_regcache() (regcache.c:372)
==27679== by 0x4FF63D: post_create_inferior(target_ops*, int) (infcmd.c:452)
==27679== by 0x43AF62: core_target_open(char const*, int) (corelow.c:458)
==27679== by 0x408B68: cmd_func(cmd_list_element*, char const*, int) (cli-decode.c:1892)
...
gdb/ChangeLog
2019-02-27 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* target.c (target_detach): Clear the regcache and the
frame cache.
I tried gdbreplay yesterday, but the remotelogfile I received was made
on Windows, so the lines were terminated with \r\n rather than plain
\n.
This patch changes gdbreplay to allow \r\n line termination when
reading the log file.
gdb/gdbserver/ChangeLog
2019-02-27 Tom Tromey <tromey@adacore.com>
* gdbreplay.c (logchar): Handle \r\n.
As a follow up to the previous commit, add a test for "set
width/height -1", to make sure we don't overflow in readline with
negative values either.
gdb/testsuite/ChangeLog:
2019-02-27 Pedro Alves <palves@redhat.com>
* gdb.base/page.exp: Add tests for "set width/height -1".
When we cap the height/width sizes before passing to readline, tweak
the corresponding command variable to show "unlimited":
(gdb) set height 0x8000
(gdb) show height
Number of lines gdb thinks are in a page is unlimited.
Instead of the current output:
(gdb) set height 0x8000
(gdb) show height
Number of lines gdb thinks are in a page is 32768.
gdb/ChangeLog:
2019-02-27 Pedro Alves <palves@redhat.com>
* utils.c (set_screen_size): When we cap the height/width sizes,
tweak the corresponding command variable to show "unlimited":
gdb/testsuite/ChangeLog:
2019-02-27 Pedro Alves <palves@redhat.com>
* gdb.base/page.exp: Add tests for "set/show width/height" with
"infinite" values.
GDB calls rl_set_screen_size in readline with the current screen size,
measured in rows and columns. To represent "infinite" sizes, GDB
passes in INT_MAX; however, since rl_set_screen_size internally
multiplies the number of rows and columns, this causes a signed
integer overflow. To prevent this we can instead pass in the
approximate square root of INT_MAX (which is still reasonably large),
so that even when the number of rows and columns is "infinite" we
don't overflow.
gdb/ChangeLog:
2019-02-27 Saagar Jha <saagar@saagarjha.com>
Pedro Alves <palves@redhat.com>
* utils.c (set_screen_size): Reduce "infinite" rows and columns
before calling rl_set_screen_size.
This patch removes the non-IS_PY3K code in infpy_write_memory()
and infpy_search_memory(). In both cases, the remaining code
from these ifdefs is related to use of the PEP 3118 buffer protocol.
(Deleted code is either due to simplification or related to use of the
old buffer protocol.) PEP 3118 is sometimes referred to as the "new"
buffer protocol, though it's not that new anymore.
The link below describes new features in Python 2.6. In particular,
it says that the buffer protocol described by PEP 3118 is in Python
2.6. It also says (at the top of the page) that Python 2.6 was
released on Oct 1, 2008.
https://docs.python.org/3/whatsnew/2.6.html#pep-3118-revised-buffer-protocol
The last security release for the Python 2.6 series was 2.6.9. It was
released on Oct 29, 2013. According to this document...
https://www.python.org/download/releases/2.6.9/
...support for the 2.6 series has ended:
With the 2.6.9 release, and five years after its first release,
the Python 2.6 series is now officially retired. All official
maintenance for Python 2.6, including security patches, has ended.
For ongoing maintenance releases, please see the Python 2.7
series.
As noted earlier, Python 2.6, Python 2.7, and Python 3.X all have
support for the PEP 3118 buffer protocol. Python releases prior
to 2.6 use an older buffer protocol. Since Python 2.6 has been
retired for a good while now, it seems reasonable to me to remove
code using the older buffer protocol from GDB.
I have also simplified some of the code via use of the Py_buffer
unique_ptr specialization which I introduced in the two argument
gdb.Value constructor patch series. Therefore, there is a dependency
on patch #1 from that series.
I have tested against both Python 2.7.15 and 3.7.2. I see no
regressions among the non-racy tests. I've also verified that
PyBuffer_Release is being called when the affected functions exit
while running the tests in gdb.python/py-inferior.exp by hand. I've
also tried running valgrind on GDB while running this test, but I'm
puzzled by the results that I'm seeing - I'm seeing no additional
leaks when I comment out the Py_buffer_up lines that I introduced.
That said, I'm not seeing any leaks that obviously originate from
either infpy_write_memory() or infpy_search_memory().
gdb/ChangeLog:
* python/py-inferior.c (infpy_write_memory): Remove non-IS_PY3K
code from these functions. Remove corresponding ifdefs. Use
Py_buffer_up instead of explicit calls to PyBuffer_Release.
Remove gotos and target of gotos.
(infpy_search_memory): Likewise.
Make use of the default gdbarch method for gdbarch_dummy_id.
I have not tested this change but, by inspecting the code, I believe
the default method is equivalent to the code being deleted.
gdb/ChangeLog:
* gdb/hppa-tdep.c (hppa_dummy_id): Delete.
(hppa_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* gdb/h8300-tdep.c (h8300_unwind_pc): Delete.
(h8300_unwind_sp): Delete.
(h8300_dummy_id): Delete.
(h8300_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* gdb/ft32-tdep.c (ft32_dummy_id): Delete.
(ft32_unwind_pc): Delete.
(ft32_unwind_sp): Delete.
(ft32_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* gdb/frv-tdep.c (frv_dummy_id): Delete.
(frv_unwind_pc): Delete.
(frv_unwind_sp): Delete.
(frv_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
This change has been tested with no regressions.
gdb/ChangeLog:
* gdb/riscv-tdep.c (riscv_dummy_id): Delete.
(riscv_unwind_pc): Delete.
(riscv_unwind_sp): Delete.
(riscv_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* gdb/csky-tdep.c (csky_dummy_id): Delete.
(csky_unwind_pc): Delete.
(csky_unwind_sp): Delete.
(csky_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* gdb/cris-tdep.c (cris_dummy_id): Delete.
(cris_unwind_pc): Delete.
(cris_unwind_sp): Delete.
(cris_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
and gdbarch_unwind_pc.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* gdb/bfin-tdep.c (bfin_dummy_id): Delete.
(bfin_unwind_pc): Delete.
(bfin_gdbarch_init): Don't register deleted functions with gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* gdb/arm-tdep.c (arm_dummy_id): Delete.
(arm_unwind_pc): Delete.
(arm_unwind_sp): Delete.
(arm_gdbarch_init): Don't register deleted functions with gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted. The
only difference is that the old ARC specific methods had additional
debugging, however, this was discussed on the mailing list[1] and it
was agreed these methods could be removed.
[1] https://sourceware.org/ml/gdb-patches/2018-12/msg00386.html
gdb/ChangeLog:
* gdb/arc-tdep.c (arc_dummy_id): Delete.
(arc_unwind_pc): Delete.
(arc_unwind_sp): Delete.
(arc_gdbarch_init): Don't register deleted functions with gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id, and
gdbarch_unwind_pc.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* gdb/alpha-tdep.c (alpha_dummy_id): Delete.
(alpha_unwind_pc): Delete.
(alpha_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* gdb/aarch64-tdep.c (aarch64_dummy_id): Delete.
(aarch64_unwind_pc): Delete.
(aarch64_unwind_sp): Delete.
(aarch64_gdbarch_init): Don't register deleted functions with
gdbarch.
In 'type_align' when computing the alignment of a structure we should
not consider the alignment of static structure members, these are
usually stored outside of the structure and therefore don't have any
impact on the structures alignment requirements.
I've extended the existing alignment calculating test to compile in
both C and C++ now so that we can create structures with static
members.
gdb/ChangeLog:
* gdbtypes.c (type_align): Don't consider static members when
computing structure alignment.
gdb/testsuite/ChangeLog:
* gdb.base/align.exp: Extend to compile in both C and C++, and add
tests for structs with static members.
This commit restructures the relationship between the type_align
function and the gdbarch_type_align method.
The problem being addressed with this commit is this; previously the
type_align function was structured so that for "basic" types (int,
float, etc) the gdbarch_type_align hook was called, which for
"compound" types (arrays, structs, etc) the common type_align code has
a fixed method for how to extract a "basic" type and would then call
itself on that "basic" type.
The problem is that if an architecture wants to modify the alignment
rules for a "compound" type then this is not currently possible.
In the revised structure, all types pass through the
gdbarch_type_align method. If this method returns 0 then this
indicates that the architecture has no special rules for this type,
and GDB should apply the default rules for alignment. However, the
architecture is free to provide an alignment for any type, both
"basic" and "compound".
After this commit the default alignment rules now all live in the
type_align function, the default_type_align only ever returns 0,
meaning apply the default rules.
I've updated the 3 targets (arc, i386, and nios2) that already
override the gdbarch_type_align method to fit the new scheme.
Tested on X86-64/GNU Linux with no regressions.
gdb/ChangeLog:
* arc-tdep.c (arc_type_align): Provide alignment for basic types,
return 0 for other types.
* arch-utils.c (default_type_align): Always return 0.
* gdbarch.h: Regenerate.
* gdbarch.sh (type_align): Extend comment.
* gdbtypes.c (type_align): Add additional comments, always call
gdbarch_type_align before applying the default rules.
* i386-tdep.c (i386_type_align): Return 0 as the default rule,
generic code will then apply a suitable default.
* nios2-tdep.c (nios2_type_align): Provide alignment for basic
types, return 0 for other types.
Now that the GDB 8.3 branch has been created, we can
bump the version number.
gdb/ChangeLog:
GDB 8.3 branch created (143420fb0d):
* version.in: Bump version to 8.3.50.DATE-git.
When the target description support was added to RISC-V, the register
numbers assigned to the fflags, frm, and fcsr control registers in the
default target descriptions didn't match the register numbers used by
GDB before the target description support was added.
What this means is that if a tools exists in the wild that is using
hard-coded register number, setup to match GDB's old numbering, then
this will have been broken (for fflags, frm, and fcsr) by the move to
target descriptions. QEMU is such a tool.
There are a couple of solutions that could be used to work around this
issue:
- The user can create their own xml description file with the
register numbers setup to match their old tool, then load this by
telling GDB 'set tdesc filename FILENAME'.
- Update their old tool to use the newer default numbering scheme, or
better yet add proper target description support to their tool.
- We could have RISC-V GDB change to maintain the old defaults.
This patch changes GDB back to using the old numbering scheme.
This change is only visible to remote targets that don't supply their
own xml description file and instead rely on GDB's default numbering.
Note that even though 32bit-cpu.xml and 64bit-cpu.xml have changed,
the corresponding .c file has not, this is because the numbering added
to the registers in the xml files is number 0, this doesn't result in
any new C code being generated .
gdb/ChangeLog:
* features/riscv/32bit-cpu.xml: Add register numbers.
* features/riscv/32bit-fpu.c: Regenerate.
* features/riscv/32bit-fpu.xml: Add register numbers.
* features/riscv/64bit-cpu.xml: Add register numbers.
* features/riscv/64bit-fpu.c: Regenerate.
* features/riscv/64bit-fpu.xml: Add register numbers.
The new test case in py-value.exp fails -- the code was changed to
throw ValueError, but the test still checks for TypeError. This patch
fixes the problem.
I'm checking this in. Tested on x86-64 Fedora 29.
gdb/testsuite/ChangeLog
2019-02-26 Tom Tromey <tromey@adacore.com>
* gdb.python/py-value.exp (test_value_from_buffer): Check for
ValueError, not TypeError.
gdb/ChangeLog:
* NEWS: Mention two argument form of gdb.Value constructor.
gdb/doc/ChangeLog:
* python.texi (Values From Inferior): Document second form
of Value.__init__.
Provided a buffer BUFOBJ and a type TYPE, construct a gdb.Value object
with type TYPE, where the value's contents are taken from BUFOBJ.
E.g...
(gdb) python import struct
(gdb) python unsigned_int_type=gdb.lookup_type('unsigned int')
(gdb) python b=struct.pack('=I',0xdeadbeef)
(gdb) python v=gdb.Value(b, unsigned_int_type) ; print("%#x" % v)
0xdeadbeef
This two argument form of the gdb.Value constructor may also be used
to obtain gdb values from selected portions of buffers read with
Inferior.read_memory(). The test case (which is in a separate patch)
demonstrates this use case.
gdb/ChangeLog:
* python/py-value.c (convert_buffer_and_type_to_value): New
function.
(valpy_new): Parse arguments via gdb_PyArg_ParseTupleAndKeywords.
Add support for handling an optional second argument. Call
convert_buffer_and_type_to_value as appropriate.
This patch causes PyBuffer_Release() to be called when the associated
buffer goes out of scope. I've been using it as follows:
...
Py_buffer_up buffer_up;
Py_buffer py_buf;
if (PyObject_CheckBuffer (obj)
&& PyObject_GetBuffer (obj, &py_buf, PyBUF_SIMPLE) == 0)
{
/* Got a buffer, py_buf, out of obj. Cause it to released
when it goes out of scope. */
buffer_up.reset (&py_buf);
}
...
This snippet of code was taken directly from an upcoming patch to
python-value.c.
gdb/ChangeLog:
* python/python-internal.h (Py_buffer_deleter): New struct.
(Py_buffer_up): New typedef.
Previously if build_id_verify failed, dwz_bfd was cleared to NULL via
release(), but the BFD object was not destroyed. Use reset() with
nullptr instead to delete the BFD.
gdb/ChangeLog:
* dwarf2read.c (dwarf2_get_dwz_file): Reset dwz_bfd to nullptr
instead of releasing ownership.
When loading dwp files, we create an array of ELF sections indexed by the ELF
section index in the dwp file. The size of this array is calculated by
section_count, as returned by bfd_count_sections, plus 1 (to account for the
null section at index 0). However, when loading the bfd file, strtab/symtab
sections are not added to the list, nor do they increment section_count, so
section_count is actually smaller than the number of ELF sections.
This happens to work when using GNU dwp, which lays out .debug section first,
with sections like .shstrtab coming at the end. Other tools, like llvm-dwp, put
.strtab first, and gdb crashes when loading those dwp files.
For instance, with the current state of gdb, loading a file like this:
$ readelf -SW <file.dwp>
[ 0] <empty>
[ 1] .debug_foo PROGBITS ...
[ 2] .strtab STRTAB ...
... results in section_count = 2 (.debug is the only thing placed into
bfd->sections, so section_count + 1 == 2), and sectp->this_idx = 1 when mapping
over .debug_foo in dwarf2_locate_common_dwp_sections, which passes the
assertion that 1 < 2.
However, using a dwp file produced by llvm-dwp:
$ readelf -SW <file.dwp>
[ 0] <empty>
[ 1] .strtab STRTAB ...
[ 2] .debug_foo PROGBITS ...
... results in section_count = 2 (.debug is the only thing placed into
bfd->sections, so section_count + 1 == 2), and sectp->this_idx = 2 when mapping
over .debug_foo in dwarf2_locate_common_dwp_sections, which fails the assertion
that 2 < 2.
The assertion hit is:
gdb/dwarf2read.c:13009: internal-error: void dwarf2_locate_common_dwp_sections(bfd*, asection*, void*): Assertion `elf_section_nr < dwp_file->num_sections' failed.
This patch changes the calculation of section_count to use elf_numsections,
which should return the actual number of ELF sections.
commit 192b62ce0b ("Use class to manage
BFD reference counts") changed darwin_get_dyld_bfd to use:
+ dyld_bfd.release ();
rather than
- do_cleanups (cleanup);
However, using release here leaks the BFD. Instead, simply assigning
"sub" to "dyld_bfd" achieves what was meant.
gdb/ChangeLog
2019-02-25 Tom Tromey <tromey@adacore.com>
* solib-darwin.c (darwin_get_dyld_bfd): Don't release dyld_bfd.
Back when I proposed the '--readnever' feature, I somehow forgot or
decided not to include the bits related to gcore.in in the original
patch. This patch finally updates the gcore script to invoke GDB
using '--readnever'.
We've been carrying this patch on Fedora GDB for quite some time, and
as expected the corefiles generated by gcore on Fedora don't have
problems, which I think is the best indicator that the it's safe to
generate corefiles using '--readnever'.
gdb/ChangeLog:
2019-02-23 Sergio Durigan Junior <sergiodj@redhat.com>
* gcore.in: Add '--readnever' option when invoking GDB.
This patch fixes the copyright year range which escaped
the 2019 update, because the patch was submitted in 2018, but
only really pushed in 2019.
Pushed: https://www.sourceware.org/ml/gdb-patches/2019-02/msg00109.html
Submitted: https://www.sourceware.org/ml/gdb-patches/2018-12/msg00444.html
We normally are pretty good at remembering those little things,
but this one fell through the cracks. This commit fixes this,
by re-running the copyright.py script and checking in the changes
made by that script.
gdb/testsuite/ChangeLog:
* gdb.ada/mi_ref_changeable.exp: Update copyright year range.
* gdb.ada/mi_ref_changeable/foo_rb20_056.adb: Likewise.
* gdb.ada/mi_ref_changeable/pck.adb: Likewise.
* gdb.ada/mi_ref_changeable/pck.ads: Likewise.
* gdb.dwarf2/inlined_subroutine-inheritance.exp: Likewise.
I missed those files which need to be updated manually when I did
the copyright year range update. The copyright.py script reminds
us of that fact with the following message at the end...
REMINDER: Multiple copyright headers must be updated by hand:
gdb/doc/gdb.texinfo
gdb/doc/refcard.tex
gdb/gdbarch.sh
... and somehow I missed this. This commit makes the change for
gdb.texinfo and refcard.tex. gdbarch.sh is being updated separately
by Andrew Burgess.
gdb/doc/ChangeLog:
* gdb.texinfo: Update copyright year ranges.
* refcard.tex: Likewise.
When looking for a separate debug file that matches a given build-id,
GDB only looks in the host's debug dir (typically /usr/lib/debug). This
patch makes it look in the sysroot as well. This is to match the
behavior of GDB when using debuglink-based separate debug files,
introduced in :
402d2bfec4 ("Look for separate debug files in debug directories under a sysroot.")
In the following example, my sysroot is "/tmp/sysroot" and I am trying
to load symbols for
/tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so. This is
the current behavior:
(gdb) file /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so
Reading symbols from /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so...
Looking for separate debug info (build-id) for /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so
Trying /usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... no, unable to compute real path
<snip>
(No debugging symbols found in /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so)
With this patch:
(gdb) file /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so
Reading symbols from /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so...
Looking for separate debug info (build-id) for /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so
Trying /usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... no, unable to compute real path
Trying /tmp/sysroot/usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... yes!
Reading symbols from /tmp/sysroot/usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug...
In the original code, there is a suspicious "abfd.release ()" in
build_id_to_debug_bfd, that I don't understand. If a file with the
right name exists but its build-id note doesn't match, we release (leak)
our reference, meaning the file will stay open? I removed it in the new
code, so that the reference is dropped if we end up not using that file.
I tested briefly by corrupting a separate debug file to trigger this
code, nothing exploded.
gdb/ChangeLog:
* build-id.c (build_id_to_debug_bfd_1): New function.
(build_id_to_debug_bfd): Look for separate debug file in
sysroot.
The copyright year that gdbarch.sh places into the generated files
gdbarch.{c,h} wasn't updated at the start of the year. After this
commit the gdbarch.{c,h} files regenerate as the currently are in the
tree.
gdb/ChangeLog:
* gdbarch.sh: Update the copyright year range that is placed into
generated files.
This patch attempts to fix a bug dealing with setting breakpoints
in default symtabs that are symlinks. For example:
(gdb) list
11 GNU General Public License for more details.
12
13 You should have received a copy of the GNU General Public License
14 along with this program. If not, see <http://www.gnu.org/licenses/>. */
15
16 static int
17 foo (void)
18 {
19 return 0; /* break here */
20 }
(gdb)
21
22 int
23 main (void)
24 {
25 return foo ();
26 }
(gdb) b 19
No line 19 in the current file.
Make breakpoint pending on future shared library load? (y or [n])
The problem here is that when create_sals_line_offset sets the default
symtab, it immediately calls symtab_to_fullname, passing that fullname
to collect_symtabs_from_filename to find all matching symtabs. This
fails because we end up looking for a symtab with the name of the
actual file on disk (which is different in this case because of the
symlink) instead of the one stored in the debug info.
Since we already have the lookup name of the default symtab, use it
instead of the fullname. [This fullname thing was originally added
in 2007 in a series dealing with *displaying* absolute file names.
Clearly, this instance has nothing to do with the display of file names.]
gdb/ChangeLog
PR symtab/23853
* linespec.c (create_sals_line_offset): Search for the default
symtab's filename instead of its fullname.
gdb/testsuite/ChangeLog
PR symtab/23853
* gdb.base/symlink-sourcefile.c: New file.
* gdb.base/symlink-sourcefile.exp: New file.
I noticed a trailing "." in the @item for "show remotelogfile".
This removes it. Committing as obvious.
gdb/doc/ChangeLog
2019-02-21 Tom Tromey <tromey@adacore.com>
* gdb.texinfo (Remote Configuration): Remove trailing "." from
@item.
The GCC Guality testsuite within GCC compiles C/C++ files in GCC at
various optimization levels then debugs them in GDB, checking that
program values can be read. This is done within the dejagnu framework.
The new style options in GDB have broken many of the tests due to the
testsuite being unable to process the new control characters. The fix
in Guality is to either to improve the string matching or to disable
styling on the cli or init file (after checking gdb is recent enough
to support styling).
This fix will also need making an any other testsuites in the wild
that use GDB.
An alternative would be to automatically disable styling when using GDB
in batch mode. The reasoning here is that batch mode is only used when
automating GDB and any output will be processed later either with text
processing tools or viewed in text editors, many of these will not
correctly handle the control characters by default. This ensures GDB
continues to work as expected. Anyone who explicitly wants styling in
batch mode can enable it either in the init file or adding to the batch
file - but that would not be the standard use case.
Patch simply disables style after reading the batch command flag, before
reading in the init file or batch file.
gdb/ChangeLog:
* main.c (captured_main_1): Disable styling in batch mode.
symtab_symbol_info has a couple of messages that say "regulation
expression". I think "regular expression" was meant, so this patch
changes it.
gdb/ChangeLog
2019-02-20 Tom Tromey <tom@tromey.com>
* symtab.c (symtab_symbol_info): Fix typos.
gdb/testsuite/ChangeLog
2019-02-20 Tom Tromey <tom@tromey.com>
* gdb.base/info_qt.exp: Update.
While answering a user's question on irc, I realized that the
metasyntactic variables in "help find" are not in upper case. As you
know this is one of my pet quests, so here is a patch to fix this.
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-02-20 Tom Tromey <tromey@adacore.com>
* findcmd.c (_initialize_mem_search): Use upper case for
metasyntactic variables.
AArch64 does not define any reggroups. This causes "maintenance print
reggroups" to dump the default set (which is ok).
However, if a new group is added via an xml file, then this now becomes
the only group.
Fixes gdb.xml/tdesc-regs.exp on AArch64.
gdb/ChangeLog:
* aarch64-tdep.c (aarch64_add_reggroups): New function
(aarch64_gdbarch_init): Call aarch64_add_reggroups.
Errors that happen in nested sourced files (when a sourced file sources
another file) lead to a wrong error message, or use-after-free.
For example, if I put this in "a.gdb":
command_that_doesnt_exist
and this in "b.gdb":
source a.gdb
and try to "source b.gdb" in GDB, the result may look like this:
(gdb) source b.gdb
b.gdb:1: Error in sourced command file:
_that_doesnt_exist:1: Error in sourced command file:
Undefined command: "command_that_doesnt_exist". Try "help".
Notice the wrong file name where "a.gdb" should be. The exact result
may differ, depending on the feelings of the memory allocator.
What happens is:
- The "source a.gdb" command is saved by command_line_append_input_line
in command_line_input's static buffer.
- Since we are sourcing a file, the script_from_file function stores the
script name (a.gdb) in the source_file_name global. However, it doesn't
do a copy, it just saves a pointer to command_line_input's static buffer.
- The "command_that_doesnt_exist" command is saved by
command_line_append_input_line in command_line_input's static buffer.
Depending on what xrealloc does, source_file_name may now point to
freed memory, or at the minimum the data it was pointing to was
overwritten.
- When the error is handled in script_from_file, we dererence
source_file_name to print the name of the file in which the error
occured.
To fix it, I made source_file_name an std::string, so that keeps a copy of
the file name instead of pointing to a buffer with a too small
lifetime.
With this patch, the expected filename is printed, and no use-after-free
occurs:
(gdb) source b.gdb
b.gdb:1: Error in sourced command file:
a.gdb:1: Error in sourced command file:
Undefined command: "command_that_doesnt_exist". Try "help".
I passed explicit template parameters to make_scoped_restore
(<std::string, const std::string &>), so that the second parameter is
passed by reference and avoid a copy.
It was not as obvious as I first thought to change gdb.base/source.exp
to test this, because source commands inside sourced files are
interpreted relative to GDB's current working directory, not the
directory of the currently sourced file. As a workaround, I moved the
snippet that tests errors after the snippet that adds the source
directory to the search path. This way, the "source source-error-1.gdb"
line in source-error.exp manages to find the file.
For reference, here is what ASAN reports when use-after-free occurs:
(gdb) source b.gdb
=================================================================
==18498==ERROR: AddressSanitizer: heap-use-after-free on address 0x60c000019847 at pc 0x7f1d3645de8e bp 0x7ffdcb892e50 sp 0x7ffdcb8925c8
READ of size 6 at 0x60c000019847 thread T0
#0 0x7f1d3645de8d in printf_common /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:546
#1 0x7f1d36477175 in __interceptor_vasprintf /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1525
#2 0x5632eaffa277 in xstrvprintf(char const*, __va_list_tag*) /home/simark/src/binutils-gdb/gdb/common/common-utils.c:122
#3 0x5632eaff96d1 in throw_it /home/simark/src/binutils-gdb/gdb/common/common-exceptions.c:351
#4 0x5632eaff98df in throw_verror(errors, char const*, __va_list_tag*) /home/simark/src/binutils-gdb/gdb/common/common-exceptions.c:379
#5 0x5632eaff9a2a in throw_error(errors, char const*, ...) /home/simark/src/binutils-gdb/gdb/common/common-exceptions.c:394
#6 0x5632eafca21a in script_from_file(_IO_FILE*, char const*) /home/simark/src/binutils-gdb/gdb/cli/cli-script.c:1553
#7 0x5632eaf8a500 in source_script_from_stream /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:569
#8 0x5632eaf8a735 in source_script_with_search /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:605
#9 0x5632eaf8ab20 in source_command /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:664
#10 0x5632eafa8b4a in do_const_cfunc /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:106
#11 0x5632eafb0687 in cmd_func(cmd_list_element*, char const*, int) /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:1892
#12 0x5632ebf3dd87 in execute_command(char const*, int) /home/simark/src/binutils-gdb/gdb/top.c:630
#13 0x5632eb3b25d3 in command_handler(char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:583
#14 0x5632ebf3cf09 in read_command_file(_IO_FILE*) /home/simark/src/binutils-gdb/gdb/top.c:425
#15 0x5632eafca054 in script_from_file(_IO_FILE*, char const*) /home/simark/src/binutils-gdb/gdb/cli/cli-script.c:1547
#16 0x5632eaf8a500 in source_script_from_stream /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:569
#17 0x5632eaf8a735 in source_script_with_search /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:605
#18 0x5632eaf8ab20 in source_command /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:664
#19 0x5632eafa8b4a in do_const_cfunc /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:106
#20 0x5632eafb0687 in cmd_func(cmd_list_element*, char const*, int) /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:1892
#21 0x5632ebf3dd87 in execute_command(char const*, int) /home/simark/src/binutils-gdb/gdb/top.c:630
#22 0x5632eb3b25d3 in command_handler(char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:583
#23 0x5632eb3b2f87 in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /home/simark/src/binutils-gdb/gdb/event-top.c:770
#24 0x5632eb3b0fe1 in gdb_rl_callback_handler /home/simark/src/binutils-gdb/gdb/event-top.c:213
#25 0x5632ec1c8729 in rl_callback_read_char /home/simark/src/binutils-gdb/readline/callback.c:220
#26 0x5632eb3b0b8f in gdb_rl_callback_read_char_wrapper_noexcept /home/simark/src/binutils-gdb/gdb/event-top.c:175
#27 0x5632eb3b0da1 in gdb_rl_callback_read_char_wrapper /home/simark/src/binutils-gdb/gdb/event-top.c:192
#28 0x5632eb3b2186 in stdin_event_handler(int, void*) /home/simark/src/binutils-gdb/gdb/event-top.c:511
#29 0x5632eb3aa6a9 in handle_file_event /home/simark/src/binutils-gdb/gdb/event-loop.c:733
#30 0x5632eb3aaf41 in gdb_wait_for_event /home/simark/src/binutils-gdb/gdb/event-loop.c:859
#31 0x5632eb3a88ea in gdb_do_one_event() /home/simark/src/binutils-gdb/gdb/event-loop.c:347
#32 0x5632eb3a89bf in start_event_loop() /home/simark/src/binutils-gdb/gdb/event-loop.c:371
#33 0x5632eb76fbfc in captured_command_loop /home/simark/src/binutils-gdb/gdb/main.c:330
#34 0x5632eb772ea8 in captured_main /home/simark/src/binutils-gdb/gdb/main.c:1176
#35 0x5632eb773071 in gdb_main(captured_main_args*) /home/simark/src/binutils-gdb/gdb/main.c:1192
#36 0x5632eabfe7f9 in main /home/simark/src/binutils-gdb/gdb/gdb.c:32
#37 0x7f1d3554f222 in __libc_start_main (/usr/lib/libc.so.6+0x24222)
#38 0x5632eabfe5dd in _start (/home/simark/build/binutils-gdb/gdb/gdb+0x195d5dd)
0x60c000019847 is located 7 bytes inside of 128-byte region [0x60c000019840,0x60c0000198c0)
freed by thread T0 here:
#0 0x7f1d36502491 in __interceptor_realloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:105
#1 0x5632eaff9f47 in xrealloc /home/simark/src/binutils-gdb/gdb/common/common-utils.c:62
#2 0x5632eaff6b44 in buffer_grow(buffer*, char const*, unsigned long) /home/simark/src/binutils-gdb/gdb/common/buffer.c:40
#3 0x5632eb3b271d in command_line_append_input_line /home/simark/src/binutils-gdb/gdb/event-top.c:614
#4 0x5632eb3b28c6 in handle_line_of_input(buffer*, char const*, int, char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:654
#5 0x5632ebf402a6 in command_line_input(char const*, char const*) /home/simark/src/binutils-gdb/gdb/top.c:1252
#6 0x5632ebf3cee9 in read_command_file(_IO_FILE*) /home/simark/src/binutils-gdb/gdb/top.c:422
#7 0x5632eafca054 in script_from_file(_IO_FILE*, char const*) /home/simark/src/binutils-gdb/gdb/cli/cli-script.c:1547
#8 0x5632eaf8a500 in source_script_from_stream /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:569
#9 0x5632eaf8a735 in source_script_with_search /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:605
#10 0x5632eaf8ab20 in source_command /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:664
#11 0x5632eafa8b4a in do_const_cfunc /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:106
#12 0x5632eafb0687 in cmd_func(cmd_list_element*, char const*, int) /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:1892
#13 0x5632ebf3dd87 in execute_command(char const*, int) /home/simark/src/binutils-gdb/gdb/top.c:630
#14 0x5632eb3b25d3 in command_handler(char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:583
#15 0x5632ebf3cf09 in read_command_file(_IO_FILE*) /home/simark/src/binutils-gdb/gdb/top.c:425
#16 0x5632eafca054 in script_from_file(_IO_FILE*, char const*) /home/simark/src/binutils-gdb/gdb/cli/cli-script.c:1547
#17 0x5632eaf8a500 in source_script_from_stream /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:569
#18 0x5632eaf8a735 in source_script_with_search /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:605
#19 0x5632eaf8ab20 in source_command /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:664
#20 0x5632eafa8b4a in do_const_cfunc /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:106
#21 0x5632eafb0687 in cmd_func(cmd_list_element*, char const*, int) /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:1892
#22 0x5632ebf3dd87 in execute_command(char const*, int) /home/simark/src/binutils-gdb/gdb/top.c:630
#23 0x5632eb3b25d3 in command_handler(char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:583
#24 0x5632eb3b2f87 in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /home/simark/src/binutils-gdb/gdb/event-top.c:770
#25 0x5632eb3b0fe1 in gdb_rl_callback_handler /home/simark/src/binutils-gdb/gdb/event-top.c:213
#26 0x5632ec1c8729 in rl_callback_read_char /home/simark/src/binutils-gdb/readline/callback.c:220
#27 0x5632eb3b0b8f in gdb_rl_callback_read_char_wrapper_noexcept /home/simark/src/binutils-gdb/gdb/event-top.c:175
#28 0x5632eb3b0da1 in gdb_rl_callback_read_char_wrapper /home/simark/src/binutils-gdb/gdb/event-top.c:192
#29 0x5632eb3b2186 in stdin_event_handler(int, void*) /home/simark/src/binutils-gdb/gdb/event-top.c:511
previously allocated by thread T0 here:
#0 0x7f1d36502491 in __interceptor_realloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:105
#1 0x5632eaff9f47 in xrealloc /home/simark/src/binutils-gdb/gdb/common/common-utils.c:62
#2 0x5632eaff6b44 in buffer_grow(buffer*, char const*, unsigned long) /home/simark/src/binutils-gdb/gdb/common/buffer.c:40
#3 0x5632eb3b271d in command_line_append_input_line /home/simark/src/binutils-gdb/gdb/event-top.c:614
#4 0x5632eb3b28c6 in handle_line_of_input(buffer*, char const*, int, char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:654
#5 0x5632ebf402a6 in command_line_input(char const*, char const*) /home/simark/src/binutils-gdb/gdb/top.c:1252
#6 0x5632ebf3cee9 in read_command_file(_IO_FILE*) /home/simark/src/binutils-gdb/gdb/top.c:422
#7 0x5632eafca054 in script_from_file(_IO_FILE*, char const*) /home/simark/src/binutils-gdb/gdb/cli/cli-script.c:1547
#8 0x5632eaf8a500 in source_script_from_stream /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:569
#9 0x5632eaf8a735 in source_script_with_search /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:605
#10 0x5632eaf8ab20 in source_command /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:664
#11 0x5632eafa8b4a in do_const_cfunc /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:106
#12 0x5632eafb0687 in cmd_func(cmd_list_element*, char const*, int) /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:1892
#13 0x5632ebf3dd87 in execute_command(char const*, int) /home/simark/src/binutils-gdb/gdb/top.c:630
#14 0x5632eb3b25d3 in command_handler(char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:583
#15 0x5632eb3b2f87 in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /home/simark/src/binutils-gdb/gdb/event-top.c:770
#16 0x5632eb3b0fe1 in gdb_rl_callback_handler /home/simark/src/binutils-gdb/gdb/event-top.c:213
#17 0x5632ec1c8729 in rl_callback_read_char /home/simark/src/binutils-gdb/readline/callback.c:220
#18 0x5632eb3b0b8f in gdb_rl_callback_read_char_wrapper_noexcept /home/simark/src/binutils-gdb/gdb/event-top.c:175
#19 0x5632eb3b0da1 in gdb_rl_callback_read_char_wrapper /home/simark/src/binutils-gdb/gdb/event-top.c:192
#20 0x5632eb3b2186 in stdin_event_handler(int, void*) /home/simark/src/binutils-gdb/gdb/event-top.c:511
#21 0x5632eb3aa6a9 in handle_file_event /home/simark/src/binutils-gdb/gdb/event-loop.c:733
#22 0x5632eb3aaf41 in gdb_wait_for_event /home/simark/src/binutils-gdb/gdb/event-loop.c:859
#23 0x5632eb3a88ea in gdb_do_one_event() /home/simark/src/binutils-gdb/gdb/event-loop.c:347
#24 0x5632eb3a89bf in start_event_loop() /home/simark/src/binutils-gdb/gdb/event-loop.c:371
#25 0x5632eb76fbfc in captured_command_loop /home/simark/src/binutils-gdb/gdb/main.c:330
#26 0x5632eb772ea8 in captured_main /home/simark/src/binutils-gdb/gdb/main.c:1176
#27 0x5632eb773071 in gdb_main(captured_main_args*) /home/simark/src/binutils-gdb/gdb/main.c:1192
#28 0x5632eabfe7f9 in main /home/simark/src/binutils-gdb/gdb/gdb.c:32
#29 0x7f1d3554f222 in __libc_start_main (/usr/lib/libc.so.6+0x24222)
SUMMARY: AddressSanitizer: heap-use-after-free /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:546 in printf_common
gdb/ChangeLog:
* top.h (source_file_name): Change to std::string.
* top.c (source_file_name): Likewise.
(command_line_input): Adjust.
* cli/cli-script.c (script_from_file): Adjust.
gdb/testsuite/ChangeLog:
* gdb.base/source.exp: Move "error in sourced script" code to
the end.
* gdb.base/source-error.gdb: Move contents to
source-error-1.gdb. Add new code to source source-error-1.gdb.
* gdb.base/source-error-1.gdb: New file, from previous
source-error.gdb.
While working on the Ada task code, I noticed a few things that could
be cleaned up:
* task_list_valid_p was not set in all cases in ada_build_task_list.
This causes many needless re-fetches of the task list.
* task_list_valid_p can be bool, and various functions can also return
bool.
* Nothing checks the return value of read_known_tasks, so it can be
changed to return void.
* The call to ada_build_task_list in
ravenscar_thread_target::update_thread_list is redundant, because
this is the first thing done by iterate_over_live_ada_tasks.
Tested using the internal AdaCore test suite against a ravenscar
target.
gdb/ChangeLog
2019-02-19 Tom Tromey <tromey@adacore.com>
* ravenscar-thread.c
(ravenscar_thread_target::update_thread_list): Don't call
ada_build_task_list.
* ada-lang.h (ada_build_task_list): Don't declare.
* ada-tasks.c (struct ada_tasks_inferior_data)
<task_list_valid_p>: Now bool.
(read_known_tasks, ada_task_list_changed)
(ada_tasks_invalidate_inferior_data): Update.
(read_known_tasks_array): Return bool.
(read_known_tasks_list): Likewise.
(read_known_tasks): Return void.
(ada_build_task_list): Now static.
The code in type_align (gdbtypes.c) currently hard-codes the rules for
aligning method and member pointers. It would seem better to forward
these types through the gdbarch hook, so that an architecture could
override the alignment of these types if needed.
Only 3 architectures currently override the gdbarch alignment hook,
these are arc, i386, and nio2.
For arc and nios the alignment rules are that alignment is the minimum
of 4-bytes and the type length. As pointers are 4-bytes on these
targets, then (assuming method and members pointers are also 4-bytes)
there should be no change to the alignment after this patch.
For i386 the gdbarch alignment hook overrides for some INT and FLOAT
types only. For method and member pointers we align on the type size
still, so there should be no change to the alignment after this patch.
I tested this on x86-64 GNU Linux with no regressions.
gdb/ChangeLog:
* gdbtypes.c (type_align): Allow alignment of TYPE_CODE_METHODPTR
and TYPE_CODE_MEMBERPTR to be overridden by the gdbarch.
Valgrind reports leaks such as the below.
Fix these leaks by changing ada_tasks_pspace_data_handle
and ada_tasks_inferior_data_handle to use the 'with_cleanup' register variant.
Tested on debian/amd64 natively and under Valgrind.
==26346== 56 bytes in 1 blocks are definitely lost in loss record 631 of 3,249
==26346== at 0x4C2C4CC: operator new(unsigned long) (vg_replace_malloc.c:344)
==26346== by 0x38F911: get_ada_tasks_inferior_data(inferior*) (ada-tasks.c:281)
==26346== by 0x38FA3F: ada_tasks_invalidate_inferior_data (ada-tasks.c:1362)
==26346== by 0x38FA3F: ada_tasks_new_objfile_observer(objfile*) (ada-tasks.c:1411)
==26346== by 0x60CBC5: operator() (functional:2127)
==26346== by 0x60CBC5: notify (observable.h:106)
==26346== by 0x60CBC5: clear_symtab_users(enum_flags<symfile_add_flag>) (symfile.c:2903)
...
==26346== 104 bytes in 1 blocks are definitely lost in loss record 984 of 3,249
==26346== at 0x4C2E0BC: calloc (vg_replace_malloc.c:762)
==26346== by 0x4056F0: xcalloc (common-utils.c:84)
==26346== by 0x38F8AE: xcnew<ada_tasks_pspace_data> (poison.h:122)
==26346== by 0x38F8AE: get_ada_tasks_pspace_data(program_space*) (ada-tasks.c:253)
==26346== by 0x38FA77: ada_tasks_invalidate_pspace_data (ada-tasks.c:1354)
==26346== by 0x38FA77: ada_tasks_new_objfile_observer(objfile*) (ada-tasks.c:1394)
==26346== by 0x60CBC5: operator() (functional:2127)
==26346== by 0x60CBC5: notify (observable.h:106)
...
gdb/ChangeLog
2019-02-18 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* ada-task.c (_initialize_tasks): Use 'with_cleanup' register
variant for ada_tasks_pspace_data_handle and
ada_tasks_inferior_data_handle.
(ada_tasks_pspace_data_cleanup): New function.
(ada_tasks_inferior_data_cleanup): New function.
While working on the previous patch, I noticed that if
macro_source_fullname returned a std::string, then the callers would
be simplified. This patch implements this idea.
gdb/ChangeLog
2019-02-17 Tom Tromey <tom@tromey.com>
* macrotab.h (macro_source_fullname): Return a std::string.
* macrotab.c (macro_include, check_for_redefinition)
(macro_undef, macro_lookup_definition, foreach_macro)
(foreach_macro_in_scope): Update.
(macro_source_fullname): Return a std::string.
* macrocmd.c (show_pp_source_pos): Update.
This adds filename styling to "info macro".
gdb/ChangeLog
2019-02-17 Tom Tromey <tom@tromey.com>
* macrocmd.c (show_pp_source_pos): Style the file names.
gdb/testsuite/ChangeLog
2019-02-17 Tom Tromey <tom@tromey.com>
* gdb.base/style.exp: Use -g3 to compile when possible. Add test
for macro styling.
* gdb.base/style.c (SOME_MACRO): New macro.
The styling series introduced some new errors in the TUI -- the series
changed how source lines are allocated, without updating
tui_set_source_content_nil.
There are several failures but a typical one looks like:
==6274== Use of uninitialised value of size 8
==6274== at 0x4E4A095: wclrtoeol (in /usr/lib64/libncursesw.so.6.1)
==6274== by 0x4E47617: waddch (in /usr/lib64/libncursesw.so.6.1)
==6274== by 0x8325CB: tui_puts_internal(_win_st*, char const*, int*) (tui-io.c:393)
==6274== by 0x82E89D: tui_file::puts(char const*) (tui-file.c:39)
==6274== by 0x84BF5F: vfprintf_unfiltered(ui_file*, char const*, __va_list_tag*) (utils.c:2026)
This patch rewrites tui_set_source_content_nil, fixing the bug.
This was also reported as PR tui/24197.
Verified by running valgrind before and after on x86-64 Fedora 29.
gdb/ChangeLog
2019-02-17 Tom Tromey <tom@tromey.com>
PR tui/24197:
* tui/tui-source.c (tui_set_source_content_nil): Rewrite.
I believe this fixes all the pager output problems with styling that
Philippe pointed out, plus at least one more. The patch is somewhat
hard to reason about, so you may wish to give it a try. Even writing
the tests was hard.
This removes the style caching, because it was difficult to keep the
style cache correct in all cases. Since this would cause more style
escapes to be emitted, instead it changes fputs_styled to try to avoid
unnecessary changes.
Another bug was that the wrap buffer was not flushed in the case where
wrap_column==0. In the old (pre-patch series) code, characters were
directly emitted in this case; so flushing the wrap buffer here
restores this behavior.
On error the wrap buffer must be emptied. Otherwise, interrupting
output can leave characters in the buffer that will be emitted later.
As discussed on gdb-patches, this fixes the ada-lang.c problem where
filtered and unfiltered printing were mixed. Now user_select_syms
uses filtered printing, which is what its callees were already doing.
Finally, it was possible for source line highlighting to be garbled
(and invalid escape sequences emitted) if the pager was invoked at the
wrong spot. To fix this, the patch arranges for source line escapes
to always be emitted as a unit.
gdb/ChangeLog
2019-02-17 Tom Tromey <tom@tromey.com>
* ada-lang.c (user_select_syms): Use filtered printing.
* utils.c (wrap_style): New global.
(desired_style): Remove.
(emit_style_escape): Add stream parameter.
(set_output_style, reset_terminal_style, prompt_for_continue):
Update.
(flush_wrap_buffer): Only flush gdb_stdout.
(wrap_here): Set wrap_style.
(fputs_maybe_filtered): Clear the wrap buffer on exception. Don't
treat escape sequences as a character. Change when wrap buffer is
flushed.
(fputs_styled): Do not set the output style when the default is
requested.
* ui-style.h (struct ui_file_style) <is_default>: New method.
* source.c (print_source_lines_base): Emit escape sequences in one
piece.
gdb/testsuite/ChangeLog
2019-02-17 Tom Tromey <tom@tromey.com>
* gdb.base/style.exp: Add line-wrapping tests.
* gdb.base/page.exp: Add test for quitting during pagination.
This commit enhances type_align to handle TYPE_CODE_RANGE types
the same as integers and enums, rather than returning zero,
which means for this function that it could not determine its
alignment.
gdb/ChangeLog:
* gdbtypes.c (type_align): Handle TYPE_CODE_RANGE the same as
integers and enumeration types.
Tested on x86_64-linux. Also tested on a variety of platforms
(with CPUs being ARM, AArch64, Leon3 (SPARC-like), PowerPC,
PowerPC64, RV64, Visium, x86, x86_64).
Trying to print a packed array sometimes leads to a crash (see
attached testcase for an example of when this happens):
| (gdb) p bad
| [1] 65571 segmentation fault gdb -q foo
Variable "bad" is declared in the debug information as an array where
the array's type name has an XPnnn suffix:
| .uleb128 0xc # (DIE (0x566) DW_TAG_typedef)
| .long .LASF200 # DW_AT_name: "pck__t___XP1"
| [loc info attributes snipped]
| .long 0x550 # DW_AT_type
| .byte 0x1 # DW_AT_alignment
The signals to GDB that the debugging information follows a GNAT encoding
used for packed arrays, and an in order to decode it, we need to find
the type whose name is the same minus the "___XPnnn" suffix: "pck__t".
For that, we make a call to ada-lang.c::standard_lookup, which is
a simple function which essentially does:
| /* Return the result of a standard (literal, C-like) lookup of NAME in
| given DOMAIN, visible from lexical block BLOCK. */
|
| [...]
| sym = lookup_symbol_in_language (name, block, domain, language_c, 0);
Unfortunately for us, while the intent of this call was to perform
an exact-match lookup, in our case, it returns ... type pck__t___XP1
instead! In other words, it finds itself back. The reason why it finds
this type is a confluence of two factors:
(1) Forcing the lookup into language_c currently does not affect
how symbol matching is done anymore, because we look at the symbol's
language to determine which kind of matching should be done;
(2) The lookup searches the local context (via block) first, beforei
doing a more general lookup. And looking at the debug info for
the main subprogram, we see that type "pck__t" is not declared
there, only in the debug info for pck.ads. In other words,
there is no way that we accidently find "pck__t" by random chance.
I believe Pedro added a new function called ada_lookup_encoded_symbol
for that specific purpose, so I started by replacing the lookup
by language above by this. Unfortunately, still no joy.
This was because, even though ada_lookup_encoded_symbol puts angle-
brackets around the search name to signal that we want a verbatim
search, we end up losing that information in the function called
to compare a symbol with the search name:
| static bool
| do_full_match (const char *symbol_search_name,
| const lookup_name_info &lookup_name,
| completion_match_result *comp_match_res)
| {
| return full_match (symbol_search_name, ada_lookup_name (lookup_name));
^^^^^^^^^^^^^^^
|
<=> lookup_name.m_ada.m_encoded_name
(no angle brackets)
The way I fixed this was by introducing a new function called
do_exact_match, and then adjust ada_get_symbol_name_matcher to
return that function when seeing that we have a verbatim non-wild-match
search.
As it happens, this fixes an incorrect test in gdb.ada/homony.exp,
where we were inserting a breakpoint on a symbol using the angle-brackets
notation, and got 2 locations for that breakpoint...
(gdb) b <homonym__get_value>
Breakpoint 1 at 0x4029fc: <homonym__get_value>. (2 locations)
... each location being in a different function:
(gdb) info break
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x00000000004029fc in homonym.get_value
at /[...]/homonym.adb:32
1.2 y 0x0000000000402a3a in homonym.get_value
at /[...]/homonym.adb:50
(gdb) x /i 0x00000000004029fc
0x4029fc <homonym__get_value+8>: movl $0x1d,-0x4(%rbp)
(gdb) x /i 0x0000000000402a3a
0x402a3a <homonym__get_value__2+8>: movl $0x11,-0x4(%rbp)
Since we used angle-brackets, we shouldn't be matching the second one,
something this patch fixes.
gdb/ChangeLog:
* ada-lang.c (standard_lookup): Use ada_lookup_encoded_symbol
instead of lookup_symbol_in_language
(do_exact_match): New function.
(ada_get_symbol_name_matcher): Return do_exact_match when
doing a verbatim match.
gdb/testsuite/ChangeLog:
* gdb.ada/big_packed_array: New testcase.
* gdb.ada/homonym.exp: Fix incorrect expected output for
"break <homonym__get_value>" test.
Tested on x86_64-linux.
ravenscar-thread.c intercepts resume and wait target requests and
replaces the requested ptid with the ptid of the underlying CPU.
However, this is incorrect when a request is made with a wildcard
ptid.
This patch adds a special case to ravenscar-thread.c for
minus_one_ptid. I don't believe a special case for process wildcards
is necessary, so I have not added that.
Joel's description explains the bug well:
At the user level, we noticed the issue because we had a test were
we insert a breakpoint one some code which is only run from, say,
CPU #2, whereas we unfortunately resumed the execution after having
stopped somewhere in CPU #1. As a result, we sent an order to resume
CPU #1, which starves CPU #2 forever, because the code in CPU #1
waits for some of the Ada tasks allocated to CPU #2 (and we never
reach our breakpoint either).
gdb/ChangeLog
2019-02-15 Tom Tromey <tromey@adacore.com>
* ravenscar-thread.c (ravenscar_thread_target::resume)
(ravenscar_thread_target::wait): Special case wildcard requests.
This changes ravenscar-thread.c to make it ready for multi-target.
This is done by moving globals into the target, and then arranging to
allocate the target with "new" and delete the target in its "close"
method.
gdb/ChangeLog
2019-02-15 Tom Tromey <tromey@adacore.com>
* ravenscar-thread.c (base_ptid): Remove.
(struct ravenscar_thread_target) <close>: New method.
<m_base_ptid>: New member.
<update_inferior_ptid, active_task, task_is_currently_active,
runtime_initialized>: Declare methods.
<ravenscar_thread_target>: Add constructor.
(ravenscar_thread_target::task_is_currently_active)
(ravenscar_thread_target::update_inferior_ptid)
(ravenscar_runtime_initialized): Rename. Now methods.
(ravenscar_thread_target::resume, ravenscar_thread_target::wait)
(ravenscar_thread_target::update_thread_list): Update.
(ravenscar_thread_target::active_task): Now method.
(ravenscar_thread_target::store_registers)
(ravenscar_thread_target::prepare_to_store)
(ravenscar_thread_target::prepare_to_store)
(ravenscar_thread_target::mourn_inferior): Update.
(ravenscar_inferior_created): Use "new" to create target.
(ravenscar_thread_target::get_ada_task_ptid): Update.
(_initialize_ravenscar): Don't initialize base_ptid.
(ravenscar_ops): Remove global.
This adds a push_target overload that takes a "target_ops_up &&".
This removes some calls to release a target_ops_up, and makes the
intent here clearer.
gdb/ChangeLog
2019-02-15 Tom Tromey <tromey@adacore.com>
* target.h (push_target): Declare new overload.
* target.c (push_target): New overload, taking an rvalue reference.
* remote.c (remote_target::open_1): Use push_target overload.
* corelow.c (core_target_open): Use push_target overload.
This changes some functions in ravenscar-thread.c to return "bool"
rather than int, where appropriate, and also changes "(void)" to "()".
gdb/ChangeLog
2019-02-15 Tom Tromey <tromey@adacore.com>
* ravenscar-thread.c (is_ravenscar_task)
(ravenscar_task_is_currently_active): Return bool.
(ravenscar_update_inferior_ptid, get_running_thread_msymbol)
(_initialize_ravenscar): Remove "(void)".
(has_ravenscar_runtime, ravenscar_runtime_initialized): Likewise.
Return bool.
This fixes some incorrect formatting in ravenscar-thread.c.
gdb/ChangeLog
2019-02-15 Tom Tromey <tromey@adacore.com>
* ravenscar-thread.c (ravenscar_runtime_initializer)
(has_ravenscar_runtime, get_running_thread_id)
(ravenscar_thread_target::resume): Fix indentation.
This turns ravenscar_arch_ops into an abstract base class and updates
all the places where it is used. This is an improvement because it
avoids any possibility of forgetting to set one of the function
pointers. It also makes clear that these functions aren't intended to
be changed dynamically.
This version of the patch removes the prepare_to_store method, as it
is unused, and it is easy enough to add if it is ever needed.
gdb/ChangeLog
2019-02-15 Tom Tromey <tromey@adacore.com>
* sparc-ravenscar-thread.c (struct sparc_ravenscar_ops): Derive
from ravenscar_arch_ops.
(sparc_ravenscar_ops::fetch_registers)
(sparc_ravenscar_ops::store_registers): Now methods.
(sparc_ravenscar_prepare_to_store): Remove.
(sparc_ravenscar_ops): Redefine.
* ravenscar-thread.h (struct ravenscar_arch_ops): Add virtual
methods and destructor. Remove members.
* ravenscar-thread.c (ravenscar_thread_target::fetch_registers)
(ravenscar_thread_target::store_registers)
(ravenscar_thread_target::prepare_to_store): Update.
* ppc-ravenscar-thread.c (ppc_ravenscar_generic_prepare_to_store):
Remove.
(struct ppc_ravenscar_powerpc_ops): Derive from
ravenscar_arch_ops.
(ppc_ravenscar_powerpc_ops::fetch_registers)
(ppc_ravenscar_powerpc_ops::store_registers): Now methods.
(ppc_ravenscar_powerpc_ops): Redefine.
(struct ppc_ravenscar_e500_ops): Derive from ravenscar_arch_ops.
(ppc_ravenscar_e500_ops::fetch_registers)
(ppc_ravenscar_e500_ops::store_registers): Now methods.
(ppc_ravenscar_e500_ops): Redefine.
* aarch64-ravenscar-thread.c
(aarch64_ravenscar_generic_prepare_to_store): Remove.
(struct aarch64_ravenscar_ops): Derive from ravenscar_arch_ops.
(aarch64_ravenscar_fetch_registers)
(aarch64_ravenscar_store_registers): Now methods.
(aarch64_ravenscar_ops): Redefine.
This changes some code in ravenscar-thread.c to use scoped_restore. I
am not sure if it matters in practice, but this makes these methods
exception-safe in case the methods lower in the target stack can
throw.
gdb/ChangeLog
2019-02-15 Tom Tromey <tromey@adacore.com>
* ravenscar-thread.c (ravenscar_thread_target::stopped_by_sw_breakpoint)
(ravenscar_thread_target::stopped_by_hw_breakpoint)
(ravenscar_thread_target::stopped_by_watchpoint)
(ravenscar_thread_target::stopped_data_address)
(ravenscar_thread_target::core_of_thread): Use scoped_restore.
Phillipe noticed that create_ada_exception_catchpoint was not freeing
the "addr_string" memory:
==14141== 114 bytes in 4 blocks are definitely lost in loss record 1,054 of 3,424
==14141== at 0x4C2BE6D: malloc (vg_replace_malloc.c:309)
==14141== by 0x405107: xmalloc (common-utils.c:44)
==14141== by 0x7563F9: xstrdup (xstrdup.c:34)
==14141== by 0x381B21: ada_exception_sal (ada-lang.c:13217)
==14141== by 0x381B21: create_ada_exception_catchpoint(gdbarch*, ada_exception_catchpoint_kind, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int, int, int) (ada-lang.c:13251)
==14141== by 0x3820A8: catch_ada_exception_command(char const*, int, cmd_list_element*) (ada-lang.c:13285)
==14141== by 0x3F4828: cmd_func(cmd_list_element*, char const*, int) (cli-decode.c:1892)
This patch fixes the problem by changing ada_exception_sal to return a
std::string via its out parameter.
gdb/ChangeLog
2019-02-15 Philippe Waroquiers <philippe.waroquiers@skynet.be>
Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_exception_sal): Change addr_string to a
std::string.
(create_ada_exception_catchpoint): Update.
Philippe noticed a memory leak coming from ada_catchpoint_location --
it was not freeing the "function_name" member from its base class:
==14141== 114 bytes in 4 blocks are definitely lost in loss record 1,055 of 3,424
==14141== at 0x4C2BE6D: malloc (vg_replace_malloc.c:309)
==14141== by 0x405107: xmalloc (common-utils.c:44)
==14141== by 0x7563F9: xstrdup (xstrdup.c:34)
==14141== by 0x3B82B3: set_breakpoint_location_function(bp_location*, int) (breakpoint.c:7156)
==14141== by 0x3C112B: add_location_to_breakpoint(breakpoint*, symtab_and_line const*) (breakpoint.c:8609)
==14141== by 0x3C127A: init_raw_breakpoint(breakpoint*, gdbarch*, symtab_and_line, bptype, breakpoint_ops const*) (breakpoint.c:7187)
==14141== by 0x3C1B52: init_ada_exception_breakpoint(breakpoint*, gdbarch*, symtab_and_line, char const*, breakpoint_ops const*, int, int, int) (breakpoint.c:11262)
==14141== by 0x381C2E: create_ada_exception_catchpoint(gdbarch*, ada_exception_catchpoint_kind, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int, int, int) (ada-lang.c:13255)
This patch fixes the problem by further C++-ifying bp_location. In
particular, bp_location_ops is now removed, and the "dtor" function
pointer is replaced with an ordinary destructor.
gdb/ChangeLog
2019-02-15 Philippe Waroquiers <philippe.waroquiers@skynet.be>
Tom Tromey <tromey@adacore.com>
* breakpoint.c (~bp_location): Rename from bp_location_dtor.
(bp_location_ops): Remove.
(base_breakpoint_allocate_location): Update.
(free_bp_location): Update.
* ada-lang.c (class ada_catchpoint_location)
<ada_catchpoint_location>: Remove ops parameter.
(ada_catchpoint_location_dtor): Remove.
(ada_catchpoint_location_ops): Remove.
(allocate_location_exception): Update.
* breakpoint.h (struct bp_location_ops): Remove.
(class bp_location) <bp_location>: Remove bp_location_ops
parameter.
<~bp_location>: Add destructor.
<ops>: Remove.
..., which is not defined in GNU/Hurd systems, and so commit
94585166df "Extended-remote follow-exec" caused:
[...]/gdb/remote.c: In member function 'void remote_target::remote_parse_stop_reply(const char*, stop_reply*)':
[...]/gdb/remote.c:7343:22: error: 'PATH_MAX' was not declared in this scope
char pathname[PATH_MAX];
^~~~~~~~
gdb/
* remote.c (remote_target::remote_parse_stop_reply): Avoid using
'PATH_MAX'.
Hurd's commit baf7e5c8ce176aead15c2559952d8bdf0da41ffd "hurd: Use polymorphic
port types to return some rights" causes in the GDB build:
/usr/bin/ld: process_reply_S.o: in function `_Xproc_pid2proc_reply':
[...]/gdb/process_reply_S.c:754: undefined reference to `S_proc_pid2proc_reply'
/usr/bin/ld: [...]/gdb/process_reply_S.c:730: undefined reference to `S_proc_pid2proc_reply'
/usr/bin/ld: process_reply_S.o: in function `_Xproc_task2proc_reply':
[...]/gdb/process_reply_S.c:589: undefined reference to `S_proc_task2proc_reply'
/usr/bin/ld: [...]/gdb/process_reply_S.c:565: undefined reference to `S_proc_task2proc_reply'
/usr/bin/ld: process_reply_S.o: in function `_Xproc_getmsgport_reply':
[...]/gdb/process_reply_S.c:204: undefined reference to `S_proc_getmsgport_reply'
/usr/bin/ld: [...]/gdb/process_reply_S.c:180: undefined reference to `S_proc_getmsgport_reply'
collect2: error: ld returned 1 exit status
gdb/
* gnu-nat.c (S_proc_getmsgport_reply, S_proc_task2proc_reply)
(S_proc_pid2proc_reply): Adjust to Hurd "proc" interface changes.
... that appeared with 9bf2a70066
"-Wwrite-strings: Remove -Wno-write-strings".
gdb/
* gnu-nat.c (gnu_write_inferior, parse_int_arg, _parse_bool_arg)
(check_empty): Use "const char *".
..., that is commit 00431a78b2 causing:
[...]/gdb/gnu-nat.c: In member function 'virtual void gnu_nat_target::detach(inferior*, int)':
[...]/gdb/gnu-nat.c:2284:23: error: invalid conversion from 'int' to 'inferior*' [-fpermissive]
detach_inferior (pid);
^
In file included from [...]/gdb/gnu-nat.c:61:0:
[...]/gdb/inferior.h:523:13: note: initializing argument 1 of 'void detach_inferior(inferior*)'
extern void detach_inferior (inferior *inf);
^~~~~~~~~~~~~~~
Fixed by inlining the removed code.
gdb/
* gnu-nat.c (gnu_nat_target::detach): Instead of
'detach_inferior (pid)' call
'detach_inferior (find_inferior_pid (pid))'.
..., that is commit f6ac5f3d63 causing:
In file included from [...]/gdb/gnu-nat.c:24:0:
[...]/gdb/gnu-nat.h:123:1: error: expected class-name before '{' token
{
^
[...]/gdb/gnu-nat.h:128:16: error: 'inferior' has not been declared
void detach (inferior *, int) override;
^~~~~~~~
[...]/gdb/gnu-nat.h:132:8: error: use of enum 'target_xfer_status' without previous declaration
enum target_xfer_status xfer_partial (enum target_object object,
^~~~~~~~~~~~~~~~~~
[...]/gdb/gnu-nat.h:132:46: error: use of enum 'target_object' without previous declaration
enum target_xfer_status xfer_partial (enum target_object object,
^~~~~~~~~~~~~
[...]/gdb/gnu-nat.h:124:8: error: 'void gnu_nat_target::attach(const char*, int)' marked 'override', but does not override
void attach (const char *, int) override;
^~~~~~
[...]
[...]/gdb/gnu-nat.c: In member function 'virtual void gnu_nat_target::detach(inferior*, int)':
[...]/gdb/gnu-nat.c:2286:34: error: 'ops' was not declared in this scope
inf_child_maybe_unpush_target (ops);
^~~
[...]/gdb/gnu-nat.c:2286:34: note: suggested alternative: 'open'
inf_child_maybe_unpush_target (ops);
^~~
open
[...]/gdb/gnu-nat.c:2286:3: error: 'inf_child_maybe_unpush_target' was not declared in this scope
inf_child_maybe_unpush_target (ops);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[...]/gdb/gnu-nat.c:2286:3: note: suggested alternative: 'maybe_unpush_target'
inf_child_maybe_unpush_target (ops);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
maybe_unpush_target
[...]/gdb/i386-gnu-nat.c:200:1: warning: 'void gnu_store_registers(target_ops*, regcache*, int)' defined but not used [-Wunused-function]
gnu_store_registers (struct target_ops *ops,
^~~~~~~~~~~~~~~~~~~
[...]/gdb/i386-gnu-nat.c:109:1: warning: 'void gnu_fetch_registers(target_ops*, regcache*, int)' defined but not used [-Wunused-function]
gnu_fetch_registers (struct target_ops *ops,
^~~~~~~~~~~~~~~~~~~
[...]
/usr/bin/ld: i386-gnu-nat.o:(.data.rel+0x0): undefined reference to `vtable for i386_gnu_nat_target'
collect2: error: ld returned 1 exit status
gdb/
* gnu-nat.c (gnu_nat_target::detach): Instead of
'inf_child_maybe_unpush_target (ops)' call 'maybe_unpush_target'.
* gnu-nat.h: #include "inf-child.h".
* i386-gnu-nat.c (gnu_fetch_registers): Rename/move to
'i386_gnu_nat_target::fetch_registers'.
(gnu_store_registers): Rename/move to
'i386_gnu_nat_target::store_registers'.
In file included from ./nm.h:25:0,
from [...]/gdb/defs.h:423,
from [...]/gdb/gdb.c:19:
[...]/gdb/regcache.h:35:46: warning: 'get_thread_regcache' initialized and declared 'extern'
extern struct regcache *get_thread_regcache (thread_info *thread);
^~~~~~~~~~~
[...]/gdb/regcache.h:35:46: error: 'regcache* get_thread_regcache' redeclared as different kind of symbol
[...]
[...]/gdb/gdbarch.h:1203:69: error: 'thread_info' is not a type
extern LONGEST gdbarch_get_syscall_number (struct gdbarch *gdbarch, thread_info *thread);
^~~~~~~~~~~
Fixed with a different (self-contained, more maintainable?) approach compared
to what has been done in commit 7aabaf9d4a
"Create private_thread_info hierarchy", and commit
75cbc781e3 "gdb: For macOS, s/thread_info/struct
thread_info/". We don't want to change all the GDB code to everywhere use
'class thread_info' or 'struct thread_info' instead of plain 'thread_info'.
gdb/
* config/i386/nm-i386gnu.h: Don't "#include" any files.
* gnu-nat.h (mach_thread_info): New function.
* gnu-nat.c (thread_takeover_sc_cmd): Use it.
Using the gdb.ada/call_pn.exp testcase, and running it by hand on
riscv64-elf, we get the following error:
(gdb) call pn(55)
Could not compute alignment of type
The problem occurs because the parameter's type is a TYPE_CODE_RANGE,
and that type code is not handled by riscv_type_alignment. So this patch
fixes the issue by handling TYPE_CODE_RANGE the same way we handle other
integral types.
gdb/ChangeLog:
* riscv-rdep.c (riscv_type_alignment): Handle TYPE_CODE_RANGE.
Tested on riscv64-elf using AdaCore's testsuite.
This is a followup on a recent patch which, among other things
introduced the exit notification of the main thread in order
to be symetrical with the fact that a thread notification was
emitted before signaling its creation.
This patch takes the opposite approach of removing both creation
and exit notifications for that main thread, which is consistent
with what is done on other platforms such as GNU/Linux for instance.
gdb/ChangeLog
* windows-nat.c (windows_add_thread): Add new parameter
"main_thread_p" with default value set to false. Update
function documentation as well as all callers.
(windows_delete_thread): Likewise.
(fake_create_process): Update call to windows_add_thread.
(get_windows_debug_event) <CREATE_THREAD_DEBUG_EVENT>
<CREATE_PROCESS_DEBUG_EVENT>: Likewise.
<EXIT_THREAD_DEBUG_EVENT, EXIT_PROCESS_DEBUG_EVENT>: Update
call to windows_delete_thread.
Tested on x86-windows (MinGW) using AdaCore's testsuite.
gdb/testsuite/ChangeLog
2019-02-12 Weimin Pan <weimin.pan@oracle.com>
PR breakpoints/21870
* gdb.arch/aarch64-dbreg-contents.exp: New file.
* gdb.arch/aarch64-dbreg-contents.c: New file.
Object file paths passed to find_separate_debug_file are always
canonical paths with symbolic links resolved. If a sysroot path
traverses a symbolic link, it will not match the object file paths.
Generate a canonical version of the sysroot directory. If it is
valid, use it instead of gdb_sysroot with child_path to determine if
an object file is under a system root.
gdb/ChangeLog:
* symfile.c (find_separate_debug_file): Use canonical path of
sysroot with child_path instead of gdb_sysroot if it is valid.
This fixes the case where the sysroot happens to end in a trailing
'/'. Note that the path returned from child_path always skips over
the directory separator at the start of the base path, so a separator
must always be explicitly added before the base path.
gdb/ChangeLog:
* symfile.c (find_separate_debug_file): Use child_path to
determine if an object file is under a sysroot.
child_path returns a pointer to the first component in a child path
that comes after a parent path. This does not depend on trying to
stat() the paths since they may describe remote paths but instead
relies on filename parsing. The function requires that the child path
describe a filename that contains at least one component below the
parent path and returns a pointer to the first component.
gdb/ChangeLog:
* Makefile.in (SUBDIR_UNITTESTS_SRCS): Add
unittests/child-path-selftests.c.
* common/pathstuff.c (child_path): New function.
* common/pathstuff.h (child_path): New prototype.
* unittests/child-path-selftests.c: New file.
When an object file is present in a system root, GDB currently looks
for separate debug files under the global debugfile directories. For
example, if the sysroot is set to "/myroot" and hte global debugfile
directory is set to "/usr/lib/debug", GDB will look for a separate
debug file for "/myroot/lib/libc.so.7" in the following paths:
/myroot/lib/libc.so.7.debug
/myroot/lib/.debug/libc.so.7.debug
/usr/lib/debug//myroot/lib/libc.so.7.debug
/usr/lib/debug/lib/libc.so.7.debug
However, some system roots include a full system installation
including a nested global debugfile directory under the sysroot. This
patch adds an additional check to support such systems. In the
example above the additional path searched is:
/myroot/usr/lib/debug/lib/libc.so.7.debug
To try to preserve existing behavior as much as possible, this new
path is searched last for each global debugfile directory.
gdb/ChangeLog:
* symfile.c (find_separate_debug_file): Look for separate debug
files in debug directories under the sysroot.
Note that print_msymbol_info does not (yet?) print data msymbol
using variable_name_style, as otherwise 'info variables'
would show the non debugging symbols in variable name style,
but 'real' variables would be not styled.
2019-02-12 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* symtab.h (struct minimal_symbol data_p): New const method.
(struct minimal_symbol text_p): Likewise.
* symtab.c (output_source_filename): Use file name style
to print file name.
(print_symbol_info): Likewise.
(print_msymbol_info): Use address style to print addresses.
Use function name style to print executable text symbols.
(expand_symtab_containing_pc): Use data_p.
(find_pc_sect_compunit_symtab): Likewise.
Note that ada-typeprint.c print_func_type is called with
types representing functions and is also called to print
a function NAME together with its type. In such a case, the function
name will be printed using function name style.
Similarly, c_print_type_1 is called to print a type, optionally
with the name of an object of this type in the VARSTRING arg.
So, c_print_type_1 uses function name style to print varstring
when the type code indicates that c_print_type_1 TYPE is some
'real code'.
gdb/ChangeLog
2019-02-12 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* ada-typeprint.c (print_func_type): Print function name
style to print function name.
* c-typeprint.c (c_print_type_1): Likewise.
Checking the syscall number when stopped on entry/exit relies on checking
the value in register X8.
However, on exit from an execve syscall, the registers will all be cleared.
Given this is only checked on syscall entry/exit, then a cleared register
state either means execve exit or syscall 0 (io_setup) entry with invalid
parameters and an invalid FR and LR, which in reality should never happen.
Use this to detect execve exit.
Move function to allow use of aarch64_sys_execve enum, and use newer
regcache functions.
Fixes gdb.base/catch-syscall.exp on Aarch64.
gdb/ChangeLog:
* aarch64-linux-tdep.c (aarch64_linux_get_syscall_number): Check
for execve.
Valgrind detects a bunch of leaks in several tests, such as:
==22905== 40 (24 direct, 16 indirect) bytes in 1 blocks are definitely lost in loss record 531 of 3,268
==22905== at 0x4C2C4CC: operator new(unsigned long) (vg_replace_malloc.c:344)
==22905== by 0x5893AD: get_type_stack() (parse.c:1509)
==22905== by 0x3F4EAD: c_yyparse() (c-exp.y:1223)
==22905== by 0x3F71BC: c_parse(parser_state*) (c-exp.y:3308)
==22905== by 0x588CEA: parse_exp_in_context_1(char const**, unsigned long, block const*, int, int, int*) [clone .constprop.89] (parse.c:1205)
==22905== by 0x588FA1: parse_exp_in_context (parse.c:1108)
==22905== by 0x588FA1: parse_exp_1 (parse.c:1099)
==22905== by 0x588FA1: parse_expression(char const*) (parse.c:1247)
...
==22395== 456 (168 direct, 288 indirect) bytes in 7 blocks are definitely lost in loss record 2,658 of 2,978
==22395== at 0x4C2C4CC: operator new(unsigned long) (vg_replace_malloc.c:344)
==22395== by 0x5893AD: get_type_stack() (parse.c:1509)
==22395== by 0x3F4ECF: c_yyparse() (c-exp.y:1230)
==22395== by 0x3F71BC: c_parse(parser_state*) (c-exp.y:3308)
==22395== by 0x588CEA: parse_exp_in_context_1(char const**, unsigned long, block const*, int, int, int*) [clone .constprop.89] (parse.c:1205)
==22395== by 0x588FA1: parse_exp_in_context (parse.c:1108)
==22395== by 0x588FA1: parse_exp_1 (parse.c:1099)
==22395== by 0x588FA1: parse_expression(char const*) (parse.c:1247)
==22395== by 0x67BB9D: whatis_exp(char const*, int) (typeprint.c:515)
...
==22395== VALGRIND_GDB_ERROR_BEGIN
==22395== 144 (24 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 1,016 of 2,978
==22395== at 0x4C2C4CC: operator new(unsigned long) (vg_replace_malloc.c:344)
==22395== by 0x5893AD: get_type_stack() (parse.c:1509)
==22395== by 0x3F4E8A: c_yyparse() (c-exp.y:1217)
==22395== by 0x3F71BC: c_parse(parser_state*) (c-exp.y:3308)
==22395== by 0x588CEA: parse_exp_in_context_1(char const**, unsigned long, block const*, int, int, int*) [clone .constprop.89] (parse.c:1205)
==22395== by 0x588FA1: parse_exp_in_context (parse.c:1108)
==22395== by 0x588FA1: parse_exp_1 (parse.c:1099)
==22395== by 0x588FA1: parse_expression(char const*) (parse.c:1247)
==22395== by 0x67BB9D: whatis_exp(char const*, int) (typeprint.c:515)
...
Fix these by storing the allocated type_stack in the cpstate->type_stacks
vector.
Tested on debian/amd64, natively and under valgrind.
gdb/ChangeLog
2019-02-10 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* c-exp.y (direct_abs_decl): Use emplace_back to record the
type_stack.
Consider the following variable, which is a string whose value
is not known at compile time, because it is the return value
from a function call (Get_Name):
A : String := Get_Name;
If one tries to create a varobj for that variable, everything works
as expected:
| (gdb) -var-create a * a
| ^done,name="a",numchild="19",value="[19] \"Some kind of string\"",type="<ref> array (1 .. 19) of character",thread-id="1",has_more="0"
However, try then to request an update, regardless of whether the string
has changed or not, and we get a crash:
| -var-update a
| ~"/[...]/gdb/varobj.c:1379: internal-error: bool install_new_value(varobj*, value*, bool): Assertion `!value_lazy (var->value.get ())' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable.\nQuit this debugging session? (y or n) "
When the varobj gets created (-var-create), the expression is evaluated
and transformed into a value. The debugging information describes our
variables as a reference to an array of characters, so our value has
the corresponding type. We then call varobj.c::install_new_value
to store that value inside our varobj, and we see that this function
pretty starts by determining weither our varobj is changeable, via:
| changeable = varobj_value_is_changeable_p (var);
(where 'var' is the varobj we are building, and where the function
varobj_value_is_changeable_p simply dispatches to the Ada version
of this routine: ada_value_is_changeable_p).
At this point, the varobj doesn't have a value, yet, but it does
have a type which was provided by varobj_create a little bit before
install_new_value was called. So ada_value_is_changeable_p uses that
to determine whether or not our type is changeable.
Since our type is a reference to an array, and that the value of
such objects is displayed as if there weren't a reference, it means
that our object is changeable -- in other words, if an element of
the string changes, then the "value" field of the varobj will change
accordingly. But unfortunately, ada_value_is_changeable_p mistakenly
returns false, because it is missing the handling of reference types.
As a consequence of this, install_new_value doesn't feel it is
necessary to fetch the value's contents, as explained by the following
comment inside that function:
/* The new value might be lazy. If the type is changeable,
that is we'll be comparing values of this type, fetch the
value now. Otherwise, on the next update the old value
will be lazy, which means we've lost that old value. */
This means that a lazy value gets installed inside our varobj
as a result of the mistake in ada_value_is_changeable_p.
Another important detail is that, after determining whether
our varobj is changeable or not, it then purposefully removes
the reference layer from our value:
/* We are not interested in the address of references, and given
that in C++ a reference is not rebindable, it cannot
meaningfully change. So, get hold of the real value. */
if (value)
value = coerce_ref (value);
The consequence of those two facts on shows up only later, when
the user requests an update (-var-update). When doing so, GDB
evaluates the expression again into a value which is once more
a reference to a string, and then calls install_new_value again
to install the new value and report any changes. This time around,
the call to...
| changeable = varobj_value_is_changeable_p (var);
... now gets a varobj which has a value, and one which had the reference
layer removed! So, this time, we classify the varobj correctly, and
say it is changeable. And because it is changeable, we then go into
the section of code in install_new_value which checks for changes,
where we need the varobj's value to not be lazy, as explained by
the comment we quoted above. That's what the assertion was about.
This patch fixes the issues by teaching ada_value_is_changeable_p
to ignore reference layers when evaluating a given varobj's type.
gdb/ChangeLog:
* ada-varobj.c (ada_value_is_changeable_p): Add handling of
TYPE_CODE_REF types.
gdb/testsuite/ChangeLog:
* gdb.ada/mi_ref_changeable: New testcase.
Prior to this patch, this testcase reports 2 unresolved tests
(due to GDB hitting the internal error). With this patch, all
tests in this testcase pass.
Tested on x86_64-linux, no regression.
This adds fp reg support similar to the existing general reg support.
This fixes one gdb testsuite failure
FAIL: gdb.base/gcore.exp: corefile restored system registers
which fails without the patch because fcsr was missing. Otherwise, no
regressions with riscv64-linux native testsuite run.
gdb/
* riscv-linux-tdep.c (riscv_linux_fregmap): New.
(riscv_linux_fregset): New.
(riscv_linux_iterate_over_regset_sections): Call cb for .reg2 section.
The recent BP/WP changes for AArch64 swapping the order in add_lwp()
so that the process was added before the lwp. This was due to the lwp
creation requiring the process data.
This also needs changing in linux_attach().
Also add additional checks to make sure cannot attach to the same
process twice. Add test case for this - do this by splitting
attach.exp into distinct pass and error case sections.
Fixes gdb.server/ext-attach.exp on Aarch64.
gdb/gdbserver/ChangeLog:
* linux-low.c (linux_attach): Add process before lwp.
* server.c (attach_inferior): Check if already attached.
gdb/testsuite/ChangeLog:
* gdb.base/attach.exp: Add double attach test.
When creating a pty to spawn a subprocess (such as gdb), Expect
copies the settings of its own controlling terminal, including the
number of rows and columns. If you "make check" on a terminal with just
a few rows (e.g. 4), GDB will paginate before reaching the initial
prompt. In default_gdb_start, used by most tests, this is already
handled: if we see the pagination prompt, we sent \n to continue.
Philippe reported that gdb.base/corefile.exp didn't work in terminals
with just a few rows. This test spawns GDB by hand, because it needs to
check things before the initial prompt, which it couldn't do if it used
default_gdb_start.
In this case I think it's not safe to use the same technique as in
default_gdb_start. Even if we could send a \n if we see a pagination
prompt, we match some multiline regexes in there. So if a pagination
slips in there, it might make the regexes not match and fail the test.
It's also not possible to use -ex "set height 0" or -iex "set height 0",
it is handled after the introduction text is shown.
The simplest way I found to avoid showing the pagination completely is
to set stty_init (documented in expect's man page) to initialize gdb's
pty with a fixed number of rows.
And actually, if we set stty_init in gdb_init, it works nicely as a
general solution applicable to all tests. We can therefore remove the
solution introduced in e882ef3cfc ("testsuite: expect possible
pagination when starting gdb") where we matched the pagination prompt
during startup.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (default_gdb_start): Don't match pagination
prompt.
(gdb_init): Set stty_init.
While working on my other scripts to deal with gdb headers, I noticed
that some files were missing include guards. I wrote a script to add
the missing ones, but found that using the obvious names for the
guards ran into clashes -- for example, gdb/nat/linux-nat.h used
"LINUX_NAT_H", but this was also the script's choice for
gdb/linux-nat.h.
So, I changed the script to normalize all include guards in gdb. This
patch is the result.
As usual the script is available here:
https://github.com/tromey/gdb-refactoring-scripts
Tested by rebuilding; I also ran it through "Fedora-x86_64-m64" on the
buildbot.
gdb/ChangeLog
2019-02-07 Tom Tromey <tom@tromey.com>
* yy-remap.h: Add include guard.
* xtensa-tdep.h: Add include guard.
* xcoffread.h: Rename include guard.
* varobj-iter.h: Add include guard.
* tui/tui.h: Rename include guard.
* tui/tui-winsource.h: Rename include guard.
* tui/tui-wingeneral.h: Rename include guard.
* tui/tui-windata.h: Rename include guard.
* tui/tui-win.h: Rename include guard.
* tui/tui-stack.h: Rename include guard.
* tui/tui-source.h: Rename include guard.
* tui/tui-regs.h: Rename include guard.
* tui/tui-out.h: Rename include guard.
* tui/tui-layout.h: Rename include guard.
* tui/tui-io.h: Rename include guard.
* tui/tui-hooks.h: Rename include guard.
* tui/tui-file.h: Rename include guard.
* tui/tui-disasm.h: Rename include guard.
* tui/tui-data.h: Rename include guard.
* tui/tui-command.h: Rename include guard.
* tic6x-tdep.h: Add include guard.
* target/waitstatus.h: Rename include guard.
* target/wait.h: Rename include guard.
* target/target.h: Rename include guard.
* target/resume.h: Rename include guard.
* target-float.h: Rename include guard.
* stabsread.h: Add include guard.
* rs6000-tdep.h: Add include guard.
* riscv-fbsd-tdep.h: Add include guard.
* regformats/regdef.h: Rename include guard.
* record.h: Rename include guard.
* python/python.h: Rename include guard.
* python/python-internal.h: Rename include guard.
* python/py-stopevent.h: Rename include guard.
* python/py-ref.h: Rename include guard.
* python/py-record.h: Rename include guard.
* python/py-record-full.h: Rename include guard.
* python/py-record-btrace.h: Rename include guard.
* python/py-instruction.h: Rename include guard.
* python/py-events.h: Rename include guard.
* python/py-event.h: Rename include guard.
* procfs.h: Add include guard.
* proc-utils.h: Add include guard.
* p-lang.h: Add include guard.
* or1k-tdep.h: Rename include guard.
* observable.h: Rename include guard.
* nto-tdep.h: Rename include guard.
* nat/x86-linux.h: Rename include guard.
* nat/x86-linux-dregs.h: Rename include guard.
* nat/x86-gcc-cpuid.h: Add include guard.
* nat/x86-dregs.h: Rename include guard.
* nat/x86-cpuid.h: Rename include guard.
* nat/ppc-linux.h: Rename include guard.
* nat/mips-linux-watch.h: Rename include guard.
* nat/linux-waitpid.h: Rename include guard.
* nat/linux-ptrace.h: Rename include guard.
* nat/linux-procfs.h: Rename include guard.
* nat/linux-osdata.h: Rename include guard.
* nat/linux-nat.h: Rename include guard.
* nat/linux-namespaces.h: Rename include guard.
* nat/linux-btrace.h: Rename include guard.
* nat/glibc_thread_db.h: Rename include guard.
* nat/gdb_thread_db.h: Rename include guard.
* nat/gdb_ptrace.h: Rename include guard.
* nat/fork-inferior.h: Rename include guard.
* nat/amd64-linux-siginfo.h: Rename include guard.
* nat/aarch64-sve-linux-sigcontext.h: Rename include guard.
* nat/aarch64-sve-linux-ptrace.h: Rename include guard.
* nat/aarch64-linux.h: Rename include guard.
* nat/aarch64-linux-hw-point.h: Rename include guard.
* mn10300-tdep.h: Add include guard.
* mips-linux-tdep.h: Add include guard.
* mi/mi-parse.h: Rename include guard.
* mi/mi-out.h: Rename include guard.
* mi/mi-main.h: Rename include guard.
* mi/mi-interp.h: Rename include guard.
* mi/mi-getopt.h: Rename include guard.
* mi/mi-console.h: Rename include guard.
* mi/mi-common.h: Rename include guard.
* mi/mi-cmds.h: Rename include guard.
* mi/mi-cmd-break.h: Rename include guard.
* m2-lang.h: Add include guard.
* location.h: Rename include guard.
* linux-record.h: Rename include guard.
* linux-nat.h: Add include guard.
* linux-fork.h: Add include guard.
* i386-darwin-tdep.h: Rename include guard.
* hppa-linux-offsets.h: Add include guard.
* guile/guile.h: Rename include guard.
* guile/guile-internal.h: Rename include guard.
* gnu-nat.h: Rename include guard.
* gdb-stabs.h: Rename include guard.
* frv-tdep.h: Add include guard.
* f-lang.h: Add include guard.
* event-loop.h: Add include guard.
* darwin-nat.h: Rename include guard.
* cp-abi.h: Rename include guard.
* config/sparc/nm-sol2.h: Rename include guard.
* config/nm-nto.h: Rename include guard.
* config/nm-linux.h: Add include guard.
* config/i386/nm-i386gnu.h: Rename include guard.
* config/djgpp/nl_types.h: Rename include guard.
* config/djgpp/langinfo.h: Rename include guard.
* compile/gcc-cp-plugin.h: Add include guard.
* compile/gcc-c-plugin.h: Add include guard.
* compile/compile.h: Rename include guard.
* compile/compile-object-run.h: Rename include guard.
* compile/compile-object-load.h: Rename include guard.
* compile/compile-internal.h: Rename include guard.
* compile/compile-cplus.h: Rename include guard.
* compile/compile-c.h: Rename include guard.
* common/xml-utils.h: Rename include guard.
* common/x86-xstate.h: Rename include guard.
* common/version.h: Rename include guard.
* common/vec.h: Rename include guard.
* common/tdesc.h: Rename include guard.
* common/selftest.h: Rename include guard.
* common/scoped_restore.h: Rename include guard.
* common/scoped_mmap.h: Rename include guard.
* common/scoped_fd.h: Rename include guard.
* common/safe-iterator.h: Rename include guard.
* common/run-time-clock.h: Rename include guard.
* common/refcounted-object.h: Rename include guard.
* common/queue.h: Rename include guard.
* common/ptid.h: Rename include guard.
* common/print-utils.h: Rename include guard.
* common/preprocessor.h: Rename include guard.
* common/pathstuff.h: Rename include guard.
* common/observable.h: Rename include guard.
* common/netstuff.h: Rename include guard.
* common/job-control.h: Rename include guard.
* common/host-defs.h: Rename include guard.
* common/gdb_wait.h: Rename include guard.
* common/gdb_vecs.h: Rename include guard.
* common/gdb_unlinker.h: Rename include guard.
* common/gdb_unique_ptr.h: Rename include guard.
* common/gdb_tilde_expand.h: Rename include guard.
* common/gdb_sys_time.h: Rename include guard.
* common/gdb_string_view.h: Rename include guard.
* common/gdb_splay_tree.h: Rename include guard.
* common/gdb_setjmp.h: Rename include guard.
* common/gdb_ref_ptr.h: Rename include guard.
* common/gdb_optional.h: Rename include guard.
* common/gdb_locale.h: Rename include guard.
* common/gdb_assert.h: Rename include guard.
* common/filtered-iterator.h: Rename include guard.
* common/filestuff.h: Rename include guard.
* common/fileio.h: Rename include guard.
* common/environ.h: Rename include guard.
* common/common-utils.h: Rename include guard.
* common/common-types.h: Rename include guard.
* common/common-regcache.h: Rename include guard.
* common/common-inferior.h: Rename include guard.
* common/common-gdbthread.h: Rename include guard.
* common/common-exceptions.h: Rename include guard.
* common/common-defs.h: Rename include guard.
* common/common-debug.h: Rename include guard.
* common/cleanups.h: Rename include guard.
* common/buffer.h: Rename include guard.
* common/btrace-common.h: Rename include guard.
* common/break-common.h: Rename include guard.
* cli/cli-utils.h: Rename include guard.
* cli/cli-style.h: Rename include guard.
* cli/cli-setshow.h: Rename include guard.
* cli/cli-script.h: Rename include guard.
* cli/cli-interp.h: Rename include guard.
* cli/cli-decode.h: Rename include guard.
* cli/cli-cmds.h: Rename include guard.
* charset-list.h: Add include guard.
* buildsym-legacy.h: Rename include guard.
* bfin-tdep.h: Add include guard.
* ax.h: Rename include guard.
* arm-linux-tdep.h: Add include guard.
* arm-fbsd-tdep.h: Add include guard.
* arch/xtensa.h: Rename include guard.
* arch/tic6x.h: Add include guard.
* arch/i386.h: Add include guard.
* arch/arm.h: Rename include guard.
* arch/arm-linux.h: Rename include guard.
* arch/arm-get-next-pcs.h: Rename include guard.
* arch/amd64.h: Add include guard.
* arch/aarch64-insn.h: Rename include guard.
* arch-utils.h: Rename include guard.
* annotate.h: Add include guard.
* amd64-darwin-tdep.h: Rename include guard.
* aarch64-linux-tdep.h: Add include guard.
* aarch64-fbsd-tdep.h: Add include guard.
* aarch32-linux-nat.h: Add include guard.
gdb/gdbserver/ChangeLog
2019-02-07 Tom Tromey <tom@tromey.com>
* x86-tdesc.h: Rename include guard.
* x86-low.h: Add include guard.
* wincecompat.h: Rename include guard.
* win32-low.h: Add include guard.
* utils.h: Rename include guard.
* tracepoint.h: Rename include guard.
* tdesc.h: Rename include guard.
* target.h: Rename include guard.
* server.h: Rename include guard.
* remote-utils.h: Rename include guard.
* regcache.h: Rename include guard.
* nto-low.h: Rename include guard.
* notif.h: Add include guard.
* mem-break.h: Rename include guard.
* lynx-low.h: Add include guard.
* linux-x86-tdesc.h: Add include guard.
* linux-s390-tdesc.h: Add include guard.
* linux-ppc-tdesc-init.h: Add include guard.
* linux-low.h: Add include guard.
* linux-aarch64-tdesc.h: Add include guard.
* linux-aarch32-low.h: Add include guard.
* inferiors.h: Rename include guard.
* i387-fp.h: Rename include guard.
* hostio.h: Rename include guard.
* gdbthread.h: Rename include guard.
* gdb_proc_service.h: Rename include guard.
* event-loop.h: Rename include guard.
* dll.h: Rename include guard.
* debug.h: Rename include guard.
* ax.h: Rename include guard.
When first fixing splay tree key leaks in macrotab.c, some duplicated code
logic was factorized.
The key leaks will be fixed in libiberty, but the code factorization
is better kept in any case.
gdb/ChangeLog
2019-02-06 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* macrotab.c (macro_define_internal): New function that
factorizes macro_define_object_internal and macro_define_function
code.
(macro_define_object_internal): Use macro_define_internal.
(macro_define_function): Likewise.
Valgrind detects leaks like the following (gdb.base/macscp.exp).
This patch fixes 1 of the 3 leaks (the last one in the list below).
The remaining leaks are better fixed in splay_tree_remove and
splay_tree_insert in libiberty.
Tested on debian/amd64, natively and under valgrind.
==22285== 64 (48 direct, 16 indirect) bytes in 1 blocks are definitely lost in loss record 737 of 3,377
==22285== at 0x4C2BE6D: malloc (vg_replace_malloc.c:309)
==22285== by 0x4049E7: xmalloc (common-utils.c:44)
==22285== by 0x533A20: new_macro_key(macro_table*, char const*, macro_source_file*, int) (macrotab.c:355)
==22285== by 0x53438B: macro_define_function(macro_source_file*, int, char const*, int, char const**, char const*) (macrotab.c:822)
==22285== by 0x52F945: macro_define_command(char const*, int) (macrocmd.c:409)
...
==22285== 128 (96 direct, 32 indirect) bytes in 2 blocks are definitely lost in loss record 1,083 of 3,377
==22285== at 0x4C2BE6D: malloc (vg_replace_malloc.c:309)
==22285== by 0x4049E7: xmalloc (common-utils.c:44)
==22285== by 0x533A20: new_macro_key(macro_table*, char const*, macro_source_file*, int) (macrotab.c:355)
==22285== by 0x534277: macro_define_object_internal(macro_source_file*, int, char const*, char const*, macro_special_kind) (macrotab.c:776)
==22285== by 0x52F7E0: macro_define_command(char const*, int) (macrocmd.c:414)
...
==22285== 177 bytes in 19 blocks are definitely lost in loss record 1,193 of 3,377
==22285== at 0x4C2BE6D: malloc (vg_replace_malloc.c:309)
==22285== by 0x4049E7: xmalloc (common-utils.c:44)
==22285== by 0x52F5BD: extract_identifier(char const**, int) (macrocmd.c:316)
==22285== by 0x52F77D: macro_define_command(char const*, int) (macrocmd.c:355)
gdb/ChangeLog
2019-02-06 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* macrocmd.c (extract_identifier): Return
a gdb::unique_xmalloc_ptr<char> instead of a char *, and update
callers.
The kern.proc.args.<pid> sysctl returns the argv array as a packed
array of arguments, each null terminated. To construct a complete
command line, the arguments must be joined with spaces by converting
the intermediate nul characters to spaces. Previously only the first
argument was shown in cmdline output. Now, all arguments are shown.
gdb/ChangeLog:
* fbsd-nat.c (fbsd_fetch_cmdline): Join arguments with spaces.
I noticed that target_stack::unpush first uses the target "t", then
later asserts that it is non-NULL:
strata stratum = t->stratum ();
[...]
gdb_assert (t != NULL);
This is backwards, though, as the assertion must come first.
gdb/ChangeLog
2019-02-05 Tom Tromey <tom@tromey.com>
* target.c (target_stack::unpush): Move assertion earlier.
The IPA objects currently may use gnulib replacement apis, which is
wrong: gnulib is not linked into the produced dso and it cannot be
because it is not built with -fPIC -fvisibility=hidden.
The gnulib replacement detection is broken under cross compilation:
for targets other than *-gnu*, replacements are enabled that depend
on execution time detection. This causes unnecessary build failure
when the target has proper support for the replaced api.
This fix tries to undo the replacements, which is tricky because the
gnulib headers are still used for various compile time fixups and
there is no simple knob in gnulib to only turn the replacements off.
Without this workaround gdb fails to cross build to non-gnu targets:
ld: tracepoint-ipa.o: in function `gdb_agent_helper_thread(void*)':
gdb/gdbserver/tracepoint.c:7221: undefined reference to `rpl_strerror'
...
Makefile:434: recipe for target 'libinproctrace.so' failed
gdb/gdbserver/ChangeLog:
PR gdb/23985
* Makefile.in (IPAGENT_CFLAGS): Add UNDO_GNULIB_CFLAGS.
(UNDO_GNULIB_CFLAGS): Undo gnulib replacements.
PR python/23615 points out that gdb.execute_gdb_command does not
release the Python GIL. This means that, while the gdb command is
running, other Python threads do not run.
This patch solves the problem by introducing a new RAII class that can
be used to temporarily release and then re-acquire the GIL, then puts
this into the appropriate places in execute_gdb_command and
gdbpy_parse_and_eval.
This does not include a test case, because after some research I could
not find a way to write one that was not racy.
gdb/ChangeLog
2019-01-30 Tom Tromey <tom@tromey.com>
PR python/23615:
* python/python.c (execute_gdb_command): Use gdbpy_allow_threads.
(gdbpy_parse_and_eval): Likewise.
* python/python-internal.h (gdbpy_allow_threads): New class.
Replace individual calls to trad_frame_set_reg_addr for the general
purpose and floating point registers in signal trampoline frames used
by FreeBSD/aarch64 and FreeBSD/arm with calls to
trad_frame_set_reg_addr using the register maps for the corresponding
register sets.
gdb/ChangeLog:
* aarch64-fbsd-tdep.c (aarch64_fbsd_gregmap)
(aarch64_fbsd_fpregmap): Move earlier.
(AARCH64_MCONTEXT_REG_SIZE, AARCH64_MCONTEXT_FPREG_SIZE): Delete.
(aarch64_fbsd_sigframe_init): Use trad_frame_set_reg_regmap
instead of individual calls to trad_frame_set_reg_addr.
* arm-fbsd-tdep.c (arm_fbsd_gregmap, arm_fbsd_vfpregmap): Move
earlier.
(ARM_MCONTEXT_REG_SIZE, ARM_MCONTEXT_VFP_REG_SIZE): Delete.
(arm_fbsd_sigframe_init): Use trad_frame_set_reg_regmap
instead of individual calls to trad_frame_set_reg_addr.
The GDB wiki page has a much better contribution checklist than
that in the GDB CONTRIBUTE file. In addition, the wiki is easier
to keep up to date with current processes.
Reduce the CONTRIBUTE file down to a short paragraph followed by
a link to the contribution process. This also ensures anyone
reading the CONTRIBUTE file for a given release has access to the
latest processes.
gdb/ChangeLog:
* CONTRIBUTE: Replace contribution list with wiki link.
The recent BP/WP changes for AArch64 swapping the order in add_lwp()
so that the process was added before the lwp. This was due to the lwp
creation requiring the process data.
This also needs changing in linux_attach().
Fixes gdb.server/ext-attach.exp on Aarch64.
(This regression was hidden due to the racy nature of the gdb.server
tests - now they are no longer racy it'll be easier to spot. Also
checked X86).
gdb/gdbserver/ChangeLog:
2019-01-25 Alan Hayward <alan.hayward@arm.com>
* linux-low.c (linux_attach): Add process before lwp.
I noticed that py-finish-breakpoint.exp had two calls to
skip_python_tests, in quick succession. This patch removes the second
one.
gdb/testsuite/ChangeLog
2019-01-27 Tom Tromey <tom@tromey.com>
* gdb.python/py-finish-breakpoint.exp: Remove duplicate call to
skip_python_tests.
This changes the Makefiles to remove the -I for the common/
subdirectory. This will enforce the rule that includes must use the
'common/filename.h' form.
gdb/ChangeLog
2019-01-25 Tom Tromey <tom@tromey.com>
* Makefile.in (GDB_CFLAGS): Don't add -I for common.
gdb/gdbserver/ChangeLog
2019-01-25 Tom Tromey <tom@tromey.com>
* Makefile.in (INCLUDE_CFLAGS): Don't add -I for common.
This changes create-version.sh to have the generated file use
common/version.h as the file name.
gdb/ChangeLog
2019-01-25 Tom Tromey <tom@tromey.com>
* common/create-version.sh: Use common/version.h.
This replaces the pointer and length parameters of target_pass_signals
and target_program_signals with a gdb::array_view parameter, and fixes
the fallout.
In infrun.c, the signal_stop, signal_print, signal_program,
signal_catch, signal_pass globals are currently pointers to
heap-allocated memory. I see no point in that, so I converted them to
arrays. This allows simplifying the calls to
target_pass_signals/target_program_signals, since we can pass the
array directly, which can implicitly convert to gdb::array_view.
gdb/ChangeLog:
2019-01-24 Pedro Alves <palves@redhat.com>
* infrun.c (signal_stop, signal_print, signal_program)
(signal_catch, signal_pass): Now arrays instead of pointers.
(update_signals_program_target, do_target_resume)
(signal_catch_update, handle_command, _initialize_infrun): Adjust.
* linux-nat.c (linux_nat_target::pass_signals)
(linux_nat_target::create_inferior, linux_nat_target::attach):
Adjust.
* linux-nat.h (linux_nat_target::pass_signals): Adjust.
* nto-procfs.c (nto_procfs_target::pass_signals): Adjust.
* procfs.c (procfs_target::pass_signals): Adjust.
* record-full.c (record_full_target::resume): Adjust.
* remote.c (remote_target::pass_signals)
(remote_target::program_signals): Adjust.
* target-debug.h (target_debug_print_signals): Now takes a
gdb::array_view as parameter. Adjust.
* target.h (target_ops) <pass_signals, program_signals>: Replace
pointer and length parameters with gdb::array_view.
(target_pass_signals, target_program_signals): Likewise.
* target-delegates.c: Regenerate.
This fixes the following build error with clang/libc++, reported at
<https://sourceware.org/ml/gdb-patches/2019-01/msg00537.html>:
(...)
In file included from breakpoint.c:34:
In file included from ./inferior.h:54:
./common/forward-scope-exit.h:98:7: error: no matching constructor for
initialization of 'decltype(std::bind(&delete_longjmp_breakpoint,
std::declval<int>()))' (aka '__bind<void (*)(int), int>')
: m_bind_function (std::bind (function, args...))
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./common/gdb_optional.h:155:19: note: in instantiation of member
function 'detail::forward_scope_exit<void (int),
&delete_longjmp_breakpoint, void (int)>::forward_scope_exit' requested
here
new (&m_item) T (std::forward<Args>(args)...);
^
breakpoint.c:11127:18: note: in instantiation of function template
specialization 'gdb::optional<detail::forward_scope_exit<void (int),
&delete_longjmp_breakpoint, void (int)> >::emplace<int &>' requested
here
lj_deleter.emplace (thread);
^
/Applications/Xcode-10.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/functional:2220:7:
note: candidate constructor (the implicit copy constructor) not
viable: no known conversion from '__bind<[...], int &>' to 'const
__bind<[...], int>' for 1st argument
class __bind
^
(...)
I don't really know why I ended up with a copy here. We can just pass
the arguments directly to the being-constructed bind.
gdb/ChangeLog:
2019-01-24 Pedro Alves <palves@redhat.com>
* common/forward-scope-exit.h
(forward_scope_exit::forward_scope_exit): Pass arguments to
m_bind_function directly, instead of creating a std::bind and
copying that.
Static members in C++ structs are global data and therefore not part of the
list of struct members considered for passing in registers.
Note the corresponding code in GCC (from which the GDB AAPCS code is based)
does not have any static member checks due to the static members not being
part of the struct type at that point.
Extend gdb.base/infcall-nested-structs.exp to test structs with static
members when compiled for C++. XFAIL more cases for x86_64 (see gdb/24104).
For completeness, ensure some test cases have both empty structures and
static members.
Also fixes gdb.dwarf2/dw2-cp-infcall-ref-static.exp.
gdb/ChangeLog:
* aarch64-tdep.c (aapcs_is_vfp_call_or_return_candidate_1): Check
for static members.
(pass_in_v_vfp_candidate): Likewise.
gdb/testsuite/ChangeLog:
* gdb.base/infcall-nested-structs.c (struct struct_static_02_01):
New structure.
(struct struct_static_02_02): Likewise.
(struct struct_static_02_03): Likewise.
(struct struct_static_02_04): Likewise.
(struct struct_static_04_01): Likewise.
(struct struct_static_04_02): Likewise.
(struct struct_static_04_03): Likewise.
(struct struct_static_04_04): Likewise.
(struct struct_static_06_01): Likewise.
(struct struct_static_06_02): Likewise.
(struct struct_static_06_03): Likewise.
(struct struct_static_06_04): Likewise.
(cmp_struct_static_02_01): Likewise.
(cmp_struct_static_02_02): Likewise.
(cmp_struct_static_02_03): Likewise.
(cmp_struct_static_02_04): Likewise.
(cmp_struct_static_04_01): Likewise.
(cmp_struct_static_04_02): Likewise.
(cmp_struct_static_04_03): Likewise.
(cmp_struct_static_04_04): Likewise.
(cmp_struct_static_06_01): Likewise.
(cmp_struct_static_06_02): Likewise.
(cmp_struct_static_06_03): Likewise.
(cmp_struct_static_06_04): Likewise.
(call_all): Test new structs.
* gdb.base/infcall-nested-structs.exp: Likewise.
This removes the regcache_invalidator class in favor of a scope_exit.
This seems like an improvement (albeit a minor one) because
regcache_invalidator is only used in a single spot.
gdb/ChangeLog:
2019-01-23 Tom Tromey <tom@tromey.com>
Pedro Alves <palves@redhat.com>
* regcache.c (class regcache_invalidator): Remove.
(regcache::raw_write): Use make_scope_exit.
ui-out.h refers to some cleanup functions that no longer exist. This
updates the reference.
gdb/ChangeLog:
2019-01-23 Tom Tromey <tom@tromey.com>
* ui-out.h (class ui_out_emit_type): Update comment.
This updates a comment in fetch_inferior_event. The comment refers to
a cleanup that is now a scoped_restore_current_thread.
gdb/ChangeLog:
2019-01-23 Tom Tromey <tom@tromey.com>
* infrun.c (fetch_inferior_event): Update comment.
This removes the remaining cleanup from fetch_inferior_event,
replacing it with a SCOPE_EXIT. This required introducing a new scope
and reindenting.
gdb/ChangeLog:
2019-01-23 Tom Tromey <tom@tromey.com>
Pedro Alves <palves@redhat.com>
* infrun.c (reinstall_readline_callback_handler_cleanup): Remove
parameter.
(fetch_inferior_event): Use SCOPE_EXIT.
This removes the cleanup from stop_all_threads, replacing it with a
scope_exit.
gdb/ChangeLog:
2019-01-23 Tom Tromey <tom@tromey.com>
Pedro Alves <palves@redhat.com>
* infrun.c (disable_thread_events): Delete.
(stop_all_threads): Use SCOPE_EXIT.
This removes clear_symtab_users_cleanup, replacing it with uses of
forward_scope_exit.
gdb/ChangeLog:
2019-01-23 Tom Tromey <tom@tromey.com>
Pedro Alves <palves@redhat.com>
* symfile.c: Include forward-scope-exit.h.
(clear_symtab_users_cleanup): Replace forward declaration with
a FORWARD_SCOPE_EXIT.
(syms_from_objfile_1): Use the forward_scope_exit and
gdb::optional instead of cleanup_function.
(reread_symbols): Use the forward_scope_exit instead of
cleanup_function.
(clear_symtab_users_cleanup): Remove function.
This removes a cleanup from linux-nat.c, replacing it with a
scope_exit.
gdb/ChangeLog:
2019-01-23 Tom Tromey <tom@tromey.com>
Pedro Alves <palves@redhat.com>
* linux-nat.c: Include scope-exit.h.
(cleanup_target_stop): Remove.
(linux_nat_target::static_tracepoint_markers_by_strid): Use
SCOPE_EXIT.
This removes cleanup_delete_std_terminate_breakpoint, replacing it
with a use of SCOPE_EXIT.
gdb/ChangeLog:
2019-01-23 Tom Tromey <tom@tromey.com>
Pedro Alves <palves@redhat.com>
* infcall.c (cleanup_delete_std_terminate_breakpoint): Remove.
(call_function_by_hand_dummy): Use SCOPE_EXIT.
This removes make_bpstat_clear_actions_cleanup, replacing it with uses
of scope_exit.
gdb/ChangeLog:
2019-01-23 Tom Tromey <tom@tromey.com>
Andrew Burgess <andrew.burgess@embecosm.com>
Pedro Alves <palves@redhat.com>
* infrun.c (fetch_inferior_event): Use scope_exit.
* utils.h (make_bpstat_clear_actions_cleanup): Don't declare.
* top.c (execute_command): Use scope_exit.
* breakpoint.c (bpstat_do_actions): Use scope_exit.
* utils.c (do_bpstat_clear_actions_cleanup)
(make_bpstat_clear_actions_cleanup): Remove.
v3: sorted earlier in the series, and replaces the cleanup in
fetch_inferior_event here too instead of in some other patch.
This removes delete_just_stopped_threads_infrun_breakpoints_cleanup,
replacing it with uses of scope_exit.
gdb/ChangeLog:
2019-01-23 Tom Tromey <tom@tromey.com>
Pedro Alves <palves@redhat.com>
* infrun.c: Include "common/scope-exit.h"
(delete_just_stopped_threads_infrun_breakpoints_cleanup): Remove.
(wait_for_inferior): Use SCOPE_EXIT.
(fetch_inferior_event): Use scope_exit.
In v3: remove the "have BKPT_CHAIN already discarded" comment too.
The remaining null cleanup in breakpoint.c does not seem to protect
anything, so remove it.
gdb/ChangeLog:
2019-01-23 Tom Tromey <tom@tromey.com>
Pedro Alves <palves@redhat.com>
* breakpoint.c (create_breakpoint): Remove cleanup.
This removes delete_longjmp_breakpoint_cleanup in favor of forward_scope_exit.
gdb/ChangeLog:
2019-01-23 Tom Tromey <tom@tromey.com>
Andrew Burgess <andrew.burgess@embecosm.com>
Pedro Alves <palves@redhat.com>
* breakpoint.c (until_break_command): Use
delete_longjmp_breakpoint_cleanup class.
* infcmd.c (delete_longjmp_breakpoint_cleanup): Remove function.
(until_next_command): Use delete_longjmp_breakpoint_cleanup class.
* inferior.h: Include forward-scope-exit.h.
(delete_longjmp_breakpoint_cleanup): Replace function declaration
with FORWARD_SCOPE_EXIT type.
Replace the custom local class with a SCOPE_EXIT.
gdb/ChangeLog:
2019-01-23 Pedro Alves <palves@redhat.com>
* gdbarch-selftests.c (struct on_exit): Use SCOPE_EXIT.
This reimplements the manually-written scoped_finish_thread_state
class as a forward_scope_exit instantiation. forward_scope_exit has
the same interface as scoped_finish_thread_state, so nothing else has
to change.
A forward_scope_exit is preferred over make_scope_exit here because
infrun.c:normal_stop needs to wrap scoped_finish_thread_state in a
gdb::optional. Since we need the type there, might as well use it
everywhere.
gdb/ChangeLog:
2019-01-23 Pedro Alves <palves@redhat.com>
Andrew Burgess <andrew.burgess@embecosm.com>
* gdbthread.h: Include "common/forward-scope-exit.h".
(scoped_finish_thread_state): Redefine custom class in terms of
forward_scope_exit.
This adds a template that can be used to automatically instantiate
scope_exit-like types that wrap some cleanup function. The
instantiated type has a ctor that has the same interface as the
wrapped function. While the "magic" is just straight C++11, the
intended use is via the FORWARD_SCOPE_EXIT macro, which is a minimal
macro that avoids spelling out the wrapped function name more than
once:
void some_function (int foo, object *bar);
using some_function_fce = FORWARD_SCOPE_EXIT (some_function);
some_function_fce cleanup (some_int, some_obj_ptr);
The above runs:
some_function (some_int, some_obj_ptr);
at scope exit.
This is mainly useful as opposed to a simpler SCOPE_EXIT when you need
to:
- cancel the scope_exit, in which case you need the object's name
- wrap the scope_exit in a gdb::optional, in which case you need the
scope_exit's type in advance.
More details in the code comments.
gdb/ChangeLog:
2019-01-23 Pedro Alves <palves@redhat.com>
Andrew Burgess <andrew.burgess@embecosm.com>
* common/forward-scope-exit.h: New file.
This add a new template class scope_exit. scope_exit is a
general-purpose scope guard that calls its exit function at the end of
the current scope. A scope_exit may be canceled by calling the
"release" method. The API is modeled on P0052R5 - Generic Scope Guard
and RAII Wrapper for the Standard Library, which is itself based on
Andrej Alexandrescu's ScopeGuard/SCOPE_EXIT.
The main advantage of scope_exit is avoiding writing single-use RAII
classes and its boilerplate. Following patches will remove a few of
such classes.
There are two forms available:
- The "make_scope_exit" form allows canceling the scope guard. Use
it like this:
auto cleanup = make_scope_exit ( <function, function object, lambda> );
...
cleanup.release (); // cancel
- If you don't need to cancel the guard, you can use the SCOPE_EXIT
macro, like this:
SCOPE_EXIT { /* any code you like here. */ }
Note: scope_exit instances do not allocate anything on the heap.
gdb/ChangeLog:
2019-01-23 Pedro Alves <palves@redhat.com>
Andrew Burgess <andrew.burgess@embecosm.com>
Tom Tromey <tom@tromey.com>
* common/scope-exit.h: New file.
A following patch will include common/preprocessor.h in some .c file
that also includes readline.h, and that revealed a conflict -- ESC is
defined by readline.h as well (actually readline's chardefs.h) with a
completely unrelated meaning:
#define ESC CTRL('[')
Rename our version to avoid the conflict.
gdb/ChangeLog:
2019-01-23 Pedro Alves <palves@redhat.com>
* common/preprocessor.h (ESC): Rename to ...
(ESC_PARENS): ... this.
* common/valid-expr.h (CHECK_VALID_EXPR_1, CHECK_VALID_EXPR_2)
(CHECK_VALID_EXPR_3, CHECK_VALID_EXPR_4): Adjust.
When building symtab.c, I get:
../../binutils-gdb/gdb/language.h: In function ‘void print_symbol_info(search_domain, symbol*, int, const char*)’:
../../binutils-gdb/gdb/language.h:738:20: warning: ‘*((void*)& l +4)’ may be used uninitialized in this function [-Wmaybe-uninitialized]
set_language (m_lang);
~~~~~~~~~~~~~^~~~~~~~
../../binutils-gdb/gdb/symtab.c:4613:41: note: ‘*((void*)& l +4)’ was declared here
scoped_switch_to_sym_language_if_auto l (sym);
^
This is another instance of the std::optional problem, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635.
However, it seemed straightforward and inexpensive to me to silence
this one, which is what this patch does.
gdb/ChangeLog
2019-01-23 Tom Tromey <tom@tromey.com>
* language.h (class scoped_switch_to_sym_language_if_auto):
Initialize m_lang in both cases.
The code to not set empty hardware BPs/WPs on new threads will only work
if the newly allocated struct is empty.
Ensure the structure is created zeroed.
This patch removes the remaining racy behaviour on gdb.threads tests
when run on AArch64 Ubuntu.
gdb/ChangeLog:
* nat/aarch64-linux.c (aarch64_linux_new_thread): Replace XNEW
with XCNEW.
I did not see any reason that corelow.c should include <sys/file.h>.
The provided explanatory comment seems to be wrong. This patch
removes the include.
2019-01-22 Tom Tromey <tom@tromey.com>
* corelow.c: Do not include sys/file.h.
tui-wingeneral.h uses WINDOW, which is defined by curses. So, include
gdb_curses.h from tui-wingeneral.h.
2019-01-22 Tom Tromey <tom@tromey.com>
* tui/tui-wingeneral.h: Include gdb_curses.h.
A compile in the TUI somehow had "lines" defined as a macro. This
caused a compile error when including source-cache.h after whatever
header did that. I tracked this down to a #define in
/usr/include/term.h, so I just changed source-cache.h to avoid the
clash.
gdb/ChangeLog
2019-01-22 Tom Tromey <tom@tromey.com>
* source-cache.h (class source_cache) <get_source_lines,
get_plain_source_lines, extract_lines>: Rename "lines" parameter.
remote-fileio.h refers to remote_target, so forward-declare it.
gdb/ChangeLog
2019-01-22 Tom Tromey <tom@tromey.com>
* remote-fileio.h (struct remote_target): Declare.
py-ref.h can really only be included from a specific spot in
python-internal.h. The other includes are not useful, and cause
compilation errors if the includes are ever sorted. So, remove these
includes.
Arguably, py-ref.h should simply not be a separate header.
gdb/ChangeLog
2019-01-22 Tom Tromey <tom@tromey.com>
* python/py-arch.c: Do not include py-ref.h.
* python/py-bpevent.c: Do not include py-ref.h.
* python/py-cmd.c: Do not include py-ref.h.
* python/py-continueevent.c: Do not include py-ref.h.
* python/py-event.h: Do not include py-ref.h.
* python/py-evtregistry.c: Do not include py-ref.h.
* python/py-finishbreakpoint.c: Do not include py-ref.h.
* python/py-frame.c: Do not include py-ref.h.
* python/py-framefilter.c: Do not include py-ref.h.
* python/py-function.c: Do not include py-ref.h.
* python/py-infevents.c: Do not include py-ref.h.
* python/py-linetable.c: Do not include py-ref.h.
* python/py-objfile.c: Do not include py-ref.h.
* python/py-param.c: Do not include py-ref.h.
* python/py-prettyprint.c: Do not include py-ref.h.
* python/py-progspace.c: Do not include py-ref.h.
* python/py-symbol.c: Do not include py-ref.h.
* python/py-symtab.c: Do not include py-ref.h.
* python/py-type.c: Do not include py-ref.h.
* python/py-unwind.c: Do not include py-ref.h.
* python/py-utils.c: Do not include py-ref.h.
* python/py-value.c: Do not include py-ref.h.
* python/py-varobj.c: Do not include py-ref.h.
* python/py-xmethods.c: Do not include py-ref.h.
* python/python.c: Do not include py-ref.h.
* varobj.c: Do not include py-ref.h.
If objfiles.h is included after bcache.h, then the "bcache" function
will cause a compiler error because "bcache" will be seen as a
function, not a type. Fix this error by using the "struct" keyword.
gdb/ChangeLog
2019-01-22 Tom Tromey <tom@tromey.com>
* objfiles.h (struct objfile_per_bfd_storage): Use "struct"
keyword for bcache.
The include sorter can't handle multi-line comments on the same line
as a #include. This patch removes the only such comment.
In general I think these sorts of comments do not provide much value:
more often than not, I find that the comment is obsolete in one way or
another, and so the include sorter removes them in most cases.
gdb/ChangeLog
2019-01-22 Tom Tromey <tom@tromey.com>
* compile/compile-cplus-types.c: Remove a comment by #include.
gcc-c-plugin.h refers to some types defined in compile-internal.h.
This patch changes the former to include the latter.
gdb/ChangeLog
2019-01-22 Tom Tromey <tom@tromey.com>
* compile/gcc-c-plugin.h: Include compile-internal.h.
This removes the EXTERN define from stabsread.h. This is the only
spot that still uses this approach, and it interfered with sorting the
includes in stabsread.c.
Tested by rebuilding.
gdb/ChangeLog
2019-01-22 Tom Tromey <tom@tromey.com>
* stabsread.c (EXTERN): Do not define.
(symnum, next_symbol_text_func, processing_gcc_compilation)
(within_function, global_sym_chain, global_stabs)
(previous_stab_code, this_object_header_files)
(n_this_object_header_files)
(n_allocated_this_object_header_files): Define.
* stabsread.h (EXTERN): Never define. Use "extern".
E.g. in gdb.base/default.exp, valgrind detects leaks such as
==17663== 1,438 bytes in 101 blocks are definitely lost in loss record 2,804 of 2,884
==17663== at 0x4C2BE6D: malloc (vg_replace_malloc.c:309)
==17663== by 0x418A17: xmalloc (common-utils.c:44)
==17663== by 0x4E6F19C: history_expand (histexpand.c:1061)
==17663== by 0x4B4490: handle_line_of_input(buffer*, char const*, int, char const*) (event-top.c:685)
==17663== by 0x4B4562: command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) (event-top.c:753)
...
Fix the leak by using an unique_xmalloc_ptr for history_value.
gdb/ChangeLog
2019-01-22 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* event-top.c (handle_line_of_input): use unique_xmalloc_ptr for
history_value.
When gdb.base/infcall-nested-structs.c is complied as C++, the compiler
will not pass structs containing empty structs via float arguments.
This is because structs in C++ have a minimum size of 1, causing padding
in the struct once compiled. The AAPCS does not allow structs with
padding to be passed in float arguments.
Add padding checks to AArch64 and add C++ compile variant to the test.
Some of the tests fail on X86_64. This has been raised as bug gdb/24104.
gdb/ChangeLog:
* aarch64-tdep.c (aapcs_is_vfp_call_or_return_candidate_1): Check
for padding.
gdb/testsuite/ChangeLog:
* gdb.base/infcall-nested-structs.exp: Test C++ in addition to C.
Using -fstack-protector-strong will cause GDB to break on the wrong line
when placing a breakpoint on a function. This is due to inadequate dwarf
line numbering, and is being tracked by the GCC bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88432
GCC (and Clang) provided by Debian/Ubuntu default to stack protector
being enabled.
Ensure that when running the GDB testsuite, stack protector is always
turned off for GCC 4.1.0 (when stack protector was added) and above.
Ensure that this does not cause infinite recursion due to
test_compiler_info having to compile a file itself.
Add a test to explicitly test breakpoints with various levels of stack
protection on both GCC and Clang, with xfail for the known errors.
Restore change in ovldbreak.exp which worked around the issue.
gdb/testsuite/ChangeLog:
2019-01-18 Alan Hayward <alan.hayward@arm.com>
* gdb.base/stack-protector.c: New test.
* gdb.base/stack-protector.exp: New file.
* gdb.cp/ovldbreak.exp: Only allow a single break line.
* lib/gdb.exp (get_compiler_info): Use getting_compiler_info
option.
(gdb_compile): Remove stack protector for GCC and prevent
recursion.
This simplifies the minimal symbol iterator, by using
minimal_symbol_count and just doing a somewhat ordinary array-like
iteration. array_view is nearly usable, except that it is more
convenient for this iterator to return pointers rather than
references.
gdb/ChangeLog
2019-01-16 Tom Tromey <tom@tromey.com>
* objfiles.h (class objfile_msymbols) <iterator>: Change argument
type. Remove no-argument constructor.
<iterator::operator++>: Simplify.
<begin>: Update.
<end>: Use minimal_symbol_count.
This removes the objfile_psymtabs class in favor of a method on
objfile and on psymtab_storage.
2019-01-16 Tom Tromey <tom@tromey.com>
* objfiles.h (struct objfile) <psymtabs>: New method.
(class objfile_psymtabs): Remove.
* psymtab.h (class psymtab_storage) <partial_symtab_range>: New
typedef.
<range>: New method.
(require_partial_symbols): Change return type.
* psymtab.c (require_partial_symbols)
(psym_expand_symtabs_matching): Update.
* mdebugread.c (parse_partial_symbols): Update.
* dbxread.c (dbx_end_psymtab): Update.
This changes the all_objfiles_safe range adapter to be a method on the
program space, and fixes up all the users.
gdb/ChangeLog
2019-01-15 Tom Tromey <tom@tromey.com>
* progspace.h (program_space) <objfiles_safe_range>: New
typedef.
<objfiles_safe>: New method.
* objfiles.h (class all_objfiles_safe): Remove.
* objfiles.c (free_all_objfiles, objfile_purge_solibs): Update.
* jit.c (jit_inferior_exit_hook): Update.
This removes the remaining cleanups from solib-target.c, plus a VEC,
by using std::vector and std::unique_ptr.
Tested by the buildbot.
gdb/ChangeLog
2019-01-17 Tom Tromey <tom@tromey.com>
* solib-target.c (lm_info_target_p): Remove typedef. Don't
declare VEC.
(solib_target_parse_libraries): Change return type.
(library_list_start_segment, library_list_start_section)
(library_list_end_library, library_list_start_library); Update.
(solib_target_free_library_list): Remove.
(solib_target_parse_libraries): Remove cleanup. Change return
type.
(solib_target_current_sos): Update.
This replaces "the the" with "the" in various comments.
Tested by rebuilding. This didn't test the solib-dsbt.c change, but
it looks harmless.
gdb/ChangeLog
2019-01-17 Tom Tromey <tromey@bapiya>
* valprint.c: Replace "the the" with "the".
* symtab.c: Replace "the the" with "the".
* solib.c: Replace "the the" with "the".
* solib-dsbt.c: Replace "the the" with "the".
* linespec.c: Replace "the the" with "the".
* dwarf2loc.h: Replace "the the" with "the".
* amd64-windows-tdep.c: Replace "the the" with "the".
* aarch64-tdep.c: Replace "the the" with "the".
This patch is an attempt to deal with a variety of bugs reported where
GDB segfaults attempting to access a dwarf2_cu's builder. In certain
circumstances, this builder can be NULL. This is especially common
when inheriting DIEs via inlined subroutines in other CUs. The test
case demonstrates one such situation reported by users. See gdb/23773,
rhbz1638798, and dups for other concrete examples.
The approach taken here is to save the ancestor CU into the dwarf2_cu of
all CUs with DIEs that are "imported." This can happen whenever
follow_die_offset and friends are called. This essentially introduces a
chain of CUs that caused the importation of a DIE from a CU. Whenever
a builder is requested of a CU that has none, the ancestors are searched
for the first one with a builder.
A design side effect of this is that the builder can now only be
accessed by getter and setter methods because the builder itself
is private.
The bulk of the patch is relatively mindless text conversion from
"cu->builder" to "cu->get_builder ()". I've included one test which
was derived from one (of the many) bugs reported on the issue in both
sourceware and Fedora bugzillas.
gdb/ChangeLog:
PR gdb/23773
* dwarf2read.c (dwarf2_cu) <ancestor>: New field.
<builder>: Rename to ..
<m_builder>: ... this and make private.
(dwarf2_cu::get_builder): New method. Change all users of
`builder' to use this method.
(dwarf2_start_symtab): Move to ...
(dwarf2_cu::start_symtab): ... here. Update all callers
(setup_type_unit_groups): Move to ...
(dwarf2_cu::setup_type_unit_groups): ... here. Update all
callers.
(dwarf2_cu::reset_builder): New method.
(process_full_compunit, process_full_type_unit): Use
dwarf2_cu::reset_builder.
(follow_die_offset): Record the ancestor CU if it is different
from the followed DIE's CU.
(follow_die_sig_1): Likewise.
gdb/testsuite/ChangeLog:
PR gdb/23773
* gdb.dwarf2/inlined_subroutine-inheritance.exp: New file.
This patch adds a table summarizing the history or MI versions:
- The version number
- Which GDB version introduced it
- Breaking changes compared to the previous version
The goal of the table is to help writers of front ends know which
version of MI they can use with a given GDB version. It will also help
them update their code to work against a newer MI version.
Right now, we just have 1 and 2, but we expect to add an entry for 3
soon. I did a bit of archelogy and reverse engineering of the code to
come up with the breaking changes for MI 2.
I did some changes to the text around it, some things that I thought
needed to be clarified, seemed a bit dated or seemed just wrong
(especially "Apart from mi0, new versions of @value{GDBN} will not
support old versions of MI").
gdb/doc/ChangeLog:
* gdb.texinfo (GDB/MI Development and Front Ends): Add table of
MI versions. Update text around it.
This removes the remaining cleanup from remote.c, by changing
remote_state::buf to be a gdb::char_vector, and then fixing up all the
fallout. The resulting patch is somewhat ugly, but on the other hand,
it eliminates some possibilities for mistakes.
Regression tested using the
Fedora-x86_64-native-extended-gdbserver-m64 builder on the buildbot.
gdb/ChangeLog
2019-01-15 Tom Tromey <tom@tromey.com>
* remote.c (class remote_state) <buf>: Now a char_vector.
<buf_size>: Remove.
(remote_target::getpkt): Change type of buf. Remove sizeof_buf
parameter.
(remote_target::getpkt_or_notif_sane_1)
(remote_target::getpkt_sane)
(remote_target::getpkt_or_notif_sane): Likewise.
(class remote_target) <putpkt>: New overload.
(remote_target::read_frame): Change type of "buf_p". Remove
sizeof_p parameter.
(packet_ok): New overload.
(packet_check_result): New overload.
Update all uses.
This constifies the "buf" arguments to various remote-notif functions
and updates the users.
gdb/ChangeLog
2019-01-14 Tom Tromey <tom@tromey.com>
* remote-notif.c (handle_notification, remote_notif_ack)
(remote_notif_parse): Make "buf" const.
* remote-notif.h (struct notif_client) <parse, ack>: Make "buf"
const.
(remote_notif_parse, remote_notif_ack, handle_notification):
Likewise.
* remote.c (remote_notif_stop_parse): Make "buf" const.
(remote_target::remote_parse_stop_reply): Make "buf" const.
(remote_notif_stop_ack): Make "buf" const.
This constifies the parameter to remote_console_output.
gdb/ChangeLog
2019-01-14 Tom Tromey <tom@tromey.com>
* remote.c (remote_console_output): Make parameter const.
This constifies the final parameter to target_pass_signals and
target_program_signals and updates the rest of gdb.
Note that I have no way to test the nto-procfs.c change.
gdb/ChangeLog
2019-01-14 Tom Tromey <tom@tromey.com>
* target-debug.h (target_debug_print_signals): Constify.
* nto-procfs.c (nto_procfs_target::pass_signals): Update.
* procfs.c (procfs_target::pass_signals): Update.
* linux-nat.c (linux_nat_target::pass_signals): Update.
* linux-nat.h (class linux_nat_target) <pass_signals>: Update.
* target-delegates.c: Rebuild.
* remote.c (remote_target::program_signals): Update.
(remote_target::pass_signals): Update.
* target.c (target_pass_signals): Constify argument.
(target_program_signals): Likewise.
* target.h (struct target_ops) <pass_signals, program_signals>:
Constify argument.
(target_pass_signals, target_program_signals): Constify argument.
The fix for PR tui/28819 regressed gdb command output a bit. In
"nonl" mode, pressing the Enter key will result in a newline not being
echoed properly, so that gdb output for the command will begin on the
same line as the input.
This patch changes gdb_wgetch to echo the newline. I have only tested
this interactively, as the TUI doesn't have automated tests in
general.
gdb/ChangeLog
2019-01-14 Tom Tromey <tom@tromey.com>
PR tui/28819:
* tui/tui-io.c (gdb_wgetch): Print \r when needed.
This patch defines pseudo-registers "v0" through "v31" as aliases that
map to the corresponding raw "vr0" through "vr31" vector registers for
Power.
The motivation behind this is that although GDB defines these
registers as "vrX", the disassembler prints them as "vX", e.g. as the
operands in instructions such as "vaddubm v2,v1,v1". This can be
confusing to users trying to print out the values of the operands
while inspecting the disassembled code.
The new aliases are made not to belong to any register group, to avoid
duplicated values in "info register vector" and "info register all".
The arch-specific rs6000_pseudo_register_reggroup_p function had
previously been removed since the other pseudo-registers could have
their groups inferred by their type. It restored with this patch to
handle the aliases. Membership for the other pseudo-registers is
still determined using the default function.
A new tests checks that GDB prints the expected values of vector
registers after they are filled by the inferior, by using both the raw
names and the aliases. Two other existing tests are modified to also
test the aliases.
gdb/ChangeLog:
2019-01-14 Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
* ppc-tdep.h (struct gdbarch_tdep) <ppc_v0_alias_regnum>: New
field.
* rs6000-tdep.c: Include reggroups.h.
(IS_V_ALIAS_PSEUDOREG): Define.
(rs6000_register_name): Return names for the "vX" aliases.
(rs6000_pseudo_register_type): Return type for the "vX" aliases.
(rs6000_pseudo_register_reggroup_p): Restore. Handle "vX"
aliases. Call default_register_reggroup_p for all other
pseudo-registers.
(v_alias_pseudo_register_read, v_alias_pseudo_register_write):
New functions.
(rs6000_pseudo_register_read, rs6000_pseudo_register_write):
Handle "vX" aliases.
(v_alias_pseudo_register_collect): New function.
(rs6000_ax_pseudo_register_collect): Handle "vX" aliases.
(rs6000_gdbarch_init): Initialize "vX" aliases as
pseudo-registers. Restore registration of
rs6000_pseudo_register_reggroup_p with
set_tdesc_pseudo_register_reggroup_p.
gdb/testsuite/ChangeLog:
2019-01-14 Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
* gdb.arch/vsx-regs.exp: Add tests that use the vector register
aliases.
* gdb.arch/altivec-regs.exp: Likewise. Fix indentation of two
tests.
* gdb.arch/powerpc-vector-regs.c: New file.
* gdb.arch/powerpc-vector-regs.exp: New file.
gdb/doc/ChangeLog:
2019-01-14 Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
* gdb.texinfo (PowerPC Features): Document the alias
pseudo-registers for the org.gnu.gdb.power.altivec feature.
This patch fixes one of the tests in gdb.arch/altivec-regs.exp that
was passing an incorrect list to gdb_expect_list, which always
matched.
gdb/testsuite/ChangeLog:
2019-01-14 Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
* gdb.arch/altivec-regs.exp: Fix the list passed to
gdb_expect_list when testing "info vector".
Commit 37d9e06231 ("gdb: xtensa: handle privileged registers") changed
how the tdep->num_regs and tdep->num_pseudo_regs are calculated, but
didn't update these numbers in the gdbarch for the xtensa-linux target.
As a result xtensa-linux-gdb behaves as xtensa-elf-gdb and cannot
communicate with the linux gdbserver.
Fix tdep->num_pseudo_regs calculation and call set_gdbarch_num_regs and
set_gdbarch_num_pseudo_regs in xtensa_linux_init_abi.
gdb/
2019-01-13 Max Filippov <jcmvbkbc@gmail.com>
* xtensa-linux-tdep.c (xtensa_linux_init_abi): Update
tdep->num_pseudo_regs. Add calls to set_gdbarch_num_regs and
set_gdbarch_num_pseudo_regs.
Currently, the behaviour is:
(gdb) show style
(gdb) set style
(gdb) show style address
(gdb) set style address
(gdb)
With this patch, the behaviour is:
(gdb) show style
style address background: The "address" background color is: none
style address foreground: The "address" foreground color is: blue
style address intensity: The "address" display intensity is: normal
enabled: CLI output styling is enabled.
style filename background: The "filename" background color is: none
style filename foreground: The "filename" foreground color is: green
style filename intensity: The "filename" display intensity is: normal
style function background: The "function" background color is: none
style function foreground: The "function" foreground color is: yellow
style function intensity: The "function" display intensity is: normal
style variable background: The "variable" background color is: none
style variable foreground: The "variable" foreground color is: cyan
style variable intensity: The "variable" display intensity is: normal
(gdb) set style
"set style" must be followed by an appropriate subcommand.
List of set style subcommands:
set style address -- Address display styling
set style enabled -- Set whether CLI styling is enabled
set style filename -- Filename display styling
set style function -- Function name display styling
set style variable -- Variable name display styling
Type "help set style" followed by set style subcommand name for full documentation.
Type "apropos word" to search for commands related to "word".
Command name abbreviations are allowed if unambiguous.
(gdb) show style address
background: The "filename" background color is: none
foreground: The "filename" foreground color is: green
intensity: The "filename" display intensity is: normal
(gdb) set style address
List of set style address subcommands:
set style address background -- Set the background color for this property
set style address foreground -- Set the foreground color for this property
set style address intensity -- Set the display intensity color for this property
Type "help set style address" followed by set style address subcommand name for full documentation.
Type "apropos word" to search for commands related to "word".
Command name abbreviations are allowed if unambiguous.
(gdb)
gdb/ChangeLog
* cli/cli-style.h (class cli_style_option): <add_setshow_commands>
Remove arg prefixname, add do_set and do_show.
Add member functions set_list and show_list.
* cli/cli-style.c (class cli_style_option): Update accordingly.
(style_set_list): Move to file scope.
(style_show_list): Likewise.
(set_style): Call help_list.
(show_style): Call cmd_show_list.
(_initialize_cli_style): New macro STYLE_ADD_SETSHOW_COMMANDS.
Update to use the new macro.
One of our users remarked that the help doesn't mention the fact that
the "catch exception" supports the special argument "unhandled" to catch
exceptions which do not have a handler. This patch changes the output
of...
| (gdb) help catch exception
| Catch Ada exceptions, when raised.
| With an argument, catch only exceptions with the given name.
... to ...
| (gdb) help catch exception
| Catch Ada exceptions, when raised.
| Usage: catch exception [ ARG ]
|
| Without any argument, stop when any Ada exception is raised.
| If ARG is "unhandled" (without the quotes), only stop when the exception
| being raised does not have a handler (and will therefore lead to the task's
| termination).
| Otherwise, the catchpoint only stops when the name of the exception being
| raised is the same as ARG.
gdb/ChangeLog:
* ada-lang.c (_initialize_ada_language): Expand the help text
for the "catch exception" command.
Tested on x86_64-linux, no regression.
Having paths in the test names makes it harder to compare results
between two runs in different directories. Give the test a name so
that the path doesn't appear.
gdb/ChangeLog:
* gdb.base/style.exp: Don't include path in testname.
Fix warning:
gdb/symtab.c: In function ‘int matching_obj_sections(obj_section*, obj_section*)’:
gdb/symtab.c:1024:12: warning: ‘obj’ may be used uninitialized in this function [-Wmaybe-uninitialized]
if (obj->separate_debug_objfile_backlink != NULL
2019-01-12 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* symtab.c (matching_obj_sections): Initialize obj,
declare it closer to its usage.
This changes inf_threads_iterator and some range adapters in
thread-iter.h to use next_iterator and next_adapter instead.
gdb/ChangeLog
2019-01-10 Tom Tromey <tom@tromey.com>
* thread-iter.h (inf_threads_iterator): Use next_iterator.
(basic_inf_threads_range): Remove.
(inf_threads_range, inf_non_exited_threads_range)
(safe_inf_threads_range): Use next_adapter.
This is a test derived from one of the reproducers in symtab/23010.
The DIE tree used here is typical of compilations with LTO, where an
artificial parent DIE of language C99 imports DIEs of other languages.
gdb/testsuite/ChangeLog:
PR gdb/23712
PR symtab/23010
* gdb.dwarf2/multidictionary.exp: New file.
Finally, we can remove dw2_add_symbol_to_list since the wrapper function
originally introduced to catch this multi-language scenario is no longer
needed. With multi-language dictionaries, we can now support adding
symbols of multiple languages, negating the need for the assertion
entirely.
This patch should now fix gdb/23712 (and symtab/23010). At least it will
if the NULL buildsym_compunit problem doesn't strike first (see gdb/23773).
gdb/ChangeLog:
PR gdb/23712
PR symtab/23010
* dwarf2read.c (dw2_add_symbol_to_list): Remove.
(fixup_go_packaging, new_symbol): Use add_symbol_to_list.
Now that multidictionary's are being used, there is no longer any need
to retain the four temporary functions introduced in the beginning of
this series.
This patch removes them.
As an additional cleanup, since the single-language dictionaries are
no longer used outside dictionary.c, make all of those functions
static.
gdb/ChangeLog:
PR gdb/23712
PR symtab/23010
* dictionary.c (pending_to_vector): Remove.
(dict_create_hashed_1, dict_create_linear_1, dict_add_pending_1):
Remove _1 suffix, replacing functions of the same name. Update
all callers.
(dict_create_hashed, dict_create_hashed_expandable)
(dict_create_linear, dict_create_linear_expandable, dict_free)
(dict_add_symbol, dict_add_pending, dict_size, dict_empty):
Make functions static.
This patch builds on the previous by enabling the `new' multidictionary
API. A lot of the hunks are simply textual replacements of "dict_"
with "mdict_" and similar transformations.
A word of warning, even with the use of multidictionaries, the code
still does not satisfactorily fix the reported problems with gdb/23712
(or gdb/23010). We still have additional changes to make before that
happens.
gdb/ChangeLog:
PR gdb/23712
PR symtab/23010
* dictionary.h (struct dictionary): Replace declaration with
multidictionary.
(dict_create_hashed, dict_create_hashed_expandable)
(dict_create_linear, dict_create_linear_expandable)
(dict_free, dict_add_symbol, dict_add_pending, dict_empty)
(dict_iterator_first, dict_iterator_next, dict_iter_match_first)
(dict_iter_match_next, dict_size): Rename to "mdict_" versions
taking multidictionary argument.
[ALL_DICT_SYMBOLS]: Update for multidictionary.
* block.h (struct block) <dict>: Change to multidictionary
and rename `multidict'.
* block.c, buildsym.c, jit.c, mdebugread.c, objfiles.c,
symmisc.c: Update all dictionary references to multidictionary.
gdb/23712 is a new manifestation of the now-infamous (at least to me)
symtab/23010 assertion failure (DICT_LANGUAGE == SYMBOL_LANGAUGE).
An example of the problem (using test case from symtab/23010):
Reading symbols from /home/rdiez/rdiez/arduino/JtagDue/BuildOutput/JtagDue-obj-release/firmware.elf...done.
(gdb) p SysTick_Handler
dwarf2read.c:9715: internal-error: void dw2_add_symbol_to_list(symbol*, pending**): Assertion `(*listhead) == NULL || (SYMBOL_LANGUAGE ((*listhead)->symbol[0]) == SYMBOL_LANGUAGE (symbol))' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
This assertion was added specifically to catch this condition (of adding
symbols of different languages to a single pending list).
The problems we're now seeing on systems utilizing DWARF debugging seem to
be caused by the use of LTO, which adds a CU with an artificial DIE of
language C99 which references DIEs in other CUs of language C++.
Thus, we create a dictionary containing symbols of C99 but end up
stuffing C++ symbols into it, and the dw2_add_symbol_to_list triggers.
The approach taken here to fix this is to introduce multi-language
dictionaries to "replace" the standard, single-language dictionaries
used today.
Note to reviewers: This patch introduces some temporary functions to
aide with review. This and other artifacts (such as "See dictionary.h"
which appear incorrect) will all be valid at the end of the series.
This first patch introduces the new multidictionary and its API (which
is, by design, identical to the old dictionary interface). It also
mutates dict_create_hashed and dict_create_linear so that they take
a std::vector instead of the usual struct pending linked list. This will
be needed later on.
This patch does /not/ actually enable multidictionary's. That is left
for a subsequent patch in the series.
I've done exhaustive performance testing with this approach, and I've
attempted to minimize the overhead for the (overwhelmingly) most common
one-language scenario.
On average, a -g3 -O0 GDB (the one we developers use) will see
approximately a 4% slowdown when initially reading symbols. [I've
tested only GDB and firefox with -readnow.] When using -O2, this
difference shrinks to ~0.5%. Since a number of runs with these
patches actually run /faster/ than unpatched GDB, I conclude that
these tests have at least a 0.5% error margin.
On our own gdb.perf test suite, again, results appear to be pretty
negligible. Differences to unpatched GDB range from -7.8% (yes,
patched version is again faster than unpatched) to 27%. All tests
lying outside "negligible," such as the 27% slowdown, involve a total
run time of 0.0007 (or less) with smaller numbers of CUs/DSOs (usually 10
or 100). In all cases, the follow-up tests with more CUs/DSOs is never
more than 3% difference to the baseline, unpatched GDB.
In my opinion, these results are satisfactory.
gdb/ChangeLog:
PR gdb/23712
PR symtab/23010
* dictionary.c: Include unordered_map.
(pending_to_vector): New function.
(dict_create_hashed_1, dict_create_linear_1, dict_add_pending_1):
Rewrite the non-"_1" functions to take vector instead
of linked list.
(dict_create_hashed, dict_create_linear, dict_add_pending): Use the
"new" _1 versions of the same name.
(multidictionary): Define.
(std::hash<enum language): New definition.
(collate_pending_symbols_by_language, mdict_create_hashed)
(mdict_create_hashed_expandable, mdict_create_linear)
(mdict_create_linear_expandable, mdict_free)
(find_language_dictionary, create_new_language_dictionary)
(mdict_add_symbol, mdict_add_pending, mdict_iterator_first)
(mdict_iterator_next, mdict_iter_match_first, mdict_iter_match_next)
(mdict_size, mdict_empty): New functions.
* dictionary.h (mdict_iterator): Define.
Coverity points out that gdb/tracepoint.c:parse_tracepoint_definition
can leak 'cond' in this line:
cond = (char *) xmalloc (2 * xlen + 1);
That can leak because we're in a loop and 'cond' may have already been
xmalloc'ed into in a previous iteration. That won't normally happen,
because we don't expect to see a tracepoint definition with multiple
conditions listed, but, it doesn't hurt to be pedantically correct,
in case some stub manages to send something odd back to GDB.
At first I thought I'd just replace the xmalloc call with:
cond = (char *) xrealloc (cond, 2 * xlen + 1);
and be done with it. However, my pedantic self realizes that
warning() can throw as well (due to pagination + Ctrl-C), so I fixed
it using gdb::unique_xmalloc_ptr instead.
While doing this, I noticed that these vectors in struct uploaded_tp:
std::vector<char *> actions;
std::vector<char *> step_actions;
hold heap-allocated strings, but nothing is freeing the strings,
AFAICS.
So I ended up switching all the heap-allocated strings in uploaded_tp
to unique pointers. This patch is the result of that.
I also wrote an alternative, but similar patch that uses std::string
throughout instead of gdb::unique_xmalloc_ptr, but in the end reverted
it because the code didn't look that much better, and I kind of
dislike replacing pointers with fat std::string's (3 or 4 times the
size of a pointer) in structures.
gdb/ChangeLog:
2019-01-10 Pedro Alves <palves@redhat.com>
* breakpoint.c (read_uploaded_action)
(create_tracepoint_from_upload): Adjust to use
gdb::unique_xmalloc_ptr.
* ctf.c (ctf_write_uploaded_tp):
(SET_ARRAY_FIELD): Use emplace_back.
(SET_STRING_FIELD): Adjust to use gdb::unique_xmalloc_ptr.
* tracefile-tfile.c (tfile_write_uploaded_tp):
* tracepoint.c (parse_tracepoint_definition): Adjust to use
gdb::unique_xmalloc_ptr.
* tracepoint.h (struct uploaded_tp) <cond, actions, step_actions,
at_string, cond_string, cmd_strings>: Replace char pointers
with gdb::unique_xmalloc_ptr.
lm_info_target::name is nowadays std::string, so we're leaking the
result of xstrdup.
gdb/ChangeLog:
2019-01-10 Pedro Alves <palves@redhat.com>
* solib-target.c (library_list_start_library): Don't xstrdup name.
Coverity points out that all the "continue;" statements in the switch
case in parse_partial_symbols leak STABSTRING. This is because we
only release STABSTRING at the end of the scope, with:
if (stabstring
&& stabstring != debug_info->ss + fh->issBase + sh.iss)
xfree (stabstring);
but that bit of code is skipped if a case in the switch statement ends
with "continue".
Fix this by using gdb::unique_xmalloc_ptr to manage the heap-allocated
version of 'stabsstring'.
I don't know how to test this.
gdb/ChangeLog:
2019-01-10 Pedro Alves <palves@redhat.com>
* mdebugread.c (parse_partial_symbols): Use
gdb::unique_xmalloc_ptr to manage heap-allocated 'stabsstring'.
The previous commit:
commit 1ef8573cc7
Date: Wed Jan 9 14:02:39 2019 +0000
gdb: Improve scoped_switch_fork_info class
contained a bug, an incorrect variable name was used. Fixed in this
commit.
gdb/ChangeLog:
* linux-fork.c (scoped_switch_fork_info)
<~scoped_switch_fork_info>: Fix incorrect variable name.
After committing this patch I got this feedback:
https://sourceware.org/ml/gdb-patches/2019-01/msg00181.html
This patch makes the constructor of scoped_switch_fork_info explicit,
and wraps the core of the destructor in a TRY/CATCH block.
I've run this through the testsuite on X86-64/GNU Linux, however, this
code is not exercised, so this patch is untested.
gdb/ChangeLog:
* linux-fork.c (scoped_switch_fork_info)
<scoped_switch_fork_info>: Make explicit.
<~scoped_switch_fork_info>: Wrap core in TRY/CATCH.
Previously, the psymtab obstack was just a pointer to the objfile
obstack. This patch changes psymtabs to use their own obstack,
instead. A gdb::optional is used to avoid unnecessary allocation when
the obstack is not needed.
After this patch, the psymtab code lifetime model is that, in the core
psymtab code, objects allocated on the psymtab obstack may point to
other such objects, or to objects on the per-BFD obstack -- but never
to the objfile obstack.
Note however that this invariant is only obeyed the core psymtab code,
and even there not quite fully: there is still a link from the psymtab
to the full symtab.
Symbol readers are free to work however they like; and in particular,
even after this patch, in practice all symbol readers violate this
invariant via the read_symtab_private field.
gdb/ChangeLog
2019-01-10 Tom Tromey <tom@tromey.com>
* objfiles.h (objfile::reset_psymtabs): Update.
* objfiles.c (objfile::objfile): Update.
* psymtab.h (psymtab_storage::obstack): Update.
(psymtab_storage::m_obstack): Use gdb::optional.
(class psymtab_storage): Update comment. Remove objfile
parameter.
* psymtab.c (psymtab_storage::psymtab_storage): Update.
This adds a new psymtab allocation method to psymtab_storage and
changes the free_psymtabs member to be private. While not strictly
necessary, this seems like a decent cleanup, and also makes it simpler
to move psymtabs off of obstacks entirely, should that prove
desirable.
gdb/ChangeLog
2019-01-10 Tom Tromey <tom@tromey.com>
* psymtab.h (psymtab_storage::allocate_psymtab): New method.
<free_psymtabs>: Now private.
* psymtab.c (psymtab_storage::allocate_psymtab): Implement.
(allocate_psymtab): Use new method.
This adds a new method to psymtab_storage to allocate storage for
psymtab dependencies, then changes the symbol readers to use it. This
has the effect of moving the storage to the psymtab storage obstack.
gdb/ChangeLog
2019-01-10 Tom Tromey <tom@tromey.com>
* xcoffread.c (xcoff_end_psymtab): Use allocate_dependencies.
* psymtab.h (psymtab_storage::allocate_dependencies): New method.
* mdebugread.c (parse_partial_symbols): Use
allocate_dependencies.
* dwarf2read.c (dwarf2_create_include_psymtab): Use
allocate_dependencies.
(process_psymtab_comp_unit_reader)
(build_type_psymtab_dependencies): Likewise.
* dbxread.c (dbx_end_psymtab): Use allocate_dependencies.
This moves a couple more psymtab-related allocations to the psymtab
obstack.
gdb/ChangeLog
2019-01-10 Tom Tromey <tom@tromey.com>
* psymtab.c (add_psymbol_to_bcache): Pass psymtab obstack to
PSYMBOL_SET_LANGUAGE.
(allocate_psymtab): Allocate psymtab on the psymtab obstack.
After this patch, the psymtab address map will now be allocated on the
psymtab obstack rather than the objfile obstack. This also changes
the psymtab storage object to make the obstack private; this will be
used later.
gdb/ChangeLog
2019-01-10 Tom Tromey <tom@tromey.com>
* psymtab.h (psymtab_storage::obstack): New method.
<m_obstack>: Rename from obstack; now private.
* psymtab.c (psymtab_storage): Update.
* dwarf2read.c (create_addrmap_from_index)
(create_addrmap_from_aranges, dwarf2_build_psymtabs_hard):
Update.
This introduces a new method, objfile::reset_psymtabs, and changes
reread_symbols to use it. This method simply destroys the existing
partial symbols and recreates the psymtab_storage object.
This patch fixes a latent bug -- namely, that reread_symbols should
clear objfile::psymbol_map, but does not. I can submit that
separately if you'd prefer.
gdb/ChangeLog
2019-01-10 Tom Tromey <tom@tromey.com>
* symfile.c (reread_symbols): Call objfile->reset_psymtabs.
* objfiles.h (objfile::reset_psymtabs): New method.
This introduces a new psymtab_storage class, which holds all
psymbol-related objects that are independent of the objfile. (This
latter contraint explains why psymbol_map was not moved; though this
could still be done with some work.)
This patch does not yet change where psymtab allocation is done --
that comes later. This just wraps everything in a single object to
make further transformations simpler.
Note that a shared_ptr is used to link from the objfile to the
psymtab_storage object. The end goal here is to allow a given symbol
reader to simply attach to the psymtab_storage object to the BFD, then
reuse it in later invocations; shared_ptr makes this simple to reason
about.
gdb/ChangeLog
2019-01-10 Tom Tromey <tom@tromey.com>
* symmisc.c (print_symbol_bcache_statistics): Update.
(print_objfile_statistics): Update.
* symfile.c (reread_symbols): Update.
* psymtab.h (class psymtab_storage): New.
* psymtab.c (psymtab_storage): New constructor.
(~psymtab_storage): New destructor.
(require_partial_symbols): Update.
(ALL_OBJFILE_PSYMTABS_REQUIRED): Rewrite.
(find_pc_sect_psymtab, find_pc_sect_psymbol)
(match_partial_symbol, lookup_partial_symbol, dump_psymtab)
(psym_dump, recursively_search_psymtabs, psym_has_symbols)
(psym_find_compunit_symtab_by_address, sort_pst_symbols)
(start_psymtab_common, end_psymtab_common)
(add_psymbol_to_bcache, add_psymbol_to_list, init_psymbol_list)
(allocate_psymtab): Update.
(psymtab_storage::discard_psymtab): Rename from discard_psymtab.
Update.
(dump_psymtab_addrmap, maintenance_print_psymbols)
(maintenance_check_psymtabs): Update.
(class objfile_psymtabs): Move to objfiles.h.
* psympriv.h (discard_psymtab): Now inline.
(psymtab_discarder::psymtab_discarder): Update.
(psymtab_discarder::~psymtab_discarder): Update.
(ALL_OBJFILE_PSYMTABS): Rewrite.
* objfiles.h (struct objfile) <psymtabs, psymtabs_addrmap,
free_psymtabs, psymbol_cache, global_psymbols, static_psymbols>:
Remove fields.
<partial_symtabs>: New field.
(class objfile_psymtabs): Move from psymtab.h. Update.
* objfiles.c (objfile::objfile): Initialize partial_symtabs, not
psymbol_cache.
(objfile::~objfile): Don't destroy psymbol_cache.
* mdebugread.c (parse_partial_symbols): Update.
* dwarf2read.c (create_addrmap_from_index)
(create_addrmap_from_aranges, dw2_find_pc_sect_compunit_symtab)
(process_psymtab_comp_unit_reader, dwarf2_build_psymtabs_hard)
(add_partial_subprogram, dwarf2_ranges_read): Update.
* dwarf-index-write.c (write_address_map)
(write_one_signatured_type, recursively_write_psymbols)
(class debug_names, class debug_names, write_psymtabs_to_index):
Update.
This changes symbol_set_names to take an objfile_per_bfd_storage
argument, and updates the users. It also changes PSYMBOL_SET_NAMES to
take this argument directly; I feel this clarifies the storage
location of objects created in psymtab.c.
gdb/ChangeLog
2019-01-10 Tom Tromey <tom@tromey.com>
* symtab.h (SYMBOL_SET_NAMES): Update.
(symbol_set_names): Update.
(MSYMBOL_SET_NAMES): Update.
* symtab.c (symbol_set_names): Change argument to be an
objfile_per_bfd_storage.
* psymtab.c (add_psymbol_to_bcache): Update.
* psympriv.h (PSYMBOL_SET_NAMES): Take per_bfd argument.
This changes create_demangled_names_hash to take an
objfile_per_bfd_storage parameter. This makes it clearer where it is
storing the objects it allocates.
gdb/ChangeLog
2019-01-10 Tom Tromey <tom@tromey.com>
* symtab.c (create_demangled_names_hash): Change argument to be an
objfile_per_bfd_storage.
(symbol_set_names): Update.
Existing callers to init_psymbol_list were checking to see if psymbols
had already been initialized. It seemed better to me to do this check
directly in init_psymbol_list, simplifying the callers.
gdb/ChangeLog
2019-01-10 Tom Tromey <tom@tromey.com>
* xcoffread.c (xcoff_initial_scan): Unconditionally call
init_psymbol_list.
* psymtab.c (init_psymbol_list): Do nothing if already called.
* psympriv.h (init_psymbol_list): Add comment.
* dwarf2read.c (dwarf2_build_psymtabs): Unconditionally call
init_psymbol_list.
* dbxread.c (dbx_symfile_read): Unconditionally call
init_psymbol_list.
This changes add_psymbol_to_list to use an enum, rather than a pointer
to a vector, to decide where to put the new symbol. This reduces the
number of direct references to the static_psymbols and global_psymbols
members of the objfile, which is handy in a later patch.
gdb/ChangeLog
2019-01-10 Tom Tromey <tom@tromey.com>
* xcoffread.c (scan_xcoff_symtab): Update.
* psymtab.c (add_psymbol_to_list): Replace "list" parameter with
"where".
* mdebugread.c (parse_partial_symbols)
(handle_psymbol_enumerators): Update.
* dwarf2read.c (add_partial_symbol, load_partial_dies): Update.
* dbxread.c (read_dbx_symtab): Update.
* psympriv.h (psymbol_placement): New enum.
(add_psymbol_to_list): Update.
start_psymtab_common takes references to the global_psymbols and
static_psymbols vectors, but it also has an objfile parameter. This
is redundant, so this patch simplifies the function by removing those
reference parameters.
gdb/ChangeLog
2019-01-10 Tom Tromey <tom@tromey.com>
* xcoffread.c (xcoff_start_psymtab): Remove global_psymbols and
static_psymbols parameters.
(scan_xcoff_symtab): Update.
* psymtab.c (start_psymtab_common): Remove global_psymbols and
static_psymbols parameters.
* psympriv.h (start_psymtab_common): Update.
* mdebugread.c (parse_partial_symbols): Update.
* dwarf2read.c (create_partial_symtab): Update.
* dbxread.c (read_dbx_symtab): Update.
(start_psymtab): Remove global_psymbols and static_psymbols
parameters.
allocate_psymtab has long cleared the new psymtab that is returned.
This patch documents this behavior and then removes some redundant
initializations.
gdb/ChangeLog
2019-01-10 Tom Tromey <tom@tromey.com>
* xcoffread.c (xcoff_end_psymtab): Remove some initializations.
* psymtab.c (allocate_psymtab): Add comment.
* psympriv.h (allocate_psymtab): Add comment.
* dwarf2read.c (dwarf2_create_include_psymtab): Remove some
initializations.
* dbxread.c (dbx_end_psymtab): Remove some initializations.
This moves a couple of mdebugread-related declarations from symfile.h
to mdebugread.h, which seemed more appropriate.
gdb/ChangeLog
2019-01-10 Tom Tromey <tom@tromey.com>
* symfile.h (mdebug_build_psymtabs, elfmdebug_build_psymtabs):
Don't declare.
* mipsread.c: Include mdebugread.h.
* mdebugread.h (mdebug_build_psymtabs, elfmdebug_build_psymtabs):
Declare.
* elfread.c: Include mdebugread.h.
This removes the ALL_OBJSECTIONS macro, replacing its uses with ranged
for loops.
The special code in this macro for noticing a "break" from the inner
loop was only needed in a single place; so rather than try to
replicate this, I've simply replaced that use with a "goto".
gdb/ChangeLog
2019-01-09 Tom Tromey <tom@tromey.com>
* symfile.c (overlay_invalidate_all, find_pc_overlay)
(find_pc_mapped_section, list_overlays_command)
(map_overlay_command, unmap_overlay_command)
(simple_overlay_update): Use all_objfiles.
* spu-tdep.c (spu_overlay_update): Use all_objfiles.
* printcmd.c (info_symbol_command): Use all_objfiles.
* objfiles.h (ALL_OBJSECTIONS): Remove.
* maint.c (maintenance_translate_address): Use all_objfiles.
* gcore.c (gcore_create_callback): Use all_objfiles.
(objfile_find_memory_regions): Likewise.
This removes the ALL_OBJFILES and ALL_FILETABS macros, replacing them
with ranged for loops.
gdb/ChangeLog
2019-01-09 Tom Tromey <tom@tromey.com>
* symtab.c (find_line_symtab, info_sources_command)
(make_source_files_completion_list): Use objfile_compunits.
* source.c (select_source_symtab): Use objfile_compunits.
* objfiles.h (struct objfile): Update comment.
(ALL_OBJFILES): Remove.
(ALL_FILETABS): Remove.
* mi/mi-cmd-file.c (mi_cmd_file_list_exec_source_files): Use
objfile_compunits.
This removes ALL_OBJFILE_FILETABS, replacing its uses with ranged for
loops.
gdb/ChangeLog
2019-01-09 Tom Tromey <tom@tromey.com>
* symmisc.c (print_objfile_statistics, dump_objfile)
(maintenance_print_symbols): Use compunit_filetabs.
* source.c (forget_cached_source_info_for_objfile): Use
compunit_filetabs.
* objfiles.h (ALL_OBJFILE_FILETABS): Remove.
(ALL_FILETABS): Use compunit_filetabs.
* objfiles.c (objfile_relocate1): Use compunit_filetabs.
* coffread.c (coff_symtab_read): Use compunit_filetabs.
This removes ALL_COMPUNIT_FILETABS, replacing its uses with ranged for
loops.
Because this is still used in the ALL_OBJFILE_FILETABS macro, in some
places a declaration had to be removed or renamed to avoid shadowing.
gdb/ChangeLog
2019-01-09 Tom Tromey <tom@tromey.com>
* symtab.h (ALL_COMPUNIT_FILETABS): Remove.
(compunit_filetabs): New.
* symtab.c (iterate_over_some_symtabs, find_pc_sect_line): Use
compunit_filetabs.
(info_sources_command, make_source_files_completion_list): Remove
declaration.
* symmisc.c (print_objfile_statistics, dump_objfile)
(maintenance_print_symbols): Remove declaration.
(maintenance_info_symtabs): Use compunit_filetabs.
(maintenance_info_line_tables): Likewise.
* source.c (select_source_symtab): Change local variable name.
(forget_cached_source_info_for_objfile): Remove declaration.
* objfiles.h (ALL_OBJFILE_FILETABS): Use compunit_filetabs.
* objfiles.c (objfile_relocate1): Remove declaration.
* mi/mi-cmd-file.c (mi_cmd_file_list_exec_source_files): Remove
declaration.
* maint.c (count_symtabs_and_blocks): Use compunit_filetabs.
* coffread.c (coff_symtab_read): Remove declaration.
* buildsym.c (buildsym_compunit::end_symtab_with_blockvector): Use
compunit_filetabs.
This removes the ALL_COMPUNITS, replacing its uses with two nested
ranged for loops.
gdb/ChangeLog
2019-01-09 Tom Tromey <tom@tromey.com>
* symtab.c (lookup_objfile_from_block)
(find_pc_sect_compunit_symtab, search_symbols)
(default_collect_symbol_completion_matches_break_on): Use
objfile_compunits.
* objfiles.h (ALL_COMPUNITS): Remove.
* maint.c (count_symtabs_and_blocks): Use objfile_compunits.
* cp-support.c (add_symbol_overload_list_qualified): Use
objfile_compunits.
* ada-lang.c (ada_collect_symbol_completion_matches)
(ada_add_global_exceptions): Use objfile_compunits.
This removes the ALL_MSYMBOLS and ALL_OBJFILE_MSYMBOLS macros,
replacing their uses with ranged for loops.
In a couple of spots, a new declaration was needed in order to work
around shadowing; these are just temporary and are removed in a
subsequent patch.
gdb/ChangeLog
2019-01-09 Tom Tromey <tom@tromey.com>
* symtab.c (search_symbols)
(default_collect_symbol_completion_matches_break_on): Use
objfile_msymbols.
* ada-lang.c (ada_lookup_simple_minsym)
(ada_collect_symbol_completion_matches): Use objfile_msymbols.
* minsyms.c (find_solib_trampoline_target): Use objfile_msymbols.
* hppa-tdep.c (hppa_lookup_stub_minimal_symbol): Use
objfile_msymbols.
* coffread.c (coff_symfile_read): Use objfile_msymbols.
* symmisc.c (dump_msymbols): Use objfile_msymbols.
* objc-lang.c (find_methods): Use objfile_msymbols.
(info_selectors_command, info_classes_command): Likewise.
* stabsread.c (scan_file_globals): Use objfile_msymbols.
* objfiles.h (class objfile_msymbols): New.
(ALL_OBJFILE_MSYMBOLS): Remove.
(ALL_MSYMBOLS): Remove.
This removes most uses of ALL_OBJFILES, replacing them with ranged for
loops. The remaining uses are all in macros, and will be removed in
subsequent patches.
gdb/ChangeLog
2019-01-09 Tom Tromey <tom@tromey.com>
* symtab.c (iterate_over_symtabs, matching_obj_sections)
(expand_symtab_containing_pc, lookup_static_symbol)
(basic_lookup_transparent_type, find_pc_sect_compunit_symtab)
(find_symbol_at_address, find_line_symtab, find_main_name): Use
all_objfiles.
* probe.c (find_probe_by_pc, collect_probes): Use all_objfiles.
* breakpoint.c (create_overlay_event_breakpoint)
(create_longjmp_master_breakpoint)
(create_std_terminate_master_breakpoint)
(create_exception_master_breakpoint): Use all_objfiles.
* linux-thread-db.c (try_thread_db_load_from_pdir)
(has_libpthread): Use all_objfiles.
* ada-lang.c (add_nonlocal_symbols): Use all_objfiles.
* linespec.c (iterate_over_all_matching_symtabs)
(search_minsyms_for_name): Use all_objfiles.
* maint.c (maintenance_info_sections): Use all_objfiles.
* main.c (captured_main_1): Use all_objfiles.
* spu-tdep.c (spu_objfile_from_frame): Use all_objfiles.
* guile/scm-objfile.c (gdbscm_objfiles): Use all_objfiles.
* guile/scm-pretty-print.c
(ppscm_find_pretty_printer_from_objfiles): Use all_objfiles.
* solib-spu.c (append_ocl_sos): Use all_objfiles.
* symmisc.c (maintenance_print_symbols): Use all_objfiles.
(maintenance_print_msymbols): Use all_objfiles.
* source.c (select_source_symtab): Use all_objfiles.
* jit.c (jit_find_objf_with_entry_addr): Use all_objfiles.
* symfile.c (remove_symbol_file_command)
(expand_symtabs_matching, map_symbol_filenames): Use
all_objfiles.
* ppc-linux-tdep.c (ppc_linux_spe_context_inferior_created): Use
all_objfiles.
* dwarf2-frame.c (dwarf2_frame_find_fde): Use all_objfiles.
* objc-lang.c (find_methods): Use all_objfiles.
* objfiles.c (have_partial_symbols, have_full_symbols)
(have_minimal_symbols, qsort_cmp)
(default_iterate_over_objfiles_in_search_order): Use
all_objfiles.
* hppa-tdep.c (find_unwind_entry): Use all_objfiles.
* psymtab.c (maintenance_print_psymbols): Use all_objfiles.
(maintenance_check_psymtabs): Use all_objfiles.
(ALL_PSYMTABS): Remove.
* compile/compile-object-run.c (do_module_cleanup): Use
all_objfiles.
* blockframe.c (find_pc_partial_function): Use all_objfiles.
* cp-support.c (add_symbol_overload_list_qualified): Use
all_objfiles.
* windows-tdep.c (windows_iterate_over_objfiles_in_search_order):
Use all_objfiles.
* dwarf-index-write.c (save_gdb_index_command): Use all_objfiles.
* python/py-xmethods.c (gdbpy_get_matching_xmethod_workers): Use
all_objfiles.
* python/py-objfile.c (objfpy_lookup_objfile_by_name)
(objfpy_lookup_objfile_by_build_id): Use all_objfiles.
* python/py-prettyprint.c (find_pretty_printer_from_objfiles):
Uses all_objfiles.
* solib.c (solib_read_symbols): Use all_objfiles
This removes the ALL_PSPACE_OBJFILES macro in favor of ranged for
loops.
gdb/ChangeLog
2019-01-09 Tom Tromey <tom@tromey.com>
* probe.c (parse_probes_in_pspace): Use all_objfiles.
* guile/scm-progspace.c (gdbscm_progspace_objfiles): Use
all_objfiles.
* objfiles.h (ALL_PSPACE_OBJFILES): Remove.
* symmisc.c (print_symbol_bcache_statistics)
(print_objfile_statistics, maintenance_print_objfiles)
(maintenance_info_symtabs, maintenance_check_symtabs)
(maintenance_expand_symtabs, maintenance_info_line_tables): Use
all_objfiles.
* source.c (forget_cached_source_info): Use all_objfiles.
* symfile-debug.c (set_debug_symfile): Use all_objfiles.
* elfread.c (elf_gnu_ifunc_resolve_by_cache)
(elf_gnu_ifunc_resolve_by_got): Use all_objfiles.
* objfiles.c (update_section_map): Use all_objfiles.
(shared_objfile_contains_address_p): Likewise.
* psymtab.c (maintenance_info_psymtabs): Use all_objfiles.
* python/py-progspace.c (pspy_get_objfiles): Use all_objfiles.
This introduces an iterable object which can be used to iterate over
objfiles. It also introduces a generic "next_iterator", which can be
used to iterate over types that have a "next" field.
gdb/ChangeLog
2019-01-09 Tom Tromey <tom@tromey.com>
* common/next-iterator.h: New file.
* objfiles.h (class all_objfiles): New.
(struct objfile_iterator): New.
2019-01-09 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* NEWS: Move the description of the changed "frame", "select-frame",
and "info frame" commands to the Changed commands section.
An upcoming sync with gcc's libiberty [1] will remove support for old
mangling schemes (GNU v2, Lucid, ARM, HP and EDG). It will remove the
cplus_demangle_opname function, so we need to get rid of its usages in
GDB (it's a GNU v2 specific function).
I think the changes are mostly relatively obvious, some hacks that were
necessary to support overloaded operators with GNU v2 mangling are not
needed anymore.
The change in stabsread.c is perhaps less obvious. I think we could get
rid of more code in that region that is specific to old mangling
schemes, but I chose to do only the minimal changes required to remove
the cplus_demangle_opname uses. There is also a detailed comment just
above that explaining how GNU v2 and v3 mangled symbols are handled, I
decided to leave it as-is, since I wasn't sure which part to remove,
change or leave there.
[1] The commit "Remove support for demangling GCC 2.x era mangling
schemes.", specifically.
gdb/ChangeLog:
* gdbtypes.c (check_stub_method_group): Remove handling of old
mangling schemes.
* linespec.c (find_methods): Likewise.
* stabsread.c (read_member_functions): Likewise.
* valops.c (search_struct_method): Likewise.
(value_struct_elt_for_reference): Likewise.
* NEWS: Mention this change.
gdb/testsuite/ChangeLog:
* gdb.cp/demangle.exp (test_gnu_style_demangling): Rename to...
(test_gnuv3_style_demangling): ... this.
(test_lucid_style_demangling): Remove.
(test_arm_style_demangling): Remove.
(test_hp_style_demangling): Remove.
(do_tests): Remove calls to the above.
gdb/doc/ChangeLog:
* gdb.texinfo (Print Settings): Remove mention of specific
demangle-style values, just refer to the in-process help.
When printing source lines with calls to print_source_lines we need to
pass a start line number and an end line number. The end line number
is calculated by calling get_lines_to_list and adding this value to
the start line number. For example this code from list_command:
print_source_lines (cursal.symtab, first,
first + get_lines_to_list (), 0);
The problem is that get_lines_to_list returns a value based on the
GDB setting `set listsize LISTSIZE`. By default LISTSIZE is 10,
however, its also possible to set LISTSIZE to unlimited, in which
case get_lines_to_list will return INT_MAX.
As the parameter signature for print_source_lines is:
void print_source_lines (struct symtab *, int, int,
print_source_lines_flags);
and `first` in the above code is an `int`, then when LISTSIZE is
`unlimited` the above code will result in signed integer overflow,
which is undefined.
The solution in this patch is a new class source_lines_range that can
be constructed from a single line number and a direction (forward or
backward). The range is then constructed from the line number and the
value of get_lines_to_list.
gdb/ChangeLog:
* cli/cli-cmds.c (list_command): Pass a source_lines_range to
print_source_lines.
* source.c (print_source_lines_base): Update line number check.
(print_source_lines): New function.
(source_lines_range::source_lines_range): New function.
* source.h (class source_lines_range): New class.
(print_source_lines): New declaration.
I noticed that when running this test:
make check-gdb RUNTESTFLAGS="--target_board=native-gdbserver gdb.mi/mi-break.exp"
I would occasionally see some UNRESOLVED test results like this:
(gdb)
PASS: gdb.mi/mi-break.exp: mi-mode=separate: breakpoint at main
Expecting: ^(kill[
]+)?(.*[
]+[(]gdb[)]
[ ]*)
kill
&"kill\n"
~"Kill the program being debugged? (y or n) [answered Y; input not from terminal]\n"
=thread-group-exited,id="i1"
ERROR: Got interactive prompt.
UNRESOLVED: gdb.mi/mi-break.exp: mi-mode=separate:
The problem appears to be that the expect buffer fills up to include
the '(y or n)' prompt without including the following lines.
The pattern supplied by the outer test script is looking for the
following lines. As the following lines are not present then expect
matches on the interactive prompt case rather than the case for the
user supplied pattern.
The problem with this is that we are not really at an interactive
prompt, GDB is providing an answer for us and then moving on. When I
examine a successful run of the test the output from GDB is identical,
the only difference is where expect happens to buffer the output from
GDB.
This patch remove all special handling of the interactive prompt
case. This means that if we ever break GDB and start seeing an
unexpected interactive prompt then tests will rely on a timeout to
fail, instead of having dedicated interactive prompt detection, but
this solves the problem that an auto-answered prompt looks very
similar to an interactive prompt.
With this patch in place I can now leave the following loop running
indefinitely, where before it would fail usually after ~10
iterations.
while make check-gdb RUNTESTFLAGS="--target_board=native-gdbserver gdb.mi/mi-break.exp"; \
do /bin/true; \
done
gdb/testsuite/ChangeLog:
* lib/mi-support.exp (mi_gdb_test): Remove interactive prompt
case.
Valgrind reports a leak in many tests, such as:
==9382== 16 bytes in 1 blocks are definitely lost in loss record 236 of 3,282
==9382== at 0x4C2BE6D: malloc (vg_replace_malloc.c:309)
==9382== by 0x4197AF: xrealloc (common-utils.c:64)
==9382== by 0x51D16A: xresizevec<linespec_canonical_name> (poison.h:170)
==9382== by 0x51D16A: add_sal_to_sals(linespec_state*, std::vector<symtab_and_line, std::allocator<symtab_and_line> >*, symtab_and_line*, char const*, int) (linespec.c:1041)
==9382== by 0x51E2BF: create_sals_line_offset (linespec.c:2215)
==9382== by 0x51E2BF: convert_linespec_to_sals(linespec_state*, linespec*) (linespec.c:2358)
==9382== by 0x521B5D: convert_explicit_location_to_sals (linespec.c:2473)
Fix leak by xfree-ing self->canonical_names in linespec_state_destructor.
The leak probably appeared with the patch 'Remove cleanup from linespec.c',
as there was a cleanup to xfree canonical_names before the patch.
Tested on Debian/amd64, native and under valgrind.
2019-01-09 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* linespec.c (linespec_state_destructor): Free self->canonical_names.
PR gdb/24060 points out a compilation failure of the C, Fortran and Pascal
parsers when they are built using the macOS system bison. The bug is a name
clash between the VARIABLE token name and the VARIABLE enumerator in ui-out.h.
This patch renames VARIABLE in c-exp.y, f-exp.y and p-exp.y to DOLLAR_VARIABLE
to avoid the clash. It also renames similar variables in other .y files so
that all languages use the same name.
gdb/ChangeLog
2019-01-07 Tom Tromey <tom@tromey.com>
2019-01-07 Simon Marchi <simon.marchi@ericsson.com>
PR gdb/24060:
* ada-exp.y (DOLLAR_VARIABLE): Rename from SPECIAL_VARIABLE.
* ada-lex.l (DOLLAR_VARIABLE): Likewise.
* c-exp.y (DOLLAR_VARIABLE): Rename from VARIABLE.
* f-exp.y (DOLLAR_VARIABLE): Likewise.
* m2-exp.y (DOLLAR_VARIABLE): Rename from INTERNAL_VAR.
* p-exp.y (DOLLAR_VARIABLE): Rename from VARIABLE.
Declarations for functions in source.c are split between source.h and
symtab.h. This commit moves the small number that are in symtab.h
into source.h. There's just one file that needs to add an include of
source.h in order to build.
I've moved the function header comments from source.c to source.h
inline with the recommended GDB style.
gdb/ChangeLog:
* source.c (select_source_symtab): Move header comment to
declaration in source.h.
(forget_cached_source_info_for_objfile): Likewise.
(forget_cached_source_info): Likewise.
(identify_source_line): Likewise.
* source.h (identify_source_line): Move declaration from symtab.h
and add comment from source.c
(print_source_lines): Likewise.
(forget_cached_source_info_for_objfile): Likewise.
(forget_cached_source_info): Likewise.
(select_source_symtab): Likewise.
(enum print_source_lines_flag): Move definition from symtab.h.
* symtab.h (identify_source_line): Move declaration to source.h.
(print_source_lines): Likewise.
(forget_cached_source_info_for_objfile): Likewise.
(forget_cached_source_info): Likewise.
(select_source_symtab): Likewise.
(enum print_source_lines_flag): Move definition to source.h.
* tui/tui-hooks.c: Add 'source.h' include.
...by which I mean from high line number to low, not, actually
backward character by character!
Commit:
commit 62f29fda90
Date: Tue Oct 9 22:21:05 2018 -0600
Highlight source code using GNU Source Highlight
introduced a regression in the test gdb.linespec/explicit.exp, in
which a request is made to GDB to print a reverse sequence of lines,
from +10 to -10 from the current line number. The expected behaviour
is that GDB prints nothing. The above commit changed this so that GDB
now prints:
Line number 32 out of range; /path/to/gdb/testsuite/gdb.linespec/explicit.c has 71 lines.
which is a little confusing.
This commit fixes the regression, and restores the behaviour that GDB
prints nothing.
While I was passing I noticed a call to `back` on a std::string that I
was concerned could be empty if the request for source lines returns
an empty string. I don't know if it would be possible for a request
for lines to return an empty string, I guess it should be impossible,
in which case, maybe this should be an assertion, but adding a `empty`
check, seems like an easy and cheap safety net.
gdb/ChangeLog:
* source.c (print_source_lines_base): Handle requests to print
reverse line number sequences, and guard against empty lines
string.
In this commit:
commit 62f29fda90
Date: Tue Oct 9 22:21:05 2018 -0600
Highlight source code using GNU Source Highlight
A bug was introduced such that when displaying source code from a file
with lines `\r\n` GDB would print `^M` at the end of each line.
This caused a regression on the test gdb.fortran/nested-funcs.exp,
which happens to have `\r\n` line endings.
gdb/ChangeLog:
* source.c (print_source_lines_base): Fix skip of '\r' if next
character is '\n'.
This removes the remaining cleanups from c-exp.y by moving some
globals into c_parse_state, and changing expansion_obstack to be an
auto_obstack.
gdb/ChangeLog
2019-01-06 Tom Tromey <tom@tromey.com>
* c-exp.y (struct c_parse_state) <macro_original_text,
expansion_obstack>: New member.
(macro_original_text, expansion_obstack): Remove globals.
(scan_macro_expansion, scanning_macro_expansion)
(finished_macro_expansion): Update.
(scan_macro_cleanup): Remove.
(yylex, c_parse): Update.
This removes a string-related cleanup from c-exp.y, by adding a new
member to c_parse_state to store the strings.
gdb/ChangeLog
2019-01-06 Tom Tromey <tom@tromey.com>
* c-exp.y (struct c_parse_state) <strings>: New member.
(operator_stoken): Update.
This removes the use of VEC from parse.c and, at the same time,
removes some related cleanups from c-exp.y.
gdb/ChangeLog
2019-01-06 Tom Tromey <tom@tromey.com>
* parser-defs.h (type_ptr): Remove typedef. Don't declare VEC.
(union type_stack_elt) <typelist_val>: Now a pointer to
std::vector.
(type_stack_cleanup): Don't declare.
(push_typelist): Update.
* parse.c (pop_typelist): Return a std::vector.
(push_typelist): Take a std::vector.
(follow_types): Update. Do not free args.
(type_stack_cleanup): Remove.
* c-exp.y (struct c_parse_state): New.
(cpstate): New global.
(type_aggregate_p, exp, ptr_operator, parameter_typelist)
(nonempty_typelist): Update.
(func_mod): Create a new vector.
(c_parse): Create a c_parse_state.
(check_parameter_typelist): Do not delete params.
(function_method): Update. Do not delete type_list.
PR gdb/28155 notes a crash in "finish" that occurs with a particular
source file compiled by clang.
The bug is the typical gdb problem of a missing call to check_typedef.
clang emits a function whose return type is a typedef to void.
get_return_value asserts that the return type is not void, but the
callers were not using check_typedef first.
gdb/ChangeLog
2019-01-06 Tom Tromey <tom@tromey.com>
PR gdb/28155:
* python/py-finishbreakpoint.c (bpfinishpy_init): Use
check_typedef.
* infcmd.c (finish_command_fsm_should_stop): Use check_typedef.
(print_return_value): Likewise.
gdb/testsuite/ChangeLog
2019-01-06 Tom Tromey <tom@tromey.com>
PR gdb/28155:
* gdb.dwarf2/typedef-void-finish.exp: New file.
Now that gdb is transitioning away from cleanups, there is no reason
to keep the cleanup and exception checker scripts around. This patch
removes them.
gdb/ChangeLog
2019-01-05 Tom Tromey <tom@tromey.com>
* contrib/cleanup_check.py: Remove.
* contrib/gcc-with-excheck: Remove.
* contrib/exsummary.py: Remove.
* contrib/excheck.py: Remove.
Running any program twice on Windows current results in GDB crashing:
$ gdb -q any_program
(gdb) run
$ gdb dummy -batch -ex run -ex run
[New Thread 684960.0xe5878]
[New Thread 684960.0xd75ac]
[New Thread 684960.0xddac8]
[New Thread 684960.0xc1f50]
[Thread 684960.0xd75ac exited with code 0]
[Thread 684960.0xddac8 exited with code 0]
[Thread 684960.0xc1f50 exited with code 0]
[Inferior 1 (process 684960) exited normally]
(gdb) run
Segmentation fault
The crash happens while processing the CREATE_PROCESS_DEBUG_EVENT
for the second run; in particular, we have in get_windows_debug_event:
| case CREATE_PROCESS_DEBUG_EVENT:
| [...]
| if (main_thread_id)
| windows_delete_thread (ptid_t (current_event.dwProcessId, 0,
| main_thread_id),
| 0);
The problem is that main_thread_id is the TID of the main thread from
the *previous* inferior, and this code is trying to delete that
thread. The problem is that it is constructing a PTID by pairing
the TID of the previous inferior with the PID of the new inferior.
As a result, when we dig inside windows_delete_thread to see
how it would handle that, we see...
| delete_thread (find_thread_ptid (ptid));
Since the PTID is bogus, we end up calling delete_thread with
a NULL thread_info. It used to be harmless, turning the delete_thread
into a nop, but the following change...
| commit 0803633106
| Date: Thu Nov 22 16:09:14 2018 +0000
| Subject: Per-inferior thread list, thread ranges/iterators, down with ALL_THREADS, etc.
... changed delete_thread to get the list of threads from
the inferior, which itself is now accessed via the given
thread_info. This is the corresponding diff that shows the change:
| - for (tp = thread_list; tp; tpprev = tp, tp = tp->next)
| + for (tp = thr->inf->thread_list; tp; tpprev = tp, tp = tp->next)
As a result of this, passing a NULL thread_info is no longer
an option!
Stepping back a bit, the reason behind deleting the thread late
could be found in a patch from Dec 2003, which laconically explains:
| commit 87a45c9606
| Date: Fri Dec 26 00:39:04 2003 +0000
|
| * win32-nat.c (get_child_debug_event): Keep main thread id around
| even after thread exits since Windows insists on continuing to
| report events against it.
A look at the gdb-patches archives did not provide any additional
clues (https://www.sourceware.org/ml/gdb-patches/2003-12/msg00478.html).
It is not clear whether this is still needed or not. This patch
assumes that whatever isue there was, the versions of Windows
we currently support no longer have it.
With that in mind, this commit fixes the issue by deleting the thread
when the inferior sends the exit-process event as opposed to deleting it
later, while starting a new inferior.
This also restores the printing of the thread-exit notification for
the main thread, which was missing before. Looking at the transcript
of the example shown above, we can see 4 thread creation notifications,
and only 3 notifications for thread exits. Now creation and exit
notifications are balanced.
In the handling of EXIT_THREAD_DEBUG_EVENT, the main_thread_id
check is removed because deemed unnecessary: The main thread was
introduced by a CREATE_PROCESS_DEBUG_EVENT, and thus the kernel
is expected to report its death via EXIT_PROCESS_DEBUG_EVENT.
And finally, because the behavior of delete_thread did change
(albeit when getting a value we probably never expected to receive),
this patch also adds a gdb_assert. The purpose is to provide some
immediate information in case there are other callers that mistakenly
call delete_thread with a NULL thread info. This can be useful
information when direct debugging of GDB isn't an option.
gdb/ChangeLog:
* thread.c (delete_thread_1): Add gdb_assert that THR is not
NULL. Initialize tpprev to NULL instead of assigning it
to NULL on the next statement.
* windows-nat.c (windows_delete_thread): Remove check for
main_thread_id before printing thread exit notifications.
(get_windows_debug_event) <EXIT_THREAD_DEBUG_EVENT>:
Remove thread ID check against main_thread_id.
<CREATE_PROCESS_DEBUG_EVENT>: Remove call to
windows_delete_thread.
<EXIT_PROCESS_DEBUG_EVENT>: Add call to windows_delete_thread.
I noticed a few places where a Usage line in gdb did not use upper
case for metasyntactic variables. This patch fixes all the instances
I found.
Tested on x86-64 Fedora 28.
gdb/ChangeLog
2019-01-04 Tom Tromey <tom@tromey.com>
* compile/compile.c (_initialize_compile): Use upper case for
metasyntactic variables.
* symmisc.c (_initialize_symmisc): Use upper case for
metasyntactic variables.
* psymtab.c (_initialize_psymtab): Use upper case for
metasyntactic variables.
* demangle.c (demangle_command): Use upper case for metasyntactic
variables.
(_initialize_demangler): Likewise.
* ax-gdb.c (_initialize_ax_gdb): Use upper case for metasyntactic
variables.
valgrind pointed out that the string copy in tui_set_source_content
was not allocating space for the trailing \0:
==3941== Invalid write of size 1
==3941== at 0x4C3239F: strcpy (vg_replace_strmem.c:512)
==3941== by 0x72036B: strcpy (string_fortified.h:90)
==3941== by 0x72036B: tui_set_source_content(symtab*, int, int) (tui-source.c:203)
Looking closer, I don't think there's a need to check the line width
here, so this patch changes it to use xstrdup.
Tested by re-running the TUI under valgrind. There are still other
valgrind reports from TUI code, but this one is gone.
gdb/ChangeLog
2019-01-03 Tom Tromey <tom@tromey.com>
* tui/tui-source.c (tui_set_source_content): Use xstrdup.
py-symtab.c has some questionable casts of Py_None to symtab_object*.
This patch avoids these casts by instead using downcasts at the
appropriate places.
gdb/ChangeLog
2019-01-03 Tom Tromey <tom@tromey.com>
* python/py-symtab.c (salpy_str): Update.
(struct salpy_sal_object) <symtab>: Now a PyObject.
(salpy_dealloc): Update.
(del_objfile_sal): Use gdbpy_ref.
This improves the reference counting in py-type.c by using gdbpy_ref
and gdbpy_ref::new_reference in more places.
gdb/ChangeLog
2019-01-03 Tom Tromey <tom@tromey.com>
* python/py-type.c (convert_field): Use new_reference. Return
gdbpy_ref.
(make_fielditem): Return gdbpy_ref.
(typy_fields): Update.
(typy_getitem): Update.
(field_name): Return gdbpy_ref. Use new_reference.
(typy_iterator_iternext): Update.
This simplifies gdbpy_stop_recording, by having it use Py_RETURN_NONE
rather than writing it out manually, and by usin the idiomatic
GDB_PY_HANDLE_EXCEPTION.
gdb/ChangeLog
2019-01-03 Tom Tromey <tom@tromey.com>
* python/py-record.c (gdbpy_stop_recording): Use Py_RETURN_NONE.
This changes some more place in the Python code to use gdbpy_ref
rather than explicit reference counting. While doing this I found a
latent bug in typy_fields_items -- it was not checking for errors in
one spot. I also changed valpy_dealloc to use Py_XDECREF rather than
an explicit "if".
gdb/ChangeLog
2019-01-03 Tom Tromey <tom@tromey.com>
* python/py-value.c (valpy_dealloc): Use Py_XDECREF.
* python/py-type.c (typy_fields_items): Use gdbpy_ref.
* python/py-progspace.c (pspy_set_printers): Use gdbpy_ref.
(pspy_set_frame_filters, pspy_set_frame_unwinders)
(pspy_set_type_printers): Likewise.
* python/py-function.c (fnpy_init): Use gdbpy_ref.
* python/py-cmd.c (cmdpy_init): Use gdbpy_ref.
* python/py-objfile.c (objfpy_set_printers): Use gdbpy_ref.
(objfpy_set_frame_filters, objfpy_set_frame_unwinders)
(objfpy_set_type_printers): Likewise.
This introduces a new class that wraps PyErr_Fetch and PyErr_Restore,
and then changes all the callers in gdb to use it. This reduces the
amount of explicit reference counting that is done in the Python code.
I also found and fixed a latent bug in gdbpy_print_stack -- it was not
correctly checking some error conditions, nor clearing the exception
when needed.
gdb/ChangeLog
2019-01-03 Tom Tromey <tom@tromey.com>
* python/python.c (gdbpy_enter, ~gdbpy_enter): Update.
(gdbpy_print_stack): Use gdbpy_err_fetch.
* python/python-internal.h (class gdbpy_err_fetch): New class.
(class gdbpy_enter) <m_error_type, m_error_value,
m_error_traceback>: Remove.
<m_error>: New member.
(gdbpy_exception_to_string): Don't declare.
* python/py-varobj.c (py_varobj_iter_next): Use gdbpy_err_fetch.
* python/py-value.c (convert_value_from_python): Use
gdbpy_err_fetch.
* python/py-utils.c (gdbpy_err_fetch::to_string): Rename from
gdbpy_exception_to_string.
(gdbpy_handle_exception): Use gdbpy_err_fetch.
* python/py-prettyprint.c (print_stack_unless_memory_error): Use
gdbpy_err_fetch.
Remove cleanup from linux_nat_target::follow_fork, instead add a new
unique_ptr specialisation for holding lwp_info pointers and use this
to ensure the pointer is cleaned up when needed.
gdb/ChangeLog:
* linux-nat.c (delete_lwp_cleanup): Delete.
(struct lwp_deleter): New struct.
(lwp_info_up): New typedef.
(linux_nat_target::follow_fork): Delete cleanup, and make use of
lwp_info_up.
Replace cleanup in linux-fork.c:inferior_call_waitpid with a RAII
object.
gdb/ChangeLog:
* linux-fork.c (class scoped_switch_fork_info): New class.
(inferior_call_waitpid): Update to use scoped_switch_fork_info.
This patch removes the setup of a null_cleanup in
valops.c:find_overload_match, and all the calls to do_cleanups.
gdb/ChangeLog:
* valops.c (find_overload_match): Remove use of null_cleanup, and
calls to do_cleanups.
This patch changes cp-support.c:cp_func_name to return a
'gdb::unique_xmalloc_ptr<char>' instead of a 'char *'. This allows a
cleanup to be removed from valops.c:find_overload_match.
gdb/ChangeLog:
* compile/compile-cplus-types.c
(compile_cplus_instance::decl_name): Handle changes to
cp_func_name.
* cp-support.c (cp_func_name): Update header comment, update
return type.
* cp-support.h (cp_func_name): Update return type in declaration.
* valops.c (find_overload_match): Move temp_func local to top
level of function and change its type. Use temp_func to hold and
delete temporary string obtained from cp_func_name.
Convert one of the variables that requires a cleanup from a 'char *'
to a 'gdb::char_vector' in remote_target::remote_check_symbols.
Tested on x86-64/Linux with target_board native-gdbserver and
native-extended-gdbserver.
gdb/ChangeLog:
* remote.c (remote_target::remote_check_symbols): Convert `msg` to
gdb::char_vector, remove cleanup, and update uses of `msg`.
s0 is listed as both an int register name and an FP register name. The FP reg
name is wrong. This looks like a simple editting error, and has an easy fix.
Tested with riscv64-linux build and check, with no regressions.
gdb/
* riscv-tdep.c (riscv_freg_feature): Drop s0 name from f8.
This removes a cleanup from target-descriptions.c, by changing it to
use a unique_ptr instead. Note that a deletion adapter is used, even
though target_desc is allocated with new, to avoid moving target_desc
to target-descriptions.h.
gdb/ChangeLog
2019-01-02 Tom Tromey <tom@tromey.com>
* xml-tdesc.c (xml_cache): Hold a target_desc_up.
(tdesc_parse_xml): Remove cleanups.
* target-descriptions.h (make_cleanup_free_target_description):
Don't declare.
(target_desc_deleter): New struct.
(target_desc_up): New typedef.
* target-descriptions.c (target_desc_deleter::operator()): Rename
from free_target_description.
(make_cleanup_free_target_description): Remove.
This removes the remaining cleanups from linespec.c. This adds a
constructor and destructor to linespec_parser, but in a minimal way --
the parser could still benefit from a bit more C++-ification.
gdb/ChangeLog
2019-01-02 Tom Tromey <tom@tromey.com>
* linespec.c (struct linespec_parser): Rename from ls_parser. Add
constructor, destructor.
(linespec_parser): Remove typedef.
(~linespec_parser): Rename from linespec_parser_delete.
(linespec_lex_to_end, linespec_complete_label)
(linespec_complete): Update.
(decode_line_full): Remove cleanups.
(decode_line_1): Update.
Most callers of inferior_to_inferior_object already use a gdbpy_ref,
so this changes inferior_to_inferior_object to return one. Doing this
revealed that create_thread_object was not correctly handling the case
where inferior_to_inferior_object failed, so this patch fixes this as
well.
gdb/ChangeLog
2019-01-02 Tom Tromey <tom@tromey.com>
* python/python-internal.h (inferior_to_inferior_object): Change
return type.
* python/py-exitedevent.c (create_exited_event_object): Update.
* python/py-inferior.c (inferior_to_inferior_object): Return
gdbpy_ref.
(python_new_inferior, python_inferior_deleted)
(thread_to_thread_object, delete_thread_object)
(build_inferior_list, gdbpy_selected_inferior): Update.
* python/py-infthread.c (create_thread_object): Update. Also fail
if inferior_to_inferior_object fails.
This patch moves the per-inferior data related to displaced stepping to
be directly in the inferior structure, rather than in a container on the
side.
On notable difference is that previously, we deleted the state on
inferior exit, which guaranteed a clean state if re-using the inferior
for a new run or attach. We now need to reset the state manually.
At the same time, I changed step_saved_copy to be a gdb::byte_vector, so
it is automatically freed on destruction (which should plug the leak
reported here [1]).
[1] https://sourceware.org/ml/gdb-patches/2018-11/msg00202.html
gdb/ChangeLog:
* inferior.h (class inferior) <displaced_step_state>: New field.
* infrun.h (struct displaced_step_state): Move here from
infrun.c. Initialize fields, add constructor.
<inf>: Remove field.
<reset>: New method.
* infrun.c (struct displaced_step_inferior_state): Move to
infrun.h.
(displaced_step_inferior_states): Remove.
(get_displaced_stepping_state): Adust.
(displaced_step_in_progress_any_inferior): Adjust.
(displaced_step_in_progress_thread): Adjust.
(displaced_step_in_progress): Adjust.
(add_displaced_stepping_state): Remove.
(get_displaced_step_closure_by_addr): Adjust.
(remove_displaced_stepping_state): Remove.
(infrun_inferior_exit): Call displaced_step_state.reset.
(use_displaced_stepping): Don't check for NULL.
(displaced_step_prepare_throw): Call
get_displaced_stepping_state.
(displaced_step_fixup): Don't check for NULL.
(prepare_for_detach): Don't check for NULL.
When the call does not complete, the call_thread_fsm allocated
by new_call_thread_fsm is not cleaned up and deleted, which causes
the following leak e.g. in gdb.base/callfuncs.exp:
==29263== 560 bytes in 7 blocks are definitely lost in loss record 2,833 of 3,341
==29263== at 0x4C2E0BC: calloc (vg_replace_malloc.c:762)
==29263== by 0x405110: xcalloc (common-utils.c:84)
==29263== by 0x4E67EB: xcnew<call_thread_fsm> (poison.h:122)
==29263== by 0x4E67EB: new_call_thread_fsm (infcall.c:516)
==29263== by 0x4E67EB: call_function_by_hand_dummy(value*, type*, gdb::array_view<value*>, void (*)(void*, int), void*) (infcall.c:1154)
==29263== by 0x4E784E: call_function_by_hand(value*, type*, gdb::array_view<value*>) (infcall.c:693)
==29263== by 0x496111: eval_call(expression*, noside, int, value**, char const*, type*) [clone .isra.5] (eval.c:835)
Fix the leak by similarly doing cleanup/destroy when restoring
previous state machine.
Tested on debian/amd64, natively and under valgrind.
2019-01-02 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* infcall.c (call_function_by_hand_dummy): cleanup/destroy sm
in case of call that did not complete.
When using remote debugging server, and when debuggee filename is
inferred via qXfer:exec-file:read request, or sysroot starts with
"target:", this "target:" prefix of filepaths is not treated correctly
during debug file search - it appears in the middle of the looked up
paths.
In the following example, unpatched GDB can't find separate debug files for
neither the executable, nor standard libraries:
$ gdb -ex 'set debug separate-debug-file 1' -ex 'set sysroot target:/' -ex 'set debug-file-directory /usr/lib/debug:/home/j/hide' -ex 'target remote :3333' -ex 'break main' -ex 'continue' -ex 'bt' -ex 'info sharedlibrary' -ex 'set confirm off' -ex 'quit'
GNU gdb (Gentoo 9999 vanilla) 8.2.50.20181109-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://bugs.gentoo.org/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Remote debugging using :3333
Reading /home/j/test from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading /home/j/test from remote target...
Reading symbols from target:/home/j/test...
Looking for separate debug info (debug link) for target:/home/j/test
Trying target:/home/j/test.debug
Reading /home/j/test.debug from remote target...
Trying target:/home/j/.debug/test.debug
Reading /home/j/.debug/test.debug from remote target...
Trying /usr/lib/debug/target:/home/j/test.debug
Trying /home/j/hide/target:/home/j/test.debug
(No debugging symbols found in target:/home/j/test)
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
Reading symbols from target:/lib64/ld-linux-x86-64.so.2...
Looking for separate debug info (debug link) for target:/lib64/ld-linux-x86-64.so.2
Trying target:/lib64/ld-2.27.so.debug
Reading /lib64/ld-2.27.so.debug from remote target...
Trying target:/lib64/.debug/ld-2.27.so.debug
Reading /lib64/.debug/ld-2.27.so.debug from remote target...
Trying /usr/lib/debug/target:/lib64/ld-2.27.so.debug
Trying /home/j/hide/target:/lib64/ld-2.27.so.debug
(No debugging symbols found in target:/lib64/ld-linux-x86-64.so.2)
Looking for separate debug info (build-id) for system-supplied DSO at 0x7ffff7ffa000
Trying /usr/lib/debug/.build-id/fd/03d584bc1a90ba28be457635a02662c9f9c1f2.debug
Trying /home/j/hide/.build-id/fd/03d584bc1a90ba28be457635a02662c9f9c1f2.debug
0x00007ffff7dd7000 in ?? () from target:/lib64/ld-linux-x86-64.so.2
Breakpoint 1 at 0x4005eb
Continuing.
Reading /lib64/libpthread.so.0 from remote target...
Reading /lib64/libc.so.6 from remote target...
Looking for separate debug info (debug link) for target:/lib64/libpthread.so.0
Trying target:/lib64/libpthread-2.27.so.debug
Reading /lib64/libpthread-2.27.so.debug from remote target...
Trying target:/lib64/.debug/libpthread-2.27.so.debug
Reading /lib64/.debug/libpthread-2.27.so.debug from remote target...
Trying /usr/lib/debug/target:/lib64/libpthread-2.27.so.debug
Trying /home/j/hide/target:/lib64/libpthread-2.27.so.debug
Looking for separate debug info (debug link) for target:/lib64/libc.so.6
Trying target:/lib64/libc-2.27.so.debug
Reading /lib64/libc-2.27.so.debug from remote target...
Trying target:/lib64/.debug/libc-2.27.so.debug
Reading /lib64/.debug/libc-2.27.so.debug from remote target...
Trying /usr/lib/debug/target:/lib64/libc-2.27.so.debug
Trying /home/j/hide/target:/lib64/libc-2.27.so.debug
Breakpoint 1, 0x00000000004005eb in main ()
#0 0x00000000004005eb in main ()
From To Syms Read Shared Object Library
0x00007ffff7dd6e80 0x00007ffff7df4650 Yes (*) target:/lib64/ld-linux-x86-64.so.2
0x00007ffff7bbbb70 0x00007ffff7bcbfee Yes (*) target:/lib64/libpthread.so.0
0x00007ffff780f200 0x00007ffff7962d7c Yes (*) target:/lib64/libc.so.6
(*): Shared library is missing debugging information.
With current fix, the paths used always have target: in the beginning
and this helps to find all debug files:
$ gdb -ex 'set debug separate-debug-file 1' -ex 'set sysroot target:/' -ex 'set debug-file-directory /usr/lib/debug:/home/j/hide' -ex 'target remote :3333' -ex 'break main' -ex 'continue' -ex 'bt' -ex 'info sharedlibrary' -ex 'set confirm off' -ex 'quit'
GNU gdb (Gentoo 9999 vanilla) 8.2.50.20181109-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://bugs.gentoo.org/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Remote debugging using :3333
Reading /home/j/test from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading /home/j/test from remote target...
Reading symbols from target:/home/j/test...
Looking for separate debug info (debug link) for target:/home/j/test
Trying target:/home/j/test.debug
Reading /home/j/test.debug from remote target...
Trying target:/home/j/.debug/test.debug
Reading /home/j/.debug/test.debug from remote target...
Trying target:/usr/lib/debug//home/j/test.debug
Reading /usr/lib/debug//home/j/test.debug from remote target...
Trying target:/home/j/hide//home/j/test.debug
Reading /home/j/hide//home/j/test.debug from remote target...
Reading /home/j/hide//home/j/test.debug from remote target...
Reading symbols from target:/home/j/hide//home/j/test.debug...
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
Reading symbols from target:/lib64/ld-linux-x86-64.so.2...
Looking for separate debug info (debug link) for target:/lib64/ld-linux-x86-64.so.2
Trying target:/lib64/ld-2.27.so.debug
Reading /lib64/ld-2.27.so.debug from remote target...
Trying target:/lib64/.debug/ld-2.27.so.debug
Reading /lib64/.debug/ld-2.27.so.debug from remote target...
Trying target:/usr/lib/debug//lib64/ld-2.27.so.debug
Reading /usr/lib/debug//lib64/ld-2.27.so.debug from remote target...
Reading /usr/lib/debug//lib64/ld-2.27.so.debug from remote target...
Reading symbols from target:/usr/lib/debug//lib64/ld-2.27.so.debug...
Looking for separate debug info (build-id) for system-supplied DSO at 0x7ffff7ffa000
Trying /usr/lib/debug/.build-id/fd/03d584bc1a90ba28be457635a02662c9f9c1f2.debug
Trying /home/j/hide/.build-id/fd/03d584bc1a90ba28be457635a02662c9f9c1f2.debug
0x00007ffff7dd7000 in _start () from target:/lib64/ld-linux-x86-64.so.2
Breakpoint 1 at 0x4005ef: file test/test16.c, line 13.
Continuing.
Reading /lib64/libpthread.so.0 from remote target...
Reading /lib64/libc.so.6 from remote target...
Looking for separate debug info (debug link) for target:/lib64/libpthread.so.0
Trying target:/lib64/libpthread-2.27.so.debug
Reading /lib64/libpthread-2.27.so.debug from remote target...
Trying target:/lib64/.debug/libpthread-2.27.so.debug
Reading /lib64/.debug/libpthread-2.27.so.debug from remote target...
Trying target:/usr/lib/debug//lib64/libpthread-2.27.so.debug
Reading /usr/lib/debug//lib64/libpthread-2.27.so.debug from remote target...
Reading /usr/lib/debug//lib64/libpthread-2.27.so.debug from remote target...
Looking for separate debug info (debug link) for target:/lib64/libc.so.6
Trying target:/lib64/libc-2.27.so.debug
Reading /lib64/libc-2.27.so.debug from remote target...
Trying target:/lib64/.debug/libc-2.27.so.debug
Reading /lib64/.debug/libc-2.27.so.debug from remote target...
Trying target:/usr/lib/debug//lib64/libc-2.27.so.debug
Reading /usr/lib/debug//lib64/libc-2.27.so.debug from remote target...
Reading /usr/lib/debug//lib64/libc-2.27.so.debug from remote target...
Breakpoint 1, main () at test/test16.c:13
13 for ( i=0; i<10; ++i)
#0 main () at test/test16.c:13
From To Syms Read Shared Object Library
0x00007ffff7dd6e80 0x00007ffff7df4650 Yes target:/lib64/ld-linux-x86-64.so.2
0x00007ffff7bbbb70 0x00007ffff7bcbfee Yes target:/lib64/libpthread.so.0
0x00007ffff780f200 0x00007ffff7962d7c Yes target:/lib64/libc.so.6
gdb/ChangeLog:
2018-11-09 Andrey Utkin <autkin@undo.io>
* symfile.c (find_separate_debug_file): Fix search of debug files for
remote debuggee.
Signed-off-by: Andrey Utkin <autkin@undo.io>
This fixes a few minor style issues I found in gdb/python: some
unnecessary casts, the removal of an unnecessary local variable, and
one instance of incorrect formatting.
Tested by rebuilding and re-running gdb.python.
gdb/ChangeLog
2019-01-02 Tom Tromey <tom@tromey.com>
* python/py-inferior.c (gdbpy_initialize_inferior): Fix
indentation.
* python/py-frame.c (frapy_older): Remove cast.
(frapy_newer): Likewise.
* python/py-breakpoint.c (local_setattro): Remove cast.
* python/py-arch.c (archpy_name): Remove local variable.
* python/py-type.c (gdbpy_lookup_type): Remove cast.
The year range in the copyright header of that file was incorrect:
// Copyright (C) 3 Free Software Foundation, Inc.
Tracing the origin of this file down, I found that it was copied
from GCC's libstdc++-v3 testsuite:
Adapt and integrate string_view tests
https://www.sourceware.org/ml/gdb-patches/2018-04/msg00113.html
Looking at the version in GCC, I found the same issue, so sent
a fix there:
https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00000.html
Now that the fix is in GCC, this commit applies the same fix
to our copy.
gdb/ChangeLog:
* unittests/basic_string_view/element_access/char/empty.cc:
Fix year range in copyright header.
The goal of this commit is to allow RV64 binaries compiled for the 'F'
extension to run on a target that supports both the 'F' and 'D'
extensions.
The 'D' extension depends on the 'F' extension and chapter 9 of the
RISC-V ISA manual implies that running a program compiled for 'F' on
a 'D' target should be fine.
To support this the gdbarch now holds two feature sets, one represents
the features that are present on the target, and one represents the
features requested in the ELF flags.
The existing error checks are relaxed slightly to allow binaries
compiled for 32-bit 'F' extension to run on targets with the 64-bit
'D' extension.
A new set of functions called riscv_abi_{xlen,flen} are added to
compliment the existing riscv_isa_{xlen,flen}, and some callers to the
isa functions now call the abi functions when that is appropriate.
In riscv_call_arg_struct two asserts are removed, these asserts no
longer make sense. The asserts were both like this:
gdb_assert (TYPE_LENGTH (ainfo->type)
<= (cinfo->flen + cinfo->xlen));
And were made in two cases, when passing structures like these:
struct {
integer field1;
float field2;
};
or,
struct {
float field1;
integer field2;
};
When running on an RV64 target which only has 32-bit float then the
integer field could be 64-bits, while if the float field is 32-bits
the overall size of the structure can be 128-bits (with 32-bits of
padding). In this case the assertion would fail, however, the code
isn't incorrect, so its safe to just remove the assertion.
This was tested by running on an RV64IMFDC target using a compiler
configured for RV64IMFC, and comparing the results with those obtained
when using a compiler configured for RV64IMFDC. The only regressions
I see (now) are in gdb.base/store.exp and are related too different
code generation choices GCC makes between the two targets.
Finally, this commit does not make any attempt to support running
binaries compiled for RV32 on an RV64 target, though nothing in here
should prevent that being supported in the future.
gdb/ChangeLog:
* arch/riscv.h (struct riscv_gdbarch_features) <hw_float_abi>:
Delete.
<operator==>: Update with for removed field.
<hash>: Likewise.
* riscv-tdep.h (struct gdbarch_tdep) <features>: Renamed to...
<isa_features>: ...this.
<abi_features>: New field.
(riscv_isa_flen): Update comment.
(riscv_abi_xlen): New declaration.
(riscv_abi_flen): New declaration.
* riscv-tdep.c (riscv_isa_xlen): Update to get answer from
isa_features.
(riscv_abi_xlen): New function.
(riscv_isa_flen): Update to get answer from isa_features.
(riscv_abi_flen): New function.
(riscv_has_fp_abi): Update to get answer from abi_features.
(riscv_call_info::riscv_call_info): Use abi xlen and flen, not isa
xlen and flen.
(riscv_call_info) <xlen, flen>: Update comment.
(riscv_call_arg_struct): Remove invalid assertions
(riscv_features_from_gdbarch_info): Update now hw_float_abi field
is removed.
(riscv_gdbarch_init): Gather isa features and abi features
separately, ensure both match on the gdbarch when reusing an old
gdbarch. Relax an error check to allow 32-bit abi float to run on
a target with 64-bit float hardware.
Valgrind detects the below error in gdb.base/list.exp.
==14763== Invalid read of size 4
==14763== at 0x60B584: search_command_helper(char const*, int, bool) [clone .constprop.91] (source.c:1601)
==14763== by 0x408888: cmd_func(cmd_list_element*, char const*, int) (cli-decode.c:1892)
==14763== by 0x668550: execute_command(char const*, int) (top.c:630)
==14763== by 0x4B2F7B: command_handler(char const*) (event-top.c:583)
==14763== by 0x4B326C: command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) (event-top.c:772)
...
==14763== Address 0x6d9f09c is 4 bytes before a block of size 156 alloc'd
==14763== at 0x4C2E2B3: realloc (vg_replace_malloc.c:836)
==14763== by 0x41904C: xrealloc (common-utils.c:62)
==14763== by 0x60A300: find_source_lines(symtab*, int) (source.c:1203)
==14763== by 0x608219: source_cache::get_plain_source_lines(symtab*, int, int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*) (source-cache.c:51)
==14763== by 0x60A46B: print_source_lines_base(symtab*, int, int, enum_flags<print_source_lines_flag>) (source.c:1350)
==14763== by 0x404E2D: list_command(char const*, int) (cli-cmds.c:1080)
....
Add the missing condition to end the loop once line 1 has been
reversed-searched.
gdb/ChangeLog
2019-01-01 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* source.c (search_command_helper): Stop reverse search
when line 1 has been searched.
The last text produced was not freed, causing the below leak
(e.g. in gdb.base/catch-syscall.exp):
==24970== 56 bytes in 12 blocks are definitely lost in loss record 626 of 3,289
==24970== at 0x4C2BE6D: malloc (vg_replace_malloc.c:309)
==24970== by 0x66B9C3F: __vasprintf_chk (vasprintf_chk.c:80)
==24970== by 0x405181: vasprintf (stdio2.h:210)
==24970== by 0x405181: xstrvprintf(char const*, __va_list_tag*) (common-utils.c:122)
==24970== by 0x40524B: xstrprintf(char const*, ...) (common-utils.c:113)
==24970== by 0x3B49DB: print_one_catch_syscall(breakpoint*, bp_location**) (break-catch-syscall.c:275)
==24970== by 0x3C698F: print_one_breakpoint_location(breakpoint*, bp_location*, int, bp_location**, int) (breakpoint.c:6076)
==24970== by 0x3C75B1: print_one_breakpoint(breakpoint*, bp_location**, int) (breakpoint.c:6373)
==24970== by 0x3C7D0E: breakpoint_1(char const*, int, int (*)(breakpoint const*)) (breakpoint.c:6571)
==24970== by 0x3C822C: info_breakpoints_command(char const*, int) (breakpoint.c:6625)
2019-01-01 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* break-catch-syscall.c (print_one_catch_syscall): xfree
the last text.
gdb/ChangeLog:
* top.c (print_gdb_version): Update Copyright year in version
message.
gdb/gdbserver/ChangeLog:
* gdbreplay.c (gdbreplay_version): Update copyright year in
version message.
* server.c (gdbserver_version): Likewise.
This commit applies all changes made after running the gdb/copyright.py
script.
Note that one file was flagged by the script, due to an invalid
copyright header
(gdb/unittests/basic_string_view/element_access/char/empty.cc).
As the file was copied from GCC's libstdc++-v3 testsuite, this commit
leaves this file untouched for the time being; a patch to fix the header
was sent to gcc-patches first.
gdb/ChangeLog:
Update copyright year range in all GDB files.
Following the change of logic where the input_handler gets a
gdb::unique_xmalloc_ptr<char>, a call to readline directly
followed by a call to handle_line_of_input is missing a free,
and causes the below leak.
Use gdb::unique_xmalloc_ptr<char> to solve the leak.
==16291== VALGRIND_GDB_ERROR_BEGIN
==16291== 64 bytes in 1 blocks are definitely lost in loss record 1,815 of 4,111
==16291== at 0x4C2E2B3: realloc (vg_replace_malloc.c:836)
==16291== by 0x41EB1C: xrealloc (common-utils.c:62)
==16291== by 0x41DBD3: buffer_grow(buffer*, char const*, unsigned long) [clone .part.1] (buffer.c:40)
==16291== by 0x66E8FF: buffer_grow_char (buffer.h:40)
==16291== by 0x66E8FF: gdb_readline_no_editing (top.c:798)
==16291== by 0x66E8FF: command_line_input(char const*, char const*) (top.c:1249)
==16291== by 0x66EBD8: read_command_file(_IO_FILE*) (top.c:421)
==16291== by 0x412C0C: script_from_file(_IO_FILE*, char const*) (cli-script.c:1547)
==16291== by 0x40BE90: source_script_from_stream (cli-cmds.c:569)
==16291== by 0x40BE90: source_script_with_search(char const*, int, int) (cli-cmds.c:606)
==16291== by 0x54D567: catch_command_errors(void (*)(char const*, int), char const*, int) (main.c:379)
==16291== by 0x54EA84: captured_main_1 (main.c:994)
==16291== by 0x54EA84: captured_main (main.c:1167)
==16291== by 0x54EA84: gdb_main(captured_main_args*) (main.c:1193)
==16291== by 0x29DA27: main (gdb.c:32)
==16291==
==16291== VALGRIND_GDB_ERROR_END
gdb/ChangeLog
2018-12-31 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* top.c (command_line_input): Use unique_xmalloc_ptr to
manage memory allocated by readline.
This changes ui::input_handler to take a unique_xmalloc_ptr. This
clarifies the ownership transfer of input_handler's argument.
gdb/ChangeLog
2018-12-30 Tom Tromey <tom@tromey.com>
* event-top.h (command_line_handler): Update.
* top.c (class gdb_readline_wrapper_cleanup) <m_handler_orig>:
Update.
(gdb_readline_wrapper_line): Update.
* top.h (struct ui) <input_handler>: Take a unique_xmalloc_ptr.
(handle_line_of_input): Update.
* event-top.c: Update.
(gdb_readline_no_editing_callback): Update.
(command_line_handler): Take a unique_xmalloc_ptr.
(handle_line_of_input): Take a const char *.
(command_line_append_input_line): Take a const char *.
The layout for 'help set address|variable' is strange, e.g.:
(gdb) help set style address
style address
List of show Address display styling
Configure address colors and display intensity subcommands:
show Address display styling
Configure address colors and display intensity background -- Set the background color for this property
show Address display styling
Configure address colors and display intensity foreground -- Set the foreground color for this property
show Address display styling
Configure address colors and display intensity intensity -- Set the display intensity color for this property
Type "help show Address display styling
Configure address colors and display intensity" followed by show Address display styling
Configure address colors and display intensity subcommand name for full documentation.
Type "apropos word" to search for commands related to "word".
Command name abbreviations are allowed if unambiguous.
(gdb)
The help for 'set style function|filename' gives help for 'Show':
(gdb) help set style filename
Filename display styling
Configure filename colors and display intensity.
List of show style filename subcommands:
show style filename background -- Set the background color for this property
show style filename foreground -- Set the foreground color for this property
show style filename intensity -- Set the display intensity color for this property
The help for 'show style function|filename' is equally strange, as it speaks
about commands, instead of sub commands:
(gdb) help show style filename
Filename display styling
Configure filename colors and display intensity.
List of commands:
background -- Show the background color for this property
foreground -- Show the foreground color for this property
intensity -- Show the display intensity color for this property
Type "help" followed by command name for full documentation.
Type "apropos word" to search for commands related to "word".
Command name abbreviations are allowed if unambiguous.
(gdb)
This patch fixes all this.
Note that the 'set style' and 'show style' have the same prefix_doc:
(gdb) help show style
Style-specific settings
Configure various style-related variables, such as colors
...
(gdb) help set style
Style-specific settings
Configure various style-related variables, such as colors
...
Other similar commands (such as set|show history) have typically
a more specific prefix:
(gdb) help show history
Generic command for showing command history parameters.
...
(gdb) help set history
Generic command for setting command history parameters.
...
This could be fixed by having set_prefix_doc and show_prefix_doc instead of
the single prefix_doc argument to cli_style_option::add_setshow_commands.
That could be improved if deemed better.
2018-12-29 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* cli/cli-style.c (cli_style_option::add_setshow_commands):
Initialize m_set_prefix with "set", instead of re-assigning
m_show_prefix. Use m_set_prefix for set_list and m_show_prefix
for show_list.
(_initialize_cli_style): Correct the order of arguments in
variable_name_style.add_setshow_commands and
address_style.add_setshow_commands calls.
Philippe Waroquiers
Tom Tromey
Pedro Alves
Saagar Jha
Kevin Buettner
Andrew Burgess
Joel Brobecker
Simon Marchi
John Baldwin
Jordan Rupprecht
Sergio Durigan Junior
Simon Marchi
Keith Seitz
Alan Hayward
Tom Tromey
Weimin Pan
Thomas Schwinge
David Michael
KONRAD Frederic
Simon Marchi
Jim Wilson
Szabolcs Nagy
Pedro Franco de Carvalho
Max Filippov
Andrey Utkin