Andrew Burgess [Sat, 23 Feb 2019 20:07:47 +0000 (22:07 +0200)]
gdb/riscv: Use legacy register numbers in default target description
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.
Tom Tromey [Tue, 26 Feb 2019 19:12:30 +0000 (12:12 -0700)]
Fix new py-value.exp test case
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.
Kevin Buettner [Sun, 17 Feb 2019 01:31:51 +0000 (18:31 -0700)]
Document two argument form of gdb.Value constructor
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__.
Kevin Buettner [Sun, 17 Feb 2019 01:07:51 +0000 (18:07 -0700)]
Add tests for gdb.Value(bufobj, type) constructor
gdb/testsuite/ChangeLog:
* gdb.python/py-value.exp (test_value_from_buffer): New proc with
call from main program.
Kevin Buettner [Sun, 17 Feb 2019 00:46:33 +0000 (17:46 -0700)]
Define gdb.Value(bufobj, type) constructor
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.
Kevin Buettner [Sun, 17 Feb 2019 00:33:47 +0000 (17:33 -0700)]
Define unique_ptr specialization for Py_buffer.
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.
GDB Administrator [Tue, 26 Feb 2019 00:00:25 +0000 (00:00 +0000)]
Automatic date update in version.in
John Baldwin [Mon, 25 Feb 2019 22:25:01 +0000 (14:25 -0800)]
Fix BFD leak in dwarf2_get_dwz_file.
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.
Jordan Rupprecht [Mon, 25 Feb 2019 20:21:01 +0000 (12:21 -0800)]
Fix crash when loading dwp files
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.
Tom Tromey [Thu, 21 Feb 2019 17:40:49 +0000 (10:40 -0700)]
Fix BFD leak in solib-darwin.c
commit
192b62ce0b4bb5c61188f570e127a26d2c32f716 ("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.
Nick Clifton [Mon, 25 Feb 2019 12:15:41 +0000 (12:15 +0000)]
Extend objdump's --dwarf=follow-links option so that separate debug info files will also be affected by other dump function, and symbol tables from separate debug info files will be used when disassembling the main file.
* objdump.c (sym_ok): New function.
(find_symbol_for_address): Use new function.
(disassemble_section): Compare sections by name, not pointer.
(dump_dwarf): Move code to initialise byte_get pointer and iterate
over separate debug files from here to ...
(dump_bfd): ... here. Add parameter indicating that a separate
debug info file is being dumped. For main file, pull in the
symbol tables from all separate debug info files.
(display_object): Update call to dump_bfd.
* doc/binutils.texi: Document extened behaviour of the
--dwarf=follow-links option.
* NEWS: Mention this new feature.
* testsuite/binutils-all/objdump.WK2: Update expected output.
* testsuite/binutils-all/objdump.exp (test_follow_debuglink): Add
options and dump file parameters.
Add extra test.
* testsuite/binutils-all/objdump.WK3: New file.
* testsuite/binutils-all/readelf.exp: Change expected output for
readelf -wKis test.
* testsuite/binutils-all/readelf.wKis: New file.
GDB Administrator [Mon, 25 Feb 2019 00:00:31 +0000 (00:00 +0000)]
Automatic date update in version.in
Alan Modra [Sun, 24 Feb 2019 07:31:08 +0000 (18:01 +1030)]
Re: PowerPC __tls_get_addr arg parsing
Fixes non-ELF powerpc build failure:
tc-ppc.c:3009:1: error: ‘parse_tls_arg’ defined but not used
* config/tc-ppc.c (parse_tls_arg): Wrap in #ifdef OBJ_ELF.
Alan Modra [Sun, 24 Feb 2019 06:14:48 +0000 (16:44 +1030)]
PR24144, pdp11-ld overwriting section data with zeros
bfd/
PR 24144
* pdp11.c (set_section_contents): Revert 2015-02-24 change.
gas/
PR 24144
* config/obj-aout.c (obj_aout_frob_file_before_fix): Write to end
of section to ensure file contents cover aligned section size.
GDB Administrator [Sun, 24 Feb 2019 00:01:17 +0000 (00:01 +0000)]
Automatic date update in version.in
Sergio Durigan Junior [Sat, 23 Feb 2019 15:05:19 +0000 (10:05 -0500)]
Use '--readnever' when invoking GDB from gcore.in
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.
Joel Brobecker [Sat, 23 Feb 2019 12:23:22 +0000 (16:23 +0400)]
Update copyright year range in gdb.ada/mi_ref_changeable testcase
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.
Joel Brobecker [Sat, 23 Feb 2019 12:14:23 +0000 (16:14 +0400)]
Update copyright year range in gdb.texinfo and refcard.tex
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.
GDB Administrator [Sat, 23 Feb 2019 00:00:56 +0000 (00:00 +0000)]
Automatic date update in version.in
Simon Marchi [Fri, 22 Feb 2019 20:53:52 +0000 (15:53 -0500)]
Update my email address
Since this is my last day at Ericsson, I am changing my email for my
personal one in the MAINTAINERS file.
Simon Marchi [Fri, 22 Feb 2019 20:09:23 +0000 (15:09 -0500)]
Look for build-id-based separate debug files under the sysroot
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 :
402d2bfec42 ("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.
Andrew Burgess [Fri, 22 Feb 2019 20:12:21 +0000 (20:12 +0000)]
gdb: Update copyright year range generated by gdbarch.sh
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.
Keith Seitz [Fri, 22 Feb 2019 20:05:37 +0000 (12:05 -0800)]
Add missing ChangeLog entries for commit
bb995d00b3eef2f48d0be895c3509a7ddd8280a1
Keith Seitz [Fri, 22 Feb 2019 17:39:35 +0000 (09:39 -0800)]
Fix symtab/23853: symlinked default symtab
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.
Nick Clifton [Fri, 22 Feb 2019 10:36:24 +0000 (10:36 +0000)]
Extend readelf and objdump so that they will display and follow multiple links to separate debug information files.
PR 23843
* dwarf.h (struct separate_info): New structure for containing
information on separate debug info files.
* dwarf.c (struct dwo_info): New structure for containing dwo
links.
(first_dwo_info): Chain of dwo_info structures.
(first_separate_file): Chain of separate_info structures.
(separate_debug_file, separate_debug_filename): Delete.
(fetch_alt_indirect_string): Scan all separate debug info files
for the requested string.
(add_dwo_info): New function.
(add_dwo_name): New function.
(add_dwo_dir): New function.
(add_dwo_id: New function.
(free_dwo_info): New function.
(read_and_display_attr_value): Store DWO data using the new
functions.
(load_debug_section_with_follow): If necessary, scan the list of
separate debug info files for the requested section.
(add_separate_debug_file): New function.
(load_separate_debug_info): Call add_separate_debug_file to store
the information on the newly loaded file.
(load_dwo_file): Likewise.
(load_separate_debif_file): Rename to load_separate_debug_files.
Change return type to boolean. If following links then attempt to
load all separate debug info files, not just the first one.
(free_debug_memory): Release memory in dwo_info and separate_info
chains.
* objdump.c (dump_dwarf): Iterate over all loaded debg info files.
* readelf.c (process_object): Likewise.
* doc/debug.options.texi: Update descriptions of links and
follow-links options.
* testsuite/binutils-all/objdump.WK2: Update expected output.
* testsuite/binutils-all/readelf.k2: Likewise.
* NEWS: Announce the new feature.
Kyrylo Tkachov [Fri, 22 Feb 2019 09:59:05 +0000 (09:59 +0000)]
[arm][gas] Add support for Neoverse N1
This adds support for the Neoverse N1 CPU [1] to gas.
This was previously enabled under the Ares codename, which remains as
a valid option for -mcpu for compatibility reasons.
make check-gas passes on arm-none-eabi.
[1] https://community.arm.com/processors/b/blog/posts/arm-neoverse-n1-platform-accelerating-the-transformation-to-a-scalable-cloud-to-edge-infrastructure
2019-02-21 Kyrylo Tkachov <kyrylo.tkachov@arm.com>
* config/tc-arm.c (arm_cpus): Add neoverse-n1.
* doc/c-arm.texi (-mcpu): Document neoverse-n1 value.
Kyrylo Tkachov [Fri, 22 Feb 2019 09:57:45 +0000 (09:57 +0000)]
[AArch64][gas] Add support for Neoverse E1
This adds support for the Neoverse E1 CPU [1] to gas.
make check-gas passes on aarch64-none-elf.
[1] https://community.arm.com/processors/b/blog/posts/arm-neoverse-e1-platform-empowering-the-infrastructure-to-meet-next-generation-throughput-demands
2019-02-21 Kyrylo Tkachov <kyrylo.tkachov@arm.com>
* config/tc-aarch64.c (aarch64_cpus): Add neoverse-e1.
* doc/c-aarch64.texi (-mcpu): Document neoverse-e1 value.
Kyrylo Tkachov [Fri, 22 Feb 2019 09:56:50 +0000 (09:56 +0000)]
[AArch64][gas] Add support for Neoverse N1
This adds support for the Neoverse N1 [1] CPU to gas.
This was previously enabled under the Ares codename, which remains as
a valid option for -mcpu for compatibility reasons.
make check-gas passes on aarch64-none-elf.
[1] https://community.arm.com/processors/b/blog/posts/arm-neoverse-n1-platform-accelerating-the-transformation-to-a-scalable-cloud-to-edge-infrastructure
2019-02-21 Kyrylo Tkachov <kyrylo.tkachov@arm.com>
* config/tc-aarch64.c (aarch64_cpus): Add neoverse-n1.
* doc/c-aarch64.texi (-mcpu): Document neoverse-n1 value.
GDB Administrator [Fri, 22 Feb 2019 00:00:37 +0000 (00:00 +0000)]
Automatic date update in version.in
Alan Hayward [Thu, 21 Feb 2019 18:20:21 +0000 (18:20 +0000)]
Document style behavior in batch mode.
Style is disabled when running in batch mode.
gdb/ChangeLog:
* NEWS: Update style defaults.
gdb/doc/ChangeLog:
* gdb.texinfo: Update style defaults.
Tom Tromey [Thu, 21 Feb 2019 14:26:52 +0000 (07:26 -0700)]
Fix typo in "show remotelogfile" docs
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.
Alan Hayward [Thu, 21 Feb 2019 13:17:32 +0000 (13:17 +0000)]
Disable styling when running in batch mode
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.
Nick Clifton [Thu, 21 Feb 2019 10:54:12 +0000 (10:54 +0000)]
Fix illegal memory accesses by readelf when parsing corrupt IA64 unwind information.
PR 24247
* unwind-ia64.c: Include sysdep.h.
(unw_decode_x1): Check current pointer against end pointer before
accessing memory.
(unw_decode_x2): Likewise.
(unw_decode_x3): Likewise.
(unw_decode_x4): Likewise.
(unw_decode_r2): Likewise.
(unw_decode_p2_p5): Likewise.
(unw_decode_p7_p10): Likewise.
(unw_decode): Likewise.
Alan Modra [Thu, 21 Feb 2019 07:11:47 +0000 (17:41 +1030)]
PowerPC __tls_get_addr arg parsing
The syntax we ended up with for -m32 -fPIC calls to __tls_get_addr is
rather weird.
bl __tls_get_addr+0x8000(gd0@tlsgd)@plt
This came about by accident, probably due to requiring the arg reloc
before the call reloc.
Of course the @plt really belongs with __tls_get_addr since it affects
the call rather than the call arg, and it isn't a great deal of
trouble to ensure the relocs are emitted in the correct order. This
patch supports a newer syntax, like so:
bl __tls_get_addr+0x8000@plt(gd0@tlsgd)
gas/
* config/tc-ppc.c (parse_tls_arg): New function, extracted..
(md_assembler): ..from here. Call it after parsing other
suffix modifiers too.
ld/
* testsuite/ld-powerpc/tls32.s: Test new @plt syntax.
GDB Administrator [Thu, 21 Feb 2019 00:00:40 +0000 (00:00 +0000)]
Automatic date update in version.in
Tom Tromey [Fri, 8 Feb 2019 08:19:36 +0000 (01:19 -0700)]
Fix typos in symtab_symbol_info
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.
Nick Clifton [Wed, 20 Feb 2019 17:51:21 +0000 (17:51 +0000)]
Fix potential illegal memory access by readelf when parsing a binary containing corrupt system tap notes.
PR 24246
* readelf.c (print_stapsdt_note): Harden against corrupt notes.
Nick Clifton [Wed, 20 Feb 2019 17:25:33 +0000 (17:25 +0000)]
Fix potential illegal memory access by readelf when parsing corrupt IA64 unwind information.
PR 24244
* unwind-ia64.c (unw_decode_uleb128): Add end parameter, use it to
prevent walking off the end of the buffer.
(unw_decode_x1): Add end paramter, pass it to unw_decode_uleb128.
(unw_decode_x2): Likewise.
(unw_decode_x3): Likewise.
(unw_decode_x4): Likewise.
(unw_decode_r2): Pass the end parameter to unw_decode_uleb128.
(unw_decode_r3): Likewise.
(unw_decode_p7_p10): Likewise.
(unw_decode_b2): Likewise.
(unw_decode_b3_x4): Likewise.
Nick Clifton [Wed, 20 Feb 2019 17:03:47 +0000 (17:03 +0000)]
Fix a illegal memory access fault when parsing a corrupt MIPS option section using readelf.
PR 24243
* readelf.c (process_mips_specific): Check for an options section
that is too small to even contain a single option.
Nick Clifton [Wed, 20 Feb 2019 15:35:06 +0000 (15:35 +0000)]
Harden readelf's IA64 note display function so that it can handle corrupt notes.
PR 24242
* readelf.c (print_ia64_vms_note): Harden against corrupt notes.
Tom Tromey [Thu, 14 Feb 2019 14:58:58 +0000 (07:58 -0700)]
Use upper case for metasyntactic variables in "help find"
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.
Alan Hayward [Wed, 20 Feb 2019 11:56:23 +0000 (11:56 +0000)]
AArch64: Add default reggroups
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.
Max Filippov [Sat, 16 Feb 2019 00:43:23 +0000 (16:43 -0800)]
bfd: xtensa: fix callx relaxation
Big section alignment requirements between source and destination of a
long call can result in making call range bigger than what's reachable
by the call opcode. Add biggest section alignment of sections between
the call site and call destination to the call distance when making
long call relaxation decision.
2019-02-20 Eric Tsai <erictsai@cadence.com>
bfd/
* elf32-xtensa.c (is_resolvable_asm_expansion): Scan output
sections between the call site and call destination and adjust
call distance by the largest alignment.
ld/
* testsuite/ld-xtensa/call_overflow.d: New test definition.
* testsuite/ld-xtensa/call_overflow1.s: New test source.
* testsuite/ld-xtensa/call_overflow2.s: New test source.
* testsuite/ld-xtensa/call_overflow3.s: New test source.
* testsuite/ld-xtensa/xtensa.exp: Add call_overflow test.
Alan Hayward [Wed, 20 Feb 2019 10:39:28 +0000 (10:39 +0000)]
AArch64: Add pauth core file section
Used for the AArch64 pointer authentication code mask registers in Arm v8.3-a.
NT_ARM_PAC_MASK matches the value in Linux include/uapi/linux/elf.h
include/ChangeLog:
* elf/common.h (NT_ARM_PAC_MASK): Add define.
bfd/ChangeLog:
* elf-bfd.h (elfcore_write_aarch_pauth): Add declaration.
* elf.c (elfcore_grok_aarch_pauth): New function.
(elfcore_grok_note): Check for NT_ARM_PAC_MASK.
(elfcore_write_aarch_pauth): New function.
(elfcore_write_register_note): Check for AArch64 pauth section.
Alan Modra [Wed, 20 Feb 2019 08:24:41 +0000 (18:54 +1030)]
Check asprintf return value
git
a31b8bd9a05 introduced a warning (depending on your system
headers).
PR 24225
* elf32-nios2.c (nios2_elf32_relocate_section): Check asprintf
return value.
Alan Modra [Wed, 20 Feb 2019 07:52:50 +0000 (18:22 +1030)]
Unsigned integer overflows in readelf checks
PR 24132
PR 24138
* readelf.c (get_data): Avoid possibility of overflow when
checking for a read that may extend past end of file.
(process_program_headers): Likewise.
Michael Roitzsch [Wed, 20 Feb 2019 04:17:40 +0000 (14:47 +1030)]
Use or1k-darwin host SHARED_LIBADD for *-darwin.
* configure.ac (SHARED_LIBADD): Add -liberty -lintl for all
Darwin hosts, not just or1k.
* configure: Regenerate.
Alan Modra [Wed, 20 Feb 2019 01:36:31 +0000 (12:06 +1030)]
PR24233, Out of memory
PR 24233
* objdump.c (dump_bfd_private_header): Print warning if
bfd_print_private_bfd_data returns false.
Simon Marchi [Wed, 20 Feb 2019 02:10:18 +0000 (21:10 -0500)]
Fix error message and use-after-free on errors in nested sourced files
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.
Alan Modra [Tue, 19 Feb 2019 21:51:24 +0000 (08:21 +1030)]
PR24236, Heap buffer overflow in _bfd_archive_64_bit_slurp_armap
PR 24236
* archive64.c (_bfd_archive_64_bit_slurp_armap): Move code adding
sentinel NUL to string buffer nearer to loop where it is used.
Don't go past sentinel when scanning strings, and don't write
NUL again.
* archive.c (do_slurp_coff_armap): Simplify string handling to
archive64.c style.
Egeyar Bagcioglu [Wed, 20 Feb 2019 00:12:44 +0000 (16:12 -0800)]
Check whether symbols with MOVW_.ABS relocations require PLT entries (aarch64).
2019-02-19 Egeyar Bagcioglu <egeyar.bagcioglu@oracle.com>
gold/
PR gold/23870
* aarch64.cc (Target_aarch64::Scan::global): Check if a symbol with
R_AARCH64_MOVW_.ABS_* relocations requires a PLT entry.
* testsuite/Makefile.am: Add aarch64_pr23870 test case.
* testsuite/Makefile.in: Regenerate.
* testsuite/aarch64_pr23870_bar.c: New file.
* testsuite/aarch64_pr23870_foo.c: New file.
* testsuite/aarch64_pr23870_main.S: New file.
GDB Administrator [Wed, 20 Feb 2019 00:00:41 +0000 (00:00 +0000)]
Automatic date update in version.in
Tom Tromey [Fri, 15 Feb 2019 21:05:38 +0000 (14:05 -0700)]
Minor Ada task cleanups
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.
Paul Hua [Tue, 19 Feb 2019 17:57:16 +0000 (17:57 +0000)]
Fix a potential deadlock in some older Loongson 3A1000 MIPS processors.
* NEWS: Mention -m[no-]fix-loongson3-llsc.
* configure.ac: Add --enable-mips-fix-loongson3-llsc.
Define DEFAULT_MIPS_FIX_LOONGSON3_LLSC.
* config.in: Regenerated.
* configure: Likewise.
* config/tc-mips.c (sync_insn, mips_fix_loongson3_llsc):
New variables.
(options): New OPTION_FIX_LOONGSON3_LLSC,
OPTION_NO_FIX_LOONGSON3_LLSC.
(md_longopts): Add -m[no-]fix-loongson3-llsc.
(md_begin): Initialize sync insn.
(fix_loongson3_llsc): New.
(append_insn): Call fix_loongson3_llsc.
(md_parse_option): Handle OPTION_FIX_LOONGSON3_LLSC,
OPTION_NO_FIX_LOONGSON3_LLSC.
(md_show_usage): Display -m[no-]fix-loongson3-llsc.
* doc/c-mips.texi: Document -m[no-]fix-loongson3-llsc,
--enable-mips-fix-loongson3-llsc=[yes|no].
Alan Modra [Tue, 19 Feb 2019 12:18:44 +0000 (22:48 +1030)]
PR24235, Read memory violation in pei-x86_64.c
PR 24235
* pei-x86_64.c (pex64_bfd_print_pdata_section): Correct checks
attempting to prevent read past end of section.
GDB Administrator [Tue, 19 Feb 2019 00:00:40 +0000 (00:00 +0000)]
Automatic date update in version.in
Andrew Burgess [Mon, 18 Feb 2019 18:10:09 +0000 (18:10 +0000)]
gdb: Allow gdbarch to override alignment for method and member pointers
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.
Philippe Waroquiers [Sun, 17 Feb 2019 16:58:17 +0000 (17:58 +0100)]
Fix leaks of 'per program space' and 'per inferior' ada task data.
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.
Alan Modra [Mon, 18 Feb 2019 01:27:22 +0000 (11:57 +1030)]
PR24225, nios2 buffer overflow
PR 24225
* elf32-nios2.c (nios2_elf32_relocate_section): Use asprintf and
PRIx64 to generate warning messages. Print local sym names too.
GDB Administrator [Mon, 18 Feb 2019 00:00:44 +0000 (00:00 +0000)]
Automatic date update in version.in
Tom Tromey [Fri, 8 Feb 2019 08:40:39 +0000 (01:40 -0700)]
Change macro_source_fullname to return a std::string
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.
Tom Tromey [Fri, 8 Feb 2019 08:28:53 +0000 (01:28 -0700)]
Add styling to macro commands
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.
Tom Tromey [Mon, 28 Jan 2019 20:21:35 +0000 (13:21 -0700)]
Fix some valgrind errors in the TUI
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.
Tom Tromey [Thu, 7 Feb 2019 13:23:40 +0000 (06:23 -0700)]
Fix pager bugs with style output
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.
Joel Brobecker [Sun, 17 Feb 2019 15:04:57 +0000 (10:04 -0500)]
type_align: handle range types the same as ints and enums
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).
Joel Brobecker [Sun, 17 Feb 2019 13:32:45 +0000 (08:32 -0500)]
(Ada) fix GDB crash printing packed array
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.
GDB Administrator [Sun, 17 Feb 2019 00:01:01 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Sat, 16 Feb 2019 00:01:06 +0000 (00:01 +0000)]
Automatic date update in version.in
Tom Tromey [Wed, 6 Feb 2019 14:14:40 +0000 (15:14 +0100)]
Special-case wildcard requests in ravenscar-thread.c
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.
Tom Tromey [Wed, 6 Feb 2019 10:06:49 +0000 (03:06 -0700)]
Make the ravenscar thread target multi-target-ready
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.
Tom Tromey [Wed, 6 Feb 2019 09:54:17 +0000 (02:54 -0700)]
Add push_target overload
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.
Tom Tromey [Tue, 5 Feb 2019 11:11:19 +0000 (04:11 -0700)]
Minor C++-ification in ravenscar-thread.c
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.
Tom Tromey [Tue, 5 Feb 2019 11:08:48 +0000 (04:08 -0700)]
Fix formatting in ravenscar-thread.c
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.
Tom Tromey [Tue, 5 Feb 2019 10:08:02 +0000 (03:08 -0700)]
C++-ify ravenscar_arch_ops
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.
Tom Tromey [Tue, 5 Feb 2019 09:57:21 +0000 (02:57 -0700)]
Exception safety in ravenscar-thread.c
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.
Tom Tromey [Tue, 5 Feb 2019 09:53:43 +0000 (02:53 -0700)]
Fix some typos in ravenscar-thread.c
This fixes some typos I noticed in ravenscar-thread.c.
gdb/ChangeLog
2019-02-15 Tom Tromey <tromey@adacore.com>
* ravenscar-thread.c: Fix some typos.
Tom Tromey [Wed, 13 Feb 2019 12:42:18 +0000 (05:42 -0700)]
Fix memory leak in create_ada_exception_catchpoint
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.
Tom Tromey [Tue, 12 Feb 2019 21:28:07 +0000 (14:28 -0700)]
C++-ify bp_location
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.
Saagar Jha [Fri, 15 Feb 2019 12:50:52 +0000 (12:50 +0000)]
Use the correct name for various MACH-O based operating systems in comments.
include * mach-o/loader.h: Use new OS names in comments.
GDB Administrator [Fri, 15 Feb 2019 00:01:15 +0000 (00:01 +0000)]
Automatic date update in version.in
Weimin Pan [Thu, 14 Feb 2019 22:20:36 +0000 (22:20 +0000)]
Updating test case
gdb.arch/aarch64-dbreg-contents.exp:
* Replaced "run" with "runto_main + continue".
* Replaced "gdb_compile + clean_restart" with "prepare_for_testing".
* Added comment for case "exited with code 01".
gdb.arch/aarch64-dbreg-contents.c:
* Removed SET_WATCHPOINT marco.
* Removed redundent cleanup ().
* Cleaned up comment.
Thomas Schwinge [Fri, 29 Jun 2018 19:05:29 +0000 (21:05 +0200)]
[ld, hurd] Remove 'ld-elf/elf.exp' XFAILs
... as a follow-up to commit
d98164028637041c5de99af0d057bde3f168a8a8 "Run more
ld tests when not native", which replaced by a proper solution the following
mess before present in 'ld/configure.host':
-*-*-gnu*)
- # When creating static executables, we ought to use crt0.o instead of crt1.o,
- # <http://www.gnu.org/software/hurd/open_issues/binutils.html#static>,
- # but the testing infrastructure is not prepared for that. This is not
- # relevant for most tests, and the few remaining ones have been XFAILed.
- HOSTING_CRT0='[...]'
- HOSTING_LIBS='[...]'
ld/
* testsuite/ld-elf/elf.exp: Remove Hurd XFAILs.
Thomas Schwinge [Fri, 17 Feb 2017 16:45:01 +0000 (16:45 +0000)]
[gdb, hurd] Avoid using 'PATH_MAX' in 'gdb/remote.c'
..., which is not defined in GNU/Hurd systems, and so commit
94585166dfea8232c248044f9f4b1c217dc4ac2e "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'.
David Michael [Tue, 6 Jun 2017 00:35:11 +0000 (17:35 -0700)]
[gdb, hurd] Adjust to Hurd "proc" interface changes
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.
Thomas Schwinge [Thu, 14 Feb 2019 09:22:28 +0000 (10:22 +0100)]
[gdb, hurd] Address "ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]" diagnostics
... that appeared with
9bf2a700667c53003ece783c05e8b355801105f2
"-Wwrite-strings: Remove -Wno-write-strings".
gdb/
* gnu-nat.c (gnu_write_inferior, parse_int_arg, _parse_bool_arg)
(check_empty): Use "const char *".
Thomas Schwinge [Tue, 24 Jul 2018 16:04:18 +0000 (18:04 +0200)]
[gdb, hurd] Repair build after "Use thread_info and inferior pointers more throughout"
..., that is commit
00431a78b28f913a9d5c912c49680e39cfd20847 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))'.
Thomas Schwinge [Wed, 4 Jul 2018 11:27:09 +0000 (13:27 +0200)]
[gdb, hurd] Repair build after "Share fork_inferior et al with gdbserver" changes
..., that is commit
2090129c36c7e582943b7d300968d19b46160d84 causing:
[...]/gdb/gnu-nat.c: In function 'void gnu_ptrace_me()':
[...]/gdb/gnu-nat.c:2133:5: error: 'trace_start_error_with_name' was not declared in this scope
trace_start_error_with_name ("ptrace");
^~~~~~~~~~~~~~~~~~~~~~~~~~~
[...]/gdb/gnu-nat.c:2133:5: note: suggested alternative: 'throw_perror_with_name'
trace_start_error_with_name ("ptrace");
^~~~~~~~~~~~~~~~~~~~~~~~~~~
throw_perror_with_name
[...]/gdb/gnu-nat.c: In function 'void gnu_create_inferior(target_ops*, const char*, const string&, char**, int)':
[...]/gdb/gnu-nat.c:2147:9: error: 'fork_inferior' was not declared in this scope
pid = fork_inferior (exec_file, allargs, env, gnu_ptrace_me,
^~~~~~~~~~~~~
[...]/gdb/gnu-nat.c:2147:9: note: suggested alternative: 'exit_inferior'
pid = fork_inferior (exec_file, allargs, env, gnu_ptrace_me,
^~~~~~~~~~~~~
exit_inferior
[...]/gdb/gnu-nat.c:2174:30: error: 'START_INFERIOR_TRAPS_EXPECTED' was not declared in this scope
gdb_startup_inferior (pid, START_INFERIOR_TRAPS_EXPECTED);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/bin/ld: gnu-nat.o: in function `gnu_ptrace_me()':
[...]/gdb/gnu-nat.c:2134: undefined reference to `trace_start_error_with_name(char const*)'
/usr/bin/ld: gnu-nat.o: in function `gnu_create_inferior(target_ops*, char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char**, int)':
[...]/gdb/gnu-nat.c:2148: undefined reference to `fork_inferior(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char**, void (*)(), void (*)(int), void (*)(), char const*, void (*)(char const*, char* const*, char* const*))'
/usr/bin/ld: fork-child.o: in function `gdb_startup_inferior(int, int)':
[...]/gdb/fork-child.c:136: undefined reference to `startup_inferior(int, int, target_waitstatus*, ptid_t*)'
collect2: error: ld returned 1 exit status
gdb/
* configure.nat [gdb_host == i386gnu] (NATDEPFILES): Add
'nat/fork-inferior.o'.
* gnu-nat.c: #include "nat/fork-inferior.h".
Thomas Schwinge [Fri, 20 Jul 2018 00:03:25 +0000 (02:03 +0200)]
[gdb, hurd] Repair build after "Convert struct target_ops to C++" changes
..., that is commit
f6ac5f3d63e03a81c4ff3749aba234961cc9090e 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'.
Thomas Schwinge [Wed, 13 Feb 2019 11:02:20 +0000 (12:02 +0100)]
[gdb, hurd] Work around conflict between Mach's 'thread_info' function, and GDB's 'thread_info' class
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
7aabaf9d4ad52a1df1f551908fbd8cafc5e7597a
"Create private_thread_info hierarchy", and commit
75cbc781e371279f4403045be93b07fd8fe7fde5 "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.
Thomas Schwinge [Tue, 29 Mar 2011 12:02:11 +0000 (14:02 +0200)]
[gdb, hurd] Remove long obsolete 'gnu_target_pid_to_str' function declaration
... for function definition removed/renamed in 1999. ;-)
gdb/
* config/i386/nm-i386gnu.h (gnu_target_pid_to_str): Remove.
KONRAD Frederic [Thu, 14 Feb 2019 03:37:11 +0000 (22:37 -0500)]
(riscv/ada) fix error when calling functions with range argument
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.
Joel Brobecker [Thu, 14 Feb 2019 03:13:26 +0000 (07:13 +0400)]
(Windows) remove thread notification for main thread of inferior
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 Administrator [Thu, 14 Feb 2019 00:00:28 +0000 (00:00 +0000)]
Automatic date update in version.in
Simon Marchi [Wed, 13 Feb 2019 21:56:21 +0000 (16:56 -0500)]
Add Andrew Burgess as global maintainer of gdb/ and sim/
Weimin Pan [Wed, 13 Feb 2019 00:38:31 +0000 (00:38 +0000)]
Adding a test case
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.
GDB Administrator [Wed, 13 Feb 2019 00:00:39 +0000 (00:00 +0000)]
Automatic date update in version.in
John Baldwin [Tue, 12 Feb 2019 21:56:16 +0000 (13:56 -0800)]
Try to use the canonical version of a sysroot for debug file links.
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.
John Baldwin [Tue, 12 Feb 2019 21:56:16 +0000 (13:56 -0800)]
Use child_path to determine if an object file is under a sysroot.
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.
John Baldwin [Tue, 12 Feb 2019 21:56:16 +0000 (13:56 -0800)]
Add a new function child_path.
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.
John Baldwin [Tue, 12 Feb 2019 21:56:16 +0000 (13:56 -0800)]
Look for separate debug files in debug directories under a sysroot.
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.