Tom Tromey [Fri, 1 Sep 2023 20:05:04 +0000 (14:05 -0600)]
Simplify some symbol searches in linespec.c
This simplifies some symbol searches in linespec.c. In particular,
two separate searches here can now be combined into one, due to the
new use of flags.
Arguably the STRUCT_DOMAIN searches should perhaps not even be done.
Only C really has these, and C doesn't have member functions.
However, it seems relatively harmless -- and clearly compatible -- to
leave this in.
Tom Tromey [Fri, 17 Nov 2023 01:02:14 +0000 (18:02 -0700)]
Simplify some symbol searches in Ada code
This changes some of the Ada code to simplify symbol searches. For
example, if a function is being looked for, the search is narrowed to
use SEARCH_FUNCTION_DOMAIN rather than SEARCH_VFT. In one spot, a
search of the "struct" domain is removed, because Ada does not have a
tag domain.
Tom Tromey [Thu, 2 Mar 2023 14:44:11 +0000 (07:44 -0700)]
Use the new symbol domains
This patch changes the DWARF reader to use the new symbol domains. It
also adjusts many bits of associated code to adapt to this change.
The non-DWARF readers are updated on a best-effort basis. This is
somewhat simpler since most of them only support C and C++. I have no
way to test a few of these.
I went back and forth a few times on how to handle the "tag"
situation. The basic problem is that C has a special namespace for
tags, which is separate from the type namespace. Other languages
don't do this. So, the question is, should a DW_TAG_structure_type
end up in the tag domain, or the type domain, or should it be
language-dependent?
I settled on making it language-dependent using a thought experiment.
Suppose there was a Rust compiler that only emitted nameless
DW_TAG_structure_type objects, and specified all structure type names
using DW_TAG_typedef. This DWARF would be correct, in that it
faithfully represents the source language -- but would not work with a
purely struct-domain implementation in gdb. Therefore gdb would be
wrong.
Now, this approach is a little tricky for C++, which uses tags but
also enters a typedef for them. I notice that some other readers --
like stabsread -- actually emit a typedef symbol as well. And, I
think this is a reasonable approach. It uses more memory, but it
makes the internals simpler. However, DWARF never did this for
whatever reason, and so in the interest of keeping the series slightly
shorter, I've left some C++-specific hacks in place here.
Note that this patch includes language_minimal as a language that uses
tags. I did this to avoid regressing gdb.dwarf2/debug-names-tu.exp,
which doesn't specify the language for a type unit. Arguably this
test case is wrong.
Tom Tromey [Fri, 1 Sep 2023 20:29:33 +0000 (14:29 -0600)]
Remove old symbol_matches_domain
Nothing calls the variant of symbol_matches_domain that accepts a
domain_enum for searching, so this patch removes it and the
corresponding symbol::matches.
Tom Tromey [Fri, 31 Mar 2023 05:00:26 +0000 (23:00 -0600)]
Use domain_search_flags in lookup_symbol et al
This changes lookup_symbol and associated APIs to accept
domain_search_flags rather than a domain_enum.
Note that this introduces some new constants to Python and Guile. I
chose to break out the documentation patch for this, because the
internals here do not change until a later patch, and it seemed
simpler to patch the docs just once, rather than twice.
Tom Tromey [Sat, 11 Mar 2023 14:55:42 +0000 (07:55 -0700)]
Use domain_search_flags in lookup_global_symbol_language
This changes quick_symbol_functions::lookup_global_symbol_language to
accept domain_search_flags rather than just a domain_enum, and fixes
up the fallout.
To avoid introducing any regressions, any code passing VAR_DOMAIN now
uses SEARCH_VFT.
That is, no visible changes should result from this patch. However,
it sets the stage to refine some searches later on.
Tom Tromey [Sat, 9 Sep 2023 23:41:30 +0000 (17:41 -0600)]
Introduce "scripting" domains
The Python and Guile code exposed the internal domain constants both
as attributes of symbols and as values to pass to lookup functions.
Now, perfect backward compatibility here can't be achieved: some
symbols are going to have domain changes by the end of this series.
However, it seemed to me that we can preserve lookups using the basic
domain values.
This patch implements this by exporting the "or"-able search constants
with an extra bit set. Then it introduces some functions to convert
such constants to domain_search_flags. This will be used by the
Python and Guile code, so that both old- and new-style lookups will
work properly; and while preserving the idea that the domain constants
can be compared to a symbol's domain.
Tom Tromey [Sat, 11 Mar 2023 05:16:51 +0000 (22:16 -0700)]
Remove a check of VAR_DOMAIN
completion_list_add_symbol checks that the returned symbol has
VAR_DOMAIN, but also checks that its address class is LOC_BLOCK. The
domain check is redundant -- only functions can possibly be LOC_BLOCK
-- and leaving this in place will cause a regression when combined
with a later patch in this series. This patch preemptively removes
the redundant check.
Tom Tromey [Thu, 2 Mar 2023 22:20:29 +0000 (15:20 -0700)]
Add domain_search_flags
This adds a new flag enum type, domain_search_flags, which is the flag
version of domain_enum. Nothing uses this yet, but the goal here is
to have all symbol searches and lookups use these flags. The new
names are chosen to exactly parallel domain_enum.
Tom Tromey [Thu, 2 Mar 2023 22:07:47 +0000 (15:07 -0700)]
Add two new symbol domains
This adds two new symbol domain constants, TYPE_DOMAIN and
FUNCTION_DOMAIN.
Historically, gdb was a C debugger, and the symbol tables continue to
reflect this. In particular, symbol domains match the C language,
with VAR_DOMAIN including variables, functions, and types.
However, other languages have other approaches to namespacing. And,
in any case, it is often useful for other parts of gdb to be able to
distinguish between some domains at lookup time, without resorting to
examining a symbol's location -- in some situations, this sort of
filtering happens too late.
Nothing uses these new domains yet, but the idea behind the patch is
to separate symbols into more domains and then let the
language-specific parts of gdb implement their semantics in terms of
these categories.
Tom Tromey [Sun, 3 Sep 2023 22:28:54 +0000 (16:28 -0600)]
Use a .def file for domain_enum
Future patches will change and reuse the names from domain_enum. This
patch makes this less error-prone by having a single point to define
these names, using the typical gdb ".def" file.
Tom Tromey [Fri, 10 Mar 2023 18:48:25 +0000 (11:48 -0700)]
Split up a big 'if' in symtab.c
global_symbol_searcher::add_matching_symbols in symtab.c has a
gigantic 'if' statement -- 33 lines of conditional expression. This
patch splits it up into a series of separate 'if's.
Tom Tromey [Thu, 2 Mar 2023 22:08:42 +0000 (15:08 -0700)]
Remove NR_DOMAINS
NR_DOMAINS is only used for a static assert, but we no longer need it
now. If we add too many constants to this enum, GCC will warn about
the bitfield overflow:
error: ‘symbol::m_domain’ is too small to hold all values of ‘enum domain_enum’
Tom Tromey [Mon, 20 Nov 2023 04:09:57 +0000 (21:09 -0700)]
Give names to unspecified types
A patch later in this series will change check_typedef to also look in
the type domain. This change by itself caused a regression, but one
that revealed some peculiar behavior.
The regression is in nullptr_t.exp, where examining a std::nullptr_t
will change from the correct:
typedef decltype(nullptr) std::nullptr_t;
to
typedef void std::nullptr_t;
Right now, the DWARF reader marks all unspecified types as stub types.
However, this interacts weirdly with check_typedef, which currently
does not try to resolve types -- only struct-domain objects.
My first attempt here was to fix this by changing void types not to be
stub types, as I didn't see what value that provided. However, this
caused another regression, because call_function_by_hand_dummy checks
for stub-ness:
if (values_type == NULL || values_type->is_stub ())
values_type = default_return_type;
I'm not really sure why it does this rather than check for
TYPE_CODE_VOID.
While looking into this, I found another oddity: the DWARF reader
correctly creates a type named 'decltype(nullptr)' when it seems a
DW_TAG_unspecified_type -- but it creates a symbol named "void"
instead.
This patch changes the DWARF reader to give the symbol the correct
name. This avoids the regression.
Tom Tromey [Fri, 10 Mar 2023 16:49:24 +0000 (09:49 -0700)]
Make nsalias.exp more reliable
nsalias.exp tries to detect a complaint that is issued when expanding
a CU. However, the test is a bit funny in that, while gdb does
currently expand the CU and issue the complaint, it also emits this
error:
No symbol "N100" in current context.
This series will change gdb such that this CU is not expanded -- which
makes sense, the symbol in question doesn't actually match the lookups
that are done.
So, to make the test more robust, a direct request to expand symtabs
is done instead.
Tom Tromey [Thu, 18 Jan 2024 20:27:02 +0000 (13:27 -0700)]
Fix latent bug in DW_TAG_entry_point handling
A DW_TAG_entry_point symbol inherits its extern/static property from
the enclosing subroutine. This is encoded in new_symbol -- but the
cooked indexer does not agree.
Tom Tromey [Thu, 30 Mar 2023 16:25:40 +0000 (10:25 -0600)]
Small cleanup in DWARF reader
I noticed a couple of spots in dwarf/read.c:new_symbol that call
add_symbol_to_list. However, this function is generally written to
set list_to_add, and then have a single call to add_symbol_to_list at
the end. This patch cleans up this discrepancy.
Note that new_symbol is overlong and should probably be split up.
Tom Tromey [Thu, 30 Mar 2023 16:21:59 +0000 (10:21 -0600)]
Fix bug in cooked index scanner
Testing this entire series pointed out that the cooked index scanner
disagrees with new_symbol about certain symbols. In particular,
new_symbol has this comment:
Ada and Fortran subprograms, whether marked external or
not, are always stored as a global symbol, because we want
This patch updates the scanner to match.
I don't know why the current code does not cause failures.
It's maybe worth noting that incremental CU expansion -- creating
symtabs directly from the index -- would eliminate this sort of bug.
Indu Bhagat [Fri, 26 Jan 2024 18:30:18 +0000 (10:30 -0800)]
gas: scfi: untraceable control flow should be a hard error
PR gas/31284
Currently, if an indirect jump is seen, GCFG (a CFG of ginsns) cannot be
created, and the SCFI machinery bails out with a warning:
"Warning: Untraceable control flow for func 'foo'; Skipping SCFI"
It is, however, better suited if this is a hard error. Change it to a
hard error. Also change the message to skip mentioning "SCFI", because
the error itself may also useful when ginsns are used for other passes
(distinct from SCFI) involving GCFG, like a pass to detect if there is
unreachable code. Hence, simply say:
"Error: untraceable control flow for func 'foo'"
gas/
PR gas/31284
* ginsn.c (ginsn_data_end): Use as_bad instead of as_warn.
gas/testsuite/
PR gas/31284
* gas/scfi/x86_64/ginsn-cofi-1.l: Adjust to the expected output
in case of errors.
* gas/scfi/x86_64/scfi-unsupported-cfg-1.l: Error not Warning.
Indu Bhagat [Fri, 26 Jan 2024 18:29:38 +0000 (10:29 -0800)]
x86: testsuite: scfi: adjust COFI testcase
The testcase for change of flow instructions in its current shape is not
doing much: it checks that SCFI issues an appropriate warning. The same
warning is covered by another testcase (scfi-unsupported-cfg-1); It is
better to test the ginsn translation instead, for these 'change of flow
instructions'.
Andrew Carlotti [Fri, 19 Jan 2024 13:01:40 +0000 (13:01 +0000)]
aarch64: move SHA512 instructions to +sha3
SHA512 instructions were added to the architecture at the same time as SHA3
instructions, but later than the SHA1 and SHA256 instructions. Furthermore,
implementations must support either both or neither of the SHA512 and SHA3
instruction sets. However, SHA512 instructions were originally (and
incorrectly) added to Binutils under the +sha2 flag.
This patch moves SHA512 instructions under the +sha3 flag, which matches the
architecture constraints and existing GCC and LLVM behaviour.
Jan Beulich [Fri, 26 Jan 2024 09:34:48 +0000 (10:34 +0100)]
x86/APX: TILE{RELEASE,ZERO} have no EVEX encodings
Re-using the entire VEX decode hierarchy for the respective major opcode
has led to those two also being decoded as-if valid. Follow the earlier
USE_X86_64_EVEX_{PFX,W}_TABLE approach to avoid this happening.
Jan Beulich [Fri, 26 Jan 2024 09:34:24 +0000 (10:34 +0100)]
x86/APX: no need to have decode go through x86_64_table[]
As suggested during review already, all such entries have their first
slot as Bad_Opcode, so by adding two more enumerators we can avoid doing
that decode step altogether.
Jan Beulich [Fri, 26 Jan 2024 09:32:37 +0000 (10:32 +0100)]
x86: make "-msyntax=intel -mnaked-reg" match ".intel_syntax noprefix"
Adjustments made for the directive (by set_intel_syntax()) need also
making for the command line option. Break out respective code into a new
helper function, to also be invoked during command line processing.
Further also set register_prefix when processing -mnaked-reg.
Jan Beulich [Fri, 26 Jan 2024 09:31:38 +0000 (10:31 +0100)]
x86/APX: optimize MOVBE
With identical source and destination it can be covered by the NDD-to-
legacy conversion logic as well, even if in this case the original insn
doesn't use an NDD encoding. The size savings are even better here, for
the replacement (BSWAP) not having a ModR/M byte.
Alan Modra [Thu, 25 Jan 2024 22:44:13 +0000 (09:14 +1030)]
Assertion failure dumping .eh_frame_hdr
dwarf.c can hit "Assertion '(start) <= (end)' failed" on truncated
sections, due to get_encoded_eh_value wrongly returning a full count
for truncated words.
* dwarf.c (get_encoded_eh_value): Return zero for truncated words.
even though PR ld/31289 targets xfail for [is_generic] targets. These
targets not only don't use the generic_link_hash_table linker, but also
don't use the standard ELF emulation. Add is_standard_elf for ELF
targets which use the standard ELF emulation and replace [is_generic]
with ![is_standard_elf] in PR ld/31289 tests.
Tom de Vries [Thu, 25 Jan 2024 15:36:09 +0000 (16:36 +0100)]
[gdb/testsuite] Fix regexp in vgdb_start
On Fedora 39 aarch64 I run into:
...
(gdb) target remote | vgdb --wait=2 --max-invoke-ms=2500 --pid=2114437^M
Remote debugging using | vgdb --wait=2 --max-invoke-ms=2500 --pid=2114437^M
relaying data between gdb and process 2114437^M
warning: remote target does not support file transfer, \
attempting to access files from local filesystem.^M
Reading symbols from /lib/ld-linux-aarch64.so.1...^M
_start () at ../sysdeps/aarch64/dl-start.S:22^M
warning: 22 ../sysdeps/aarch64/dl-start.S: No such file or directory^M
(gdb) FAIL: gdb.base/valgrind-infcall.exp: target remote for vgdb
...
For contrast, on openSUSE Leap 15.4 x86_64 I have:
...
(gdb) target remote | vgdb --wait=2 --max-invoke-ms=2500 --pid=18797^M
Remote debugging using | vgdb --wait=2 --max-invoke-ms=2500 --pid=18797^M
relaying data between gdb and process 18797^M
warning: remote target does not support file transfer, \
attempting to access files from local filesystem.^M
Reading symbols from /lib64/ld-linux-x86-64.so.2...^M
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)^M
0x0000000004002550 in _start () from /lib64/ld-linux-x86-64.so.2^M
(gdb) PASS: gdb.base/valgrind-infcall.exp: target remote for vgdb
...
The fail happens in vgdb_start because the regexp only matches the
"in _start ()" variant, not the "_start () at":
...
gdb_test "$vgdbcmd" " in \\.?_start .*" "target remote for vgdb"
...
Which variant you get is determined by presence of debug info.
Fix this by also matching the "_start () at" variant.
Tom de Vries [Thu, 25 Jan 2024 15:31:47 +0000 (16:31 +0100)]
[gdb/build] Workaround gcc PR113599
Since gcc commit d3f48f68227 ("c++: non-dependent .* operand folding
[PR112427]"), with gdb we run into PR gcc/113599 [1], a wrong-code bug, as
reported in PR build/31281.
Work around this by flipping inherit order:
...
-class thread_info : public refcounted_object,
- public intrusive_list_node<thread_info>
+class thread_info : public intrusive_list_node<thread_info>,
+ public refcounted_object
...
An argument could be made that this isn't necessary, because this occurred in
an unreleased gcc version.
However, I think it could be useful when bisecting gcc for other problems in
building gdb. Having this workaround means the bisect won't reintroduce the
problem. Furthermore, the workaround is harmless.
Tested on Fedora rawhide x86_64.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31281
Tom de Vries [Thu, 25 Jan 2024 15:25:07 +0000 (16:25 +0100)]
[gdb/testsuite] Fix gdb.base/eh_return.exp
On Fedora rawhide aarch64, I run into:
...
(gdb) PASS: gdb.base/eh_return.exp: set breakpoint on address
run ^M
Starting program: eh_return ^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
[Inferior 1 (process 1113051) exited normally]^M
(gdb) FAIL: gdb.base/eh_return.exp: hit breakpoint (the program exited)
...
This happens as follows: the test-case sets a breakpoint on the last
instruction of function eh2:
...
(gdb) break *0x00000000004103ec^M
...
and expects to hit the breakpoint, but instead the "br x6" is taken:
...
0x00000000004103e0 <+176>: cbz x4, 0x4103ec <eh2+188>^M
0x00000000004103e4 <+180>: add sp, sp, x5^M
0x00000000004103e8 <+184>: br x6^M
0x00000000004103ec <+188>: ret^M
...
Currently, in AIX attach-twice.exp testcase is untested due to the below error.
gdb/testsuite/gdb.base/attach-twice.c:43:7: error: too few arguments to function 'ptrace'
This is because in AIX ptrace has five arguments. This patch is a fix for the same such that
this test case runs in AIX and other targets as well.
H.J. Lu [Wed, 24 Jan 2024 21:53:11 +0000 (13:53 -0800)]
ld: Improve --fatal-warnings for unknown command-line options
There are 2 problems with --fatal-warnings for unknown command-line
options:
1. --fatal-warnings doesn't trigger an error for an unknown command-line
option when --fatal-warnings is the last command-line option.
2. When --fatal-warnings triggers an error for an unknown command-line
option, the message says that the unknown command-line option is ignored.
This patch queues unknown command-line option warnings and outputs queued
command-line option warnings after all command-line options have been
processed so that --fatal-warnings can work for unknown command-line
options regardless of the order of --fatal-warnings.
When --fatal-warnings is used, the linker message is changed from
ld: warning: -z bad-option ignored
to
ld: error: unsupported option: -z bad-option
The above also applies to "-z dynamic-undefined-weak" when the known
"-z dynamic-undefined-weak" option is ignored.
Tom Tromey [Thu, 11 Jan 2024 16:52:55 +0000 (09:52 -0700)]
Emit stopped event for DAP attach request
In an earlier patch, I wrote:
... It also adds some machinery so that attach stops can be
suppressed, which I think is the right thing to do.
However, after some discussions here at AdaCore, I now believe this to
be incorrect -- while DAP says that expected "continue" events should
be suppressed, there is no corresponding language for expected "stop"
events, and indeed "stop" events explicitly mention cases like "step".
This patch arranges for the stop event to be emitted again.
Tom Tromey [Tue, 9 Jan 2024 18:47:17 +0000 (11:47 -0700)]
Handle DW_AT_endianity on enumeration types
A user found that gdb would not correctly print a field from an Ada
record using the scalar storage order feature. We tracked this down
to a combination of problems.
First, GCC did not emit DW_AT_endianity on the enumeration type.
DWARF does not specify this, but it is an obvious and harmless
extension. This was fixed in GCC recently:
arm_epilogue_frame_this_id has a comment saying that it fall backs to using
the current PC if the function start address can't be identified, but it
actually uses only the PC to make the frame id.
This patch makes the code match the comment. Another hint that it's what
is intended is that arm_prologue_this_id, a function almost identical to
it, does that.
The problem was found by code inspection. It fixes the following testsuite
failures:
FAIL: gdb.base/unwind-on-each-insn.exp: foo: instruction 9: check frame-id matches
FAIL: gdb.reverse/solib-reverse.exp: reverse-next third shr1
FAIL: gdb.reverse/solib-reverse.exp: reverse-next second shr1
FAIL: gdb.reverse/solib-reverse.exp: reverse-next first shr1
FAIL: gdb.reverse/solib-reverse.exp: reverse-next generic
FAIL: gdb.reverse/solib-reverse.exp: reverse-step into solib function one
FAIL: gdb.reverse/solib-reverse.exp: reverse-step within solib function one
FAIL: gdb.reverse/solib-reverse.exp: reverse-step into solib function two
FAIL: gdb.reverse/solib-reverse.exp: reverse-step within solib function two
Guinevere Larsen [Thu, 24 Aug 2023 09:00:35 +0000 (11:00 +0200)]
gdb/testsuite: add test for backtracing for threaded inferiors from a corefile
This patch is based on an out-of-tree patch that fedora has been
carrying for a while. It tests if GDB is able to properly unwind a
threaded program in the following situations:
* regular threads
* in a signal handler
* in a signal handler executing on an alternate stack
And the final frame can either be in a syscall or in an infinite loop.
The test works by running the inferior until a crash to generate a
corefile, or until right before the crash. Then applies a backtrace to
all threads to see if any frame can't be identified, and the order of
the threads in GDB. Finally, it goes thread by thread and tries to
collect a large part of the backtrace, to confirm that everything is
being unwound correctly.
Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Reviewed-By: Luis Machado <luis.machado@arm.com> Approved-By: Luis Machado <luis.machado@arm.com>
mengqinggang [Thu, 18 Jan 2024 11:03:11 +0000 (19:03 +0800)]
LoongArch: gas: Start a new frag after instructions that can be relaxed
For R_LARCH_TLS_{LE_HI20_R,LE_ADD_R,LD_PC_HI20,GD_PC_HI20, DESC_PC_HI20}
relocations, start a new frag to get correct eh_frame Call Frame Information
FDE DW_CFA_advance_loc info.
mengqinggang [Sun, 1 Oct 2023 07:29:44 +0000 (15:29 +0800)]
LoongArch: gas: Don't define LoongArch .align
Gcc may generate "\t.align\t%d,54525952,4\n" before commit b20c7ee066cb7d952fa193972e8bc6362c6e4063. To write 54525952 (NOP) to object
file, we call s_align_ptwo (-4). It result in alignment padding must be a
multiple of 4 if .align has second parameter.
Restructure the architecture extensions table, add a new table for architecture
version dependencies, add missing architecture extensions, and improve some
extension descriptions.
Andrew Carlotti [Wed, 17 Jan 2024 12:37:15 +0000 (12:37 +0000)]
aarch64: Include +predres2 in -march=armv8.9-a
This matches the dependencies in the architecture, in LLVM, and even in the
original Binutils commit message that mistakenly included it only in armv9.4-a.
Guinevere Larsen [Mon, 22 Jan 2024 09:13:52 +0000 (10:13 +0100)]
gdb: fix "list ." related crash
When a user attempts to use the "list ." command with an inferior that
doesn't have debug symbols, GDB would crash. This was reported as PR
gdb/31256.
The crash would happen when attempting to get the current symtab_and_line
for the stop location, because the symtab would return a null pointer
and we'd attempt to dereference it to print the line.
This commit fixes that by checking for an empty symtab and erroring out
of the function if it happens.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31256 Approved-By: Tom Tromey <tom@tromey.com>
Mike Frysinger [Tue, 23 Jan 2024 08:09:43 +0000 (03:09 -0500)]
sim: sh: fix nested braces in struct init
The op struct includes an array of strings, but doesn't use braces
around that array when initializing. This causes a ton of warnings
when using -Wmissing-braces. Add them to fix.
The code this tool generates is the same before & after.
Jaydeep Patil [Thu, 11 Jan 2024 05:28:21 +0000 (05:28 +0000)]
sim: riscv: Fix crash during instruction decoding
The match_never() function has been removed and thus step_once() crashes
during instruction decoding. Fixed it by checking for null pointer before
invoking function attached to match_func member of riscv_opcode structure
Some compilers warn in the frv code:
sem.c:24343:41: error: incompatible function pointer types passing
'void (SIM_CPU *, UINT, UDI)' (aka 'void (struct _sim_cpu *, unsigned int, unsigned long)')
to parameter of type
'void (*)(SIM_CPU *, UINT, DI)' (aka 'void (*)(struct _sim_cpu *, unsigned int, long)') [-Wincompatible-function-pointer-types]
This is due to frvbf_h_acc40U_set using UDI for setting the new value,
but using the common sim_queue_fn_di_write API which uses DI. The same
size, but different sign. We could change frvbf_h_acc40U_set to take a
DI without changing behavior in practice: the UDI is already passed via
the queue function which accepts a DI, and frvbf_h_acc40U_set already
casts the input to UDI before running any operations on it. However,
these files are all generated, so manual changes here would be reverted.
Seems like we can only change the register type for all APIs in the cpu
definition. This builds cleanly, and passes sim unittests. Not sure if
it's 100% the answer, but seems to be the best we have currently.
Simon Marchi [Fri, 19 Jan 2024 21:15:41 +0000 (21:15 +0000)]
gdb/testsuite: avoid duplicate test names in gdb.dwarf2/dw2-zero-range.exp (and more)
Tom Tromey noticed that dw2-zero-range.exp reported a duplicate test
name. This happens because have_index calls get_index_type with the
default test name. Refactor the test to avoid this, while cleaning a
few other things, the most important being:
- factor out the relocated and unrelocated parts in their own procs
- give different names to generated binaries in different variations,
such that all binaries are left in the test output directory (this
makes it easier to debug a specific variation)
Fix 31252 gprofng causes testsuite parallel jobs fail
Before running our tests, we made a fake installation into ./tmpdir.
This installation changes libopcodes.la in the build area.
Gas testing may fail if gas and gprofng tests are run in parallel.
I create a script to run gprofng. Inside this script, LD_LIBRARY_PATH,
GPROFNG_SYSCONFDIR are set.
putenv_libcollector_ld_misc() first uses $GPROFNG_PRELOAD_LIBDIRS to create
directories for SP_COLLECTOR_LIBRARY_PATH ($SP_COLLECTOR_LIBRARY_PATH is used
to set up LD_PRELOAD).
gprofng/ChangeLog
2024-01-19 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
PR gprofng/31252
PR gprofng/30808
* src/envsets.cc (putenv_libcollector_ld_misc): Use
$GPROFNG_PRELOAD_LIBDIRS first to build SP_COLLECTOR_LIBRARY_PATH.
* testsuite/config/default.exp: Create a script to run gprofng.
* testsuite/lib/display-lib.exp: Fix typo.
Mark Wielaard [Sun, 21 Jan 2024 23:47:46 +0000 (00:47 +0100)]
binutils: Fix calloc argument order in srconv.c
GCC 14 will warn about calling calloc with swapped size and count
arguments.
binutils/srconv.c: In function ‘nints’:
binutils/srconv.c:598:36: error: ‘xcalloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args]
598 | return (int *) (xcalloc (sizeof (int), x));
| ^~~
binutils/srconv.c:598:36: note: earlier argument should specify number of elements, later size of each element
Mark Wielaard [Sun, 21 Jan 2024 23:36:09 +0000 (00:36 +0100)]
binutils: Fix calloc argument order in coffgrok.c
GCC 14 will warn about calling calloc with swapped size and count
arguments.
binutils-gdb/binutils/coffgrok.c: In function ‘do_sections_p1’:
binutils-gdb/binutils/coffgrok.c:116:72: error: ‘xcalloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args]
116 | struct coff_section *all = (struct coff_section *) (xcalloc (sizeof (struct coff_section),
| ^~~~~~
binutils-gdb/binutils/coffgrok.c:116:72: note: earlier argument should specify number of elements, later size of each element
Mark Wielaard [Sun, 21 Jan 2024 23:12:45 +0000 (00:12 +0100)]
libsframe: Fix calloc argument order in dump_sframe_header
GCC14 warns about the order of the arguments to calloc
libsframe/sframe-dump.c: In function ‘dump_sframe_header’:
libsframe/sframe-dump.c:70:39: warning: ‘calloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
70 | flags_str = (char*) calloc (sizeof (char), SFRAME_HEADER_FLAGS_STR_MAX_LEN);
| ^~~~
libsframe/sframe-dump.c:70:39: note: earlier argument should specify number of elements, later size of each element
Fix this by swapping the size and count arguments.
libsframe/
* sframe-dump.c (dump_sframe_header): Swap arguments to calloc
Mark Wielaard [Sun, 21 Jan 2024 20:51:26 +0000 (21:51 +0100)]
opcodes: tic4x_disassemble swap xcalloc arguments
GCC 14 will detect when the size and count arguments of calloc are
swapped.
binutils-gdb/opcodes/tic4x-dis.c: In function ‘tic4x_disassemble’:
binutils-gdb/opcodes/tic4x-dis.c:710:32: error: ‘xcalloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args]
710 | optab = xcalloc (sizeof (tic4x_inst_t *), (1 << TIC4X_HASH_SIZE));
| ^~~~~~~~~~~~
binutils-gdb/opcodes/tic4x-dis.c:710:32: note: earlier argument should specify number of elements, later size of each element
binutils-gdb/opcodes/tic4x-dis.c:712:40: error: ‘xcalloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args]
712 | optab_special = xcalloc (sizeof (tic4x_inst_t *), TIC4X_SPESOP_SIZE);
| ^~~~~~~~~~~~
binutils-gdb/opcodes/tic4x-dis.c:712:40: note: earlier argument should specify number of elements, later size of each element
opcodes/ChangeLog:
* /tic4x-dis.c (tic4x_disassemble): Swap size and count xcalloc
arguments.
Tom Tromey [Wed, 10 Jan 2024 19:51:10 +0000 (12:51 -0700)]
Handle EOF more gracefully in DAP
A user pointed out that gdb will print a Python exception when it gets
an EOF in DAP mode. And, it turns out that an EOF like this also
causes gdb not to exit. This is due to the refactoring that moved the
JSON reader to its own thread -- previously this caused an exception
to propagate and cause an exit, but now it just leaves the reader
hung.
This patch fixes these problems by arranging to handle EOF more
gracefully.
Tom Tromey [Wed, 17 Jan 2024 11:29:59 +0000 (04:29 -0700)]
Fix handling of DW_OP_GNU_push_tls_address
In one spot, DW_OP_GNU_push_tls_address is handled differently from
DW_OP_form_tls_address. However, I think they should always be
treated identically.
Mark Wielaard [Mon, 22 Jan 2024 11:58:11 +0000 (12:58 +0100)]
sim: Fix -Werror=shadow=local by changing mem to addr in sim_{read,write}
m32c/cpu.h defines mem as enum value, which causes GCC 14 to emit
sim/m32c/gdb-if.c: In function ‘sim_read’:
sim/m32c/gdb-if.c:162:33: error: declaration of ‘mem’ shadows a previous local [-Werror=shadow=local]
162 | sim_read (SIM_DESC sd, uint64_t mem, void *buf, uint64_t length)
| ~~~~~~~~~^~~
In file included from ../../binutils-gdb/sim/m32c/gdb-if.c:38:
sim/m32c/cpu.h:83:3: note: shadowed declaration is here
83 | mem,
| ^~~
Fix this by renaming mem to addr in all sim_read and sim_write functions.
Most already used addr instead of mem. In one file, sim/rx/gdb-if.c, this
also meant renaming the local addr variable to vma.
Mark Wielaard [Sun, 21 Jan 2024 22:47:35 +0000 (23:47 +0100)]
sim: Fix some -Werror=shadow=compatible-local issues in aarch64/simulator.c
With GCC 14 -Werror=shadow=compatible-local flags the reuse of single
capital letters used in aarch64/cpustate.h enums
88 | expand_logical_immediate (uint32_t S, uint32_t R, uint32_t N)
| ~~~~~~~~~^
In file included from ../../binutils-gdb/sim/aarch64/aarch64-sim.h:27,
from ../../binutils-gdb/sim/aarch64/simulator.c:33:
217 | N = 1 << N_IDX
| ^
sim/aarch64/simulator.c: In function ‘expand_logical_immediate’:
sim/aarch64/simulator.c:88:60: error: declaration of ‘N’ shadows a previous local [-Werror=shadow=compatible-local]
sim/aarch64/cpustate.h:217:3: note: shadowed declaration is here
Mark Wielaard [Sun, 21 Jan 2024 22:52:50 +0000 (23:52 +0100)]
sim: Fix cc -Werror=shadow=local in cr16/simops.c
include/opcode/cr16.h defines cc as an enum value, which causes GCC 14
to warn
sim/cr16/simops.c: In function ‘cond_stat’:
sim/cr16/simops.c:138:26: error: declaration of ‘cc’ shadows a previous local [-Werror=shadow=local]
138 | static int cond_stat(int cc)
| ~~~~^~
In file included from ../../binutils-gdb/sim/cr16/cr16-sim.h:26,
from ../../binutils-gdb/sim/cr16/simops.c:39:
sim/../include/opcode/cr16.h:149:3: note: shadowed declaration is here
149 | cc,
| ^~
Guinevere Larsen [Thu, 14 Dec 2023 09:52:29 +0000 (10:52 +0100)]
gdb/testsuite: relax filename restriction in some gdb.btrace tests
The test gdb.btrace/tailcall.exp has multiple tests that include the
filename in the output. When testing with gcc, only a relative path is
printed, but when using clang, the full file path is printed instead.
This makes most of those tests fail, with the exception of "record goto
4" which allows for more characters before the file name. The test
gdb.btrace/recod_goto.exp suffers with the same issue
This commit allows for text before the filename. However, instead of how
the aforementioned "record goto 4", it uses a regexp that doesn't allow
for newlines, just in case some off output happens.
Guinevere Larsen [Wed, 20 Dec 2023 11:46:42 +0000 (12:46 +0100)]
gdb/testsuite: modernize gdb.dwarf2/dw2-noloc.exp
The test gdb.dwarf2/dw2-noloc.exp predates the dwarf assembler, and uses
some unreliable assumptions about where global labels get put.
Specifically, when using clang to compile the test, both labels it uses
to gauge the adresses of the main function get reshuffled to be side-by-side,
and the debug information ends up making it look like main's high pc is equal
to low pc, meaning we never enter the main function's scope, and that leads to
22 failures because the "main_*" variables are technically never in scope.
This patch modernizes the aforementioned test to use the dwarf
assembler, which removes all failures when using clang. It also renames
the .c file to be more inline with current standard.
Xi Ruoyao [Fri, 19 Jan 2024 16:38:24 +0000 (00:38 +0800)]
LoongArch: Fix some test failures about TLS desc and TLS relaxation
There are two issues causing 11 test failures:
1. The TLS desc tests are matching the entire disassemble of a linked
executable. But if ld is configured --enable-default-hash-style=gnu
(note that most modern distros use this option), the layout of the
linked executables will be different and the immediate operands in
the linked executables will also be different. So we add
"--hash-style=both" for these tests to cancel the effect of
--enable-default-hash-style=gnu, like [x86_64 mark-plt tests].
2. By default objdump disassemble uses [pseudo-instructions] so "addi.w"
is outputed as "li.w", causing mismatches in TLS relaxation tests.
We can turn off the pseudo-instruction usage in objdump using "-M
no-aliases" to fix them.
Jan Beulich [Mon, 22 Jan 2024 07:52:30 +0000 (08:52 +0100)]
x86/APX: also amend the PUSH2/POP2 testcase
Commit f530d5f1bab6 ("Update x86/APX: VROUND{P,S}{S,D} can generally be
encoded") took care of only half of the remaining issue. Add #pass here
as well.
gdb/record: print frame information when exiting a recursive call
Currently, when GDB is reverse stepping out of a function into the same
function due to a recursive call, it doesn't print frame information, as
reported by PR record/29178. This happens because when the inferior
leaves the current frame, GDB decides to refresh the step information,
clobbering the original step_frame_id, making it impossible to figure
out later on that the frame has been changed.
This commit changes GDB so that, if we notice we're in this exact
situation, we won't refresh the step information.
Because of implementation details, this change can cause some debug
information to be read when it normally wouldn't before, which showed up
as a regression on gdb.dwarf2/dw2-out-of-range-end-of-seq. Since that
isn't a problem, the test was changed to allow for the new output.
Although there is nothing wrong with this change in principle, it
happens to break most of the tests in gdb/testsuite/gdb.rocm/*.exp.
This is because those tests do rely on GDB not loading debug
information. This is necessary because the debug information produced
for AMDGPU code is using DWARF extensions which are not supported by GDB
at this point.
In this patch, I propose to use a lazy loading mechanism so the frame_id
for the current frame is only computed when required instead of when
entering process_event_stop_test. The lazy_loader class is currently
defined locally in infrun.c, but if it turns out to be useful elsewhere,
it could go somewhere under gdbsupport.
Another approach could have been to revert fb84fbf8a51f5be2e78765508ebd9753af96b492 (gdb/infrun: simplify
process_event_stop_test) and adjust the implementation of bf2813aff8f2988ad3d53e819a0415abf295c91f (gdb/record: print frame
information when exiting a recursive call). However, I think that the
lazy loading works well with the simplification done recently, so I went
down that route.
Regression tested on x86_64-linux (Ubuntu 22.04) with AMDGPU support.
Change-Id: Ib63a162128130d1786a77c98623e9e3dcbc363b7 Approved-by: Kevin Buettner <kevinb@redhat.com>
Simon Marchi [Fri, 19 Jan 2024 20:32:32 +0000 (15:32 -0500)]
gdb: remove SYMBOL_*_OPS macros
Remove SYMBOL_BLOCK_OPS, SYMBOL_COMPUTED_OPS and SYMBOL_REGISTER_OPS, in
favor of methods on struct symbol. More changes could be done here to
improve the design and make things safer, but I just wanted to do a
straightforward change to remove the macros for now.
Change-Id: I27adb74a28ea3c0dc9a85c2953413437cd95ad21 Reviewed-by: Kevin Buettner <kevinb@redhat.com>
Tom Tromey [Mon, 15 Jan 2024 01:21:42 +0000 (18:21 -0700)]
Simplify DWARF symtab inclusion handling
In the past, dwarf2_per_cu_data was allocated using malloc, so special
handling was needed for the vector used for symtab handling. We
changed this to use 'new' a while back, so this code can now be
greatly simplified.
Regression tested on x86-64 Fedora 38.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Andrew Burgess [Fri, 29 Dec 2023 09:50:10 +0000 (09:50 +0000)]
gdb: remove deprecated_exec_file_display_hook and associated code
This commit removes deprecated_exec_file_display_hook and the
associated specify_exec_file_hook.
The specify_exec_file_hook is used to add a new hook function to
deprecated_exec_file_display_hook, but is only used from the insight
debugger.
I posted a patch to remove the use of specify_exec_file_hook from
insight, and instead use gdb::observers::executable_changed, this
patch can be found here (it has now been merged):
Сергей Чернов [Fri, 19 Jan 2024 18:01:18 +0000 (11:01 -0700)]
Fix remote serial read
After closing "Bug 30770 - serial.c does not preserve errno correctly"
https://sourceware.org/bugzilla/show_bug.cgi?id=30770
remote debugging became impossible due to an attempt to recv() by a call intended for the socket, and not for the character device file. The
documentation implicitly states that it is possible to use the read() call to work with a socket. But this does not mean in the general case that it is
permissible to use recv in the case of a non-socket.
libc:
ldd (Ubuntu GLIBC 2.38-1ubuntu6) 2.38
kernel:
Linux klen-dev-um790pro 6.5.0-14-generic #14-Ubuntu SMP PREEMPT_DYNAMIC Tue Nov 14 14:59:49 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
gdb: build from trank at 15.0.50.20231226-git
GDB output:
$ arm-kgp-eabi-gdb
GNU gdb (Klen's_GNU_package_(KGP)_for_target::arm-kgp-eabi<rmprofile/lto>_host::x86_64-kgp-linux-gnu_znver4-avx512<<ílex>>)
15.0.50.20231226-git
....
(gdb) tar ext /dev/ttyACM1
Remote debugging using /dev/ttyACM1
Remote communication error. Target disconnected: error while reading: Socket operation on non-socket.
(gdb)
after fix gdb work fine
$ arm-kgp-eabi-gdb -q
(gdb) tar ext /dev/ttyACM0
Remote debugging using /dev/ttyACM0
(gdb) mon swd
Target voltage: 0.0V
Available Targets:
No. Att Driver
STM32F40x M4
(gdb) att 1
Attaching to Remote target
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0x08020c80 in ?? ()
(gdb)
Aaron Merey [Fri, 19 Jan 2024 16:20:19 +0000 (11:20 -0500)]
gdb/ui-out.h: Fix exception handling in do_with_buffered_output
Replace throw with throw_exeception in do_with_buffered_output.
This patch fixes regressions in gdb.dwarf2/dw2-dir-file-name.exp
caused by commit 519d63439.
do_with_buffered_output needs to use throw_exception instead of
throw to ensure that exceptions of the correct type are thrown.
If using throw, gdb_exception_error may be wrongly converted into
gdb_exception during print_frame_info. This prevents the exception
from being caught in print_stack_frame.
Tom de Vries [Fri, 19 Jan 2024 16:40:03 +0000 (17:40 +0100)]
[gdb/testsuite] Update xfail in gdb.threads/attach-many-short-lived-threads.exp
With test-case gdb.threads/attach-many-short-lived-threads.exp, I run into:
...
(gdb) attach 7773^M
Attaching to program: attach-many-short-lived-threads, process 7773^M
Cannot attach to lwp 7776: Operation not permitted (1)^M
(gdb) PASS: $exp: iter 1: attach
info threads^M
No threads.^M
(gdb) PASS: $exp: iter 1: no new threads
set breakpoint always-inserted on^M
(gdb) PASS: $exp: iter 1: set breakpoint always-inserted on
break break_fn^M
Breakpoint 1 at 0x400b4d: file attach-many-short-lived-threads.c, line 57.^M
(gdb) PASS: $exp: iter 1: break break_fn
continue^M
The program is not being run.^M
(gdb) FAIL: $exp: iter 1: break at break_fn: 1 \
(the program is no longer running)
...
There's some code in the test-case dealing with a similar warning:
...
-re "warning: Cannot attach to lwp $decimal: Operation not permitted" {
...
But since commit c6f7f9c80c3 ("Bail out of "attach" if a thread cannot be
traced"), the warning has been changed into an error.
Fix the FAIL by updating the test-case to expect an error instead of a
warning.
projects / thirdparty / binutils-gdb.git / log
