Commit Graph

101583 Commits

Author SHA1 Message Date
Alan Modra
aa3c112fab Power10 Reduced precision outer product operations
include/
	* opcode/ppc.h (PPC_OPERAND_ACC): Define.  Renumber following
	PPC_OPERAND defines.
opcodes/
	* ppc-opc.c (insert_xa6a, extract_xa6a, insert_xb6a, extract_xb6a):
	New functions.
	(powerpc_operands): Define ACC, PMSK8, PMSK4, PMSK2, XMSK, YMSK,
	YMSK2, XA6a, XA6ap, XB6a entries.
	(PMMIRR, P_X_MASK, P_XX1_MASK, P_GER_MASK): Define
	(P_GER2_MASK, P_GER4_MASK, P_GER8_MASK, P_GER64_MASK): Define.
	(PPCVSX4): Define.
	(powerpc_opcodes): Add xxmfacc, xxmtacc, xxsetaccz,
	xvi8ger4pp, xvi8ger4, xvf16ger2pp, xvf16ger2, xvf32gerpp, xvf32ger,
	xvi4ger8pp, xvi4ger8, xvi16ger2spp, xvi16ger2s, xvbf16ger2pp,
	xvbf16ger2, xvf64gerpp, xvf64ger, xvi16ger2, xvf16ger2np,
	xvf32gernp, xvi8ger4spp, xvi16ger2pp, xvbf16ger2np, xvf64gernp,
	xvf16ger2pn, xvf32gerpn, xvbf16ger2pn, xvf64gerpn, xvf16ger2nn,
	xvf32gernn, xvbf16ger2nn, xvf64gernn, xvcvbf16sp, xvcvspbf16.
	(prefix_opcodes): Add pmxvi8ger4pp, pmxvi8ger4, pmxvf16ger2pp,
	pmxvf16ger2, pmxvf32gerpp, pmxvf32ger, pmxvi4ger8pp, pmxvi4ger8,
	pmxvi16ger2spp, pmxvi16ger2s, pmxvbf16ger2pp, pmxvbf16ger2,
	pmxvf64gerpp, pmxvf64ger, pmxvi16ger2, pmxvf16ger2np, pmxvf32gernp,
	pmxvi8ger4spp, pmxvi16ger2pp, pmxvbf16ger2np, pmxvf64gernp,
	pmxvf16ger2pn, pmxvf32gerpn, pmxvbf16ger2pn, pmxvf64gerpn,
	pmxvf16ger2nn, pmxvf32gernn, pmxvbf16ger2nn, pmxvf64gernn.
gas/
	* config/tc-ppc.c (pre_defined_registers): Add accumulators.
	(md_assemble): Check acc specified in correct operand.
	* testsuite/gas/ppc/outerprod.d,
	* testsuite/gas/ppc/outerprod.s,
	* testsuite/gas/ppc/vsx4.d,
	* testsuite/gas/ppc/vsx4.s: New tests.
	* testsuite/gas/ppc/ppc.exp: Run them.
2020-05-11 21:08:37 +09:30
Alan Modra
6edbfd3beb Power10 SIMD permute class operations
opcodes/
	* ppc-opc.c (insert_imm32, extract_imm32): New functions.
	(insert_xts, extract_xts): New functions.
	(IMM32, UIM3, IX, UIM5, SH3, XTS, P8RR): Define.
	(P_XX4_MASK, P_UXX4_MASK, VSOP, P_VS_MASK, P_VSI_MASK): Define.
	(VXRC_MASK, VXSH_MASK): Define.
	(powerpc_opcodes): Add vinsbvlx, vsldbi, vextdubvlx, vextdubvrx,
	vextduhvlx, vextduhvrx, vextduwvlx, vextduwvrx, vextddvlx,
	vextddvrx, vinshvlx, vinswvlx, vinsw, vinsbvrx, vinshvrx,
	vinswvrx, vinsd, vinsblx, vsrdbi, vinshlx, vinswlx, vinsdlx,
	vinsbrx, vinshrx, vinswrx, vinsdrx, lxvkq.
	(prefix_opcodes): Add xxsplti32dx, xxspltidp, xxspltiw, xxblendvb,
	xxblendvh, xxblendvw, xxblendvd, xxpermx.
gas/
	* testsuite/gas/ppc/simd_perm.d,
	* testsuite/gas/ppc/simd_perm.s: New test.
	* testsuite/gas/ppc/ppc.exp: Run it.
2020-05-11 21:08:37 +09:30
Alan Modra
c7d7aea2f5 Power10 128-bit binary integer operations
opcodes/
	* ppc-opc.c (powerpc_opcodes): Add vrlq, vdivuq, vmsumcud, vrlqmi,
	vmuloud, vcmpuq, vslq, vdivsq, vcmpsq, vrlqnm, vcmpequq, vmulosd,
	vsrq, vdiveuq, vcmpgtuq, vmuleud, vsraq, vdivesq, vcmpgtsq, vmulesd,
	vcmpequq., vextsd2q, vmoduq, vcmpgtuq., vmodsq, vcmpgtsq., xscvqpuqz,
	xscvuqqp, xscvqpsqz, xscvsqqp, dcffixqq, dctfixqq.
gas/
	* testsuite/gas/ppc/int128.d,
	* testsuite/gas/ppc/int128.s: New test.
	* testsuite/gas/ppc/ppc.exp: Run it.
2020-05-11 21:08:37 +09:30
Alan Modra
94ba9882d5 Power10 VSX 32-byte storage access
bfd/
	* elf64-ppc.c (xlate_pcrel_opt): Handle lxvp and stxvp.
opcodes/
	* ppc-opc.c (insert_xtp, extract_xtp): New functions.
	(XTP, DQXP, DQXP_MASK): Define.
	(powerpc_opcodes): Add lxvp, stxvp, lxvpx, stxvpx.
	(prefix_opcodes): Add plxvp and pstxvp.
gas/
	* testsuite/gas/ppc/vsx_32byte.d,
	* testsuite/gas/ppc/vsx_32byte.s: New test.
	* testsuite/gas/ppc/ppc.exp: Run it.
ld/
	* testsuite/ld-powerpc/pcrelopt.s: Add lxvp and stxvp.
	* testsuite/ld-powerpc/pcrelopt.d: Update.
