Commit Graph

99148 Commits

Author SHA1 Message Date
GDB Administrator
6a093f341b Automatic date update in version.in 2019-10-23 00:00:20 +00:00
Christian Biesinger
403772ef61 Make demangled_name_entry::language not a bitfield
Having it as a bitfield causes extra work, and this is not memory-sensitive.
Furthermore, once https://sourceware.org/ml/gdb-patches/2019-10/msg00812.html
lands, the bitfield won't even save any memory at all.

gdb/ChangeLog:

2019-10-22  Christian Biesinger  <cbiesinger@google.com>

	* symtab.c (struct demangled_name_entry) <language>: Change from
	bitfield to regular variable.

Change-Id: I4ea31d1cfcbe0f09a09bd058cd304862308dc388
2019-10-22 15:36:37 -05:00
Christian Biesinger
3a49427939 Fix compile error & incorrect push
I accidentally pushed the wrong version of the patch for commit
7bb4305982 (where the review
comments were not fixed), and I did a bad conflict resolution
for ccb1ba6229 leading to a
compile error when libxxhash is available. This fixes both
issues.

gdb/ChangeLog:

2019-10-22  Christian Biesinger  <cbiesinger@google.com>

	* symtab.c (struct demangled_name_entry): Add a constructor.
	(free_demangled_name_entry): New function to call the destructor
	for demangled_name_entry.
	(create_demangled_names_hash): Pass free_demangled_name_entry to
	htab_create_alloc.
	(symbol_set_names): Call placement new for demangled_name_entry.
	* utils.c: No longer include xxhash.h here, now that fast_hash
	is inlined in the header.
	* utils.h: Instead, include it here.

Change-Id: If776099d39a65a12733d42efcb859feca1b07a39
2019-10-22 13:41:12 -05:00
Christian Biesinger
ccb1ba6229 Use libxxhash for hashing, if present
XXHash is faster than htab_hash_string:
------------------------------------------------------------
Benchmark                     Time           CPU Iterations
------------------------------------------------------------
BM_xxh3                      11 ns         11 ns   65887249
BM_xxh32                     19 ns         19 ns   36511877
BM_xxh64                     16 ns         16 ns   42964585
BM_hash_string              182 ns        182 ns    3853125
BM_iterative_hash            77 ns         77 ns    9087638

