Alan Modra [Thu, 26 Mar 2020 05:56:16 +0000 (16:26 +1030)]
Re: H8300 use of uninitialised value
This patch also had some problems. Calculation of maxlen was wrong,
and the insn arg loop needed rearranging to work with a correct length.
* disassemble.h (opcodes_assert): Declare.
(OPCODES_ASSERT): Define.
* disassemble.c: Don't include assert.h. Include opintl.h.
(opcodes_assert): New function.
* h8300-dis.c (bfd_h8_disassemble_init): Use OPCODES_ASSERT.
(bfd_h8_disassemble): Reduce size of data array. Correctly
calculate maxlen. Omit insn decoding when insn length exceeds
maxlen. Exit from nibble loop when looking for E, before
accessing next data byte. Move processing of E outside loop.
Replace tests of maxlen in loop with assertions.
Alan Modra [Thu, 26 Mar 2020 00:19:27 +0000 (10:49 +1030)]
alpha-vms: Sanity check ETIR__C_CTL_DFLOC index
I doubt anyone will want to create more than 16M debug location
entries. If there is no bound the object format allows for 32-bit
indices and of course fuzzers find that and attempt allocation of up
to a 16G byte array. The patch also fixes potential integer overflows
in calculating the array size.
* vms-alpha.c (dst_define_location): Limit size of dst_ptr_offsets
array.
(_bfd_vms_slurp_object_records): Rename "err" to "ok".
Tom Tromey [Wed, 25 Mar 2020 16:26:38 +0000 (10:26 -0600)]
Fix error message in compile-object-load.c
I noticed that an error message in compile-object-load.c mentions the
wrong symbol name. The loop just above the error is looking for
COMPILE_I_EXPR_VAL, but the error references COMPILE_I_EXPR_PTR_TYPE.
I'm checking this in as obvious. I don't have a test case -- I
noticed it because another patch I'm working on caused this error to
be thrown, but that was due to regression in my patch.
gdb/ChangeLog
2020-03-25 Tom Tromey <tom@tromey.com>
* compile/compile-object-load.c (get_out_value_type): Mention
correct symbol name in error message.
J.W. Jagersma [Wed, 25 Mar 2020 11:52:07 +0000 (11:52 +0000)]
The "b" flag for COFF sections only unsets the LOAD attribute. It should also clear the CONTENTS attribute so that named bss sections don't take up space in an object file. This can be achieved by setting the 'bss' flag in seg_info.
* config/obj-coff.c (obj_coff_section): Set the bss flag on
sections with the "b" attribute.
Tom de Vries [Wed, 25 Mar 2020 11:38:05 +0000 (12:38 +0100)]
[gdb] Print user/includes fields for maint commands
The type struct compunit_symtab contains two fields (disregarding field next)
that express relations with other compunit_symtabs: user and includes.
These fields are currently not printed with "maint info symtabs" and
"maint print symbols".
Fix this such that for "maint info symtabs" we print:
...
{ ((struct compunit_symtab *) 0x23e8450)
debugformat DWARF 2
producer (null)
dirname (null)
blockvector ((struct blockvector *) 0x23e8590)
+ user ((struct compunit_symtab *) 0x2336280)
+ ( includes
+ ((struct compunit_symtab *) 0x23e85e0)
+ ((struct compunit_symtab *) 0x23e8960)
+ )
{ symtab <unknown> ((struct symtab *) 0x23e85b0)
fullname (null)
linetable ((struct linetable *) 0x0)
}
}
...
And for "maint print symbols" we print:
...
-Symtab for file <unknown>
+Symtab for file <unknown> at 0x23e85b0
Read from object file /data/gdb_versions/devel/a.out (0x233ccf0)
Language: c
Blockvector:
block #000, object at 0x23e8530, 0 syms/buckets in 0x0..0x0
block #001, object at 0x23e84d0 under 0x23e8530, 0 syms/buckets in 0x0..0x0
+Compunit user: 0x2336300
+Compunit include: 0x23e8900
+Compunit include: 0x23dd970
...
Note: for user and includes we don't list the actual compunit_symtab address,
but instead the corresponding symtab address, which allows us to find that
symtab elsewhere in the output (given that we also now print the address of
symtabs).
gdb/ChangeLog:
2020-03-25 Tom de Vries <tdevries@suse.de>
* symtab.h (is_main_symtab_of_compunit_symtab): New function.
* symmisc.c (dump_symtab_1): Print user and includes fields.
(maintenance_info_symtabs): Same.
Andrew Burgess [Fri, 13 Mar 2020 15:50:28 +0000 (15:50 +0000)]
gdb/riscv: Apply NaN boxing when writing return values into registers
When setting up function parameters we already perform NaN boxing, as
required by the RISC-V ABI, however, we don't do this when writing
values into registers as part of setting up a return value.
This commit moves the NaN boxing code into a small helper function,
and then makes use of this function when setting up function
parameters, and also when setting up return values.
This should resolve this failure:
FAIL: gdb.base/return-nodebug.exp: float: full width of the returned result
gdb/ChangeLog:
PR gdb/25489
* riscv-tdep.c (riscv_arg_info::c_offset): Update comment.
(riscv_regcache_cooked_write): New function.
(riscv_push_dummy_call): Use new function.
(riscv_return_value): Likewise.
Shahab Vahedi [Tue, 24 Mar 2020 14:25:24 +0000 (15:25 +0100)]
arc: Use correct string when printing bfd DEBUG data
PRINT_DEBUG_RELOC_INFO_BEFORE() macro prints bunch of parameters
for debugging purposes. Due to a seemingly copy/paste mistake,
the "input_section->vma" is printed under the field name
"symbol_section->vma". This commit fixes that.
This fix is a courtesy of xiangzhai.
* elf32-arc.c (PRINT_DEBUG_RELOC_INFO_BEFORE): Use the
correct field name in the output string.
Alan Modra [Wed, 25 Mar 2020 02:37:54 +0000 (13:07 +1030)]
h8300-linux ld testsuite
This fixes lots of fails caused by h8300-linux not supporting -shared
and related options. I've also fixed ld-h8300 tests to accept the
valid h8300-linux -m options .
pr22450.d is also fixed for avr, crx, ip2k, m68hc11 and xc16x, and the
new pr25708 test for hppa64.
H.J. Lu [Tue, 24 Mar 2020 22:37:14 +0000 (15:37 -0700)]
bfd: Add a bfd_boolean argument to bfd_get_symbol_version_string
We can't call _bfd_elf_get_symbol_version_name from nm.c since it isn't
available for all target configurations. This patch add a bfd_boolean
argument to bfd_get_symbol_version_string instead.
Nick Clifton [Tue, 24 Mar 2020 13:35:53 +0000 (13:35 +0000)]
Fix assertion failure in the BFD library when linking with --emit-relocs enabled.
PR 25681
* elf.c (_bfd_elf_map_sections_to_segments): When looking for a
segment to use for PT_GNU_RELRO, ignore empty sections in a
segment's current list.
PR lto/94249
* plugin-api.h: Add more robust endianess detection.
binutils-gdb/bfd/elf.c: In function ‘setup_group’:
binutils-gdb/bfd/elf.c:740:35: error: overflow in conversion from ‘unsigned int’ to ‘int’ changes value from ‘num_group = 4294967295’ to ‘-1’ [-Werror=overflow]
740 | elf_tdata (abfd)->num_group = num_group = -1;
| ^~~~~~~~~
cc1: all warnings being treated as errors
make[2]: *** [Makefile:1608: elf.lo] Error 1
Change num_group in elf_obj_tdata to unsigned int to compile with GCC 10.
PR binutils/25717
* elf-bfd.h (elf_obj_tdata): Change num_group to unsigned int.
H.J. Lu [Tue, 24 Mar 2020 11:23:11 +0000 (04:23 -0700)]
bfd: Display symbol version for nm -D
Extend _bfd_elf_get_symbol_version_string for nm -D to display symbol
version. _bfd_elf_get_symbol_version_name is added to avoid updating
all XXX_get_symbol_version_string functions.
bfd/
PR binutils/25708
* elf-bfd.h (_bfd_elf_get_symbol_version_name): New.
* elf.c (_bfd_elf_get_symbol_version_name): New function. Based
on the previous _bfd_elf_get_symbol_version_string.
(_bfd_elf_get_symbol_version_string): Use it.
binutils/
PR binutils/25708
* nm.c (SYM_NAME): Removed.
(print_symname): Add a pointer to struct extended_symbol_info
argument. Call _bfd_elf_get_symbol_version_name to get symbol
version.
(print_symdef_entry): Pass NULL to print_symname.
(print_symbol_info_bsd): Update call to print_symname.
(print_symbol_info_sysv): Likewise.
(print_symbol_info_posix): Likewise.
ld/
PR binutils/25708
* testsuite/ld-elf/pr25708.d: New file.
Tom de Vries [Tue, 24 Mar 2020 09:00:51 +0000 (10:00 +0100)]
[gdb] Print user for maint info psymtabs
The type struct partial_symtab contains two fields (disregarding field next)
that express relations with other symtabs: user and dependencies.
When using "maint print psymbols", we see both the dependencies and the user
fields:
...
Partial symtab for source file (object 0x35ef270)
...
Depends on 0 other partial symtabs.
Shared partial symtab with user 0x35d5f40
...
But with "maint info psymtabs", we only see dependencies:
...
{ psymtab ((struct partial_symtab *) 0x35ef270)
...
dependencies (none)
}
...
Add printing of the user field for "maint info psymtabs", such that we have:
...
{ psymtab ((struct partial_symtab *) 0x35ef270)
...
+ user hello.c ((struct partial_symtab *) 0x35d5f40)
dependencies (none)
}
...
Tested on x86_64-linux.
gdb/ChangeLog:
2020-03-24 Tom de Vries <tdevries@suse.de>
* psymtab.c (maintenance_info_psymtabs): Print user field.
Alan Modra [Mon, 23 Mar 2020 12:53:31 +0000 (23:23 +1030)]
ECOFF archive uninitialised read
* ecoff.c (_bfd_ecoff_slurp_armap): Sanity check parsed_size and
symbol count. Allocate an extra byte to ensure name strings
are terminated. Sanity check name offsets. Release memory on
error return.
Alan Modra [Sun, 22 Mar 2020 09:32:55 +0000 (20:02 +1030)]
ARC: Use of uninitialised value
* arc-dis.c (find_format): Use ISO C string concatenation rather
than line continuation within a string. Don't access needs_limm
before testing opcode != NULL.
Alan Modra [Sun, 22 Mar 2020 07:45:41 +0000 (18:15 +1030)]
NS32K arg_bufs uninitialised
git commit d1e304bc27 was aimed at stopping uninitialised memory
access to the index_offset array. Unfortunately that patch resulted
in a different array being uninitialised for all instructions with
more than two arguments.
* ns32k-dis.c (print_insn_arg): Update comment.
(print_insn_ns32k): Reduce size of index_offset array, and
initialize, passing -1 to print_insn_arg for args that are not
an index. Don't exit arg loop early. Abort on bad arg number.
When running test-case gdb.threads/omp-par-scope.exp, I get this XPASS:
...
XPASS: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: \
outer stop: get valueof "num"
...
for test:
...
set thread_num [get_valueof "" "num" "unknown"]
...
The intention of the test is to get the value of local variable num, which
has been set to:
...
int num = omp_get_thread_num ();
...
but the actually printed value is 'num':
...
(gdb) print num^M
$76 = num^M
...
This is due to the fact that num is missing in the locals, so instead we find
the enum member 'num' of enum expression_operator in glibc/intl/plural-exp.h.
Fix this by getting the value using a new proc get_local_valueof, which uses
the "info locals" commands to get the value.
Tested on x86_64-linux, with gcc 7.5.0 (where the test xfails) and gcc
10.0.1 (where the test passes).
Simon Marchi [Fri, 20 Mar 2020 15:57:49 +0000 (11:57 -0400)]
gdb: remove HAVE_DECL_PTRACE
I stumbled on this snippet in nat/gdb_ptrace.h:
/* Some systems, in particular DEC OSF/1, Digital Unix, Compaq Tru64
or whatever it's called these days, don't provide a prototype for
ptrace. Provide one to silence compiler warnings. */
I believe this is unnecessary today and should be removed. First, the
comment only mentions OSes we don't support (and to be honest, I had
never even heard of).
But most importantly, in C++, a declaration with empty parenthesis
declares a function that accepts no arguments, unlike in C. So if this
declaration was really used, GDB wouldn't build, since all ptrace call
sites pass some arguments. Since we haven't heard anything about this
causing some build failures since we have transitioned to C++, I
conclude that it's not used.
This patch removes it as well as the corresponding configure check.
gdb/ChangeLog:
* ptrace.m4: Don't check for ptrace declaration.
* config.in: Re-generate.
* configure: Re-generate.
* nat/gdb_ptrace.h: Don't declare ptrace if HAVE_DECL_PTRACE is
not defined.
Tom Tromey [Fri, 20 Mar 2020 14:10:59 +0000 (08:10 -0600)]
Fix assert in c-exp.y
The "restrict" patch added some asserts to c-exp.y, but one spot was
copy-pasted and referred to the wrong table. This was pointed out by
-fsanitize=address. This patch fixes the bug.
gdb/ChangeLog
2020-03-20 Tom Tromey <tromey@adacore.com>
Tom Tromey [Fri, 20 Mar 2020 13:30:13 +0000 (07:30 -0600)]
Avoid stringop-truncation errors
I configured with -fsanitize=address and built gdb. linux-tdep.c and
ada-tasks.c failed to build due to some stringop-truncation errors,
e.g.:
In function ‘char* strncpy(char*, const char*, size_t)’,
inlined from ‘int linux_fill_prpsinfo(elf_internal_linux_prpsinfo*)’ at ../../binutils-gdb/gdb/linux-tdep.c:1742:11,
inlined from ‘char* linux_make_corefile_notes(gdbarch*, bfd*, int*)’ at ../../binutils-gdb/gdb/linux-tdep.c:1878:27:
/usr/include/bits/string_fortified.h:106:34: error: ‘char* __builtin_strncpy(char*, const char*, long unsigned int)’ specified bound 81 equals destination size [-Werror=stringop-truncation]
This patch fixes the problem by using "sizeof - 1" in the call to
strndup, as recommended in the GCC manual. This doesn't make a
difference here because the next line, in all cases, sets the final
element to '\0' anyway.
gdb/ChangeLog
2020-03-20 Tom Tromey <tromey@adacore.com>
* ada-tasks.c (read_atcb): Use smaller length in strncpy call.
* linux-tdep.c (linux_fill_prpsinfo): Use smaller length in
strncpy call.
Tom Tromey [Fri, 20 Mar 2020 13:15:08 +0000 (07:15 -0600)]
Fix column alignment in "maint info line-table"
Andrew Burgess pointed out on irc that "maint info line-table" doesn't
properly align the table headers. This patch fixes the problem by
switching the table to use ui-out.
This required a small tweak to one test case, as ui-out will pad a
field using spaces, even at the end of a line.
gdb/ChangeLog
2020-03-20 Tom Tromey <tromey@adacore.com>
* symmisc.c (maintenance_print_one_line_table): Use ui_out.
gdb/testsuite/ChangeLog
2020-03-20 Tom Tromey <tromey@adacore.com>
Tom Tromey [Fri, 20 Mar 2020 14:24:16 +0000 (08:24 -0600)]
Fix Ada val_print removal regression
The removal of val_print caused a regression in the Ada code. In one
scenario, a variant type would not be properly printed, because the
address of a component was lost. This patch fixes the bug by changing
this API to be value-based. This is cleaner and fixes the bug as a
side effect.
gdb/ChangeLog
2020-03-20 Tom Tromey <tromey@adacore.com>
Kamil Rytarowski [Thu, 19 Mar 2020 13:52:57 +0000 (14:52 +0100)]
Inherit ppc_nbsd_nat_target from nbsd_nat_target
gdb/ChangeLog:
* ppc-nbsd-nat.c (ppc_nbsd_nat_target): Inherit from
nbsd_nat_target instead of inf_ptrace_target.
* ppc-nbsd-nat.c: Include "nbsd-nat.h", as we are now using
nbsd_nat_target.
Tom de Vries [Fri, 20 Mar 2020 13:59:01 +0000 (14:59 +0100)]
[gdb/testsuite] Fix timeouts in gdb.threads/step-over-*.exp
When running test-cases gdb.threads/step-over-lands-on-breakpoint.exp and
gdb.threads/step-over-trips-on-watchpoint.exp with target board
unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects, we run into timeouts
due not being able to set a breakpoint and then trying to continue to that
breakpoint.
In total, we run into 186 timeouts, which roughly corresponds to half an hour:
...
$ grep "FAIL.*(timeout)" gdb.sum \
| awk '{print $2}' \
| sort \
| uniq -c
66 gdb.threads/step-over-lands-on-breakpoint.exp:
120 gdb.threads/step-over-trips-on-watchpoint.exp:
...
Fix this by bailing out if the first break fails.
Tested on x86_64-linux, both with native and with target board mentioned above.
gdb/testsuite/ChangeLog:
2020-03-20 Tom de Vries <tdevries@suse.de>
* gdb.threads/step-over-lands-on-breakpoint.exp (do_test): Bail out if
first break fails.
* gdb.threads/step-over-trips-on-watchpoint.exp: (do_test): Same.
H.J. Lu [Fri, 20 Mar 2020 04:00:19 +0000 (21:00 -0700)]
plugin: Use LDPT_ADD_SYMBOLS_V2 to get symbol type
Since LTO plugin may generate more than one ltrans.o file from one input
IR object as LTO wrapper ignores -flto-partition=none:
lto-wrapper.c:608:
604 /* Drop arguments that we want to take from the link line. */
605 case OPT_flto_:
606 case OPT_flto:
607 case OPT_flto_partition_:
608 continue;
the LTO wrapper approach is not only slow but also unreliable. Since
the LTO plugin API has been extended to add LDPT_ADD_SYMBOLS_V2 with
symbol type and section kind, we can use LDPT_ADD_SYMBOLS_V2 to get
symbol type, instead of invoking the LTO wrapper.
PR binutils/25640
* plugin.c (plugin_list_entry): Add has_symbol_type.
(add_symbols_v2): New function.
(bfd_plugin_open_input): Don't invoke LTO wrapper if LTO plugin
provides symbol type.
(try_load_plugin): Add LDPT_ADD_SYMBOLS_V2.
(bfd_plugin_canonicalize_symtab): Use LTO plugin symbol type if
available.
Alan Modra [Fri, 20 Mar 2020 00:21:14 +0000 (10:51 +1030)]
NDS32 disassembly of odd sized sections
* nds32-dis.c (print_insn_nds32): Remove unnecessary casts.
Initialize parts of buffer not written when handling a possible
2-byte insn at end of section. Don't attempt decoding of such
an insn by the 4-byte machinery.
Alan Modra [Thu, 19 Mar 2020 23:46:28 +0000 (10:16 +1030)]
PowerPC disassembly of odd sized sections
We shouldn't really decode a 2-byte left-over at the end of a section
as if the section contains two more bytes of zeros. Not that it
matters very much, but this patch tidies the corner case.
* ppc-dis.c (print_insn_powerpc): Only clear needed bytes of
partially filled buffer. Prevent lookup of 4-byte insns when
only VLE 2-byte insns are possible due to section size. Print
".word" rather than ".long" for 2-byte leftovers.
Alan Modra [Tue, 17 Mar 2020 21:01:47 +0000 (07:31 +1030)]
tidy elf_backend calls
Function pointers in elfNN_bed that are initialized by elfxx-target.h
to non-zero values generally don't need a non-NULL test before calling
them. Targets don't set a non-NULL function to NULL. The one
exception being elfnn-ia64.c and that exception is removed here.
* elf.c (_bfd_elf_setup_sections): Don't test known non-NULL
backend functions for NULL before calling.
(copy_special_section_fields, _bfd_elf_copy_private_bfd_data),
(bfd_section_from_shdr, assign_section_numbers): Likewise.
* elfcode.h (elf_write_relocs, elf_slurp_reloc_table): Likewise.
* elfnn-ia64.c (ignore_errors): New function.
(elf_backend_link_order_error_handler): Redefine as ignore_errors.
Nick Clifton [Thu, 19 Mar 2020 16:55:13 +0000 (16:55 +0000)]
Fix discrepancies in nm's --line-number output by adding support for the DW_AT_specification DWARF Attttribute.
PR 25676
bfd * dwarf2.c (struct varinfo): Add unit_offset field to record the
location of the varinfo in the unit's debug info data. Change the
type of the stack field to a boolean.
(lookup_var_by_offset): New function. Returns the varinfo
structure for the variable described at the given offset in the
unit's debug info.
(scan_unit_for_symbols): Add support for variables which have the
DW_AT_specification attribute.
binutils* testsuite/binutils-all/dw4.s: New test source file.
* testsuite/binutils-all/nm.exp: Run the new test.
Luis Machado [Mon, 16 Mar 2020 17:09:25 +0000 (14:09 -0300)]
[AArch64] When unavailable, fetch VG from ptrace.
I was doing some SVE tests on system QEMU and noticed quite a few failures
related to inferior function calls. Any attempt to do an inferior function
call would result in the following:
Unable to set VG register.: Success.
This happens because, after an inferior function call, GDB attempts to restore
the regcache state and updates the SVE register in order. Since the Z registers
show up before the VG register, VG is still INVALID by the time the first Z
register is being updated. So when executing the following code in
aarch64_sve_set_vq:
if (reg_buf->get_register_status (AARCH64_SVE_VG_REGNUM) != REG_VALID)
return false;
By returning false, we signal something is wrong, then we get to this:
/* First store vector length to the thread. This is done first to ensure the
ptrace buffers read from the kernel are the correct size. */
if (!aarch64_sve_set_vq (tid, regcache))
perror_with_name (_("Unable to set VG register."));
Ideally we'd always have a valid VG before attempting to set the Z registers,
but in this case the ordering of registers doesn't make that possible.
I considered reordering the registers to put VG before the Z registers, like
the DWARF numbering, but that would break backwards compatibility with
existing implementations. Also, the Z register numbering is pinned to the V
registers, and adding VG before Z would create a gap for non-SVE targets,
since we wouldn't be able to undefine VG for non-SVE targets.
As a compromise, it seems we can safely fetch the VG register value from
ptrace. The value in the kernel is likely the updated value anyway.
This patch fixed all the failures i saw in the testsuite and caused no further
regressions.
gdb/ChangeLog:
2020-03-19 Luis Machado <luis.machado@linaro.org>
* nat/aarch64-sve-linux-ptrace.c (aarch64_sve_set_vq): If vg is not
valid, fetch vg value from ptrace.
Kamil Rytarowski [Thu, 19 Mar 2020 13:01:36 +0000 (14:01 +0100)]
Avoid get_ptrace_pid() usage on NetBSD in x86-bsd-nat.c
Add gdb_ptrace() that wraps the ptrace(2) API and correctly passes
the pid,lwp pair to the calls on NetBSD; and the result of
get_ptrace_pid() on other BSD Operating Systems.
gdb/remote: Restore support for 'S' stop reply packet
A regression was introduced such that the W and X packets would give a
warning in some cases. The warning was:
warning: multi-threaded target stopped without sending a thread-id, using first non-exited thread
This problem would arise when:
1. The multi-process extensions to the remote protocol were not
being used, and
2. The inferior has multiple threads.
In this case when the W (or X) packet arrives the ptid of the
stop_reply is set to null_ptid, then when we arrive in
process_stop_reply GDB spots that we have multiple non-exited theads,
but the stop event didn't specify a thread-id.
The problem with this is that the W (and X) packets are actually
process wide events, they apply to all threads. So not specifying a
thread-id is not a problem, in fact, the best these packets allow is
for the remote to specify a process-id, not a thread-id.
If we look at how the W (and X) packets deal with a specified
process-id, then what happens is GDB sets to stop_reply ptid to a
value which indicates all threads in the process, this is done by
creating a value `ptid_t (pid)`, which sets the pid field of the
ptid_t, but leaves the tid field as 0, indicating all threads.
So, this commit does the same thing for the case where there is not
process-id specified. In process_stop_reply we not distinguish
between stop events that apply to all threads, and those that apply to
only one. If the stop event applies to only one thread then we treat
it as before. If, however, the stop event applies to all threads,
then we find the first non-exited thread, and use the pid from this
thread to create a `ptid_t (pid)` value.
If the target has multiple inferiors, and receives a process wide
event without specifying a process-id GDB now gives this warning:
warning: multi-inferior target stopped without sending a process-id, using first non-exited inferior
gdb/ChangeLog:
* remote.c (remote_target::process_stop_reply): Handle events for
all threads differently.
gdb/testsuite/ChangeLog:
* gdb.server/exit-multiple-threads.c: New file.
* gdb.server/exit-multiple-threads.exp: New file.
Andrew Burgess [Sat, 8 Feb 2020 21:26:31 +0000 (21:26 +0000)]
gdb/testsuite/fortran: Add mixed language stack test
This commit adds a test that builds a mixed language stack, the stack
contains frames of Fortran, C, and C++. The test prints the backtrace
and explores the stack printing arguments of different types in frames
of different languages.
The core of the test is repeated with GDB's language set to auto,
fortran, c, and c++ in turn to ensure that GDB is happy to print
frames and frame arguments when the language is set to a value that
doesn't match the frame language.
This test currently passes, and there are no known bugs in this area.
The aim of this commit is simply to increase test coverage, as I don't
believe this functionality is currently tested.
gdb/testsuite/ChangeLog:
* gdb.fortran/mixed-lang-stack.c: New file.
* gdb.fortran/mixed-lang-stack.cpp: New file.
* gdb.fortran/mixed-lang-stack.exp: New file.
* gdb.fortran/mixed-lang-stack.f90: New file.
(gdb) break get_va<TAB>
(gdb) break get_value(object<RETURN>
Function "get_value(object" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n
The reason this happens is that we add completions based on the
msymbol names and on the symbol names. For C++ both of these names
include the parameter list, however, the msymbol names have some
differences from the symbol names, for example:
+ typedefs are resolved,
+ whitespace rules are different around pointers,
+ the 'const' keyword is placed differently.
What this means is that the msymbol names and symbol names appear to
be completely different to GDB's completion tracker, and therefore to
readline when it offers the completions.
This commit builds on the previous commit which reworked the
completion_tracker class. It is now trivial to add a
remove_completion member function, this is then used along with
cp_canonicalize_string_no_typedefs to remove the msymbol aliases from
the completion tracker as we add the symbol names.
Now, for the above program GDB only presents a single completion for
'get_value', which is 'get_value(object_p)'.
It is still possible to reference the symbol using the msymbol name,
so a user can manually type out 'break get_value (object *)' if they
wish and will get the expected behaviour.
I did consider adding an option to make this alias exclusion optional,
in the end I didn't bother as I didn't think it would be very useful,
but I can easily add such an option if people think it would be
useful.
gdb/ChangeLog:
* completer.c (completion_tracker::remove_completion): Define new
function.
* completer.h (completion_tracker::remove_completion): Declare new
function.
* symtab.c (completion_list_add_symbol): Remove aliasing msymbols
when adding a C++ function symbol.
gdb/testsuite/ChangeLog:
* gdb.linespec/cp-completion-aliases.cc: New file.
* gdb.linespec/cp-completion-aliases.exp: New file.
Andrew Burgess [Mon, 27 Jan 2020 17:37:20 +0000 (17:37 +0000)]
gdb: Restructure the completion_tracker class
In this commit I rewrite how the completion tracker tracks the
completions, and builds its lowest common denominator (LCD) string.
The LCD string is now built lazily when required, and we only track
the completions in one place, the hash table, rather than maintaining
a separate vector of completions.
The motivation for these changes is that the next commit will add the
ability to remove completions from the list, removing a completion
will invalidate the LCD string, so we need to keep hold of enough
information to recompute the LCD string as needed.
Additionally, keeping the completions in a vector makes removing a
completion expensive, so better to only keep the completions in the
hash table.
This commit doesn't add any new functionality itself, and there should
be no user visible changes after this commit.
For testing, I ran the testsuite as usual, but I also ran some manual
completion tests under valgrind, and didn't get any reports about
leaked memory.
gdb/ChangeLog:
* completer.c (completion_tracker::completion_hash_entry): Define
new class.
(advance_to_filename_complete_word_point): Call
recompute_lowest_common_denominator.
(completion_tracker::completion_tracker): Call discard_completions
to setup the hash table.
(completion_tracker::discard_completions): Allow for being called
from the constructor, pass new equal function, and element deleter
when constructing the hash table. Initialise new class member
variables.
(completion_tracker::maybe_add_completion): Remove use of
m_entries_vec, and store more information into m_entries_hash.
(completion_tracker::recompute_lcd_visitor): New function, most
content taken from...
(completion_tracker::recompute_lowest_common_denominator):
...here, this now just visits each item in the hash calling the
above visitor.
(completion_tracker::build_completion_result): Remove use of
m_entries_vec, call recompute_lowest_common_denominator.
* completer.h (completion_tracker::have_completions): Remove use
of m_entries_vec.
(completion_tracker::completion_hash_entry): Declare new class.
(completion_tracker::recompute_lowest_common_denominator): Change
function signature.
(completion_tracker::recompute_lcd_visitor): Declare new function.
(completion_tracker::m_entries_vec): Delete.
(completion_tracker::m_entries_hash): Initialize to NULL.
(completion_tracker::m_lowest_common_denominator_valid): New
member variable.
(completion_tracker::m_lowest_common_denominator_max_length): New
member variable.
When running test-case gdb.opt/inline-locals.exp, I get:
...
Running src/gdb/testsuite/gdb.opt/inline-locals.exp ...
KPASS: gdb.opt/inline-locals.exp: info locals above bar 2 (PRMS gdb/xyz)
KPASS: gdb.opt/inline-locals.exp: info locals above bar 3 (PRMS gdb/xyz)
...
I've opened PR25695 - 'abstract and concrete variable listed both with "info
locals"' to refer to in the PRMS field, and this patch adds that reference.
Furthermore, I noticed that while I see KPASSes, given the problem description
the tests should actually be KFAILs. This patch also fixes that.
Tested on x86_64-linux. With gcc 7.5.0, I get 2 KFAILs. With clang 5.0.2,
the tests pass.
gdb/testsuite/ChangeLog:
2020-03-19 Tom de Vries <tdevries@suse.de>
* gdb.opt/inline-locals.exp: Add kfail PR number. Make kfail matching
more precise.
Alan Modra [Thu, 19 Mar 2020 05:03:03 +0000 (15:33 +1030)]
Don't use bfd.h in binutils/elfcomm.c
Better than warning about bfd types, just don't include bfd.h and
warn against including the header again.
* elfcomm.c: Don't include bfd.h or bucomm.h.
(program_name): Declare.
(process_archive_index_and_symbols): Replace bfd_boolean with int,
and substitute FALSE and TRUE.
(setup_archive, setup_nested_archive): Likewise.
* elfcomm.h: Likewise.
projects / deliverable / binutils-gdb.git / log