2020-05-11 21:08:37 +09:30
Alan Modra
f4791f1afa Power10 vector integer multiply, divide, modulo insns
opcodes/
	* ppc-opc.c (powerpc_opcodes): Add vdivuw, vdivud, vdivsw, vmulld,
	vdivsd, vmulhuw, vdiveuw, vmulhud, vdiveud, vmulhsw, vdivesw,
	vmulhsd, vdivesd, vmoduw, vmodud, vmodsw, vmodsd.
gas/
	* testsuite/gas/ppc/vec_mul.s,
	* testsuite/gas/ppc/vec_mul.d: New test.
	* testsuite/gas/ppc/ppc.exp: Run it.
2020-05-11 21:08:37 +09:30
Peter Bergner
3ff0a5ba64 Power10 byte reverse instructions
opcodes/
	* ppc-opc.c (powerpc_opcodes) <brd, brh, brw>: New mnemonics.
gas/
	* testsuite/gas/ppc/byte_rev.d,
	* testsuite/gas/ppc/byte_rev.s: New test.
	* testsuite/gas/ppc/ppc.exp: Run it.
2020-05-11 21:08:36 +09:30
Peter Bergner
afef4fe975 Power10 Copy/Paste Extensions
opcodes/
	* opcodes/ppc-opc.c (insert_l1opt, extract_l1opt): New functions.
	(L1OPT): Define.
	(powerpc_opcodes) <paste.>: Add L operand for cpu POWER10.
gas/
	* testsuite/gas/ppc/power10.d: Add paste. tests.
	* testsuite/gas/ppc/power10.s: Likewise.
2020-05-11 21:08:36 +09:30
Peter Bergner
1224c05de4 Power10 Add new L operand to the slbiag instruction
opcodes/
	* ppc-opc.c (powerpc_opcodes) <slbiag>: Add variant with L operand.
gas/
	* testsuite/gas/ppc/power10.s: New test.
	* testsuite/gas/ppc/power10.d: Likewise.
	* testsuite/gas/ppc/ppc.exp: Run it.
2020-05-11 21:08:36 +09:30
Alan Modra
6bbb0c0595 PowerPC Default disassembler to -Mpower10
* ppc-dis.c (powerpc_init_dialect): Default to "power10".
2020-05-11 21:08:36 +09:30
Alan Modra
7c1f422735 PowerPC Rename powerxx to power10
Now that ISA3.1 is out we can finish with the powerxx silliness.

bfd/
	* elf64-ppc.c: Rename powerxx to power10 throughout.
gas/
	* config/tc-ppc.c (md_assemble): Update for PPC_OPCODE_POWER10
	renaming.
	* testsuite/gas/ppc/prefix-align.d: Use -mpower10/-Mpower10 in
	place of -mfuture/-Mfuture.
	* testsuite/gas/ppc/prefix-pcrel.d: Likewise.
	* testsuite/gas/ppc/prefix-reloc.d: Likewise.
gold/
	* powerpc.cc: Rename powerxx to power10 throughout.
include/
	* elf/ppc64.h: Update comment.
	* opcode/ppc.h (PPC_OPCODE_POWER10): Rename from PPC_OPCODE_POWERXX.
ld/
	* testsuite/ld-powerpc/callstub-1.d: Use -mpower10/-Mpower10 in
	place of -mfuture/-Mfuture.
	* testsuite/ld-powerpc/notoc2.d: Likewise.
	* testsuite/ld-powerpc/powerpc.exp: Likewise.
	* testsuite/ld-powerpc/tlsgd.d: Likewise.
	* testsuite/ld-powerpc/tlsie.d: Likewise.
	* testsuite/ld-powerpc/tlsld.d: Likewise.
opcodes/
	* ppc-dis.c (ppc_opts): Add "power10" entry.
	(print_insn_powerpc): Update for PPC_OPCODE_POWER10 renaming.
	* ppc-opc.c (POWER10): Rename from POWERXX.  Update all uses.
2020-05-11 21:08:36 +09:30
Nick Clifton
73199c2b7a Updated French translation for the ld sub-directory and an update Spanish translation for the opcodes subdirectory. 2020-05-11 12:02:26 +01:00
Alan Modra
4d5acb1ea5 PR25961, buffer overflow in coff_swap_aux_in
PR 25961
	* coffgen.c (coff_get_normalized_symtab): Check that buffer
	contains required number of auxents before processing any auxent.
	* coffswap.h (coff_swap_aux_in <C_FILE>): Only swap in extended
	file name from auxents for PE.
2020-05-11 18:11:26 +09:30
GDB Administrator
b59cca2581 Automatic date update in version.in 2020-05-11 00:00:07 +00:00
Alok Kumar Sharma
86cd6bc8f6 gdb/fortran: Allow Flang MAIN_ in Fortran testing
Name of fortran main function for Flang compiler is MAIN_ while
for gfortran it is MAIN__ . In test cases MAIN__ is hardcoded for
the purpose of inserting breakpoint.

New proc is added to detect main function name depending on the
compiler used.
Fortran specific version of runto_main named fortran_runto_main
is added.

This commit adds support for Flang main function, there should be
no change for gfortran.

gdb/testsuite/ChangeLog

	* lib/fortran.exp (fortran_main): New Proc, handle flang MAIN_,
	(fortran_runto_main): New Proc, fortran version of runto_main.
	* gdb.fortran/array-bounds-high.exp: Handle flang MAIN_.
	* gdb.fortran/array-bounds.exp: Likewise.
	* gdb.fortran/array-slices.exp: Likewise.
	* gdb.fortran/block-data.exp: Likewise.
	* gdb.fortran/charset.exp: Likewise.
	* gdb.fortran/common-block.exp: Likewise.
	* gdb.fortran/complex.exp: Likewise.
	* gdb.fortran/derived-type-function.exp: Likewise.
	* gdb.fortran/derived-type.exp: Likewise.
	* gdb.fortran/info-modules.exp: Likewise.
	* gdb.fortran/info-types.exp: Likewise.
	* gdb.fortran/intrinsics.exp: Likewise.
	* gdb.fortran/library-module.exp: Likewise.
	* gdb.fortran/logical.exp: Likewise.
	* gdb.fortran/max-depth.exp: Likewise.
	* gdb.fortran/module.exp: Likewise.
	* gdb.fortran/multi-dim.exp: Likewise.
	* gdb.fortran/nested-funcs.exp: Likewise.
	* gdb.fortran/print-formatted.exp: Likewise.
	* gdb.fortran/print_type.exp: Likewise.
	* gdb.fortran/printing-types.exp: Likewise.
	* gdb.fortran/ptr-indentation.exp: Likewise.
	* gdb.fortran/ptype-on-functions.exp: Likewise.
	* gdb.fortran/subarray.exp: Likewise.
	* gdb.fortran/vla-alloc-assoc.exp: Likewise.
	* gdb.fortran/vla-datatypes.exp: Likewise.
	* gdb.fortran/vla-history.exp: Likewise.
	* gdb.fortran/vla-ptr-info.exp: Likewise.
	* gdb.fortran/vla-ptype-sub.exp: Likewise.
	* gdb.fortran/vla-ptype.exp: Likewise.
	* gdb.fortran/vla-sizeof.exp: Likewise.
	* gdb.fortran/vla-type.exp: Likewise.
	* gdb.fortran/vla-value-sub-arbitrary.exp: Likewise.
	* gdb.fortran/vla-value-sub-finish.exp: Likewise.
	* gdb.fortran/vla-value-sub.exp: Likewise.
	* gdb.fortran/vla-value.exp: Likewise.
	* gdb.fortran/whatis_type.exp: Likewise.
	* gdb.mi/mi-var-child-f.exp: Likewise.
