Tom Tromey [Wed, 11 Dec 2019 14:58:46 +0000 (07:58 -0700)]
Fix the build after bfd_get_signed_8 change
A recent commit changed bfd_get_signed_8 to extend the result to a
bfd_signed_vma. This caused a compiler error in one spot in my
--enable-targets=all gdb build, where the result of bfd_get_signed_8
was passed to printf.
Jan Beulich [Wed, 11 Dec 2019 08:42:29 +0000 (09:42 +0100)]
x86: further refine SSE check (SSE4a, SHA, GFNI)
In ("x86: extend SSE check to PCLMULQDQ, AES, and GFNI insns") I went
both a little too far and not quite far enough:
- GFNI insns also have AVX512 variants, which also shouldn't get
diagnosed,
- SSE4a insns should get diagnosed just like SSE4.x ones,
- SHA insns should get diagnosed just like PCLMULQDQ or AES ones.
Implement 'print -raw-values' and 'set print raw-values on|off'
The option framework documentation was speaking about a 'print -raw'
option, but this option does not exist.
This patch implements -raw-values option that tells to ignore the
active pretty printers when printing a value.
As we already have -raw-frame-arguments, I thought -raw-values
was more clear, in particular to differentiate
set print raw-values and set print raw-frame-arguments.
gdb/doc/ChangeLog
2019-12-11 Philippe Waroquiers <[email protected]>
* gdb.texinfo (Command Options): Use -p and -pretty in the example,
as -r is ambiguous. Update the print - TAB TAB completion result.
(Data): Document new option -raw-values. Use -p and -pretty in the
example, as -r is ambiguous.
(Print Settings): Document set print raw values.
(Pretty-Printer Commands): Document interaction between enabled
pretty printers and -raw-values/-raw-frame-arguments.
* NEWS: Document -raw-values option and the related setting commands.
* printcmd.c (print_command_parse_format): Do not set opts->raw off,
only set it on when /r is given.
* valprint.c (value_print_option_defs): New element raw-values.
* Makefile.in: Add the new file.
gdb/testsuite/ChangeLog
2019-12-11 Philippe Waroquiers <[email protected]>
* gdb.base/options.exp: Add -raw-values in the print completion list.
* gdb.python/py-prettyprint.exp: Add tests for -raw-values.
Alan Modra [Tue, 10 Dec 2019 12:52:10 +0000 (23:22 +1030)]
ubsan: cris: signed integer overflow
This was the following in print_with_operands
case 4:
number
= buffer[2] + buffer[3] * 256 + buffer[4] * 65536
+ buffer[5] * 0x1000000;
and buffer[5] * 0x1000000 can indeed overflow. So to fix this we need
to use unsigned arithmetic where overflow semantics are specified.
But number is a long, and the expression is int which will be sign
extended to long. If we make the expression unsigned it will be zero
extended. So make number an int32_t and rearrange a little for some
of the places that need fixing.
* cris-dis.c (print_with_operands): Avoid signed integer
overflow when collecting bytes of a 32-bit integer.
Alan Modra [Tue, 10 Dec 2019 12:32:37 +0000 (23:02 +1030)]
ubsan: cr16: left shift cannot be represented in type 'int'
This was:
unsigned long mask = SBM (instruction->match_bits);
with
#define SBM(offs) ((((1 << (32 - offs)) -1) << (offs)))
Well, there are a couple of problems. Firstly, the expression uses
int values (1 rather than 1u or 1ul) resulting in the ubsan error, and
secondly, a zero offs will result in a 32-bit shift which is undefined
if ints are only 32 bits.
Alan Modra [Tue, 10 Dec 2019 12:02:06 +0000 (22:32 +1030)]
ubsan: bfin: shift exponent is too large
This was the following in fmtconst_val, x is unsigned int.
x = SIGNEXTEND (x, constant_formats[cf].nbits);
Problem is, the SIGNEXTEND macro assumed its arg was a long and sign
extended by shifting left then shifting right, and didn't cast the
arg. So don't do the silly shift thing. It's not guaranteed to work
anyway according to the C standard. ">>" might do a logical shift
even if its args are signed.
* bfin-dis.c (HOST_LONG_WORD_SIZE, XFIELD): Delete.
(SIGNBIT): New.
(MASKBITS, SIGNEXTEND): Rewrite.
(fmtconst): Don't use ? expression now that SIGNEXTEND uses
unsigned arithmetic, instead assign result of SIGNEXTEND back
to x.
(fmtconst_val): Use 1u in shift expression.
Alan Modra [Tue, 10 Dec 2019 07:42:28 +0000 (18:12 +1030)]
ubsan: xtensa: left shift cannot be represented in type 'int'
In Operand_soffsetx4_decode:
soffsetx4_0 = 0x4 + ((((int) offset_0 << 14) >> 14) << 2);
and other places.
Don't sign extend with shifts! This file also has many occurrences of
truncation via shifts, which aren't a problem due to using uint32, but
I dislike on principle enough to fix.
* xtensa-modules.c (Field_* functions): Don't mask using shifts.
(Operand_soffsetx4_decode, Operand_simm4_decode),
(Operand_simm8_decode, Operand_simm8x256_decode),
(Operand_simm12b_decode, Operand_label8_decode),
(Operand_label12_decode, Operand_soffset_decode),
(Operand_xt_wbr15_label_decode, Operand_xt_wbr18_label_decode): Don't
sign extend using shifts.
(Operand_immrx4_decode, Operand_uimm16x4_decode): Avoid UB in
constant.
Alan Modra [Tue, 10 Dec 2019 07:36:09 +0000 (18:06 +1030)]
ubsan: epiphany: left shift of negative value
Two places in epiphany_cgen_extract_operand, "value" is a long.
value = ((((value) << (1))) + (pc));
cpu/
* epiphany.cpu (f-simm8, f-simm24): Use multiply rather than
shift left to avoid UB on left shift of negative values.
opcodes/
* epiphany-ibld.c: Regenerate.
Tom Tromey [Wed, 20 Nov 2019 23:07:46 +0000 (16:07 -0700)]
Minor fix to gdb.prompt documentation
I noticed that an example in the gdb.prompt documentation used the
wrong kind of quotes -- because it is code, it should use a plain
ASCII quotation mark. I also slightly shortened the sample text here,
so it would more clearly fit on a single line.
Kevin Buettner [Wed, 20 Sep 2017 22:40:14 +0000 (15:40 -0700)]
OpenMP parallel region scope tests
Add tests which check for accessibility of variables from within
various OpenMP parallel regions.
Tested on Fedora 27, 28, 29, 30, and 31. I also tested with my OpenMP
work on Fedora 30. The test has been annotated with setup_xfail and
setup_kfail statements so that there are no unexpected failures on any
of these platforms when using gcc. Better still, for my own testing
anyway, is that there are also no XPASSes or KPASSes either. So,
regardless of platform, when using gcc, and regardless of whether my
(not yet public) OpenMP work is used, seeing a FAIL indicates a real
problem.
Fedora 27 results:
# of expected passes 85
# of expected failures 65
(Note: I have not retested F27 since v1 of the patch; it's possible
that the numbers will be slightly different for v2.)
Fedora 28, 29, 30 results:
# of expected passes 131
# of expected failures 4
# of known failures 16
Fedora 30, 31 results w/ my OpenMP work:
# of expected passes 151
The above results all use gcc, either the system gcc or a development
gcc (when testing against my OpenMP work in GDB). I've also tested
with clang 9.0.0 and icc 19.0.5.281 20190815 on Fedora 31.
Fedora 31, clang:
FAIL: gdb.threads/omp-par-scope.exp: single_scope: first thread: print s1
FAIL: gdb.threads/omp-par-scope.exp: single_scope: first thread: print s3
FAIL: gdb.threads/omp-par-scope.exp: single_scope: first thread: print i1
FAIL: gdb.threads/omp-par-scope.exp: single_scope: first thread: print i3
FAIL: gdb.threads/omp-par-scope.exp: single_scope: second thread: print s1
FAIL: gdb.threads/omp-par-scope.exp: single_scope: second thread: print s3
FAIL: gdb.threads/omp-par-scope.exp: single_scope: second thread: print i1
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i02
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i11
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i12
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i22
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: second thread: print i11
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: second thread: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: after parallel: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print num
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print l
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print k
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 2nd stop: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 2nd stop: print num
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print num
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print l
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print k
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 4th stop: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 4th stop: print num
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: outer stop: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: outer stop: print i
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: outer stop: print j
For both clang and icc, it turns out that there are some problems with
the DWARF that these compilers generate. Of the two, icc does at
least nest the subprogram of the outlined function representing the
parallel region within the function that it's defined, but does not
handle inner scopes if they exist. clang places the subprogram for
the outlined function at the same level as the containing function, so
variables declared within the function aren't visible at all.
I could call setup_xfail to avoid FAILs for clang and icc also, but I don't
want to further complicate the test.
gdb/testsuite/ChangeLog:
* gdb.threads/omp-par-scope.c: New file.
* gdb/threads/omp-par-scope.exp: New file.
Kevin Buettner [Sat, 9 Nov 2019 18:09:41 +0000 (11:09 -0700)]
Add gdb_caching_proc support_nested_function_tests to lib/gdb.exp
This commit adds the gdb_caching_proc, support_nested_function_tests,
to lib/gdb.exp. It tests to see whether or not the C compiler has
support for nested function calls.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (support_nested_function_tests): New proc.
* config.in: Regenerate.
* configure: Regenerate.
* gdbsupport/agent.c (gdb_connect_sync_socket): Call
safe_strerror instead of strerror.
* gdbsupport/common.m4: Don't check for strerror.
* gdbsupport/safe-strerror.c: Support both the glibc version
of strerror_r and the XSI version.
Andre Vieira [Tue, 10 Dec 2019 16:10:17 +0000 (16:10 +0000)]
[gas][arm] Set context table for '.arch_extension'
This patch fixes .arch_extension behaviour.
Currently, context table for '.arch_extension' is only set while
"-march" processing, but it is not set while .arch processing,
so following code is rejected
Tom Tromey [Tue, 3 Dec 2019 20:31:21 +0000 (13:31 -0700)]
Normalize Ada ptype to use a single "?"
Sometimes -- notably with unchecked unions -- the Ada "ptype" code
will print a "?" or "??" to indicate something unknown. The choice of
what was printed was somewhat arbitrary, and in one case, Ada would
print an empty string rather than "?".
This patch normalizes the Ada code to use "?" rather than an empty
string or "??". My reasoning here is that a single question mark is
enough to convey unknown-ness.
* gdb.ada/unchecked_union.exp: New file.
* gdb.ada/unchecked_union/pck.adb: New file.
* gdb.ada/unchecked_union/pck.ads: New file.
* gdb.ada/unchecked_union/unchecked_union.adb: New file.
* gdb-utils.exp (string_to_regexp): Also quote "?".
Alan Modra [Mon, 9 Dec 2019 12:16:26 +0000 (22:46 +1030)]
Use disassemble_info.private_data in place of insn_sets
No cgen target uses private_data. This patch removes a
disassemble_info field that is only used by cgen, and instead uses
private_data. It also removes a macro that is no longer used.
Alan Modra [Mon, 9 Dec 2019 12:27:15 +0000 (22:57 +1030)]
Remove backup ppc struct dis_private.
ppc-dis.c used a global struct whenever malloc failed to provide the
eight bytes of memory necessary for struct dis_private. Which is
quite ridiculous. If that malloc failed there is zero chance some
other malloc won't fail too.
* ppc-dis.c (private): Delete variable.
(get_powerpc_dialect): Don't segfault on NULL info->private_data.
(powerpc_init_dialect): Don't use global private.
* objdump.c (struct objdump_disasm_info): Delete "sec".
(find_symbol_for_address): Use inf->section rather than aux->sec.
(objdump_print_addr, disassemble_bytes): Likewise.
(disassemble_section): Don't set aux->sec.
George Barrett [Mon, 9 Dec 2019 21:28:39 +0000 (08:28 +1100)]
Fix scripted probe breakpoints
The documentation for make-breakpoint from the Guile API and the `spec'
variant of the gdb.Breakpoint constructor from the Python API state that
the format acceptable for location strings is the same as that accepted
by the break command. However, using the -probe qualifier at the
beginning of the location string causes a GDB internal error as it
attempts to decode a probe location in the wrong code path. Without this
functionality, there doesn't appear to be another way to set breakpoints
on probe points from Python or Guile scripts.
This patch introduces a new helper function that returns a
breakpoint_ops instance appropriate for a parsed location and updates
the Guile and Python bindings to use said function, rather than the
current hard-coded use of bkpt_breakpoint_ops. Since this logic is
duplicated in the handling of the `break' and `trace' commands, those
are also updated to call into the new helper function.
gdb: rank an lvalue argument incompatible for an rvalue parameter
Passing an lvalue argument to a function that takes an rvalue parameter
is not allowed per C++ rules. Consider this function:
int g (int &&x) { return x; }
Calling g as in
int i = 5;
int j = g (i);
is illegal. For instance, GCC 9.2.1 yields
~~~
test.cpp: In function ‘int main()’:
test.cpp:6:14: error: cannot bind rvalue reference of type ‘int&&’ to
lvalue of type ‘int’
6 | int j = g (i);
| ^
~~~
GDB currently allows this function call:
~~~
(gdb) print g(i)
$1 = 5
~~~
Fix this by ranking an lvalue argument incompatible with an rvalue
parameter. The behavior after this patch is:
~~~
(gdb) print g(i)
Cannot resolve function g to any overloaded instance
~~~
* gdbtypes.c (rank_one_type): Return INCOMPATIBLE_TYPE_BADNESS
when ranking an lvalue argument for an rvalue parameter.
gdb/testsuite/ChangeLog:
2019-12-09 Tankut Baris Aktemur <[email protected]>
* gdb.cp/rvalue-ref-overload.cc (g): New function that takes
an rvalue parameter.
* gdb.cp/rvalue-ref-overload.exp: Test calling it with an lvalue
parameter.
Andrew Burgess [Tue, 3 Dec 2019 19:15:06 +0000 (19:15 +0000)]
gdb/testsuite: kfail some tests if using broken gcc
In some cases the Fortran stride information generated by GCC is wrong
with versions of GCC after 7.x.x. This commit adds kfails for the
tests in question with known bad versions of gcc.
Andrew Burgess [Tue, 3 Dec 2019 13:18:43 +0000 (13:18 +0000)]
gdb/testsuite/fortran: Fix info-modules/info-types for gfortran 8+
The gdb.fortran/info-modules.exp and gdb.fortran/info-types.exp tests
are failing on versions of gfortran after 7.3 due to the inclusion of
extra "system" modules and type that were not being matched by the
current test patterns.
Rather than building increasingly complex patterns that would always
be at risk of breaking with future versions of GCC I have instead
added a new library that parses the output of the following commands:
info types
info variables
info functions
info modules
info module functions
info module variables
into a data structure, the test can than run checks against the
contents of this data structure.
The benefit is that we can simply ignore extra results that we don't
care about.
There is a small risk that a bug in GDB might allow us to start
reporting incorrect results in such a way that the new library will
not spot the error. However, I have tried to mitigate this risk by
adding extra procedures into the test library (see check_no_entry) and
we can add more in future if we wanted to be even more defensive.
I tested this test file with gFortran 7.3.1, 8.3.0, and 9.2.0, I now
see 100% pass in all cases.
gdb/testsuite/ChangeLog:
* gdb.fortran/info-modules.exp: Rewrite to make use of new
sym-info-cmds library.
* gdb.fortran/info-types.exp: Likewise.
* lib/sym-info-cmds.exp: New file.
Wataru Ashihara [Sun, 8 Dec 2019 08:00:43 +0000 (17:00 +0900)]
gdb/darwin-nat.c: Fix template argument for scoped_restore_tmpl
This should be the type of startup_with_shell, whose type was changed
from int to bool at commit 80fd28264.
This fixes the build on macOS:
CXX darwin-nat.o
In file included from ../../gdb/darwin-nat.c:22:
In file included from ../../gdb/top.h:25:
In file included from ../../gdb/value.h:23:
In file included from ../../gdb/frame.h:72:
In file included from ../../gdb/language.h:26:
In file included from ../../gdb/symtab.h:33:
../../gdb/gdbsupport/gdb_optional.h:155:19: error: no matching constructor for initialization of 'scoped_restore_tmpl<int>'
new (&m_item) T (std::forward<Args>(args)...);
^ ~~~~~~~~~~~~~~~~~~~~~~~~
../../gdb/darwin-nat.c:1995:31: note: in instantiation of function template specialization 'gdb::optional<scoped_restore_tmpl<int> >::emplace<bool *, int>' requested here
restore_startup_with_shell.emplace (&startup_with_shell, 0);
^
../../gdb/gdbsupport/scoped_restore.h:69:3: note: candidate constructor template not viable: no known conversion from 'bool *' to 'int *' for 1st argument
scoped_restore_tmpl (T *var, T2 value)
^
../../gdb/gdbsupport/scoped_restore.h:57:3: note: candidate constructor not viable: requires single argument 'var', but 2 arguments were provided
scoped_restore_tmpl (T *var)
^
../../gdb/gdbsupport/scoped_restore.h:76:3: note: candidate constructor not viable: requires single argument 'other', but 2 arguments were provided
scoped_restore_tmpl (const scoped_restore_tmpl<T> &other)
^
1 error generated.
Jan Beulich [Mon, 9 Dec 2019 12:31:07 +0000 (13:31 +0100)]
x86/Intel: fix "near ptr" / "far ptr" handling
Commit dc2be329b950 ("i386: Only check suffix in instruction mnemonic")
broke rejecting of these for floating point insns. Fix this by setting
the "byte" operand attribute, which will now (again) cause an error.
Furthermore the diagnostic for the "far ptr" case in general and for the
"near ptr" case in the non-float cases became "invalid instruction
suffix" instead of the intended "operand size mismatch". Fix this by
also setting the "tbyte" operand attribute (no insn template accepts
both byte and tbyte operands).
Jan Beulich [Mon, 9 Dec 2019 12:29:44 +0000 (13:29 +0100)]
x86/Intel: drop pointless suffix setting for "tbyte ptr"
There are extremely few insns accepting "tbyte ptr" operand, so the
"tbyte" operand flag checking done by match_operand_size() is already
sufficient; the setting of the suffix has become meaningless anyway
with dc2be329b950 ("i386: Only check suffix in instruction mnemonic").
Fold the code with that setting the "byte" operand flag to force an
error (no insn at all accepts both "byte ptr" and tbyte ptr" operands,
except for AnySize ones where the two (conflicting) recorded types
don't matter (operand_size_match() doesn't call match_operand_size() in
this case).
Jan Beulich [Mon, 9 Dec 2019 12:29:14 +0000 (13:29 +0100)]
x86/Intel: drop pointless suffix setting for "fword ptr"
No floating point insn accepts an "fword ptr" operand, so the "fword"
operand flag checking done by match_mem_size() is already sufficient;
the setting of the suffix has become meaningless anyway with dc2be329b950 ("i386: Only check suffix in instruction mnemonic").
Jan Beulich [Mon, 9 Dec 2019 12:28:43 +0000 (13:28 +0100)]
x86/Intel: drop pointless special casing of LxS
LDS et al don't accept "word ptr" operands anyway, as per their insn
templates. Hence there's no need to special case this here; the check
has become dysfunctional anyway by dc2be329b950 ("i386: Only check
suffix in instruction mnemonic").
Alan Modra [Sat, 7 Dec 2019 12:01:43 +0000 (22:31 +1030)]
aarch64*-*-*ilp32 gas tests
The new pac_negate_ra_state test adds yet another failure on aarch64
ipl32 targets. This patch fixes that particular problem and a few
more that are trivial to fix.
Alan Modra [Sat, 7 Dec 2019 12:02:52 +0000 (22:32 +1030)]
Optional matching for run_dump_test
This adds an alternative to using #... in dump files, useful where we
only want to allow specific extra output. DW_CFA_nop in CIEs and FDEs
to pad out to required alignment (larger for 64-bit than 32-bit) is
an example where these optional match patterns are useful.
binutils/
* testsuite/lib/binutils-common.exp (regexp_diff): Support #?REGEXP.
ld/
* testsuite/ld-elf/eh4.d: Match optional padding DW_CFA_nop in FDEs.
* testsuite/ld-elf/eh5.d: Likewise, and extra CIEs emitted on
embedded targets.
Tom de Vries [Sun, 8 Dec 2019 10:25:28 +0000 (11:25 +0100)]
Fix inter-CU references using intra-CU form in imported-unit
When running the gdb testsuite with the cc-with-dwz board, I run into:
...
Running gdb/testsuite/gdb.dwarf2/imported-unit.exp ...
gdb compile failed, dwz: gdb.dwarf2/imported-unit/imported-unit: \
Couldn't find DIE referenced by DW_AT_abstract_origin
cc-with-tweaks.sh: dwz did not modify gdb.dwarf2/imported-unit/imported-unit.
...
The problem is that the DW_AT_abstract_origin reference here:
...
<0><d2>: Abbrev Number: 2 (DW_TAG_compile_unit)
<1><e6>: Abbrev Number: 4 (DW_TAG_subprogram)
<e7> DW_AT_abstract_origin: <0x142>
<eb> DW_AT_low_pc : 0x4004b2
<f3> DW_AT_high_pc : 0x4004c8
...
referring to a DIE in another compilation unit here:
...
<0><129>: Abbrev Number: 2 (DW_TAG_compile_unit)
<1><142>: Abbrev Number: 4 (DW_TAG_subprogram)
<143> DW_AT_name : main
<148> DW_AT_type : <0x13b>
<14c> DW_AT_external : 1
...
is encoded using intra-CU reference form DW_FORM_ref4 instead of intra-CU
reference DW_FORM_ref_addr:
...
4 DW_TAG_subprogram [has children]
DW_AT_abstract_origin DW_FORM_ref4
DW_AT_low_pc DW_FORM_addr
DW_AT_high_pc DW_FORM_addr
DW_AT value: 0 DW_FORM value: 0
...
Fix this in the DWARF assembler by making all inter-CU references use the '%'
label prefix.
Keith Seitz [Sat, 7 Dec 2019 17:35:03 +0000 (09:35 -0800)]
Core file build-id support
This patch uses new BFD support for detecting build-ids in core
files.
After this patch, it is possible to run gdb with only the
core file, and gdb will automatically load the executable and
debug info [example from tests]:
$ gdb -nx -q
(gdb) core-file corefile-buildid.core
[New LWP 29471]
Reading symbols from gdb.base/corefile-buildid/debugdir-exec/.build-id/36/fe5722c5a7ca3ac746a84e223c6a2a69193a24...
Core was generated by `outputs/gdb.base/coref'.
Program terminated with signal SIGABRT, Aborted.
(gdb)
This work is based on functionality available in Fedora originally
written by Jan Kratochvil.
* build-id.c (build_id_bfd_get): Permit bfd_core, too.
(build_id_to_debug_bfd): Make static, rewriting to use
build_id_to_bfd_suffix.
(build_id_to_bfd_suffix): Copy of build_id_to_debug_bfd,
adding `suffix' parameter. Append SUFFIX to file names
when searching for matching files.
(build_id_to_debug_bfd): Use build_id_to_bfd_suffix.
(build_id_to_exec_bfd): Likewise.
* build-id.h (build_id_to_debug_bfd): Clarify that function
searches for BFD of debug info file.
(build_id_to_exec_bfd): Declare.
* corelow.c: Include build-id.h.
(locate_exec_from_corefile_build_id): New function.
(core_target_open): If no executable BFD is found,
search for a core file BFD using build-id.
* gdb.base/corefile-buildid-shlib-shr.c: New file.
* gdb.base/corefile-buildid-shlib.c: New file.
* gdb.base/corefile-buildid.c: New file.
* gdb.base/corefile-buildid.exp: New file.
Alan Modra [Fri, 6 Dec 2019 00:51:45 +0000 (11:21 +1030)]
PR25236, common sym versioning
In cases where a relocatable object file has a common symbol, no other
file has a definition, and there is a matching common symbol found in
a shared library then ld will output a definition using the largest of
size and alignment for the commons. This patch fixes a bug in ld that
ignored common symbols when assigning versions, resulting in such
symbols being given VER_NDX_LOCAL versions.
PR 25236
* elflink.c (_bfd_elf_link_assign_sym_version): Assign versions
for ELF_COMMON_DEF_P symbols.
(elf_link_output_extsym, _bfd_elf_add_default_symbol): Adjust to
suit.
Luis Machado [Tue, 26 Nov 2019 15:52:56 +0000 (12:52 -0300)]
[ARM, sim] Fix build error and warnings
Newer GCC's have switched to -fno-common by default, and this breaks the build
for the ARM sim, like this:
binutils-gdb.git~gdb-8.3-release/sim/arm/maverick.c:65: multiple definition of `DSPsc'; libsim.a(wrapper.o):binutils-gdb.git~gdb-8.3-release/sim/arm/wrapper.c:134: first defined here
binutils-gdb.git~gdb-8.3-release/sim/arm/maverick.c:64: multiple definition of `DSPacc'; libsim.a(wrapper.o):binutils-gdb.git~gdb-8.3-release/sim/arm/wrapper.c:133: first defined here
binutils-gdb.git~gdb-8.3-release/sim/arm/maverick.c:63: multiple definition of `DSPregs'; libsim.a(wrapper.o):binutils-gdb.git~gdb-8.3-release/sim/arm/wrapper.c:132: first defined here
I also noticed a few warnings due to mismatching types, as follows:
../../../../repos/binutils-gdb/sim/arm/wrapper.c: In function ‘sim_create_inferior’:
../../../../repos/binutils-gdb/sim/arm/wrapper.c:335:16: warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
for (arg = argv; *arg != NULL; arg++)
^
../../../../repos/binutils-gdb/sim/arm/wrapper.c:342:8: warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
arg = argv;
^
../../../../repos/binutils-gdb/sim/arm/wrapper.c:345:13: warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
for (arg = argv; *arg != NULL; arg++)
^
The following patch fixes both of the above.
The DWARF will result in two entries in the symbol table, a decl with type
char *[] and a def with type char*[2].
When trying to print the value of zzz:
...
$ gdb a.spec.out -batch -ex "p zzz"
...
the decl (rather than the def) will be found in the symbol table, which is
missing the location information, and consequently we get:
...
$1 = 0x601030 <zzz>
...
[ There is a fallback mechanism that finds the address of the variable in the
minimal symbol table, but that's not used here, because the type of the decl
does not specify a size. We could use the symbol size here to get the size
of the type, but that's currently not done: PR exp/24989. Still, fixing that
PR would not fix the generic case, where minimal symbol info is not
available. ]
Fix this by preferring defs over decls when searching in the symbol table.
Kyrylo Tkachov [Fri, 6 Dec 2019 10:46:32 +0000 (10:46 +0000)]
[gas] Implement .cfi_negate_ra_state directive
This patch implements the .cfi_negate_ra_state to be consistent with
LLVM (https://reviews.llvm.org/D50136). The relevant DWARF code DW_CFA_AARCH64_negate_ra_state
is multiplexed on top of DW_CFA_GNU_window_save, as per
https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00753.html
I believe this is the simplest patch implementing this and is needed to
allow users to build, for example, the Linux kernel with Armv8.3-A
pointer authentication support with Clang while using gas as the
assembler, which is a common usecase.
gdb: fix overload resolution for see-through references
The overload resolution mechanism assigns badness values to the
necessary conversions to be made on types to pick a champion. A
badness value consists of a "rank" that scores the conversion and a
"subrank" to differentiate conversions of the same kind.
An auxiliary function, 'sum_ranks', is used for adding two badness
values. In all of its uses, except two, 'sum_ranks' is used for
populating the subrank of a badness value. The two exceptions are in
'rank_one_type':
~~~
/* See through references, since we can almost make non-references
references. */
Here, the result of a recursive call is combined with
REFERENCE_CONVERSION_BADNESS. This leads to the problem of
over-punishment by combining two ranks. Consider this:
When ranking 'an_overloaded_function (const foo &)', the badness
values REFERENCE_CONVERSION_BADNESS and CV_CONVERSION_BADNESS are
combined, whereas 'rank_one_type' assigns only the
REFERENCE_CONVERSION_BADNESS value to 'an_overloaded_function (const
foo &&)' (there is a different execution flow for that). This yields
in GDB picking the latter function as the overload champion instead of
the former.
In fact, the 'rank_one_type' function should have given
'an_overloaded_function (const foo &)' the CV_CONVERSION_BADNESS
value, with the see-through referencing increasing the subrank a
little bit. This can be achieved by introducing a new badness value,
REFERENCE_SEE_THROUGH_BADNESS, which bumps up the subrank only, and
using it in the two "exceptional" cases of 'sum_ranks'.
* gdbtypes.h: Define the REFERENCE_SEE_THROUGH_BADNESS value.
* gdbtypes.c (rank_one_type): Use REFERENCE_SEE_THROUGH_BADNESS
for ranking see-through reference cases.
gdb/testsuite/ChangeLog:
2019-12-06 Tankut Baris Aktemur <[email protected]>
* gdb.cp/rvalue-ref-overload.cc: Add a case that involves both
CV and reference conversion for overload resolution.
* gdb.cp/rvalue-ref-overload.exp: Test it.
Valgrind detects various inferior related leaks, such as:
==31877== 5,530 (56 direct, 5,474 indirect) bytes in 1 blocks are definitely lost in loss record 7,131 of 7,355
==31877== at 0x4C2E18C: calloc (vg_replace_malloc.c:760)
==31877== by 0x23E580: xcalloc (alloc.c:100)
==31877== by 0x4794A9: xcnewvec<void*> (poison.h:158)
==31877== by 0x4794A9: registry_alloc_data(registry_data_registry*, registry_fields*) (registry.c:51)
==31877== by 0x3A537C: inferior_alloc_data (inferior.c:43)
==31877== by 0x3A537C: inferior::inferior(int) (inferior.c:92)
==31877== by 0x3A5426: add_inferior_silent(int) (inferior.c:98)
==31877== by 0x3A5530: add_inferior(int) (inferior.c:122)
...
Origin of the leaks is in prune_inferiors: prune_inferiors is first removing
the inferior to prune from the inferior list, then calls delete_inferior.
But delete_inferior will only really destroy the inferior when it finds
it into the inferior list.
As delete_inferior is removing the inferior to delete from the inferior list,
ensure prune_inferiors only calls delete_inferior, without touching the
inferior list.
gdb/ChangeLog
2019-12-05 Philippe Waroquiers <[email protected]>
* inferior.c (prune_inferiors): Only call delete_inferior.
Do not modify the inferior list.
Only give FDE encoding warnings if --eh-frame-hdr was specified.
This bug was observed on nios2-linux-gnu with some C++ programs
linked with -pie or -shared. The nios2 ABI doesn't include appropriate
relocations in this instance and GCC is also being patched not to pass
--eh-frame-hdr to the linker in those cases.
Simon Marchi [Thu, 5 Dec 2019 18:44:30 +0000 (13:44 -0500)]
Remove gdbarch parameter of lookup_typename
I noticed that the gdbarch parameter of lookup_typename was unused, so I
removed it (as well as from lookup_signed_typename and
lookup_unsigned_typename) and updated all callers.
Jan Beulich [Thu, 5 Dec 2019 07:44:22 +0000 (08:44 +0100)]
Arm64: simplify Crypto arch extension handling
This, at the assembler level, is just a "brace" feature covering both
AES and SHA2. Hence there's no need for it to have a separate feature
flag, freeing up a bit for future re-use. Along these lines there are
also a number of dead definitions/variables in the opcode table file.
It does not fix:
ld: error: can't create dynamic relocation R_X86_64_64 against symbol: __gmp_binvert_limb_table in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output
>>> defined in /usr/local/lib/libgmp.a(mp_minv_tab.o)
>>> referenced by tmp-dive_1.s
>>> dive_1.o:(__gmpn_divexact_1) in archive /usr/local/lib/libgmp.a
ld: error: can't create dynamic relocation R_X86_64_64 against symbol: __gmp_binvert_limb_table in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output
>>> defined in /usr/local/lib/libgmp.a(mp_minv_tab.o)
>>> referenced by tmp-bdiv_q_1.s
>>> bdiv_q_1.o:(__gmpn_bdiv_q_1) in archive /usr/local/lib/libgmp.a
ld: error: can't create dynamic relocation R_X86_64_64 against symbol: __gmpn_invert_limb_table in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output
>>> defined in /usr/local/lib/libgmp.a(invert_limb_table.o)
>>> referenced by tmp-invert_limb.s
>>> invert_limb.o:(__gmpn_invert_limb) in archive /usr/local/lib/libgmp.a
Tom Tromey [Tue, 3 Dec 2019 00:17:45 +0000 (17:17 -0700)]
Use metadata style in a few more places
I happened to find a few more spots that should use metadata style,
but do not. I missed these in my earlier search somehow. This patch
also adds gettext markup in a couple of spots where it was missing.
Andrew Burgess [Wed, 27 Nov 2019 21:51:35 +0000 (21:51 +0000)]
gdb/testsuite: Use -J option when compiling Fortran tests
When compiling Fortran tests (e.g. gdb.fortran/info-modules.exp), the
Fotran compile produces .mod files. These files contain details of
compiled modules that are then consumed by the compiler when compiling
other files that USE a module.
Currently the compiler writes the .mod files into its current
directory, so for us this turns out to be 'build/gdb/testsuite/'.
This means that .mod files can be shared between tests, which seems
against the spirit of the GDB testsuite; source files should be
compiled fresh for each test.
This commit adds the -J option to the compiler flags whenever we
compile a Fortran file, this option tells the compiler where to write,
and look for, .mod files.
After this commit there was one Fortran test that needed fixing, with
that fix in place all of the Fortran tests pass again, but now the
.mod files are now produced in the per-test output directories.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_compile): Add -J compiler option when building
Fortran tests.
* gdb.mi/mi-fortran-modules.exp: Compile source files in correct
order.
Andrew Burgess [Tue, 3 Dec 2019 10:52:05 +0000 (10:52 +0000)]
gdb/fortran: Support for single/double type modifiers
Extend the Fortran parser to support 'single precision' and 'double
precision' types as well 'single complex' and 'double complex' types.
gdb/ChangeLog:
* f-exp.y (COMPLEX_KEYWORD, SINGLE, DOUBLE, PRECISION): New
tokens.
(typebase): New patterns for complex, single/double precision, and
single/double complex.
(f77_keywords): Change token for complex keyword, and add single,
double, and precision keywords.
gdb/testsuite/ChangeLog:
* gdb.fortran/type-kinds.exp (test_cast_1_to_type_kind): Handle
casting to type with no kind specified.
(test_basic_parsing_of_type_kinds): Additional tests for types
with no kind specified, and add tests for single/double
precision/complex types.
Simon Marchi [Wed, 4 Dec 2019 18:35:46 +0000 (13:35 -0500)]
Fix doc of AVR-specific command "info io_registers"
Running the selftests on an all-targets build, I get:
Running selftest help_doc_invariants.
help doc broken invariant: command 'info io_registers' help doc first line is not terminated with a '.' character
Self test failed: self-test failed at /home/simark/src/binutils-gdb/gdb/unittests/help-doc-selftests.c:95
Add a period at the end of the doc of that command, and make it a bit
nicer in general.
gdb/ChangeLog:
* avr-tdep.c (_initialize_avr_tdep): Improve help of command
"info io_registers".
#9 0x000055fe25584a52 in internal_error (file=0x55fe27a25fe0 "/home/simark/src/binutils-gdb/gdb/thread.c", line=95, fmt=0x55fe27a25c80 "%s: Assertion `%s' failed.")
at /home/simark/src/binutils-gdb/gdb/gdbsupport/errors.c:55
#10 0x000055fe260674bc in inferior_thread () at /home/simark/src/binutils-gdb/gdb/thread.c:95
#11 0x000055fe25c62f0f in get_current_regcache () at /home/simark/src/binutils-gdb/gdb/regcache.c:372
#12 0x000055fe2594fcf1 in current_options () at /home/simark/src/binutils-gdb/gdb/mep-tdep.c:873
#13 0x000055fe2594ff08 in mep_register_name (gdbarch=0x62100056f510, regnr=152) at /home/simark/src/binutils-gdb/gdb/mep-tdep.c:958
#14 0x000055fe25950112 in mep_register_reggroup_p (gdbarch=0x62100056f510, regnum=152, group=0x55fe2924d540 <save_group>) at /home/simark/src/binutils-gdb/gdb/mep-tdep.c:1029
#15 0x000055fe2555ad87 in gdbarch_register_reggroup_p (gdbarch=0x62100056f510, regnum=152, reggroup=0x55fe2924d540 <save_group>) at /home/simark/src/binutils-gdb/gdb/gdbarch.c:3622
#16 0x000055fe25c61d45 in reg_buffer::save(gdb::function_view<register_status (int, unsigned char*)>) (this=0x7ffc61a0ed90, cooked_read=...)
at /home/simark/src/binutils-gdb/gdb/regcache.c:247
#17 0x000055fe2552ac60 in readonly_detached_regcache::readonly_detached_regcache(gdbarch*, gdb::function_view<register_status (int, unsigned char*)>) (this=0x7ffc61a0ed90,
gdbarch=0x62100056f510, cooked_read=...) at /home/simark/src/binutils-gdb/gdb/regcache.h:444
#18 0x000055fe25c61867 in readonly_detached_regcache::readonly_detached_regcache (this=0x7ffc61a0ed90, src=...) at /home/simark/src/binutils-gdb/gdb/regcache.c:212
#19 0x000055fe25c6a5ca in selftests::cooked_read_test (gdbarch=0x62100056f510) at /home/simark/src/binutils-gdb/gdb/regcache.c:1613
The problems is that mep's code ends up calling inferior_thread, which
calls find_thread_ptid. find_thread_ptid searches for a thread by ptid
in the thread list of the inferior that is expected to contain that
thread.
However, the thread list of the mock inferior set up in cooked_read_test
is never initialized. So find_thread_ptid doesn't find the thread,
which is an unexpected situation for inferior_thread.
Simon Marchi [Wed, 4 Dec 2019 18:27:21 +0000 (13:27 -0500)]
Compare iterators, not values, in filtered_iterator::operator{==,!=}
The == and != operators on filtered_iterator are not doing the
right thing, they compare values pointed by the wrapped iterators
instead of comparing the iterators themselves.
As a result, operator== will return true if the two iterators point to
two equal values at different positions. operator!= will fail
similarly.
Also, this causes it to deference past-the-end iterators when doing.
For example, in
for (iter = ...; iter != end_iter; ++iter)
the != comparison dereferences end_iter. I don't think this should
happen.
I don't think it's a problem today, given that we only use
filtered_iterator to wrap linked lists of threads and inferiors.
Dereferencing past-the-end iterators of these types is not fatal, it
just returns NULL, which is not a value we otherwise find in the lists.
But in other contexts, it could become problematic.
I have added a simple self test that fails without the fix applied.
gdb/ChangeLog:
* filtered-iterator.h (filtered_iterator) <operator==,
operator!=>: Compare wrapped iterators, not wrapped pointers.
* Makefile.in (SUBDIR_UNITTESTS_SRCS): Add
unittests/filtered_iterator-selftests.c.
* unittests/filtered_iterator-selftests.c: New file.
* gdb.ada/scalar_storage/storage.adb: New file.
* gdb.ada/scalar_storage/pck.adb: New file.
* gdb.ada/scalar_storage/pck.ads: New file.
* gdb.ada/scalar_storage.exp: New file.
Tom Tromey [Mon, 25 Nov 2019 19:31:02 +0000 (12:31 -0700)]
Remove gdbarch_bits_big_endian
From what I can tell, set_gdbarch_bits_big_endian has never been used.
That is, all architectures since its introduction have simply used the
default, which is simply check the architecture's byte-endianness.
Because this interferes with the scalar_storage_order code, this patch
removes this gdbarch setting entirely. In some places,
type_byte_order is used rather than the plain gdbarch.
Tom Tromey [Mon, 25 Nov 2019 18:14:50 +0000 (11:14 -0700)]
Move type_byte_order earlier
I failed to notice that the scalar_storage_order patch put
type_byte_order at the end of gdbtypes.c. The end of the file is
normally where the file's _initialize function goes. This moves
type_byte_order earlier, into a more relevant section.
Tom Tromey [Wed, 4 Dec 2019 15:08:13 +0000 (08:08 -0700)]
Fix another build failure in tui-selftests.c
Christian had emailed me to say that the TUI unit test broke the mingw
build, but I erroneously thought this was fixed by the earlier patch
that made the test body conditional on the TUI being built.
However, I was wrong about this -- tui-selftests.c unconditionally
includes tui-winsource.h, which fails if curses is not available.
This patch fixes the build problem by moving this include into the
"#ifdef TUI" section.
projects / binutils.git / log