Unfortunately, XXH3 is still experimental (see
https://github.com/Cyan4973/xxHash#user-content-new-experimental-hash-algorithm)

However, regular XXH64 is still a lot faster than
htab_hash_string per my benchmark above. I used the
following string for the benchmark:
static constexpr char str[] = "_ZZZL13make_gdb_typeP7gdbarchP10tdesc_typeEN16gdb_type_creator19make_gdb_type_flagsEPK22tdesc_type_with_fieldsE19__PRETTY_FUNCTION__";

htab_hash_string is currently 4.35% + 7.98% (rehashing) of gdb
startup when attaching to Chrome's content_shell.

An additional 5.21% is spent in msymbol_hash, which does not use
this hash function. Unfortunately, since it has to lowercase the
string, it can't use this hash function.
BM_msymbol_hash                52 ns         52 ns   13281495

It may be worth investigating if strlen+XXHash is still faster than
htab_hash_string, which would make it easier to use in more places.

Debian ships xxhash as libxxhash{0,-dev}. Fedora ships it as xxhash-devel.

gdb/ChangeLog:

2019-10-22  Christian Biesinger  <cbiesinger@google.com>

	* Makefile.in: Link with libxxhash.
	* config.in: Regenerate.
	* configure: Regenerate.
	* configure.ac: Search for libxxhash.
	* utils.c (fast_hash): Use xxhash if present.

Change-Id: Icab218388b9f829522ed3977f04301ae6d4fc4ca
2019-10-22 11:47:24 -05:00
Christian Biesinger
1a6ff1a96b Add a fast_hash function in common-utils
Also updates a caller in symtab.c. For now this just calls htab_hash_string
but the next patch will change it to xxhash, if available.

gdb/ChangeLog:

2019-10-22  Christian Biesinger  <cbiesinger@google.com>

	* utils.h (fast_hash): New function.
	* symtab.c (hash_demangled_name_entry): Call new function
	fast_hash.

Change-Id: I77cac0d9aa78fc65316a2af449f52edcae72dc9b
2019-10-22 11:26:17 -05:00
Christian Biesinger
7bb4305982 Store the mangled name as a string_view
This should be a bit faster (because we can compare the size first),
but it is also a dependency for the next patch.

(3.47% of gdb startup time is spent in eq_demangled_name_entry when
attaching to Chrome's content_shell binary)

gdb/ChangeLog:

2019-10-22  Christian Biesinger  <cbiesinger@google.com>

	* symtab.c (struct demangled_name_entry): Change type of mangled
	to gdb::string_view. Also adds a constructor that takes the
	mangled name.
	(hash_demangled_name_entry): Update.
	(eq_demangled_name_entry): Update.
	(free_demangled_name_entry): New function to call the destructor
	now that this is not a POD anymore.
	(create_demangled_names_hash): Pass free_demangled_name_entry to
	htab_create_alloc.
	(symbol_set_names): Update.

Change-Id: I24711ae2bcaa9e79ca89a6f8fda385d400419175
2019-10-22 11:25:31 -05:00
Nick Clifton
6207ed2877 Prevent more potential illegal memory accesses in the RX disassembler.
* rx-dis.c (get_size_name): New function.  Provides safe
	access to name array.
	(get_opsize_name): Likewise.
	(print_insn_rx): Use the accessor functions.
2019-10-22 12:01:45 +01:00
Alan Modra
ef0cc92e9c Don't allow RELATIVE relocs in pr22269 testcase
At least, not in the GOT.  R_PPC64_RELATIVE is fine for powerpc64 in
the .opd section.

	PR 22269
	* testsuite/ld-elf/pr22269-1.rd: Look for GOT section NONE and
	RELATIVE relocs.
	* testsuite/ld-elf/shared.exp (pr22269-1): Give test a better
	name.  Use -z nocombreloc.
2019-10-22 11:46:53 +10:30
GDB Administrator
5ae8188eaa Automatic date update in version.in 2019-10-22 00:00:22 +00:00
Ali Tamur
7ba99d2188 DWARF 5 support: Handle line table and file indexes
*  Fix handling of file and directory indexes in line tables; in DWARF 5 the
indexes are zero-based. Make file_names field private to abstract this detail
from the clients. Introduce file_names, is_valid_file_index and
file_names_size methods. Reflect these changes in clients.
*  Handle DW_FORM_data16 in read_formatted_entries; it is used to record MD5
of the file entries in DWARF 5.
*  Fix a bug in line header parsing that calculates the length of the header
incorrectly. (Seemingly this manifests itself only in DWARF 5).

Tested with CC=/usr/bin/gcc (version 8.3.0) against master branch (also with
-gsplit-dwarf and -gdwarf-4 flags) and there was no increase in the set of
tests that fails. (gdb still cannot debug a 'hello world' program with DWARF 5,
so for the time being, this is all we care about).

This is part of an effort to support DWARF 5 in gdb.

gdb/ChangeLog:

	* dwarf2read.c (dir_index): Change type.
	(file_name_index): Likewise.
	(line_header::include_dir_at): Change comment and implementation on
	whether it is DWARF 5.
	(line_header::is_valid_file_index): New function.
	(line_header::file_name_at): Change comment and implementation on
	whether it is DWARF 5.
	(line_header::file_names): Change to private field renamed as
	m_file_names and introduce a new accessor method.
	(line_header::file_names_size): New method.
	(line_header::include_dirs): Change to private field and rename as
	m_include_dirs.
	(dw2_get_file_names_reader): Define local var at a smaller scope and
	reflect API change.
	(dwarf2_cu::setup_type_unit_groups): Reflect API change.
	(process_structure_scope): Likewise.
	(line_header::add_include_dir): Change message and reflect renaming.
	(line_header::add_file_name): Likewise.
	(read_formatted_entries): Handle DW_FORM_data16.
	(dwarf_decode_line_header): Fix line header length calculation.
	(psymtab_include_file_name): Change comment and API.
	(lnp_state_machine::m_file): Update comment and reflect type change.
	(lnp_state_machine::record_line): Reflect type change.
	(dwarf_decode_lines): Reflect API change.
	(file_file_name): Likewise.
	(file_full_name): Likewise.
2019-10-21 14:22:12 -07:00
Andrew Burgess
45f47c3a25 gdb: Ensure that !(a < a) is true in sort_cmp on obj_section objects
After the switch to use std::sort, if GDB is compiled with the
-D_GLIBCXX_DEBUG=1 flag then we see an error when using sort_cmp (in
objfiles.c) to sort obj_section objects.

The problem is that std::sort checks that the condition !(a < a)
holds, and currently this is not true.  GDB's sort_cmp is really
designed to sort lists in which no obj_section repeats, however, there
is some code in place to try and ensure we get a stable sort order if
there is a bug in GDB, unfortunately this code fails the above check.

By reordering some of the checks inside sort_cmp, it is pretty easy to
ensure that the !(a < a) condition holds.

I've not bothered to make this condition check optimal, like I said
this code is only in place to ensure that we get stable results if GDB
goes wrong, so I've made the smallest change needed to get the correct
behaviour.

After this commit I see no regressions when running GDB compiled with
-D_GLIBCXX_DEBUG=1.

gdb/ChangeLog:

	* objfiles.c (sort_cmp): Ensure that !(a < a) holds true.

Change-Id: I4b1e3e1640865104c0896cbb6c3fdbbc04d9645b
2019-10-21 21:10:02 +01:00
Tom Tromey
e5f3c0e3b8 Remove tui_exec_info_content
I happened to notice that the tui_exec_info_content typedef is unused.
This patch removes it.  Tested by rebuilding.

gdb/ChangeLog
2019-10-21  Tom Tromey  <tom@tromey.com>

	* tui/tui-winsource.h (tui_exec_info_content): Remove typedef.

Change-Id: I768edc482366e830eb4528c799686bb27518cdcb
2019-10-21 09:26:39 -06:00
Andrew Burgess
66b92822fa contrib: Update dg-extract-results.* from gcc
The dg-extract-results scripts have been updated in the gcc
repository.  This commit copies the updated versions of the scripts in
to the binutils-gdb repository.

There are two changes, these are:

  1. Improved detection of timeout lines, though I suspect this only
  applies to gcc results, and

  2. Detection of KPASS results, this is of interest to gdb, where
  these results would not be included in the final .sum file.

A grep over binutils-gdb shows the dg-extract-results is not used by
ld, gas, or binutils, however I tested these anyway and saw no changes
in the final .sum files (tested on x86-64 GNU/Linux).

On gdb when running tests in parallel dg-extract-results is used, and
the final .sum file now includes the KPASS results.

contrib/ChangeLog:

	* dg-extract-results.py: Update from gcc repo.
	* dg-extract-results.sh: Likewise.

Change-Id: I54abd07f4e8f5cf88a6db74519674f6939860157
2019-10-21 15:26:48 +01:00
Tom Tromey
a0a461e5b4 Fix creation of nm.h when configure is changed
My earlier patch -- commit c5adaa192 ("Fix creation of stamp-h by
gdb's configure script") -- broke the creation of nm.h.  In
particular, configure removes nm.h, so if you touch configure and
rebuild, nothing will re-create the link, breaking the build.

This patch fixes the bug, and also updates configure.ac to use
AC_CONFIG_LINKS, rather than the obsolete AC_LINK_FILES.

Finally, I noticed that gcore is in generated_files in the
Makefile.in.  I think this is incorrect, as generated_files is only
needed for files that can be the target of a #include.  So, this patch
removes it.

gdb/ChangeLog
2019-10-21  Tom Tromey  <tom@tromey.com>

	* configure.ac (nm.h): Conditionally create nm.h link.  Subst
	NM_H.   Use AC_CONFIG_LINKS.
	* configure: Rebuild.
	* Makefile.in (NM_H): New variable.
	(generated_files): Add NM_H.  Remove gcore.
	(nm.h, stamp-nmh): New targets.

Change-Id: I8dd539785d52455e85389425e4bb996c8a127a0e
2019-10-21 07:45:30 -06:00
Tom de Vries
94cb375411 [gdb/testsuite] Compile infcall-nested-structs.exp with -O2
As mentioned in commit 745ff14e6e "[gdb/tdep] Fix 'Unexpected register class'
assert in amd64_push_arguments", of the 12 KFAILs added there, 3 are KPASSing
with g++ 4.8.5.

The KPASSes are due to:
- gdb incorrectly expecting the second half of the result of function
  rtn_str_struct_02_01 in register %rdx.
- rtn_str_struct_02_01 using %rdx as a temporary, thereby accidentally setting
  it to the expected value.

Reduce the chance of hiding errors due accidental register settings by
compiling the test-case with -O2.

This fixes the KPASSes when applied on top of commit 745ff14e6e.

Tested on x86_64-linux.

Tested with g++ 4.8.5, 7.4.1, 8.3.1, 9.2.1.

gdb/testsuite/ChangeLog:

2019-10-21  Tom de Vries  <tdevries@suse.de>

	* gdb.base/infcall-nested-structs.c: Add
	__attribute__((noinline,noclone)) to all functions.
	(call_all): Add missing variable initialization.  Simplify return value.
	(breakpt): Increment volatile variable, to prevent call from being
	optimized out.
	* gdb.base/infcall-nested-structs.exp: Compile with -O2.

Change-Id: Ic027e1c957fecd6686345639db99f5eaee3cdf05
2019-10-21 15:08:54 +02:00
Alan Modra
95cc7c169c ar P support
This patch extends "ar P" to allow creation of normal (as distinct
from thin) archives with full path names.

	PR 452
	PR 25104
bfd/
	* archive.c (normalize): Return file unchanged when
	BFD_ARCHIVE_FULL_PATH.
	(_bfd_construct_extended_name_table): Pass abfd, the output
	bfd, to normalize.
	(_bfd_archive_bsd44_construct_extended_name_table): Likewise.
	* bfd.c (struct bfd): Make flags a full flagword.
	(BFD_ARCHIVE_FULL_PATH): Define.
	* bfd-in2.h: Regenerate.
binutils/
	* ar.c (write_archive): Set BFD_ARCHIVE_FULL_PATH.
	* doc/binutils.texi (extract from archive): Mention
	restrictions when extracting from archives with full paths.
	(ar P): Update to current P support.
	(ar -X32_64): Fix spelling.
2019-10-21 16:13:39 +10:30
Tom Tromey
54d83b8d39 Make unlink_objfile and put_objfile_before static
I noticed an obsolete comment just before unlink_objfile, and then I
noticed that both unlink_objfile and put_objfile_before could be
static.  This patch makes these changes, and also moves unlink_objfile
earlier, so that a forward declaration is not needed.

Tested by rebuilding.

gdb/ChangeLog
2019-10-20  Tom Tromey  <tom@tromey.com>

	* objfiles.h (unlink_objfile, put_objfile_before): Don't declare.
	* objfiles.c (unlink_objfile): Move earlier.  Now static.  Remove
	obsolete comment.
	(put_objfile_before): Now static.

Change-Id: I1b5927a60fd1cc59bfc9c6761f61652a01ef13e0
2019-10-20 20:54:06 -06:00
GDB Administrator
fd65fe1a18 Automatic date update in version.in 2019-10-21 00:00:52 +00:00
John David Anglin
2c9e9550ca [bfd] Provide 8-byte minimum alignment for .plt section
This change increases the default alignment for the .plt section
	from 4 bytes to 8 bytes.  When function descriptors are 8-byte
	aligned, they can be updated atomically on 32-bit hppa.  This
	helps with ordering issues on SMP machines.  It also ensures
	that descriptors reside on the same cache line.  This reduces
	the probability of a double TLB miss in a call.

	2019-10-20  John David Anglin  <danglin@gcc.gnu.org>

		* elf32-hppa.c (elf32_hppa_size_dynamic_sections): Provide 8-byte
		minimum alignment for .plt section.
2019-10-20 12:01:58 -04:00
GDB Administrator
80051c7439 Automatic date update in version.in 2019-10-20 00:01:57 +00:00
Simon Marchi
2377111731 gdb: Make startswith return a bool
gdb/ChangeLog:

	* gdbsupport/common-utils.h (startswith): Change return type to
	bool.

Change-Id: I1c11b9bb7f89b3885c1bb55097adb5be6d333ad4
2019-10-19 17:01:09 -04:00
Christian Biesinger
39ef2f6256 Replace some more qsort calls with std::sort
This has better typesafety, avoids a function pointer indirection,
and can benefit from inlining.

gdb/ChangeLog:

2019-10-19  Christian Biesinger  <cbiesinger@google.com>

	* bcache.c (bcache::print_statistics): Use std::sort instead of qsort.
	* breakpoint.c (bp_locations_compare): Rename to...
	(bp_location_is_less_than): ...this, and change to std::sort semantics.
	(update_global_location_list): Use std::sort instead of qsort.
	* buildsym.c (compare_line_numbers): Rename to...
	(lte_is_less_than): ...this, and change to std::sort semantics.
	(buildsym_compunit::end_symtab_with_blockvector): Use std::sort
	instead of qsort.
	* disasm.c (compare_lines): Rename to...
	(line_is_less_than): ...this, and change to std::sort semantics.
	(do_mixed_source_and_assembly_deprecated): Call std::sort instead
	of qsort.
	* dwarf2-frame.c (qsort_fde_cmp): Rename to...
	(fde_is_less_than): ...this, and change to std::sort semantics.
	(dwarf2_build_frame_info): Call std::sort instead of qsort.
	* mdebugread.c (compare_blocks):
	(block_is_less_than): ...this, and change to std::sort semantics.
	(sort_blocks): Call std::sort instead of qsort.
	* objfiles.c (qsort_cmp): Rename to...
	(sort_cmp): ...this, and change to std::sort semantics.
	(update_section_map): Call std::sort instead of qsort.
	* remote.c (compare_pnums): Remove.
	(map_regcache_remote_table): Call std::sort instead of qsort.
	* utils.c (compare_positive_ints): Remove.
	* utils.h (compare_positive_ints): Remove.
	* xcoffread.c (compare_lte): Remove.
	(arrange_linetable): Call std::sort instead of qsort.

Change-Id: Ibcddce12a3d07448701e731b7150fa23611d86de
2019-10-19 15:45:33 -05:00
John David Anglin
18338fcee6 [bfd] Revise import stubs on hppa.
This commit updates the import stubs to leave the pointer to the
	function descriptor in register %r22.  This provides a backup
	mechanism for _dl_runtime_resolve to fixup descriptors during
	lazy binding.

	bfd/ChangeLog
	2019-10-19  John David Anglin  <danglin@gcc.gnu.org>

		* elf32-hppa.c: Revise import stub sequences.
		(LONG_BRANCH_STUB_SIZE): Define.
		(LONG_BRANCH_SHARED_STUB_SIZE): Define.
		(IMPORT_STUB_SIZE): Define.
		(IMPORT_SHARED_STUB_SIZE): Define.
		(EXPORT_STUB_SIZE): Define.
		(plt_stub): Revise to not use register %r22.
		(LDO_R1_R22): Define.
		(LDW_R22_R21): Define.
		(LDW_R22_R19): Define.
		(hppa_build_one_stub): Update stub generation and use new defines.
		(hppa_size_one_stub): Likewise.
2019-10-19 13:52:23 -04:00
John David Anglin
1c1a69dcae [ld] Fix failure of pr19161 on hppa*-*linux*.
ld/ChangeLog
	2019-10-19  Alan Modra  <amodra@gmail.com>

		PR ld/25110
		* testsuite/ld-gc/gc.exp: Adjust LDFLAGS for pr19161 dump test on
		hppa*-*-linux*.
2019-10-19 13:01:29 -04:00
Sergio Durigan Junior
f71433ee7f Fix typos in symfile.c and i386-darwin-tdep.c
This commit fixes two simple typos, one in gdb/symfile.c and the other
in gdb/i386-darwin-tdep.c.  s/wether/whether/.

2019-10-19  Sergio Durigan Junior  <sergiodj@redhat.com>

	* symfile.c (init_entry_point_info): Fix typo.
	* i386-darwin-tdep.c (darwin_dwarf_signal_frame_p): Fix typo.

Change-Id: I1fbb39c32009c61c862b6bd56ce12f24a9edb2c4
2019-10-19 01:10:09 -04:00
GDB Administrator
5a023697e1 Automatic date update in version.in 2019-10-19 00:00:34 +00:00
Tom de Vries
85102364b2 [gdb] Fix more typos in comments
Fix typos in comments.  NFC.

Tested on x86_64-linux.

gdb/ChangeLog:

2019-10-18  Tom de Vries  <tdevries@suse.de>

	* aarch64-tdep.c: Fix typos in comments.
	* ada-lang.c: Same.
	* ada-tasks.c: Same.
	* alpha-tdep.c: Same.
	* alpha-tdep.h: Same.
	* amd64-nat.c: Same.
	* amd64-windows-tdep.c: Same.
	* arc-tdep.c: Same.
	* arc-tdep.h: Same.
	* arch-utils.c: Same.
	* arm-nbsd-tdep.c: Same.
	* arm-tdep.c: Same.
	* ax-gdb.c: Same.
	* blockframe.c: Same.
	* btrace.c: Same.
	* c-varobj.c: Same.
	* coff-pe-read.c: Same.
	* coffread.c: Same.
	* cris-tdep.c: Same.
	* darwin-nat.c: Same.
	* dbxread.c: Same.
	* dcache.c: Same.
	* disasm.c: Same.
	* dtrace-probe.c: Same.
	* dwarf-index-write.c: Same.
	* dwarf2-frame-tailcall.c: Same.
	* dwarf2-frame.c: Same.
	* dwarf2read.c: Same.
	* eval.c: Same.
	* exceptions.c: Same.
	* fbsd-tdep.c: Same.
	* findvar.c: Same.
	* frame.c: Same.
	* frv-tdep.c: Same.
	* gnu-v3-abi.c: Same.
	* go32-nat.c: Same.
	* h8300-tdep.c: Same.
	* hppa-tdep.c: Same.
	* i386-linux-tdep.c: Same.
	* i386-tdep.c: Same.
	* ia64-libunwind-tdep.c: Same.
	* ia64-tdep.c: Same.
	* infcmd.c: Same.
	* infrun.c: Same.
	* linespec.c: Same.
	* linux-nat.c: Same.
	* linux-thread-db.c: Same.
	* machoread.c: Same.
	* mdebugread.c: Same.
	* mep-tdep.c: Same.
	* mn10300-tdep.c: Same.
	* namespace.c: Same.
	* objfiles.c: Same.
	* opencl-lang.c: Same.
	* or1k-tdep.c: Same.
	* osabi.c: Same.
	* ppc-linux-nat.c: Same.
	* ppc-linux-tdep.c: Same.
	* ppc-sysv-tdep.c: Same.
	* printcmd.c: Same.
	* procfs.c: Same.
	* record-btrace.c: Same.
	* record-full.c: Same.
	* remote-fileio.c: Same.
	* remote.c: Same.
	* rs6000-tdep.c: Same.
	* s12z-tdep.c: Same.
	* score-tdep.c: Same.
	* ser-base.c: Same.
	* ser-go32.c: Same.
	* skip.c: Same.
	* sol-thread.c: Same.
	* solib-svr4.c: Same.
	* solib.c: Same.
	* source.c: Same.
	* sparc-nat.c: Same.
	* sparc-sol2-tdep.c: Same.
	* sparc-tdep.c: Same.
	* sparc64-tdep.c: Same.
	* stabsread.c: Same.
	* stack.c: Same.
	* symfile.c: Same.
	* symtab.c: Same.
	* target-descriptions.c: Same.
	* target-float.c: Same.
	* thread.c: Same.
	* utils.c: Same.
	* valops.c: Same.
	* valprint.c: Same.
	* value.c: Same.
	* varobj.c: Same.
	* windows-nat.c: Same.
	* xcoffread.c: Same.
	* xstormy16-tdep.c: Same.
	* xtensa-tdep.c: Same.

Change-Id: I5175f1b107bfa4e1cdd4a3361ccb4739e53c75c4
2019-10-18 02:48:08 +02:00
GDB Administrator
39849b0503 Automatic date update in version.in 2019-10-18 00:00:20 +00:00
Jim Wilson
330a6637a5 RISC-V: Report unresolved relocation error via linker's callback function.
Two patches from Nelson Chu.

It is better to use the linker's callback functions to handle the link time
error when relocating.  The unresolved relocation error can be regarded as
an unsupported relocation.  To make user easier to understand different errors,
we need to extend the current error message format of the callback function
since the format is fixed.

	bfd/
	* elfnn-riscv.c (riscv_elf_relocate_section): Use asprintf to extend
	the error message if needed, and then store the result into the
	`msg_buf`.  Finally, remember to free the unused `msg_buf`.  All error
	message for the dangerous relocation should be set before we call the
	callback function.  If we miss the error message since linker runs out
	of memory, we should set the default error message for the error.

	ld/
	* testsuite/ld-riscv-elf/lib-nopic-01a.s: Create the shared library
	lib-nopic-01a.so, it will be linked with lib-nopic-01b.s.
	* testsuite/ld-riscv-elf/lib-nopic-01b.s: Add new test for the
	unresolved relocation.  Link the non-pic code into a shared library
	may cause the error.
	* testsuite/ld-riscv-elf/lib-nopic-01b.d: Likewise.
	* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Run the new test only when
	the shared library is supported.

R_RISCV_CALL, R_RISCV_JAL and R_RISCV_RVC_JUMP are pc-relative relocation.
For now, we do not allow the object with these relocation links into a shared
library since the referenced symbols may be loaded to the places that too far
from the pc.  We can improve the error message for these unsupported relocation
to notice user that they should recompile their code with `fPIC`.

	bfd/
	* elfnn-riscv.c (riscv_elf_relocate_section): Report the error message
	that user should recompile their code with `fPIC` when linking non-pic
	code into shared library.

	ld/
	* testsuite/ld-riscv-elf/lib-nopic-01b.d: Update the error message.

Change-Id: Ib3347a0a6fa1c2b20a9647c314d5bec2c322ff04
2019-10-17 15:38:27 -07:00
Tom Tromey
c5adaa1921 Fix creation of stamp-h by gdb's configure script
I happened to notice that "make" would always print:

    CONFIG_HEADERS=config.h:config.in \
      CONFIG_COMMANDS="default depdir" \
      CONFIG_FILES= \
      CONFIG_LINKS= \
      /bin/sh config.status
    config.status: creating config.h
    config.status: config.h is unchanged

on every rebuild.  This seems to have changed due to an autoconf
upgrade at some point in the past.  In the autoconf gdb uses now, it
works to use AC_CONFIG_HEADERS and then create the stamp file via the
"commands" argument.

This patch also fixes up Makefile.in to use the new-style
config.status invocation.  It's no longer necessary to pass the output
file names via environment variables.

gdb/ChangeLog
2019-10-17  Tom Tromey  <tromey@adacore.com>

	* configure: Rebuild.
	* configure.ac: Use AC_CONFIG_HEADERS.  Create stamp-h there, not
	in AC_CONFIG_FILES invocation.
	* Makefile.in (Makefile, data-directory/Makefile, stamp-h): Use
	new-style config.status invocation.

gdb/gdbserver/ChangeLog
2019-10-17  Tom Tromey  <tromey@adacore.com>

	* configure: Rebuild.
	* configure.ac: Use AC_CONFIG_HEADERS.  Create stamp-h there, not
	in AC_CONFIG_FILES invocation.
	* Makefile.in (stamp-h, Makefile): Use new-style config.status
	invocation.

Change-Id: Ia0530d1c5b9756812d29ddb8dc1062326155e61e
2019-10-17 13:21:24 -06:00
Sergio Durigan Junior
95c746ccc4 Add libctf to src-release.sh:GDB_SUPPORT_DIRS
We're forgetting to include the libctf directory when creating the
snapshot.  This commit changes src-release.sh and adds it to
GDB_SUPPORT_DIRS.

2019-10-17  Sergio Durigan Junior  <sergiodj@redhat.com>

	* src-release.sh (GDB_SUPPORT_DIRS): Add libctf.

Change-Id: Iada82e5c9e4f8d5a0a5e467d2a628f1fba66002e
2019-10-17 14:00:51 -04:00
Tom de Vries
405feb71d4 [gdb] Fix typos in comments
Fix typos in comments.  NFC.

Tested on x86_64-linux.

gdb/ChangeLog:

2019-10-17  Tom de Vries  <tdevries@suse.de>

	* arm-nbsd-nat.c: Fix typos in comments.
	* arm-tdep.c: Same.
	* darwin-nat-info.c: Same.
	* dwarf2read.c: Same.
	* elfread.c: Same.
	* event-top.c: Same.
	* findvar.c: Same.
	* gdbtypes.c: Same.
	* hppa-tdep.c: Same.
	* i386-tdep.c: Same.
	* jit.c: Same.
	* main.c: Same.
	* mdebugread.c: Same.
	* moxie-tdep.c: Same.
	* nto-procfs.c: Same.
	* osabi.c: Same.
	* ppc-linux-tdep.c: Same.
	* remote.c: Same.
	* riscv-tdep.c: Same.
	* s390-tdep.c: Same.
	* sh-tdep.c: Same.
	* sparc-linux-tdep.c: Same.
	* sparc-nat.c: Same.
	* stack.c: Same.
	* target-descriptions.c: Same.
	* top.c: Same.
	* varobj.c: Same.

Change-Id: I6047967abd2d51c9000dea15184d19f4e952c3ff
2019-10-17 18:06:36 +02:00
Tom de Vries
062f1fc13a [gdb/testsuite] Fix gdb.fortran/module.exp for debug info from other files
On openSUSE Leap 15.1, I get:
...
FAIL: gdb.fortran/module.exp: info variables -n
...
because the info variables command prints info also for init.c:
...
File init.c:^M
24:     const int _IO_stdin_used;^M
...
while the regexps in the test-case only expect info for module.f90.

Fix this by extending the regexps.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2019-10-17  Tom de Vries  <tdevries@suse.de>

	* gdb.fortran/module.exp: Allow info variables to print info for files
	other than module.f90.

Change-Id: I401d8018b121fc7343f6bc8b671900349462457f
2019-10-17 10:07:05 +02:00
Alan Modra
a315e14713 PR29, Coreutils POSIX2_VERSION as 200112L
As of today we have just the following oddities left
./gnulib/update-gnulib.sh:ver=`autoconf --version 2>&1 | head -1 | sed 's/.*) //'`
./gnulib/update-gnulib.sh:ver=`automake --version 2>&1 | head -1 | sed 's/.*) //'`
./gnulib/update-gnulib.sh:ver=`aclocal --version 2>&1 | grep -v "called too early to check prototype" | head -1 | sed 's/.*) //'`
./src-release.sh:	head -1 $tool/version.in
./contrib/dg-extract-results.sh:tail -2 $FIRST_SUM | $GREP '^#' > /dev/null || tail -2 $FIRST_SUM

gnulib and contrib (from gcc) are outside of binutils control, so with
this patch I'm going to declare this 15 year old bug fixed.

	PR 29
	* src-release.sh (getver): Replace "head -1" with "head -n 1".
2019-10-17 16:34:02 +10:30
Tom Tromey
befcd486f4 Constify objfile::original_name
I noticed that objfile::original_name could be a "const char *" rather
than a plain "char *".  This patch implements this change.  Tested by
rebuilding.

gdb/ChangeLog
2019-10-16  Tom Tromey  <tom@tromey.com>

	* objfiles.h (struct objfile) <original_name>: Now const.
2019-10-16 20:44:21 -06:00
GDB Administrator
611fa2f46c Automatic date update in version.in 2019-10-17 00:00:23 +00:00
Andrew Burgess
0b54364d92 gdb/fortran: Add test for module variables in 'info variables' output
Recent work from Tom Tromey to better handle variables with associated
copy relocations has fixed a Fortran issue where module variables
wouldn't show up in the output of 'info variables'.

This commit adds a test for this functionality to ensure it doesn't
get broken in the future.

gdb/testsuite/ChangeLog:

	* gdb.fortran/module.exp: Extend with 'info variables' test.

Change-Id: I7306b1d0a9a72947fd48ad7a03f49df774d6573b
2019-10-16 22:22:09 +01:00
Andrew Burgess
7ff5fae704 gdb/testsuite: Allow cc-with-tweaks board file to be used with Fortran
The board file cc-with-tweaks is used as the core for lots of other
board files, for example cc-with-gdb-index and cc-with-debug-names.
This commit extends cc-with-tweaks so that it will wrap the Fortran
compiler, allowing for more test coverage.

I tested all of the board files that make use of cc-with-tweaks
running the gdb.fortran/*.exp test set, and in some cases I did see
extra failures.  The "standard" results are:

                    === gdb Summary ===

    # of expected passes            953
    # of known failures             2

With board file 'cc-with-dwz-m':

                    === gdb Summary ===

    # of expected passes            903
    # of unexpected failures        1
    # of known failures             2
    # of untested testcases         4

With board file 'dwarf4-gdb-index':

                    === gdb Summary ===

    # of expected passes            950
    # of unexpected failures        3
    # of known failures             2

With board file 'fission-dwp':

                    === gdb Summary ===

    # of expected passes            949
    # of unexpected failures        4
    # of known failures             2

Despite these extra failure I don't think this should prevent this
change going in as these failures presumably already exist in GDB.

gdb/testsuite/ChangeLog:

	* boards/cc-with-tweaks.exp: Setup F90_FOR_TARGET and
	F77_FOR_TARGET.

Change-Id: I06d412f94d0e119ad652dd6c20829f6705a54622
2019-10-16 22:22:09 +01:00
Christian Biesinger
17bfe554b9 Allow not saving the signal state in SIGSETJMP
Saving the signal state is very slow (this patch is a 14% speedup).  The
reason we need this code is because signal handler will leave the
signal blocked when we longjmp out of it.  But in this case we can
just manually unblock the signal instead of taking the unconditional
perf hit.

gdb/ChangeLog:

2019-10-16  Christian Biesinger  <cbiesinger@google.com>

	* gdbsupport/gdb_setjmp.h (SIGSETJMP): Allow passing in the value to
	pass on to sigsetjmp's second argument.
	* cp-support.c (gdb_demangle): Unblock SIGSEGV if we caught a crash.

Change-Id: Ib3010966050c64b4cc8b47d8cb45871652b0b3ea
2019-10-16 16:13:43 -05:00
Keith Seitz
950b74950f DWARF reader: Reject sections with invalid sizes
This is another fuzzer bug, gdb/23567.  This time, the fuzzer has
specifically altered the size of .debug_str:

$ eu-readelf -S objdump
Section Headers:
[Nr] Name                 Type         Addr             Off      Size     ES Flags Lk Inf Al
[31] .debug_str           PROGBITS     0000000000000000 0057116d ffffffffffffffff  1 MS     0   0  1

When this file is loaded into GDB, the DWARF reader crashes attempting
to access the string table (or it may just store a bunch of nonsense):

[gdb-8.3-6-fc30]
$ gdb -nx -q objdump
BFD: warning: /path/to/objdump has a corrupt section with a size (ffffffffffffffff) larger than the file size
Reading symbols from /path/to/objdump...
Segmentation fault (core dumped)

Nick has already committed a BFD patch to issue the warning seen above.

[gdb master 6acc1a0b]
$ gdb -BFD: warning: /path/to/objdump has a corrupt section with a size (ffffffffffffffff) larger than the file size
Reading symbols from /path/to/objdump...
(gdb) inf func
All defined functions:

File ./../include/dwarf2.def:
186:	const

              8 *>(.:
                     ;'@�B);
747:	const

              8 *�(.:
                     ;'@�B);
701:	const

              8 *�D �
                     (.:
                        ;'@�B);
71:	const

              8 *(.:
                    ;'@�B);
/* and more gibberish  */

Consider read_indirect_string_at_offset_from:

static const char *
read_indirect_string_at_offset_from (struct objfile *objfile,
                                     bfd *abfd, LONGEST str_offset,
                                     struct dwarf2_section_info *sect,
                                     const char *form_name,
                                     const char *sect_name)
{
  dwarf2_read_section (objfile, sect);
  if (sect->buffer == NULL)
    error (_("%s used without %s section [in module %s]"),
           form_name, sect_name, bfd_get_filename (abfd));
  if (str_offset >= sect->size)
    error (_("%s pointing outside of %s section [in module %s]"),
           form_name, sect_name, bfd_get_filename (abfd));
  gdb_assert (HOST_CHAR_BIT == 8);
  if (sect->buffer[str_offset] == '\0')
    return NULL;
  return (const char *) (sect->buffer + str_offset);
}

With sect_size being ginormous, the code attempts to access
sect->buffer[GINORMOUS], and depending on the layout of memory,
GDB either stores a bunch of gibberish strings or crashes.

This is an attempt to mitigate this by implementing a similar approach
used by BFD. In our case, we simply reject the section with the invalid
length:

$ ./gdb -nx -q objdump
BFD: warning: /path/to/objdump has a corrupt section with a size (ffffffffffffffff) larger than the file size
Reading symbols from /path/to/objdump...

warning: Discarding section .debug_str which has a section size (ffffffffffffffff) larger than the file size [in module /path/to/objdump]
DW_FORM_strp used without .debug_str section [in module /path/to/objdump]
(No debugging symbols found in /path/to/objdump)
(gdb)

Unfortunately, I have not found a way to regression test this, since it
requires poking ELF section headers.

gdb/ChangeLog:
2019-10-16  Keith Seitz  <keiths@redhat.com>

	PR gdb/23567
	* dwarf2read.c (dwarf2_per_objfile::locate_sections): Discard
	sections whose size is greater than the file size.

Change-Id: I896ac3b4eb2207c54e8e05c16beab3051d9b4b2f
2019-10-16 11:35:16 -07:00
Jim Wilson
ff371ec999 Add initial compile command support to RISC-V port.
This adds initial compile command support to the RISC-V port.  This fixes
about 228 testsuite failures on a riscv64-linux machine.  We need to get
the triplet right which is normally riscv64 or riscv32 instead of the
default riscv.  Also, we need to get the compiler options right, since we
don't accept the default -m64 and -mcmodel=large options, so we need to
construct -march and -mabi options which are correct for the target.  We
currently don't have info about all extensions used by the target, so this
may need to be adjusted later.  For now, I'm assuming that we have all
extensions required by the linux platform spec.

	gdb/
	* riscv-tdep.c (riscv_gcc_target_options): New.
	(riscv_gnu_triplet_regexp): New.
	(riscv_gdbarch_init): Call set_gdbarch_gcc_triplet_options and
	set_gdbarch_gnu_triplet_regexp.

Change-Id: I315ce8de7789ddf7bdd3b532f917519464941294
2019-10-16 10:58:37 -07:00
Christian Biesinger
fec4e896d6 Create xml-builtin.h to declare xml_builtins
xml-builtin.c only has character arrays and no dependencies, so this
creates a simple header file for that purpose so that gdbserver
can include that instead of re-declaring xml_builtin.

Despite the name, feature_to_c.sh is already specific to xml_builtins
(it hardcodes the variable name), so making it always output the
include for xml-builtin.h seems fine.

gdb/ChangeLog:

2019-10-16  Christian Biesinger  <cbiesinger@google.com>

	* Makefile.in: Add xml-builtin.h.
	* features/feature_to_c.sh: Add an include for xml-builtin.h
	to ensure that the compiler checks that the types match.
	* xml-builtin.h: New file.
	* xml-support.c (fetch_xml_builtin): Add missing const.
	* xml-support.h: Remove declaration of xml_builtins.

gdb/gdbserver/ChangeLog:

2019-10-16  Christian Biesinger  <cbiesinger@google.com>

	* server.c: Include xml-builtin.h.
	(get_xml_features): Don't declare xml_builtins here.

Change-Id: I806ef0851c43ead90b545a11794e41f5e5178436
2019-10-16 18:19:14 +02:00
Simon Marchi
cbbbc402e0 libctf: mark swap.h inline functions as static
When building binutils with mingw-w64, I get the following errors:

    make[4]: Entering directory '/home/simark/build/binutils-gdb-mingw/binutils'
    /bin/sh ./libtool  --tag=CC   --mode=link ccache x86_64-w64-mingw32-gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -Wno-format -Werror -I/home/simark/src/binutils-gdb/binutils/../zlib -g3 -O0 -D__USE_MINGW_ACCESS  -Wl,--stack,12582912 -o objdump.exe objdump.o dwarf.o prdbg.o rddbg.o debug.o stabs.o rdcoff.o bucomm.o version.o filemode.o elfcomm.o  ../opcodes/libopcodes.la ../libctf/libctf.la ../bfd/libbfd.la ../libiberty/libiberty.a -lintl
    libtool: link: ccache x86_64-w64-mingw32-gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -Wno-format -Werror -I/home/simark/src/binutils-gdb/binutils/../zlib -g3 -O0 -D__USE_MINGW_ACCESS -Wl,--stack -Wl,12582912 -o .libs/objdump.exe objdump.o dwarf.o prdbg.o rddbg.o debug.o stabs.o rdcoff.o bucomm.o version.o filemode.o elfcomm.o  ../opcodes/.libs/libopcodes.a ../libctf/.libs/libctf.a -L/home/simark/build/binutils-gdb-mingw/zlib ../bfd/.libs/libbfd.a -lz ../libiberty/libiberty.a -lintl
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: ../libctf/.libs/libctf.a(ctf-open.o): in function `flip_header':
    /home/simark/src/binutils-gdb/libctf/ctf-open.c:964: undefined reference to `bswap_16'
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /home/simark/src/binutils-gdb/libctf/ctf-open.c:967: undefined reference to `bswap_32'
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /home/simark/src/binutils-gdb/libctf/ctf-open.c:968: undefined reference to `bswap_32'
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /home/simark/src/binutils-gdb/libctf/ctf-open.c:969: undefined reference to `bswap_32'
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /home/simark/src/binutils-gdb/libctf/ctf-open.c:970: undefined reference to `bswap_32'
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /home/simark/src/binutils-gdb/libctf/ctf-open.c:971: undefined reference to `bswap_32'
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: ../libctf/.libs/libctf.a(ctf-open.o):/home/simark/src/binutils-gdb/libctf/ctf-open.c:972: more undefined references to `bswap_32' follow
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: ../libctf/.libs/libctf.a(ctf-open.o): in function `flip_types':
    /home/simark/src/binutils-gdb/libctf/ctf-open.c:1112: undefined reference to `bswap_16'
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /home/simark/src/binutils-gdb/libctf/ctf-open.c:1113: undefined reference to `bswap_16'
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /home/simark/src/binutils-gdb/libctf/ctf-open.c:1132: undefined reference to `bswap_32'
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /home/simark/src/binutils-gdb/libctf/ctf-open.c:1133: undefined reference to `bswap_32'
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /home/simark/src/binutils-gdb/libctf/ctf-open.c:1134: undefined reference to `bswap_32'
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /home/simark/src/binutils-gdb/libctf/ctf-open.c:1135: undefined reference to `bswap_32'
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /home/simark/src/binutils-gdb/libctf/ctf-open.c:1144: undefined reference to `bswap_32'
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: ../libctf/.libs/libctf.a(ctf-open.o):/home/simark/src/binutils-gdb/libctf/ctf-open.c:1145: more undefined references to `bswap_32' follow
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: ../libctf/.libs/libctf.a(ctf-open.o): in function `ctf_bufopen_internal':
    /home/simark/src/binutils-gdb/libctf/ctf-open.c:1342: undefined reference to `bswap_16'
    /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: ../libctf/.libs/libctf.a(ctf-open-bfd.o): in function `ctf_fdopen':
    /home/simark/src/binutils-gdb/libctf/ctf-open-bfd.c:268: undefined reference to `bswap_16'

Apparently [1], if we have a function with `inline` but not `static`,
there should be a compilation unit defining the symbol too.
Alternatively, making those functions `static` fixes that.

[1] https://stackoverflow.com/questions/16245521/c99-inline-function-in-c-file/16254679#16254679

libctf/ChangeLog:

	* swap.h (bswap_16, bswap_32, bswap_64): Make static.

Change-Id: I8fd12aedf6c90f9b7418af948e5e0bae0c32eead
2019-10-16 11:12:23 -04:00
Tom de Vries
d10eccaa72 [gdb/tdep] Fix inferior call arg passing for amd64
We currently have 12 KFAILS in gdb.base/infcall-nested-structs.exp for
PR tdep/25096.

A minimal version of the failure looks like this.  Consider test.c:
...
struct s { int c; struct { int a; float b; } s1; };
struct s ref = { 0, { 'a', 'b' } };

int __attribute__((noinline,noclone)) check (struct s arg)
{ return arg.s1.a == 'a' && arg.s1.b == 'b' && arg.c == 0; }

int main (void)
{ return check (ref); }
...

When calling 'check (ref)' from main, we have '1' as expected:
...
$ g++ test.c -g ; ./a.out ; echo $?
1
...

But when calling 'check (ref)' from the gdb prompt, we get '0':
...
$ gdb a.out -batch -ex start -ex "p check (ref)"
Temporary breakpoint 1 at 0x400518: file test.c, line 8.

Temporary breakpoint 1, main () at test.c:8
8       { return check (ref); }
$1 = 0
...

The layout of struct s is this:
- the field c occupies 4 bytes at offset 0,
- the s1.a field occupies 4 bytes at offset 4, and
- the s1.b field occupies 4 bytes at offset 8.

When compiling at -O2, we can see from the disassembly of main:
...
  4003f0:       48 8b 3d 31 0c 20 00    mov    0x200c31(%rip),%rdi \
                                               # 601028 <ref>
  4003f7:       f3 0f 10 05 31 0c 20    movss  0x200c31(%rip),%xmm0 \
                                               # 601030 <ref+0x8>
  4003fe:       00
  4003ff:       e9 ec 00 00 00          jmpq   4004f0 <_Z5check1s>
...
that check is called with fields c and s1.a passed in %rdi, and s1.b passed
in %xmm0.

However, the classification in theclass (a variable representing the first and
second eightbytes, to put it in SYSV X86_64 psABI terms) in
amd64_push_arguments is incorrect:
...
(gdb) p theclass
$1 = {AMD64_INTEGER, AMD64_INTEGER}
...
and therefore the struct is passed using %rdi and %rsi instead of using %rdi
and %xmm0, which explains the failure.

The reason that we're misclassifying the argument in amd64_classify_aggregate
has to do with how nested struct are handled.

Rather than using fields c and s1.a for the first eightbyte, and using field
s1.b for the second eightbyte, instead field c is used for the first
eightbyte, and fields s1.a and s1.b are classified together in an intermediate
eightbyte, which is then used to merge with both the first and second
eightbyte.

Fix this by factoring out a new function amd64_classify_aggregate_field, and
letting it recursively handle fields of nested structs.

Tested on x86_64-linux.

Tested with g++ 4.8.5, 7.4.1, 8.3.1, 9.2.1.

Tested with clang++ 5.0.2 (which requires removing additional_flags=-Wno-psabi
and adding additional_flags=-Wno-deprecated).

gdb/ChangeLog:

2019-10-16  Tom de Vries  <tdevries@suse.de>

	PR tdep/25096
	* amd64-tdep.c (amd64_classify_aggregate_field): Factor out of ...
	(amd64_classify_aggregate): ... here.
	(amd64_classify_aggregate_field): Handled fiels of nested structs
	recursively.

gdb/testsuite/ChangeLog:

2019-10-16  Tom de Vries  <tdevries@suse.de>

	PR tdep/25096
	* gdb.base/infcall-nested-structs.exp: Remove PR25096 KFAILs.

Change-Id: Id55c74755f0a431ce31223acc86865718ae0c123
2019-10-16 17:11:56 +02:00
Tom de Vries
745ff14e6e [gdb/tdep] Fix 'Unexpected register class' assert in amd64_push_arguments
Atm, when executing gdb.base/infcall-nested-structs.exp on x86_64-linux, we get:
...
FAIL: gdb.base/infcall-nested-structs.exp: l=c++: types-tc-tf: \
  p/d check_arg_struct_02_01 (ref_val_struct_02_01)
FAIL: gdb.base/infcall-nested-structs.exp: l=c++: types-ts-tf: \
  p/d check_arg_struct_02_01 (ref_val_struct_02_01)
FAIL: gdb.base/infcall-nested-structs.exp: l=c++: types-ti-tf: \
  p/d check_arg_struct_02_01 (ref_val_struct_02_01)

                === gdb Summary ===

nr of expected passes            9255
nr of unexpected failures        3
nr of expected failures          142
...

The 3 FAILs are reported as PR tdep/25096.

The 142 XFAILs are for a gdb assertion failure, reported in PR tdep/24104,
which should have been KFAILs since there's a problem in gdb rather than in
the environment.

A minimal version of the assertion failure looks like this. Consider test.c:
...
struct s { struct { } es1; long f; };
struct s ref = { {}, 'f' };

int __attribute__((noinline,noclone)) check (struct s arg)
{ return arg.f == 'f'; }

int main (void)
{ return check (ref); }
...

When calling 'check (ref)' from main, we have '1' as expected:
...
$ g++ test3.c -g && ( ./a.out; echo $? )
1
...

But when calling 'check (ref)' from the gdb prompt, we get:
...
$ gdb a.out -batch -ex start -ex "p check (ref)"
Temporary breakpoint 1 at 0x4004f7: file test.c, line 8.

Temporary breakpoint 1, main () at test.c:8
8       { return check (ref); }
src/gdb/amd64-tdep.c:982: internal-error: \
  CORE_ADDR amd64_push_arguments(regcache*, int, value**, CORE_ADDR, \
                                 function_call_return_method): \
  Assertion `!"Unexpected register class."' failed.
...

The assert happens in this loop in amd64_push_arguments:
...
          for (j = 0; len > 0; j++, len -= 8)
            {
              int regnum = -1;
              int offset = 0;

              switch (theclass[j])
                {
                case AMD64_INTEGER:
                  regnum = integer_regnum[integer_reg++];
                  break;

                case AMD64_SSE:
                  regnum = sse_regnum[sse_reg++];
                  break;

                case AMD64_SSEUP:
                  gdb_assert (sse_reg > 0);
                  regnum = sse_regnum[sse_reg - 1];
                  offset = 8;
                  break;

                default:
                  gdb_assert (!"Unexpected register class.");
                }
		...
            }
...
when processing theclass[0], which is AMD64_NO_CLASS:
...
(gdb) p theclass
$1 = {AMD64_NO_CLASS, AMD64_INTEGER}
...

The layout of struct s is that the empty field es1 occupies one byte (due to
c++) at offset 0, and the long field f occupies 8 bytes at offset 8.

When compiling at -O2, we can see from the disassembly of main:
...
  4003f0:       48 8b 3d 41 0c 20 00    mov    0x200c41(%rip),%rdi \
                                               # 601038 <ref+0x8>
  4003f7:       e9 e4 00 00 00          jmpq   4004e0 <_Z5check1s>
  4003fc:       0f 1f 40 00             nopl   0x0(%rax)
...
that check is called with field f passed in %rdi, meaning that the
classification in theclass is correct, it's just not supported in the loop in
amd64_push_arguments mentioned above.

Fix the assert by implementing support for 'AMD64_NO_CLASS' in that loop.

This exposes 9 more FAILs of the PR tdep/25096 type, so mark all 12 of them as
KFAIL.

Tested on x86_64-linux.

Tested with g++ 4.8.5, 7.4.1, 8.3.1, 9.2.1.  With 4.8.5, 3 of the 12 KFAILs
are KPASSing.

Tested with clang++ 5.0.2 (which requires removing additional_flags=-Wno-psabi
and adding additional_flags=-Wno-deprecated).

gdb/ChangeLog:

2019-10-16  Tom de Vries  <tdevries@suse.de>

	PR tdep/24104
	* amd64-tdep.c (amd64_push_arguments): Handle AMD64_NO_CLASS in loop
	that handles 'theclass'.

gdb/testsuite/ChangeLog:

2019-10-16  Tom de Vries  <tdevries@suse.de>

	PR tdep/24104
	* gdb.base/infcall-nested-structs.exp: Remove XFAIL for PR tdep/24104.
	Add KFAIL for PR tdep/25096.

Change-Id: I8b66345bbf5c00209ca75b1209fd4d60b36e9ede
2019-10-16 17:11:56 +02:00
Tom de Vries
03e1ab9424 [gdb/testsuite] Fix local-static.exp with g++-4.8
With g++-4.8, I see:
...
(gdb) PASS: gdb.cp/local-static.exp: c++: print free_inline_func(void)
print 'S::method()'::S_M_s_var_int^M
No symbol "S_M_s_var_int" in specified context.^M
(gdb) FAIL: gdb.cp/local-static.exp: c++: print 'S::method()'::S_M_s_var_int
...

The variable is declared like this (showing pruned .ii):
...
void S::method ()
{
  static int S_M_s_var_int = 4;
}
...

But the DWARF generated for the variable is encapsulated in an unnamed lexical
block:
...
 <1><121>: Abbrev Number: 5 (DW_TAG_structure_type)
    <122>   DW_AT_name        : S
    ...
 <2><14f>: Abbrev Number: 6 (DW_TAG_subprogram)
    ...
    <150>   DW_AT_name        : (indirect string, offset: 0x599): method
    <156>   DW_AT_linkage_name: (indirect string, offset: 0x517): \
                                _ZN1S6methodEv /* demangled: dS::method() */
    ...
 <1><3f8>: Abbrev Number: 21 (DW_TAG_subprogram)
    <3f9>   DW_AT_specification: <0x14f>
    ...
    <3fe>   DW_AT_low_pc      : 0x4004fc
    <406>   DW_AT_high_pc     : 0x2c /* 0x400528 */
    ...
 <2><418>: Abbrev Number: 17 (DW_TAG_formal_parameter)
    <419>   DW_AT_name        : (indirect string, offset: 0x68a): this
    ...
 <2><424>: Abbrev Number: 18 (DW_TAG_lexical_block)
    <425>   DW_AT_low_pc      : 0x400508
    <42d>   DW_AT_high_pc     : 0x1e /* 0x400526 */
 <3><435>: Abbrev Number: 22 (DW_TAG_variable)
    <436>   DW_AT_name        : (indirect string, offset: 0x29d): S_M_s_var_int
...
which has the effect that the variable is not addressable unless the program
counter is in the range of the lexical block.

This is caused by gcc PR debug/55541, which was fixed in gcc 5.

Mark in total 225 FAILs as XFAIL.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2019-10-16  Tom de Vries  <tdevries@suse.de>

	PR testsuite/25059
	* gdb.cp/local-static.exp (do_test): Add xfails for gcc PR debug/55541.

Change-Id: Ibe86707eecffc79f1bb474d7928ea7d0c39a00a2
2019-10-16 17:00:04 +02:00
Tom de Vries
b17fcc1039 [gdb/testsuite] Fix regexp for reg value in jit-reader.exp
On openSUSE Leap 15.1 (as well as on Fedora-x86_64-m64 buildbot) I see:
...
FAIL: gdb.base/jit-reader.exp: with jit-reader: after mangling: current frame: info registers
...

The problem is that r10 is printed signed:
...
r10            0xffffffffffffffb0  -80^M
...
but the regexp expects a signed value:
...
            "r10            $hex +$decimal" \
...

Fix this by allowing signed values.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2019-10-16  Tom de Vries  <tdevries@suse.de>

	* gdb.base/jit-reader.exp: Allow non-pointer registers to be printed
	as signed.

Change-Id: Ie494d24fad7a9af7ac6bfaf731c4aa04f1333830
2019-10-16 16:53:37 +02:00
Alan Modra
22216541c1 PR13616, linker should pad executable sections with nops, not zeros
This implements padding of orphan executable sections for PowerPC.
Of course, the simple implementation of bfd_arch_ppc_nop_fill and
removing the NOP definition didn't work, with powerpc64 hitting a
testsuite failure linking to S-records.  That's because the srec
target is BFD_ENDIAN_UNKNOWN so the test of bfd_big_endian (abfd) in
default_data_link_order therefore returned false, resulting in a
little-endian nop pattern.  The rest of the patch fixes that problem
by adding a new field to bfd_link_info that can be used to determine
actual endianness on targets like srec.

	PR 13616
include/
	* bfdlink.h (struct bfd_link_info <big_endian>): New field.
bfd/
	* cpu-powerpc.c (bfd_arch_ppc_nop_fill): New function, use it
	for all ppc arch info.
	* linker.c (default_data_link_order): Pass info->big_endian to
	arch_info->fill function.
ld/
	* emulparams/elf64lppc.sh (NOP): Don't define.
	* emulparams/elf64ppc.sh (NOP): Don't define.
	* ldwrite.c (build_link_order): Use link_info.big_endian.  Move
	code determining endian to use for data_statement to..
	* ldemul.c (after_open_default): ..here.  Set link_info.big_endian.
2019-10-16 23:07:27 +10:30
Nick Clifton
12234dfd5f Fix potential illegal memory access when disassembling corrupt RX binaries.
opcodes * rx-dis.c (get_register_name): New function.  Provides safe
	access to name array.
	(get_condition_name, get_flag_name, get_double_register_name)
	(get_double_register_high_name, get_double_register_low_name)
	(get_double_control_register_name, get_double_condition_name):
	Likewise.
	(print_insn_rx): Use the accessor functions.
2019-10-16 12:56:58 +01:00
Alan Modra
dfde93ab8c genscripts comment tidy
Some of the comments in this file are ancient and no longer reflect
reality.  This patch removes those comments, and also the description
of ld options emitted to script files.  While describing what an
option does in the script file might help reinforce what the option
does, it's unnecessary and makes for overlong lines.  Also, some of
the descriptions did not mention all the options.

	* genscripts.sh: Correct comments.  Remove outdated comment block
	saying "Generate 5 or 6 script files..".  Remove description of
	ld options from comment emitted to script files, and order options
	as per comment block in genscripts.sh saying which scripts are
	generated.
2019-10-16 11:03:34 +10:30