2020-05-11 00:48:10 +05:30
GDB Administrator
1ea1aee1ed Automatic date update in version.in 2020-05-10 00:00:15 +00:00
Tom de Vries
4343499695 [gdb] Fix catch throw regexp matching
When running test-case gdb.mi/mi-catch-cpp-exceptions.exp, we have:
...
FAIL: gdb.mi/mi-catch-cpp-exceptions.exp: all with invalid regexp: run until \
  breakpoint in main (unknown output after running)
...

This is a regression since commit 596dc4adff "Speed up psymbol reading by
removing a copy".

Before that commit, we have:
...
$ gdb \
    -batch \
    ./outputs/gdb.mi/mi-catch-cpp-exceptions/mi-catch-cpp-exceptions \
    -ex "break 67" \
    -ex "catch throw -r blahblah" \
    -ex r
Breakpoint 1 at 0x4008e5: file mi-catch-cpp-exceptions.cc, line 67.
Catchpoint 2 (throw)

Breakpoint 1, main () at mi-catch-cpp-exceptions.cc:67
67                  return 1;   /* Stop here.  */
...
In other words:
- we set a breakpoint somewhere in main,
- we set a catchpoint with a regexp that is intended to not match any
  exception, and
- run to the breakpoint, without the catchpoint triggering.

After the commit, we have:
...
$ gdb \
    -batch \
    ./outputs/gdb.mi/mi-catch-cpp-exceptions/mi-catch-cpp-exceptions \
    -ex "break 67" \
    -ex "catch throw -r blahblah" \
    -ex r
Breakpoint 1 at 0x4008e5: file mi-catch-cpp-exceptions.cc, line 67.
Catchpoint 2 (throw)

Catchpoint 2 (exception thrown), 0x00007ffff7ab037e in __cxa_throw () from \
  /usr/lib64/libstdc++.so.6
...
In other words, the catchpoint triggers.

This is caused by this bit of the commit:
...
       type_name = cplus_typename_from_type_info (typeinfo_arg);

       canon = cp_canonicalize_string (type_name.c_str ());
-      if (!canon.empty ())
-       std::swap (type_name, canon);
+      name = (canon == nullptr
+	      ? canon.get ()
+	      : type_name.c_str ());
     }
   catch (const gdb_exception_error &e)
     {
       exception_print (gdb_stderr, e);
     }

-  if (!type_name.empty ())
+  if (name != nullptr)
     {
-      if (self->pattern->exec (type_name.c_str (), 0, NULL, 0) != 0)
+      if (self->pattern->exec (name, 0, NULL, 0) != 0)
...

Before the commit, we have:
- type_name == "my_exception"
- canon = ""
and the !type_name.empty () test succeeds, and gdb executes the
self->pattern->exec call.

After the commit, we have:
- type_name == "my_exception"
- canon == NULL
- name == NULL
and the name != nullptr test fails, and gdb doesn't execute the
self->pattern->exec call.

Fix this by inverting the condition for the calculation of name:
...
-      name = (canon == nullptr
+      name = (canon != nullptr
...

Build and tested on x86_64-linux.

gdb/ChangeLog:

2020-05-09  Tom de Vries  <tdevries@suse.de>

	PR gdb/25955
	* break-catch-throw.c (check_status_exception_catchpoint): Fix name
	calculation.
2020-05-09 20:17:10 +02:00
Tom Tromey
2f78cffc16 Change server_command to bool
I noticed that "server_command" is an int, but really it should be a
bool.

gdb/ChangeLog
2020-05-09  Tom Tromey  <tom@tromey.com>

	* top.c (server_command): Now bool.
	* top.h (server_command): Now bool.
2020-05-09 12:04:58 -06:00
nitachra
6dc55ce97d Fix for the complaint observed when symbol reading due to unsupported .debug_names form
Following complaint is observed with the executable compiled with -gdwarf-5
and -gpubnames flags - "During symbol reading: Unsupported .debug_names form
DW_FORM_ref4".  This is the form corresponding to DW_IDX_die_offset attribute.
This patch fixes this complaint.  Tested with clang 10.0.0.  Test case used -

int main()
{
int sum,a,b;
sum = a + b;
return sum;
}

clang -gdwarf-5 -gpubnames test.c -o test.out

gdb -q test.out -ex "set complaints 1" -ex "start"

Reading symbols from test.out...
During symbol reading: Unsupported .debug_names form DW_FORM_ref4 \
  [in module test.out]
Temporary breakpoint 1 at 0x400484
Starting program: test.out
During symbol reading: Unsupported .debug_names form DW_FORM_ref4 \
  [in module test.out]
During symbol reading: Unsupported .debug_names form DW_FORM_ref4 \
  [in module test.out]
During symbol reading: Unsupported .debug_names form DW_FORM_ref4 \
  [in module test.out]

gdb/dwarf2/ChangeLog:

2020-05-09  Nitika Achra  <Nitika.Achra@amd.com>

	PR symtab/25952
	* read.c (dw2_debug_names_iterator::next): Handle DW_FORM_ref*
	and DW_IDX_die_offset.  If there is no compilation unit attribute in
	the index entry, then there is a single CU.  Return the CU at O index
	of compilation unit vector.

gdb/testsuite/ChangeLog:

2020-05-09  Tom de Vries  <tdevries@suse.de>

	* gdb.dwarf2/clang-debug-names.exp: Remove PR25952 kfail.
2020-05-09 10:03:51 +02:00
GDB Administrator
b326e6b0de Automatic date update in version.in 2020-05-09 00:00:12 +00:00
Tom Tromey
4f7bc5edbd Don't re-process a DIE in read_lexical_block_scope
A customer reported a crash in the DWARF reader.

Investigation showed that the crash occurred in an unusual scenario: a
function was lexically scoped within some other function -- but the
inner function inlined the outer function and referred to its DIE via
DW_AT_abstract_origin.  With the executable in question,
inherit_abstract_dies could eventually call read_lexical_block_scope,
which in turn could recurse into process_die, to process a DIE that
was already being read, triggering an assert.

This came up once before; see:

https://www.sourceware.org/ml/gdb-patches/2014-02/msg00652.html

However, in this case, I don't have an easy way to reproduce.  So,
there is no test case.

I did experiment with the failing executable.  This patch fixes the
bug and doesn't seem to cause other issues.  For example, I can still
set breakpoints on the relevant functions.

gdb/ChangeLog
2020-05-08  Tom Tromey  <tromey@adacore.com>

	* dwarf2/read.c (read_lexical_block_scope): Don't process a DIE
	already being processed.
2020-05-08 14:26:11 -06:00
Tom Tromey
8be4b118a9 More C++-ification for struct display
This changes displays to have a constructor, use bool and std::string,
and to be stored using std::vector.  The ALL_DISPLAYS and
ALL_DISPLAYS_SAFE macros are removed.  While internal iteration is
still done via map_display_numbers, this is updated to use a
function_view.  These changes simplify the code somewhat; for example,
free_display can now be removed in favor of ordinary destruction.

gdb/ChangeLog
2020-05-08  Tom Tromey  <tom@tromey.com>

	* printcmd.c (struct display) <next>: Remove.
	<display>: New constructor.
	<exp_string>: Now a std::string.
	<enabled_p>: Now a bool.
	(display_number): Move definition earlier.
	(displays): Rename from display_chain.  Now a std::vector.
	(ALL_DISPLAYS, ALL_DISPLAYS_SAFE): Remove.
	(display_command): Update.
	(do_one_display, disable_display)
	(enable_disable_display_command, do_enable_disable_display):
	Update.
	(free_display): Remove.
	(clear_displays): Rewrite.
	(delete_display): Update.
	(map_display_numbers): Use function_view.  Remove "data"
	parameter.  Update.
	(do_delete_display): Remove.
	(undisplay_command): Update.
	(do_one_display, do_displays, disable_display)
	(info_display_command): Update.
	(do_enable_disable_display): Remove.
	(enable_disable_display_command)
	(clear_dangling_display_expressions): Update.
2020-05-08 14:21:23 -06:00
Tom Tromey
94c93c35b5 Remove ALL_PSPACES
This removes the ALL_PSPACES macro.  In this case it seemed cleanest
to change how program spaces are stored -- instead of using a linked
list, they are now stored in a std::vector.

gdb/ChangeLog
2020-05-08  Tom Tromey  <tom@tromey.com>

	* symtab.c (set_symbol_cache_size)
	(maintenance_print_symbol_cache, maintenance_flush_symbol_cache)
	(maintenance_print_symbol_cache_statistics): Update.
	* symmisc.c (print_symbol_bcache_statistics)
	(print_objfile_statistics, maintenance_print_objfiles)
	(maintenance_info_symtabs, maintenance_check_symtabs)
	(maintenance_expand_symtabs, maintenance_info_line_tables):
	Update.
	* symfile-debug.c (set_debug_symfile): Update.
	* source.c (forget_cached_source_info): Update.
	* python/python.c (gdbpy_progspaces): Update.
	* psymtab.c (maintenance_info_psymtabs): Update.
	* probe.c (parse_probes): Update.
	* linespec.c (iterate_over_all_matching_symtabs)
	(collect_symtabs_from_filename, search_minsyms_for_name): Update.
	* guile/scm-progspace.c (gdbscm_progspaces): Update.
	* exec.c (exec_target::close): Update.
	* ada-tasks.c (ada_tasks_new_objfile_observer): Update.
	* breakpoint.c (print_one_breakpoint_location)
	(create_longjmp_master_breakpoint)
	(create_std_terminate_master_breakpoint): Update.
	* progspace.c (program_spaces): Now a std::vector.
	(maybe_new_address_space): Update.
	(add_program_space): Remove.
	(program_space::program_space): Update.
	(remove_program_space): Update.
	(number_of_program_spaces): Remove.
	(print_program_space, update_address_spaces): Update.
	* progspace.h (program_spaces): Change type.
	(ALL_PSPACES): Remove.
	(number_of_program_spaces): Don't declare.
	(struct program_space) <next>: Remove.
2020-05-08 14:21:22 -06:00
Tom Tromey
a1fd1ac9de Remove ALL_SO_LIBS and so_list_head
This patch started as an attempt to replace ALL_SO_LIBS with an
ordinary C++ iterator.  However, then I tripped over the so_list_head
define again, and decided to remove it as well.

gdb/ChangeLog
2020-05-08  Tom Tromey  <tom@tromey.com>

	* mi/mi-cmd-file.c (mi_cmd_file_list_shared_libraries): Update.
	* solib-svr4.c (svr4_fetch_objfile_link_map): Update.
	(enable_break): Update.
	* solib-frv.c (frv_fdpic_find_global_pointer): Update.
	(frv_fdpic_find_canonical_descriptor): Update.
	(frv_fetch_objfile_link_map): Update.
	* progspace.c (program_space::free_all_objfiles): Update.
	(program_space::solibs): New method.
	* progspace.h (struct program_space) <solibs>: New method.
	* solist.h (master_so_list): Don't declare.
	(ALL_SO_LIBS): Remove.
	* solib.h (so_list_head): Remove.
	(update_solib_list): Update comment.
	* solib.c (master_so_list): Remove.
	(solib_used, update_solib_list, solib_add)
	(info_sharedlibrary_command, clear_solib)
	(reload_shared_libraries_1, remove_user_added_objfile): Update.
2020-05-08 14:21:22 -06:00
Tom Tromey
38eae08459 Remove ALL_EXTENSION_LANGUAGES and ALL_ENABLED_EXTENSION_LANGUAGES
This removes the ALL_EXTENSION_LANGUAGES and
ALL_ENABLED_EXTENSION_LANGUAGES macros, in favor of ordinary
iterators.  For ALL_ENABLED_EXTENSION_LANGUAGES, I chose to simply
inline the check, as that seemed simpler than trying to make
filtered_iterator work for std::array.  (As an aside, this sort of
thing will be easier once we can use the ranges library...)

gdb/ChangeLog
2020-05-08  Tom Tromey  <tom@tromey.com>

	* extension.c (extension_languages): Now a std::array.
	(ALL_EXTENSION_LANGUAGES): Remove.
	(get_ext_lang_defn, get_ext_lang_of_file)
	(eval_ext_lang_from_control_command): Update.
	(finish_ext_lang_initialization)
	(auto_load_ext_lang_scripts_for_objfile)
	(ext_lang_type_printers::ext_lang_type_printers)
	(apply_ext_lang_type_printers)
	(ext_lang_type_printers::~ext_lang_type_printers)
	(apply_ext_lang_val_pretty_printer, apply_ext_lang_frame_filter)
	(preserve_ext_lang_values, get_breakpoint_cond_ext_lang)
	(breakpoint_ext_lang_cond_says_stop, check_quit_flag)
	(get_matching_xmethod_workers, ext_lang_colorize)
	(ext_lang_before_prompt): Update.
	(ALL_ENABLED_EXTENSION_LANGUAGES): Remove.
2020-05-08 14:21:22 -06:00
Tom Tromey
596dc4adff Speed up psymbol reading by removing a copy
I noticed that cp_canonicalize_string and friends copy a
unique_xmalloc_ptr to a std::string.  However, this copy isn't
genuinely needed anywhere, and it serves to slow down DWARF psymbol
reading.

This patch removes the copy and updates the callers to adapt.

This speeds up the reader from 1.906 seconds (mean of 10 runs, of gdb
on a copy of itself) to 1.888 seconds (mean of 10 runs, on the same
copy as the first trial).

gdb/ChangeLog
2020-05-08  Tom Tromey  <tom@tromey.com>

	* symtab.h (class demangle_result_storage) <set_malloc_ptr>: New
	overload.
	<swap_string, m_string>: Remove.
	* symtab.c (demangle_for_lookup, completion_list_add_symbol):
	Update.
	* stabsread.c (define_symbol, read_type): Update.
	* linespec.c (find_linespec_symbols): Update.
	* gnu-v3-abi.c (gnuv3_get_typeid): Update.
	* dwarf2/read.c (dwarf2_canonicalize_name): Update.
	* dbxread.c (read_dbx_symtab): Update.
	* cp-support.h (cp_canonicalize_string_full)
	(cp_canonicalize_string, cp_canonicalize_string_no_typedefs):
	Return unique_xmalloc_ptr.
	* cp-support.c (inspect_type): Update.
	(cp_canonicalize_string_full): Return unique_xmalloc_ptr.
	(cp_canonicalize_string_no_typedefs, cp_canonicalize_string):
	Likewise.
	* c-typeprint.c (print_name_maybe_canonical): Update.
	* break-catch-throw.c (check_status_exception_catchpoint):
	Update.
2020-05-08 14:14:06 -06:00
Tom de Vries
bf4cb9bee2 [gdb] Fix stepping over fork with follow-fork-mode child and gcc-8
When running test-case gdb.threads/fork-child-threads.exp with gcc-8 instead
of gcc-7, we have:
...
 (gdb) next^M
 [Attaching after Thread 0x7ffff7fae740 (LWP 27574) fork to child process \
   27578]^M
 [New inferior 2 (process 27578)]^M
 [Detaching after fork from parent process 27574]^M
 [Inferior 1 (process 27574) detached]^M
 [Thread debugging using libthread_db enabled]^M
 Using host libthread_db library "/lib64/libthread_db.so.1".^M
 [Switching to Thread 0x7ffff7fae740 (LWP 27578)]^M
-main () at src/gdb/testsuite/gdb.threads/fork-child-threads.c:41^M
+main () at src/gdb/testsuite/gdb.threads/fork-child-threads.c:34^M
-41            i = pthread_create (&thread, NULL, start, NULL);^M
+34        switch (fork ())^M
-(gdb) PASS: gdb.threads/fork-child-threads.exp: next over fork
+(gdb) FAIL: gdb.threads/fork-child-threads.exp: next over fork
...

This is due to the fact that gcc-8 generates more precise line info, making
the instruction after the call to fork a "recommended breakpoint location".
However, it is a bug because next is supposed to move to the next source
line.

The problem is that in process_event_stop_test we hit this code:
...
  if ((ecs->event_thread->suspend.stop_pc == stop_pc_sal.pc)
      && (ecs->event_thread->current_line != stop_pc_sal.line
	  || ecs->event_thread->current_symtab != stop_pc_sal.symtab))
    {
      if (stop_pc_sal.is_stmt)
	{
	  /* We are at the start of a different line.  So stop.  Note that
	     we don't stop if we step into the middle of a different line.
	     That is said to make things like for (;;) statements work
	     better.  */
	  if (debug_infrun)
	    fprintf_unfiltered (gdb_stdlog,
				"infrun: stepped to a different line\n");
	  end_stepping_range (ecs);
	  return;
	}
...
because current_line and current_symtab have initial values:
...
(gdb) p ecs->event_thread->current_line
$8 = 0
(gdb) p ecs->event_thread->current_symtab
$9 = (symtab *) 0x0
...

Fix this in follow_fork by copying current_line and current_symtab from
parent thread to child thread.

Tested on x86_64-linux, with gcc 7.5.0 and gcc 10.0.1.

gdb/ChangeLog:

2020-05-08  Tom de Vries  <tdevries@suse.de>

	* infrun.c (follow_fork): Copy current_line and current_symtab to
	child thread.
2020-05-08 17:26:32 +02:00
Tom de Vries
283cb58c4d [gdb/testsuite] Add gdb.dwarf2/clang-debug-names.c
Add test-case with .debug_names section using DW_FORM_ref4.

There's currently no support for .debug_names in the dwarf assembler, so we
use plain _emit rather than something more structured.

Consequently, we cannot use regular declare_labels-generated labels to refer
from .debug_names to .debug_info.  Instead, we use labels with a
predefined name, which we generate using _compute_label, and then define using
define_label.

This is the test-case for PR25952, so kfail the corresponding test.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2020-05-08  Tom de Vries  <tdevries@suse.de>

	* gdb.dwarf2/clang-debug-names.c: New test.
	* gdb.dwarf2/clang-debug-names.exp: New file.
2020-05-08 16:24:09 +02:00
GDB Administrator
cee2106c5b Automatic date update in version.in 2020-05-08 00:00:14 +00:00
Simon Marchi
a1b68f2834 gdb: small cleanup of async-event.c structs
This is a small cleanup to normalize the structures in async-event.c
with the rest of the code base:

- Remove the unnecessary typedefs
- Fix indentation of struct bodies
- Put comments above fields

No functional changes expected.

gdb/ChangeLog:

	* async-event.c (struct async_signal_handler, struct
	async_event_handler): Reformat, remove typedef.
2020-05-07 11:41:58 -04:00
Simon Marchi
98d48915d9 gdb: remove TYPE_DYN_PROP_LIST macro
Remove this macro, which abstracts how to obtain the dyn_prop_list of a
given type.  We could replace it with a method on `struct type`, but I
don't think it's needed, as the only code that accesses the dynamic prop
list directly is internal gdbtypes.c code (that can be seen as code
internal to `struct type`).  So it can just refer to the field directly.

gdb/ChangeLog:

	* gdbtypes.h (TYPE_DYN_PROP_LIST): Remove.  Update all users
	access thistype->main_type->dyn_prop_list directly.
2020-05-07 11:32:38 -04:00
Simon Marchi
7aa9131366 gdb: make remove_dyn_prop a method of struct type
Move remove_dyn_prop, currently a free function, to be a method of
struct type.

gdb/ChangeLog:

	* gdbtypes.h (struct type) <remove_dyn_prop>: New method.
	(remove_dyn_prop): Remove.  Update all users to use
	type::remove_dyn_prop.
	* gdbtypes.c (remove_dyn_prop): Rename to...
	(type::remove_dyn_prop): ... this.
2020-05-07 11:32:33 -04:00
Simon Marchi
5c54719c22 gdb: make add_dyn_prop a method of struct type
Move add_dyn_prop, currently a free function, to be a method of struct
type.

gdb/ChangeLog:

	* gdbtypes.h (struct type) <add_dyn_prop>: New method.
	(add_dyn_prop): Remove.  Update all users to use
	type::add_dyn_prop.
	* gdbtypes.c (add_dyn_prop): Rename to...
	(type::add_dyn_prop): ... this.
2020-05-07 11:32:29 -04:00
Simon Marchi
24e99c6c3c gdb: make get_dyn_prop a method of struct type
Move get_dyn_prop, currently a free function, to be a method on struct
type.

gdb/ChangeLog:

	* gdbtypes.h (struct type) <get_dyn_prop>: New method.
	(get_dyn_prop): Remove.  Update all users to use
	type::dyn_prop.
	* gdbtypes.c (get_dyn_prop): Rename to...
	(type::dyn_prop): ... this.
2020-05-07 11:32:25 -04:00
Andrew Burgess
d11a9fabab objcopy: Mention 'entry address' in description
The ELF header contains a start address, which is also sometimes
called the entry address.  The 'objdump -x' output calls this field
the 'start address', while readelf calls it 'entry point address'.
The linker talks about setting the 'entry' point in its manual.

I've always thought of this field as the 'entry address', and so when
I recently wanted to know if objcopy could adjust this field I opened
up the manual and searched for 'entry', which found no hits.

I thought it would be useful (for people like me) if the description
of 'set-start' and 'adjust-start' in the objcopy manual mentioned the
word 'entry' to make it easier to find.

binutils/ChangeLog:

	* doc/binutils.texi: Mention 'entry address' in the set-start and
	adjust-start options descriptions.
2020-05-07 11:39:39 +01:00
Nick Clifton
ff84cef42f Updated French translation for the gprof sub-directory. 2020-05-07 10:48:21 +01:00
GDB Administrator
1d5bcf8d88 Automatic date update in version.in 2020-05-07 00:00:12 +00:00
Simon Marchi
0d4bf01694 gdb: remove main_type::flag_static
It is not used.

gdb/ChangeLog:

	* gdbtypes.h (struct main_type) <flag_static>: Remove.
2020-05-06 12:26:05 -04:00
Simon Marchi
ac4a4f1cd7 gdb: handle endbr64 instruction in amd64_analyze_prologue
v2:
  - test: build full executable instead of object
  - test: add and use supports_fcf_protection
  - test: use gdb_test_multiple's -wrap option
  - test: don't execute gdb_assert if failed to get breakpoint address

Some GCCs now enable -fcf-protection by default.  This is the case, for
example, with GCC 9.3.0 on Ubuntu 20.04.  Enabling it causes the
`endbr64` instruction to be inserted at the beginning of all functions
and that breaks GDB's prologue analysis.

I noticed this because it gives many failures in gdb.base/break.exp.
But let's take this dummy program and put a breakpoint on main:

    int main(void)
    {
        return 0;
    }

Without -fcf-protection, the breakpoint is correctly put after the prologue:

    $ gcc test.c -g3 -O0 -fcf-protection=none
    $ ./gdb -q -nx --data-directory=data-directory a.out
    Reading symbols from a.out...
    (gdb) disassemble main
    Dump of assembler code for function main:
       0x0000000000001129 <+0>:     push   %rbp
       0x000000000000112a <+1>:     mov    %rsp,%rbp
       0x000000000000112d <+4>:     mov    $0x0,%eax
       0x0000000000001132 <+9>:     pop    %rbp
       0x0000000000001133 <+10>:    retq
    End of assembler dump.
    (gdb) b main
    Breakpoint 1 at 0x112d: file test.c, line 3.

With -fcf-protection, the breakpoint is incorrectly put on the first
byte of the function:

    $ gcc test.c -g3 -O0 -fcf-protection=full
    $ ./gdb -q -nx --data-directory=data-directory a.out
    Reading symbols from a.out...
    (gdb) disassemble main
    Dump of assembler code for function main:
       0x0000000000001129 <+0>:     endbr64
       0x000000000000112d <+4>:     push   %rbp
       0x000000000000112e <+5>:     mov    %rsp,%rbp
       0x0000000000001131 <+8>:     mov    $0x0,%eax
       0x0000000000001136 <+13>:    pop    %rbp
       0x0000000000001137 <+14>:    retq
    End of assembler dump.
    (gdb) b main
    Breakpoint 1 at 0x1129: file test.c, line 2.

Stepping in amd64_skip_prologue, we can see that the prologue analysis,
for GCC-compiled programs, is done in amd64_analyze_prologue by decoding
the instructions and looking for typical patterns.  This patch changes
the analysis to check for a prologue starting with the `endbr64`
instruction, and skip it if it's there.

gdb/ChangeLog:

	* amd64-tdep.c (amd64_analyze_prologue): Check for `endbr64`
	instruction, skip it if it's there.

gdb/testsuite/ChangeLog:

	* gdb.arch/amd64-prologue-skip-cf-protection.exp: New file.
	* gdb.arch/amd64-prologue-skip-cf-protection.c: New file.
2020-05-06 12:01:37 -04:00
Nick Clifton
bfeaed386d Updated Swedish translation for the gas sub-directory 2020-05-06 14:17:36 +01:00
Tom de Vries
24fe640b4d [gdb/testsuite] Fix gdb.reverse/consecutive-{precsave,reverse}.exp with gcc-8
When running test-cases gdb.reverse/consecutive-precsave.exp and
gdb.reverse/consecutive-reverse.exp with gcc-8, we get:
...
FAIL: gdb.reverse/consecutive-precsave.exp: stopped at bp, 2nd instr
FAIL: gdb.reverse/consecutive-reverse.exp: stopped at bp, 2nd instr
...

These FAILs are duplicates of the FAILs fixed in commit 7c99e7e2b0
"[gdb/testsuite] Fix gdb.base/consecutive.exp with gcc-8".

Fix these in the same manner.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2020-05-06  Tom de Vries  <tdevries@suse.de>

	* gdb.reverse/consecutive-precsave.exp: Handle if instruction after
	breakpoint is at a "recommended breakpoint location".
	* gdb.reverse/consecutive-reverse.exp: Same.
2020-05-06 14:48:50 +02:00
Tom de Vries
0d8683a321 [gdb/testsuite] Fix gdb.base/watchpoint-reuse-slot.exp with gcc-8
When running test-case gdb.base/watchpoint-reuse-slot.exp with gcc-8 instead
of gcc-7, we have:
...
 (gdb) PASS: $conf: watch *(buf.byte + 0 + 0)@1
 stepi^M
-0x00000000004004b9      34        for (i = 0; i < 100000; i++);^M
+34        for (i = 0; i < 100000; i++);^M
-(gdb) PASS: $conf: stepi advanced
+(gdb) FAIL: $conf: stepi advanced
...
where $conf is "gdb.base/watchpoint-reuse-slot.exp: hw-watch: always-inserted
off: watch x watch: : width 1, iter 0: base + 0".

This is due to the fact that gcc-8 generates more precise line info, making
the instruction at 0x4004b9 a "recommended breakpoint location", such that gdb
no longer prints the instruction address.

Fix this by getting the instruction address by printing $pc.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2020-05-06  Tom de Vries  <tdevries@suse.de>

	* gdb.base/watchpoint-reuse-slot.exp (stepi): Print $pc to get current
	address.
2020-05-06 14:27:36 +02:00
Nick Clifton
6ef719c016 Section "3.1 Preprocessing" of the online GAS manual has a wrong reference to "Using GNU CC". This fixes that link.
PR 25927
	* doc/as.texi (Preprocessing): Replace cross reference to not
	existant document with a URL to the equivalent page in the GCC
	manual.
2020-05-06 13:21:02 +01:00
Tom de Vries
b8983c4663 [gdb/testsuite] Fix cur_addr update in gdb.base/watchpoint-reuse-slot.exp
I noticed this code in gdb.base/watchpoint-reuse-slot.exp, proc stepi:
...
    gdb_test_multiple "stepi" $test {
	-re "($hex).*[string_to_regexp $srcline]\r\n$gdb_prompt $" {
	    set addr $expect_out(1,string)
	    if {$addr != $cur_addr} {
		pass $test
	    } else {
		fail $test
	    }
	    set cur_addr addr
	}
    }
...

The variable cur_addr is documented as:
...
 # The address the program is stopped at currently.
 set cur_addr ""
...
but in the gdb_test_multiple clause we assign the string "addr" to cur_addr,
while $addr contains the current address.

Fix this by assigning $addr instead "addr".

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2020-05-06  Tom de Vries  <tdevries@suse.de>

	* gdb.base/watchpoint-reuse-slot.exp: Fix incorrect assignment.
2020-05-06 14:13:02 +02:00
Tom de Vries
abf6d805a0 [gdb/testsuite] Fix gdb.base/store.exp with gcc-10
When running gdb.base/store.exp with gcc-10 instead of gcc-9, we have:
...
 (gdb) PASS: gdb.base/store.exp: continue to wack_double
 print l^M
-$22 = <optimized out>^M
+$22 = -1^M
-(gdb) UNSUPPORTED: gdb.base/store.exp: var double l; print old l, expecting -1
-(gdb) PASS: gdb.base/store.exp: var double l; print old l, expecting -1
+print r^M
+$23 = <optimized out>^M
+(gdb) FAIL: gdb.base/store.exp: var double l; print old r, expecting -2
...

With gcc-9, there's no location info for both l and r, but with gcc-10,
there's location info for l, but not r.

The test-case only checks for location info availability of l, and then
assumes location info for r is also available.

Fix this by allowing missing location info for r.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2020-05-06  Tom de Vries  <tdevries@suse.de>

	* gdb.base/store.exp (check_set, up_set): Allowing missing location
	info for r.
2020-05-06 13:49:34 +02:00
Tom de Vries
0fc2a808cb [gdb/testsuite] Fix gdb.base/shlib-call.exp with gcc-8
When running test-case gdb.base/shlib-call.exp with gcc-8 instead of gcc-7, we
have:
...
 (gdb) step^M
-main () at /data/gdb_versions/devel/src/gdb/testsuite/gdb.base/shmain.c:42^M
-42        g = mainshr1(g);^M
-(gdb) PASS: gdb.base/shlib-call.exp: step out of shr2 epilogue to main
+main () at /data/gdb_versions/devel/src/gdb/testsuite/gdb.base/shmain.c:41^M
+41        g = shr2(g);^M
+(gdb) FAIL: gdb.base/shlib-call.exp: step out of shr2 epilogue to main
...

This is due to the fact that gcc-8 generates more precise line info, making
the instruction after the call to shr2 at 0x4008f1:
...
  4008e4:  8b 05 aa 07 20 00  mov    0x2007aa(%rip),%eax  # 601094 <g>
  4008ea:  89 c7              mov    %eax,%edi
  4008ec:  e8 1f fe ff ff     callq  400710 <shr2@plt>
  4008f1:  89 05 9d 07 20 00  mov    %eax,0x20079d(%rip)  # 601094 <g>
...
a "recommended breakpoint location":
...
  [0x00000287]  Special opcode 187: advance Address by 13 to 0x4008f1 and \
    Line by 0 to 41
...
so when stepping out of shr2, gdb steps back onto line 41, the line containing
the call to shr2.

Fix this by detecting this situation and adding an extra step to reach
line 42.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2020-05-06  Tom de Vries  <tdevries@suse.de>

	* gdb.base/shlib-call.exp: Add extra step to reach shmain.c:42, if
	necessary.
2020-05-06 11:50:52 +02:00
Tom de Vries
873dd4273f [gdb/testsuite] Fix gdb_unbuffer_output return-type
When running test-case gdb.base/shlib-call.exp with clang, we get:
...
gdb compile failed, In file included from shmain.c:6:
unbuffer_output.c:39:1: warning:
      control reaches end of non-void function [-Wreturn-type]
}
^
1 warning generated.
...

Fix this by changing the return-type to void.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2020-05-06  Tom de Vries  <tdevries@suse.de>

	* lib/unbuffer_output.c (gdb_unbuffer_output): Change return type to
	void.
2020-05-06 09:41:26 +02:00
Tom de Vries
7c99e7e2b0 [gdb/testsuite] Fix gdb.base/consecutive.exp with gcc-8
When running test-case gdb.base/consecutive.exp with gcc-8 instead of gcc-7,
we get:
...
 (gdb) step^M
 ^M
-Breakpoint 3, 0x00000000004004b1 in foo () at consecutive.c:10^M
+Breakpoint 3, foo () at consecutive.c:10^M
 10        return a[0] + a[1] + a[2] + a[3] + a[4] + a[5] + a[6];^M
-(gdb) PASS: gdb.base/consecutive.exp: stopped at bp, 2nd instr
+(gdb) FAIL: gdb.base/consecutive.exp: stopped at bp, 2nd instr
...

This is due to the fact that gcc-8 generates more precise line info, making
the breakpoint address a "recommended breakpoint location", and consequently
gdb doesn't print the address prefix anymore.

Fix the FAIL by checking in the test-case whether the breakpoint address is at
"recommended breakpoint location" or not.

gdb/testsuite/ChangeLog:

2020-05-06  Tom de Vries  <tdevries@suse.de>

	* lib/gdb.exp (is_stmt_addresses, hex_in_list): New proc, factored out
	of ...
	* gdb.base/async.exp: ... here.
	* gdb.base/consecutive.exp: Handle if 2nd breakpoint is at a
	"recommended breakpoint location".
2020-05-06 07:07:47 +02:00
Tom de Vries
6173d6a696 [gdb/testsuite] Compile compile-ifunc.c with -Wno-attribute-alias
Consider the following test-case:
...
$ cat 1.c
typedef int (*final_t) (int arg);
int final (int arg)
  { return arg + 1; }
final_t gnu_ifunc (void)
  { return final; }
int gnu_ifunc_alias (int) __attribute__ ((ifunc ("gnu_ifunc")));
int main (void)
  { return gnu_ifunc_alias (10); }
...
with result:
...
$ gcc 1.c
$ ./a.out; echo $?
11
...

The test-case uses the ifunc attribute, but there's another solution using
%gnu_indirect_function.  Consider 2.c and 3.c:
...
$ cat 2.c
typedef int (*final_t) (int arg);
int final (int arg)
  { return arg + 1; }
asm (".type gnu_ifunc, %gnu_indirect_function");
final_t gnu_ifunc (void)
  { return final; }
$ cat 3.c
extern int gnu_ifunc (int);
int main (void)
  { return gnu_ifunc (10); }
...

However, it can be inconvenient to have seperate files for the incompatible
decls of gnu_ifunc, so we can use this in a single file like this:
...
$ cat 4.c
typedef int (*final_t) (int arg);
int final (int arg)
  { return arg + 1; }
asm (".type gnu_ifunc, %gnu_indirect_function");
final_t gnu_ifunc (void)
  { return final; }
extern int gnu_ifunc_alias (int arg) __attribute__ ((alias ("gnu_ifunc")));
int main (void)
  { return gnu_ifunc_alias (10); }
...

This alias trick works ok at -O0, but not at -O2:
...
$ gcc 4.c
$ ./a.out; echo $?
11
$ gcc 4.c
$ ./a.out; echo $?
176
...
and produces a warning with gcc-8 and later:
...
$ gcc-8 4.c
4.c:7:12: warning: 'gnu_ifunc_alias' alias between functions of incompatible \
  types 'int(int)' and 'int (*(void))(int)' [-Wattribute-alias]
 extern int gnu_ifunc_alias (int arg) __attribute__ ((alias ("gnu_ifunc")));
            ^~~~~~~~~~~~~~~
4.c:5:9: note: aliased declaration here
 final_t gnu_ifunc (void)
         ^~~~~~~~~
...
The warning is correct, but the mismatch is intentional.

The last variant (%gnu_indirect_function + alias) is used in
gdb.compile/compile-ifunc.c, so we run into the warning with recent gcc.

Fix the warning by compiling with -Wno-attribute-alias.

Tested the test-case on x86_64-linux with gcc-10, and observed I no longer see
the warning:
...
Running src/gdb/testsuite/gdb.compile/compile-ifunc.exp ...

                === gdb Summary ===

nr of untested testcases         1
...

gdb/testsuite/ChangeLog:

2020-05-06  Tom de Vries  <tdevries@suse.de>

	* gdb.compile/compile-ifunc.exp: Use -Wno-attribute-alias.
2020-05-06 05:27:48 +02:00
GDB Administrator
4167d44ce2 Automatic date update in version.in 2020-05-06 00:00:06 +00:00
Simon Marchi
a3bbacc120 gdb: remove main_type::flag_incomplete
It is unused.  The corresponding macro was removed in c3236f84c1 ("gdb:
remove TYPE_INCOMPLETE").

gdb/ChangeLog:

	* gdbtypes.h (struct main_type) <flag_incomplete>: Remove.
2020-05-05 16:59:32 -04:00