Simon Marchi [Thu, 21 Dec 2023 16:32:55 +0000 (16:32 +0000)]
gdb: implement address_from_register using value_from_register
As explained in the comment removed by the previous commit "gdb: pass
non-nullptr frame to gdbarch_value_from_register in
address_from_register", address_from_register copies some implementation
bits from value_from_register:
/* This routine may be called during early unwinding, at a time
where the ID of FRAME is not yet known. Calling value_from_register
would therefore abort in get_frame_id. However, since we only need
a temporary value that is never used as lvalue, we actually do not
really need to set its VALUE_NEXT_FRAME_ID. Therefore, we re-implement
the core of value_from_register, but use the null_frame_id. */
This is no longer relevant, since we now create a value with a valid next
frame id, so change address_from_register to use value_from_register.
Change-Id: I189bd96f28735ed9f47750ffd73764c459ec6f43
Simon Marchi [Thu, 21 Dec 2023 16:28:19 +0000 (16:28 +0000)]
gdb: remove read_frame_register_value's frame parameter
By now, all register struct values should have a valid next frame id
(assuming they are created using value::allocate_register or
value::allocate_register_lazy), so there should be no need to pass a
frame alongside the value to read_frame_register_value. Remove the
frame parameter and adjust read_frame_register_value accordingly.
While at it, make read_frame_register_value static, it's only used in
findvar.c.
Change-Id: I118959ef8c628499297c67810916e8ba9934bfac
Simon Marchi [Thu, 21 Dec 2023 16:21:52 +0000 (16:21 +0000)]
gdb: add type parameter to value::allocate_register and add value::allocate_register_lazy
Some places that create register struct values don't use register_type
to obtain the value type. This prevents them from using the current
version of value::allocate_register. One spot (value_of_register_lazy)
also creates a lazy register value.
Add a value::allocate_register_lazy method. Add some type parameters
to value::allocate_register and value::allocate_register_lazy, to let
the caller specify the type to use for the value. The parameters
default to nullptr, in which case we use register_type to obtain the
type.
Change-Id: I640ec0a5a0f4a55eba12d515dbfd25933229f8ec
Simon Marchi [Thu, 21 Dec 2023 16:10:17 +0000 (16:10 +0000)]
gdb: pass non-nullptr frame to gdbarch_value_from_register in address_from_register
address_from_register used to pass null_frame_id to
gdbarch_value_from_register as "this frame"'s id, because it's possible
for it to be called during unwind, when "this frame"'s id is not yet
known. This create an oddity where those register struct values are
created without a valid next frame id. I would much prefer for things
to be consistent and have all register struct values to have a valid
next frame id.
Since gdbarch_value_from_register takes a frame_info_ptr now, rather
than a frame_id, we can pass down "this frame", even if it doesn't have
a valid id. gdbarch_value_from_register implementations can obtain the
next frame from it.
However, it's possible for the "this frame"'s next frame to be an
inline frame, inlined in "this frame", in which case that next frame's
id is also not known. So, loop until we get to the next non-inline
frame (which is actually the frame where registers for "this frame" are
unwound from). This is the same thing that we do in
value_of_register_lazy, for the same reason. A later patch will factor
out this "while next frame is inline" loop to apply it to all register
struct values, so this is somewhat temporary.
Change-Id: If487c82620cc5a4a4ea5807f0a0bad80ab984078
Simon Marchi [Thu, 21 Dec 2023 16:03:02 +0000 (16:03 +0000)]
gdb: pass frame_info_ptr to gdbarch_value_from_register
Pass a frame_info_ptr rather than a frame_id. This avoids having to do
a frame lookup on the callee side, when we can just pass the frame down
directly.
I think this fixes a bug in rs6000-tdep.c where the id of the wrong
frame was set to `VALUE_NEXT_FRAME_ID (v)`.
Change-Id: I77039bc87ea8fc5262f16d0e1446515efa21c565
Simon Marchi [Wed, 20 Dec 2023 18:18:47 +0000 (18:18 +0000)]
gdb: don't set frame id after calling cooked_read_value
I don't think that setting the next frame id is needed there, all code
paths in cooked_read_value do set it properly, AFAIK.
Change-Id: Idb9d9e6f89c2c95c5ebfeec2a63fde89ed84cf3d
Mike Frysinger [Sun, 24 Dec 2023 10:26:44 +0000 (05:26 -0500)]
sim: cris: rvdummy: delete unused variable
Mike Frysinger [Sun, 24 Dec 2023 10:06:57 +0000 (05:06 -0500)]
sim: cgen: mark cgen_rtx_error noreturn
Since this function never returns, mark it as such to fix some unused
variable warnings in error code paths.
For example, cris triggers:
sim/cris/semcrisv10f-switch.c:3558:11: error:
variable 'tmp_newval' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
Even though it has an "else" path that calls this error function.
Mike Frysinger [Sun, 24 Dec 2023 09:07:32 +0000 (04:07 -0500)]
sim: cgen: regenerate decode tables
Integrate some changes from upstream cgen that tightened up the
generated output. Shouldn't be any functional changes here.
Mike Frysinger [Sun, 24 Dec 2023 08:59:02 +0000 (03:59 -0500)]
sim: sh: refine pwsb & pwad nops
Since these insns don't do anything and are effectively ignored,
return early to avoid doing any common processing at the end as
that requires initializing variables like "res" with something.
Mike Frysinger [Sun, 24 Dec 2023 08:53:03 +0000 (03:53 -0500)]
sim: sh: fix plds Dz,MACL implementation
The plds Dz,MACL insn stores the Dz bit into MACL. The current code
was storing the "res" variable into Dz and then into MACL, but not
setting "res" to anything. Delete that logic and make it match the
existing plds Dz,MACH insn.
GDB Administrator [Sun, 24 Dec 2023 00:00:11 +0000 (00:00 +0000)]
Automatic date update in version.in
Mike Frysinger [Sat, 23 Dec 2023 06:00:08 +0000 (01:00 -0500)]
sim: warnings: rework individual flag disable into dedicated vars
The -Wshadow=local is too new for some compilers, so move it to a var
that we test at configure time.
Vladimir Mezentsev [Fri, 22 Dec 2023 05:33:58 +0000 (21:33 -0800)]
gprofng: fix build problems on linux-musl
ino64_t, off64_t, fpos64_t, stat64, __u64 are not defined on linux-musl.
Fixed by declaring these types for linux-musl.
2023-12-21 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
PR gprofng/30779
PR gprofng/29593
* common/gp-defs.h: Define ino64_t, off64_t, fpos64_t for linux-musl.
* libcollector/unwind.c: Define __u64 for linux-musl.
* src/util.h: Define dbe_stat_t.
* src/ClassFile.cc: Use dbe_stat_t instead of "struct stat64".
* src/Dbe.cc: Likewise.
* src/DbeFile.cc: Likewise.
* src/DbeFile.h: Likewise.
* src/DbeSession.cc: Likewise.
* src/Experiment.cc: Likewise.
* src/checks.cc: Likewise.
* src/util.cc: Likewise.
Mike Frysinger [Fri, 22 Dec 2023 01:14:34 +0000 (20:14 -0500)]
sim: sh: fix -Wshadow=local warnings
Rename the var to avoid shadowing & clobbering the higher context.
Mike Frysinger [Fri, 22 Dec 2023 01:13:56 +0000 (20:13 -0500)]
sim: riscv: fix -Wshadow=local warnings
Inline the one usage of sd in these macros to avoid possible shadowing.
Mike Frysinger [Fri, 22 Dec 2023 01:13:19 +0000 (20:13 -0500)]
sim: ppc: fix -Wshadow=local warnings
Use a local name in the macro to avoid shadowing wherever it's used.
Mike Frysinger [Fri, 22 Dec 2023 01:12:59 +0000 (20:12 -0500)]
sim: mips: fix -Wshadow=local warnings
Delete redundant decls when the existing scope has the same var and
type available for use.
Mike Frysinger [Fri, 22 Dec 2023 01:12:25 +0000 (20:12 -0500)]
sim: m68hc11: fix -Wshadow=local warnings
Delete redundant decls when the existing scope has the same var and
type available for use.
Mike Frysinger [Fri, 22 Dec 2023 23:05:50 +0000 (18:05 -0500)]
sim: m32c: fix -Wshadow=local warnings
These decoders declare a lot of common variables for use by substeps,
and then shadows a few because of how the opc generator is implemented.
Easiest way around it is to rename the per-substep vars as needed as
anything more would require substantial changes to the opc logic.
Mike Frysinger [Fri, 22 Dec 2023 01:10:58 +0000 (20:10 -0500)]
sim: iq2000: fix -Wshadow=local warnings
Delete redundant decls.
Mike Frysinger [Fri, 22 Dec 2023 01:10:20 +0000 (20:10 -0500)]
sim: h8300: fix -Wshadow=local warnings
Delete conflicting decls when the existing scope has vars of the same
name & type for this exact use.
Mike Frysinger [Fri, 22 Dec 2023 01:09:50 +0000 (20:09 -0500)]
sim: frv: fix -Wshadow=local warnings
Delete redundant decls, and rename conflicting vars.
Mike Frysinger [Fri, 22 Dec 2023 01:09:00 +0000 (20:09 -0500)]
sim: erc32: fix -Wshadow=local warnings
Rename shadowed vars with different types to avoid confusion.
Mike Frysinger [Sat, 23 Dec 2023 04:17:45 +0000 (23:17 -0500)]
sim: cris: disable -Wshadow=local in generated mloop files
The mloop files include CGEN generated switch files which have some
nested assignments that expand into repeated shadowed variables.
Fixing this looks fairly non-trivial as it appears to be interplay
between the common CGEN code and how this particular set of cris
insns are defined. Disable the warning instead.
In file included from sim/cris/mloop.in:286:
sim/cris/semcrisv10f-switch.c: In function ‘crisv10f_engine_run_full’:
sim/cris/semcrisv10f-switch.c:12383:8: error: declaration of ‘opval’ shadows a previous local [-Werror=shadow=local]
12383 | SI opval = tmp_addr;
| ^~~~~
sim/cris/semcrisv10f-switch.c:12371:9: note: shadowed declaration is here
12371 | USI opval = ({ SI tmp_addr;
| ^~~~~
And the code looks like:
USI opval = ({
...
{
SI opval = tmp_addr;
...
}
...
});
Since the CGEN code treats "opval" as an internal variable that the cpu
definitions don't have direct access to, the likelihood of this being a
real bug is low, so leave it be. The warning is suppressed for more code
that is hand written (e.g. the mloop logic), but disabling for the entire
file is the easiest way to suppress while keeping it on everywhere else in
the sim.
Mike Frysinger [Fri, 22 Dec 2023 01:08:35 +0000 (20:08 -0500)]
sim: cris: fix -Wshadow=local warnings
Delete redundant local decls.
Mike Frysinger [Fri, 22 Dec 2023 01:07:48 +0000 (20:07 -0500)]
sim: common: fix -Wshadow=local warnings
Rename shadowed vars with different types, and delete redundant decls.
Mike Frysinger [Fri, 22 Dec 2023 01:07:00 +0000 (20:07 -0500)]
sim: bfin: fix -Wshadow=local warnings
Rename the shadowed var to avoid confusion with the function argument
as to which address this code is using.
Mike Frysinger [Fri, 22 Dec 2023 01:03:41 +0000 (20:03 -0500)]
sim: arm: fix -Wshadow=local warnings
Remove duplicate nested variable declarations, rename some to avoid
confusion when the type is different or the original value should be
retained, and fix some weirdness with nested enums in structs.
Mike Frysinger [Fri, 22 Dec 2023 01:01:31 +0000 (20:01 -0500)]
sim: aarch64: fix -Wshadow=local warnings
These functions have local vars named "val" of type float, and
then create nested vars named "val" of type double. This is a
bit confusing and causes build time warnings.
GDB Administrator [Sat, 23 Dec 2023 00:00:21 +0000 (00:00 +0000)]
Automatic date update in version.in
Tom Tromey [Tue, 12 Dec 2023 15:20:31 +0000 (08:20 -0700)]
Check for rogue DAP exceptions in test suite
This changes the test suite to look for rogue DAP exceptions in the
log file, and issue a "fail" if one is found.
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
Tom Tromey [Tue, 12 Dec 2023 17:09:55 +0000 (10:09 -0700)]
Avoid exception from attach in DAP
I noticed that the DAP attach test case (and similarly
remoted-dap.exp) had a rogue exception stack trace in the log. It
turns out that an attach will generate a stop that does not have a
reason.
This patch fixes the problem in the _on_stop event listener by making
it a bit more careful when examining the event reason. It also adds
some machinery so that attach stops can be suppressed, which I think
is the right thing to do.
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
Tom Tromey [Tue, 12 Dec 2023 16:30:41 +0000 (09:30 -0700)]
Add DAP log level parameter
This adds a new parameter to control the DAP logging level. By
default, "expected" exceptions are not logged, but the parameter lets
the user change this when more logging is desired.
This also changes a couple of spots to avoid logging the stack trace
for a DAPException.
This patch also documents the existing DAP logging parameter. I
forgot to document this before.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
Tom Tromey [Tue, 12 Dec 2023 16:29:43 +0000 (09:29 -0700)]
Introduce and use DAPException
This introduces a new DAPException class, and then changes various
spots in the DAP implementation to wrap "expected" exceptions in this.
This class will help detect rogue exceptions caused by bugs in the
implementation.
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
Tom Tromey [Mon, 11 Dec 2023 17:04:23 +0000 (10:04 -0700)]
Fix build with clang 16
clang 16 reports a missing declaration in new-op.cc. We believed
these operators to be declared starting with C++14, but apparently
that is not the case.
This patch reverts the earlier change and then updates the comment to
reflect the current state.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31141
Kévin Le Gouguec [Fri, 22 Dec 2023 13:06:15 +0000 (14:06 +0100)]
gdb: fix refactoring hiccup in rs6000_register_to_value
In 2023-12-14 "gdb: make get_frame_register_bytes take the next frame"
(
9fc79b42369), *_register_to_value functions were made to (a) call
get_next_frame_sentinel_okay (frame) (b) pass that next frame to
get_frame_register_bytes.
Step (b) was omitted for rs6000-tdep.c; this manifests as a regression on
PPC platforms for e.g. O2_float_param: instead of seeing…
Temporary breakpoint 1, callee.increment (val=val@entry=99.0, msg=...) at callee.adb:19
… we get "optimized_out" for val. Passing next_frame to
get_frame_register_bytes fixes the issue.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Thu, 7 Dec 2023 16:51:52 +0000 (09:51 -0700)]
Add 'program' to DAP 'attach' request
In many cases, it's not possible for gdb to discover the executable
when a DAP 'attach' request is used. This patch lets the IDE supply
this information.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Mike Frysinger [Fri, 22 Dec 2023 15:53:49 +0000 (10:53 -0500)]
sim: cgen: regenerate decode tables to avoid shadow warnings
Use latest cgen to regenerate the decode tables which has some shadow
warning fixes with "val" variables.
Mike Frysinger [Thu, 21 Dec 2023 04:29:16 +0000 (23:29 -0500)]
sim: cris: regen cgen decoders to fix build warnings [PR sim/31181]
Bug: https://sourceware.org/PR31181
Guinevere Larsen [Tue, 16 May 2023 14:25:53 +0000 (16:25 +0200)]
gdb: add git trailer information on gdb/MAINTAINERS
The project has been using Tested-By (tb), Reviewed-By (rb) and
Approved-By (ab) for some time, but there has been no information to be
found in the actual repository. This commit changes that by adding
information about all git trailers to the MAINTAINERS file, so that it
can be easily double-checked. Simply put, the trailers in use work as
follows:
* Tested-by: The person tested the patch and it fixes the problem, or
introduces no regressions (or both).
* Acked-by: The general outline looks good, but the maintainer hasn't
looked at the code
* Reviewed-by: The code looks good, but the reviewer has not approved
the patch to go upstream
* Approved-by: The patch is ready to be pushed to master
These last 3 trailers can also be restricted to one or more areas of GDB
by adding the areas in a comma separated list in parenthesis after the
trailers.
Finally, for completeness sake, the trailers Co-Authored-By and Bug
were added, even though they have been in use for a long time already
Reviewed-By: Kevin Buettner <kevinb@redhat.com>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Approved-By: John Baldwin <jhb@FreeBSD.org>
Jan Beulich [Fri, 22 Dec 2023 08:36:13 +0000 (09:36 +0100)]
nios2: fix .text/.data interaction with .previous
Just like obj_elf_section() is called for .section, obj_elf_{text,data}()
need calling for .text/.data.
Jan Beulich [Fri, 22 Dec 2023 08:35:52 +0000 (09:35 +0100)]
hppa/ELF: fix .text/.data interaction with .previous
For some ELF targets .text/.data are overridden. In that case
obj_elf_{text,data}() need calling, just like .code vectors to that
function for the remaining ELF targets.
While there also hand on the function arguments, even if right now
they're meaningless. This matches what other targets' code does.
Jan Beulich [Fri, 22 Dec 2023 08:35:02 +0000 (09:35 +0100)]
RISC-V: drop .bss override
It doesn't look to be a good idea to override the custom handler that
ELF has; afaict doing so broke .previous, and a sub-section specifier
wasn't accepted either.
Jan Beulich [Fri, 22 Dec 2023 08:34:10 +0000 (09:34 +0100)]
x86-64: refuse "high" 8-bit regs with .insn and VEX/XOP/EVEX encodings
Much like REX, those encodings - if permitting 8-bit regs at all, i.e.
only starting with APX - permit use of "new" 8-bit registers only. %ah,
%ch, %dh, and %bh cannot be encoded and hence should be rejected.
Permit their use outside of 64-bit code though, as "new" registers
simply don't exist there.
Jan Beulich [Fri, 22 Dec 2023 08:33:12 +0000 (09:33 +0100)]
x86: properly respect rex/{rex}
This addresses two issues: For one, a user specified "rex" did not cause
the diagnostic to trigger when there was no other need for a REX prefix;
instead, another than the specified insn+operands was encoded. And then
(which is what this started from) .insn didn't respect {rex} (and was
otherwise similarly flawed as ordinary insns).
The latter requires splitting out code from md_assemble(), for it to
become re-usable. Besides the addition to address the first issue, that
code then also needs generalizing to account for immediate operands, as
with .insn we can't make assumptions anymore on all respective templates
having at most two operands (we still can build upon there being at most
two non-immediate operands, though). While moving the code also simplify
the first if(), by folding redundant checks.
In the new testcase also test a few more things which afaics weren't
tested till now.
mengqinggang [Fri, 8 Dec 2023 07:15:50 +0000 (15:15 +0800)]
LoongArch: Add support for the third expression of .align for R_LARCH_ALIGN
If the symbol index is not zero, the addend is used to represent
the first and the third expressions of the .align.
The lowest 8 bits are used to represent the first expression.
Other bits are used to represent the third expression.
The addend of R_LARCH_ALIGN for ".align 5, ,4" is 0x405.
The addend of R_LARCH_ALIGN for ".balign 32, ,4" is 0x405.
Mike Frysinger [Fri, 22 Dec 2023 02:04:44 +0000 (21:04 -0500)]
sim: ppc: igen: fix -G handling
We weren't using the enable_p flag to see whether the option should
be enabled or disabled, and we weren't breaking out when done parsing.
Mike Frysinger [Fri, 22 Dec 2023 01:59:04 +0000 (20:59 -0500)]
sim: warnings: enable -Wreturn-type
Older versions of gcc support this warning flag. We're already clean.
Mike Frysinger [Fri, 22 Dec 2023 01:58:51 +0000 (20:58 -0500)]
sim: warnings: fix -Wreturn-mismatch typo
Mike Frysinger [Fri, 22 Dec 2023 01:11:34 +0000 (20:11 -0500)]
sim: m32c: fix initial #line number in generated code
This emits #line 2 for the first line in the output when it should be 1.
Mike Frysinger [Wed, 20 Dec 2023 01:13:22 +0000 (20:13 -0500)]
sim: mloop: add #line pragmas everywhere
This will make compiler diagnostics much better with generated code
so people can understand the original source file.
Mike Frysinger [Wed, 20 Dec 2023 01:04:34 +0000 (20:04 -0500)]
sim: common: add $LINENO rewriting support to genmloop scripts
The generated mloop files can trigger compile time warnings. It can
be difficult to see/understand where the original code is coming from
as all the diagnostics point to the generated output. Using #line
pragmas, we can point people to the original source files.
Unfortunately, this code is written in POSIX shell, and that lacks
support for line number tracking. The $LINENO variable, even when
available, can just be plain wrong. For example, when using dash
and subshells, $LINENO can end up having negative values. Add a
wrapper script that will uses awk to rewrite the $LINENO variable
to the right value to avoid all that.
Basically lineno.sh takes an input script, rewrites all uses of
$LINENO into the actual line number (and $0 into the original file
name), and then executes the temporary script.
This commit doesn't actually add #line pragmas to any files. That
comes next.
GDB Administrator [Fri, 22 Dec 2023 00:00:19 +0000 (00:00 +0000)]
Automatic date update in version.in
Tom Tromey [Fri, 8 Dec 2023 17:32:07 +0000 (10:32 -0700)]
Rename TUI locator window -> status
The TUI status window is called the "locator" in the source, but
"status" in the documentation. Whenever I've needed to find the code,
I've had to search to "locate" it (ha, ha). This patch renames the
window to match the public name of the window.
Tom Tromey [Fri, 8 Dec 2023 17:14:41 +0000 (10:14 -0700)]
Rename tui-stack -> tui-status
The TUI status line is called the "status" window in the
documentation, but not in the source. There, the relevant files are
named "tui-stack", which to me makes it sound like they have something
to do with backtraces. This patch renames them to "tui-status".
Rainer Orth [Thu, 21 Dec 2023 11:51:26 +0000 (12:51 +0100)]
ld: Add lib32 directories for 32-bit emulation on FreeBSD/amd64
GNU ld currently fails to link 32-bit executables on FreeBSD/amd64 when
the linked libraries have dependencies on shared objects themselves:
$ gcc -m32 -o ei ei.c -lexecinfo
/var/gcc/binutils/amd64/lib/gcc/amd64-pc-freebsd14.0/13.2.0/../../../../amd64-pc-freebsd14.0/bin/ld:
warning: libelf.so.2, needed by /usr/lib/../lib32/libexecinfo.so, not found
(try using -rpath or -rpath-link)
/var/gcc/binutils/amd64/lib/gcc/amd64-pc-freebsd14.0/13.2.0/../../../../amd64-pc-freebsd14.0/bin/ld:
/usr/lib/../lib32/libexecinfo.so: undefined reference to `elf_begin@R1.0'
[...]
Fixed by handling FreeBSD/amd64 like Linux/x86.
Tested on amd64-pc-freebsd14.0.
Pedro Alves [Thu, 21 Dec 2023 10:43:20 +0000 (10:43 +0000)]
Fix Clang build issue with flexible array member and non-trivial dtor
Commit
d5cebea18e7a ("Make cached_reg_t own its data") added a
destructor to cached_reg_t.
That caused a build problem with Clang, which errors out like so:
> CXX python/py-unwind.o
> gdb/python/py-unwind.c:126:16: error: flexible array member 'reg' of type 'cached_reg_t[]' with non-trivial destruction
> 126 | cached_reg_t reg[];
> | ^
This is is not really a problem for our code, which allocates the
whole structure with xmalloc, and then initializes the array elements
with in-place new, and then takes care to call the destructor
manually. Like, commit
d5cebea18e7a did:
@@ -928,7 +927,7 @@ pyuw_dealloc_cache (frame_info *this_frame, void *cache)
cached_frame_info *cached_frame = (cached_frame_info *) cache;
for (int i = 0; i < cached_frame->reg_count; i++)
- xfree (cached_frame->reg[i].data);
+ cached_frame->reg[i].~cached_reg_t ();
Maybe we should get rid of the flexible array member and use a bog
standard std::vector. I doubt this would cause any visible
performance issue.
Meanwhile, to unbreak the build, this commit switches from C99-style
flexible array member to 0-length array. It behaves the same, and
Clang doesn't complain. I got the idea from here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70932#c11
GCC 9, our oldest support version, already supported this:
https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Zero-Length.html
but the extension is actually much older than that. Note that
C99-style flexible array members are not standard C++ either.
Change-Id: I37dda18f367e238a41d610619935b2a0f2acacce
Mike Frysinger [Thu, 21 Dec 2023 06:40:10 +0000 (01:40 -0500)]
sim: warnings: enable -Wimplicit-fallthrough=5
It caught some legitimate bugs, so clearly it's helpful.
Mike Frysinger [Thu, 21 Dec 2023 06:39:26 +0000 (01:39 -0500)]
sim: sh: fix -Wimplicit-fallthrough warnings
These generate conditional insns where it tests, then fallsthru.
Mike Frysinger [Thu, 21 Dec 2023 06:38:33 +0000 (01:38 -0500)]
sim: rx: fix -Wimplicit-fallthrough warnings
Replace some fall through comments with the attribute.
Mike Frysinger [Thu, 21 Dec 2023 06:35:57 +0000 (01:35 -0500)]
sim: rl78: fix -Wimplicit-fallthrough warnings
Seems like this code was meant to fallthru.
Mike Frysinger [Thu, 21 Dec 2023 06:35:41 +0000 (01:35 -0500)]
sim: riscv: fix -Wimplicit-fallthrough warnings
Mike Frysinger [Thu, 21 Dec 2023 06:35:29 +0000 (01:35 -0500)]
sim: ppc: fix -Wimplicit-fallthrough warnings
Replace some fall through comments with the attribute.
Mike Frysinger [Thu, 21 Dec 2023 06:35:14 +0000 (01:35 -0500)]
sim: or1k: fix -Wimplicit-fallthrough warnings
Replace some fall through comments with the attribute.
Mike Frysinger [Thu, 21 Dec 2023 06:34:54 +0000 (01:34 -0500)]
sim: mips: fix -Wimplicit-fallthrough warnings
Seems like these cases were meant to fallthru.
Mike Frysinger [Thu, 21 Dec 2023 06:34:13 +0000 (01:34 -0500)]
sim: mcore: fix Wimplicit-fallthrough warnings
Seems like these decodes were intended to fallthru.
Mike Frysinger [Thu, 21 Dec 2023 06:33:32 +0000 (01:33 -0500)]
sim: m68hc11: fix -Wimplicit-fallthrough warnings
Seems like these register operations intended on falling thru.
Mike Frysinger [Thu, 21 Dec 2023 06:32:22 +0000 (01:32 -0500)]
sim: frv: fix -Wimplicit-fallthrough warnings
Replace some fall through comments with the attribute.
Mike Frysinger [Thu, 21 Dec 2023 06:31:38 +0000 (01:31 -0500)]
sim: erc32: fix -Wimplicit-fallthrough warnings
Add the attribute where it seems to make sense.
Mike Frysinger [Thu, 21 Dec 2023 06:54:31 +0000 (01:54 -0500)]
sim: cris: fix -Wimplicit-fallthrough warnings
Replace some fall through comments with the attribute.
Mike Frysinger [Thu, 21 Dec 2023 06:29:21 +0000 (01:29 -0500)]
sim: bfin: fix -Wimplicit-fallthrough warnings
Add the attribute to places where we want to fall thru.
Mike Frysinger [Thu, 21 Dec 2023 06:28:52 +0000 (01:28 -0500)]
sim: avr: fix -Wimplicit-fallthrough warnings
Replace some fall through comments with the attribute.
Mike Frysinger [Thu, 21 Dec 2023 06:28:16 +0000 (01:28 -0500)]
sim: arm: fix -Wimplicit-fallthrough warnings
Replace some fall through comments with the attribute.
Mike Frysinger [Thu, 21 Dec 2023 06:25:50 +0000 (01:25 -0500)]
sim: aarch64: fix -Wimplicit-fallthrough warnings
Replace some fall through comments with the attribute, and add some
default abort calls when the compiler can't figure out that the set
of values were already fully enumerated in the switch statement.
Mike Frysinger [Thu, 21 Dec 2023 06:29:53 +0000 (01:29 -0500)]
sim: common: fix -Wimplicit-fallthrough warnings
Replace some fall through comments with the attribute.
Mike Frysinger [Thu, 21 Dec 2023 05:19:27 +0000 (00:19 -0500)]
sim: add ATTRIBUTE_FALLTHROUGH for local code
We'll replace various /* fall through */ comments so compilers can
actually understand what the code is doing.
Mike Frysinger [Thu, 21 Dec 2023 05:38:31 +0000 (00:38 -0500)]
sim: signal: mark signal callback funcs as noreturn since they don't return
All funcs already call other funcs that don't return. The mips port is
the only exception because its generic exception handler can return in
the case of normal exceptions. So while the exceptions its signal handler
triggers doesn't return, we can't express that conditional logic. So add
some useless abort calls to make the compiler happy.
Mike Frysinger [Thu, 21 Dec 2023 06:39:01 +0000 (01:39 -0500)]
sim: sh: add missing breaks to bit processing
Doesn't seem like we want to cascade in this section when bit processing.
Mike Frysinger [Thu, 21 Dec 2023 06:38:11 +0000 (01:38 -0500)]
sim: rx: mark abort func as noreturn since it doesn't
Mike Frysinger [Thu, 21 Dec 2023 06:36:40 +0000 (01:36 -0500)]
sim: rx: add missing break to memory write
It doesn't seem like we want to keep executing the next block of code
after processing the request.
Mike Frysinger [Thu, 21 Dec 2023 06:32:59 +0000 (01:32 -0500)]
sim: iq2000: add fallback for exit syscall
Make sure this syscall always exits regardless of the exit code.
Mike Frysinger [Thu, 21 Dec 2023 06:30:20 +0000 (01:30 -0500)]
sim: cr16: add missing break statement
Doesn't seem to make sense for this to fall through
(although I'm not an expert in this ISA).
Mike Frysinger [Thu, 21 Dec 2023 06:27:18 +0000 (01:27 -0500)]
sim: arm: add missing breaks to SWI processing
Seems unlikely we want the remove syscall to fallthrough into the
rename syscall since we can't rename files that have been removed.
Mike Frysinger [Thu, 21 Dec 2023 05:31:25 +0000 (00:31 -0500)]
sim: common: mark engine restart as noreturn
This helps the compiler with optimization and fixes fallthru warnings.
Mike Frysinger [Thu, 21 Dec 2023 05:15:48 +0000 (00:15 -0500)]
sim: ppc: phb: add missing break to address decoder
I don't know what this emulation does exactly, but it missing a break
statement seems kind of obvious based on the 32-bit case above it.
Mike Frysinger [Thu, 21 Dec 2023 05:09:23 +0000 (00:09 -0500)]
sim: ppc: mark halt & restart funcs as noreturn
This helps the compiler with optimization and fixes fallthru warnings.
Mike Frysinger [Thu, 21 Dec 2023 05:02:03 +0000 (00:02 -0500)]
sim: warnings: enable -Wduplicated-cond
Mike Frysinger [Thu, 21 Dec 2023 05:00:49 +0000 (00:00 -0500)]
sim: mn10300: fix LAST_TIMER_REG typo
The compiler pointed out that we're testing LAST_TIMER_REG and
LAST_COUNTER which are the same value ... and that's because we
set LAST_TIMER_REG to the wrong register. Fix the typo.
Mike Frysinger [Thu, 21 Dec 2023 04:59:28 +0000 (23:59 -0500)]
sim: bfin: clean up astat reg name decode a little
The compiler pointed out we checked AZ twice. Sort by name to avoid
that in the future, and to make it clearer that we have coverage of
all the bits. And add the bits we were missing.
The order here doesn't matter as it's just turning a pointer into a
human readable string when store tracing is enabled.
Mike Frysinger [Tue, 19 Dec 2023 10:47:32 +0000 (05:47 -0500)]
sim: common: delete unused scache in some mloop paths
The scache vars aren't used by ports in the pbb & fast codepaths,
nor are they documented as inputs to the callbacks, so delete them
to avoid unused variable compiler warnings.
Mike Frysinger [Wed, 20 Dec 2023 00:54:13 +0000 (19:54 -0500)]
sim: cgen: unify the genmloop logic a bit
Pull out the common parts of the genmloop invocation into the common
code. This will make it easier to add more, and make the per-port
differences a little more obvious.
GDB Administrator [Thu, 21 Dec 2023 00:00:23 +0000 (00:00 +0000)]
Automatic date update in version.in
Vladimir Mezentsev [Tue, 19 Dec 2023 05:04:57 +0000 (21:04 -0800)]
gprofng: 31169 Source code locations can not be found in a C++ application
gprofng incorrectly reads the form of the DW_FORM_ref_addr attribute for DWARF
Version 3 or later.
From DWARF specification:
References that use the attribute form DW_FORM_ref_addr are specified to
be four bytes in the DWARF 32-bit format and eight bytes in the DWARF
64-bit format, while DWARF Version 2 specifies that such references have
the same size as an address on the target system.
2023-12-18 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
PR gprofng/31169
* src/DwarfLib.cc: Fix the reader for DW_FORM_ref_addr.
Pedro Alves [Fri, 1 Dec 2023 17:45:21 +0000 (17:45 +0000)]
Fix handling of vanishing threads that were stepping/stopping
Downstream, AMD is carrying a testcase
(gdb.rocm/continue-over-kernel-exit.exp) that exposes a couple issues
with the amd-dbgapi target's handling of exited threads. The test
can't be added upstream yet, unfortunately, due to dependency on DWARF
extensions that can't be upstreamed yet. However, it can be found on
the mailing list on the same series as this patch.
The test spawns a kernel with a number of waves. The waves do nothing
but exit. There is a breakpoint on the s_endpgm instruction. Once
that breakpoint is hit, the test issues a "continue" command. We
should see one breakpoint hit per wave, and then the whole program
exiting. We do see that, however we also see this:
[New AMDGPU Wave ?:?:?:1 (?,?,?)/?]
[AMDGPU Wave ?:?:?:1 (?,?,?)/? exited]
*repeat for other waves*
...
[Thread 0x7ffff626f640 (LWP 3048491) exited]
[Thread 0x7fffeb7ff640 (LWP 3048488) exited]
[Inferior 1 (process 3048475) exited normally]
That "New AMDGPU Wave" output comes from infrun.c itself adding the
thread to the GDB thread list, because it got an event for a thread
not on the thread list yet. The output shows "?"s instead of proper
coordinates, because the event was a TARGET_WAITKIND_THREAD_EXITED,
i.e., the wave was already gone when infrun.c added the thread to the
thread list.
That shouldn't ever happen for the amd-dbgapi target, threads should
only ever be added by the backend.
Note "New AMDGPU Wave ?:?:?:1" is for wave 1. What happened was that
wave 1 terminated previously, and a previous call to
amd_dbgapi_target::update_thread_list() noticed the wave had vanished
and removed it from the GDB thread list. However, because the wave
was stepping when it terminated (due to the displaced step over the
s_endpgm) instruction, it is guaranteed that the amd-dbgapi library
queues a WAVE_COMMAND_TERMINATED event for the exit.
When we process that WAVE_COMMAND_TERMINATED event, in
amd-dbgapi-target.c:process_one_event, we return it to the core as a
TARGET_WAITKIND_THREAD_EXITED event:
static void
process_one_event (amd_dbgapi_event_id_t event_id,
amd_dbgapi_event_kind_t event_kind)
{
...
if (status == AMD_DBGAPI_STATUS_ERROR_INVALID_WAVE_ID
&& event_kind == AMD_DBGAPI_EVENT_KIND_WAVE_COMMAND_TERMINATED)
ws.set_thread_exited (0);
...
}
Recall the wave is already gone from the GDB thread list. So when GDB
sees that TARGET_WAITKIND_THREAD_EXITED event for a thread it doesn't
know about, it adds the thread to the thread list, resulting in that:
[New AMDGPU Wave ?:?:?:1 (?,?,?)/?]
and then, because it was a TARGET_WAITKIND_THREAD_EXITED event, GDB
marks the thread exited right afterwards:
[AMDGPU Wave ?:?:?:1 (?,?,?)/? exited]
The fix is to make amd_dbgapi_target::update_thread_list() _not_
delete vanishing waves iff they were stepping or in progress of being
stopped. These two cases are the ones dbgapi guarantees will result
in a WAVE_COMMAND_TERMINATED event if the wave terminates:
/**
* A command for a wave was not able to complete because the wave has
* terminated.
*
* Commands that can result in this event are ::amd_dbgapi_wave_stop and
* ::amd_dbgapi_wave_resume in single step mode. Since the wave terminated
* before stopping, this event will be reported instead of
* ::AMD_DBGAPI_EVENT_KIND_WAVE_STOP.
*
* The wave that terminated is available by the ::AMD_DBGAPI_EVENT_INFO_WAVE
* query. However, the wave will be invalid since it has already terminated.
* It is the client's responsibility to know what command was being performed
* and was unable to complete due to the wave terminating.
*/
AMD_DBGAPI_EVENT_KIND_WAVE_COMMAND_TERMINATED = 2,
As the comment says, it's GDB's responsability to know whether the
wave was stepping or being stopped. Since we now have a wave_info map
with one entry for each wave, that seems like the place to store that
information. However, I still decided to put all the coordinate
information in its own structure. I.e., basically renamed the
existing wave_info to wave_coordinates, and then added a new wave_info
structure that holds the new state, plus a wave_coordinates object.
This seemed cleaner as there are places where we only need to
instantiate a wave_coordinates object.
There's an extra twist. The testcase also exercises stopping at a new
kernel right after the first kernel fully exits. In that scenario, we
were hitting this assertion after the first kernel fully exits and the
hit of the breakpoint at the second kernel is handled:
[amd-dbgapi] process_event_queue: Pulled event from dbgapi: event_id.handle = 26, event_kind = WAVE_STOP
[amd-dbgapi-lib] suspending queue_3, queue_2, queue_1 (refresh wave list)
../../src/gdb/amd-dbgapi-target.c:1625: internal-error: amd_dbgapi_thread_deleted: Assertion `it != info->wave_info_map.end ()' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
This is the exact same problem as above, just a different
manifestation. In this scenario, we end up in update_thread_list
successfully deleting the exited thread (because it was no longer the
current thread) that was incorrectly added by infrun.c. Because it
was added by infrun.c and not by amd-dbgapi-target.c:add_gpu_thread,
it doesn't have an entry in the wave_info map, so
amd_dbgapi_thread_deleted trips on this assertion:
gdb_assert (it != info->wave_info_map.end ());
here:
...
-> stop_all_threads
-> update_thread_list
-> target_update_thread_list
-> amd_dbgapi_target::update_thread_list
-> thread_db_target::update_thread_list
-> linux_nat_target::update_thread_list
-> delete_exited_threads
-> delete_thread
-> delete_thread_1
-> gdb::observers::observable<thread_info*>::notify
-> amd_dbgapi_thread_deleted
-> internal_error_loc
The testcase thus tries both running to exit after the first kernel
exits, and running to a breakpoint in a second kernel after the first
kernel exits.
Approved-By: Lancelot Six <lancelot.six@amd.com> (amdgpu)
Change-Id: I43a66f060c35aad1fe0d9ff022ce2afd0537f028
Pedro Alves [Fri, 17 Nov 2023 12:41:36 +0000 (12:41 +0000)]
Fix thread target ID of exited waves
Currently, if you step over kernel exit, you see:
stepi
[AMDGPU Wave ?:?:?:1 (?,?,?)/? exited]
Command aborted, thread exited.
(gdb)
Those '?' are because the thread/wave is already gone by the time GDB
prints the "exited" notification, we can't ask dbgapi for any info
about the wave anymore.
This commit fixes it by caching the wave's coordinates as soon as GDB
sees the wave for the first time, and making
amd_dbgapi_target::pid_to_str use the cached info.
At first I thought of clearing the wave_info object from a
thread_exited observer. However, that is too soon, resulting in this:
(gdb) si
[AMDGPU Wave 1:4:1:1 (0,0,0)/0 exited]
Command aborted, thread exited.
(gdb) thread
[Current thread is 6 (AMDGPU Wave ?:?:?:0 (?,?,?)/?) (exited)]
We need instead to clear the wave info when the thread is ultimately
deleted, so we get:
(gdb) si
[AMDGPU Wave 1:4:1:1 (0,0,0)/0 exited]
Command aborted, thread exited.
(gdb) thread
[Current thread is 6 (AMDGPU Wave 1:4:1:1 (0,0,0)/0) (exited)]
And for that, we need a new thread_deleted observable.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Approved-By: Lancelot Six <lancelot.six@amd.com> (amdgpu)
Change-Id: I6c3e22541f051e1205f75eb657b04dc15e547580
Pedro Alves [Fri, 17 Nov 2023 21:45:06 +0000 (21:45 +0000)]
Step over thread exit, always delete the thread non-silently
With AMD GPU debugging, I noticed that when stepping over a breakpoint
placed on top of the s_endpgm instruction inline (displaced=off), GDB
would behave differently -- it wouldn't print the wave exit. E.g:
With displaced stepping, or no breakpoint at all:
stepi
[AMDGPU Wave 1:4:1:1 (0,0,0)/0 exited]
Command aborted, thread exited.
(gdb)
With inline stepping:
stepi
Command aborted, thread exited.
(gdb)
In the cases we see the "exited" notification, handle_thread_exit is
what first called delete_thread on the exiting thread, which is
non-silent.
With inline stepping, however, handle_thread_exit ends up in
update_thread_list (via restart_threads) before any delete_thread
call. Thus, amd_dbgapi_target::update_thread_list notices that the
wave is gone and deletes it with delete_thread_silent.
This commit fixes it, by making handle_thread_exited call
set_thread_exited (with the default silent=false) early, which emits
the user-visible notification.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I22ab3145e18d07c99dace45576307b9f9d5d966f
Pedro Alves [Fri, 1 Dec 2023 13:31:00 +0000 (13:31 +0000)]
displaced_step_finish: Don't fetch the regcache of exited threads
displaced_step_finish can be called with event_status.kind ==
TARGET_WAITKIND_THREAD_EXITED, and in that case it is not possible to
get at the already-exited thread's registers.
This patch moves the get_thread_regcache calls to branches that
actually need it, where we know the thread is still alive.
It also adds an assertion to get_thread_regcache, to help catching
these broken cases sooner.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I63b5eacb3e02a538fc5087c270d8025adfda88c3
Pedro Alves [Mon, 20 Nov 2023 17:49:08 +0000 (17:49 +0000)]
Ensure selected thread after thread exit stop
While making step over thread exit work properly on AMDGPU, I noticed
that if there's a breakpoint on top of the exit syscall, and,
displaced stepping is off, then when GDB reports "Command aborted,
thread exited.", GDB also switches focus to a random thread, instead
of leaving the exited thread as selected:
(gdb) thread
[Current thread is 6, lane 0 (AMDGPU Lane 1:4:1:1/0 (0,0,0)[0,0,0])]
(gdb) si
Command aborted, thread exited.
(gdb) thread
[Current thread is 5 (Thread 0x7ffff626f640 (LWP 3248392))]
(gdb)
The previous patch extended gdb.threads/step-over-thread-exit.exp to
exercise this on GNU/Linux (on the CPU side), and there, after that
"si", we always end up with the exiting thread as selected even
without this fix, but that's just a concidence, there's a code path
that happens to select the exiting thread for an unrelated reason.
This commit add the explict switch, fixing the latent problem for
GNU/Linux, and the actual problem on AMDGPU. I wrote a gdb.rocm/
testcase for this, but it can't be upstreamed yet, until more pieces
of the DWARF machinery are upstream as well.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I6ff57a79514ac0142bba35c749fe83d53d9e4e51
Pedro Alves [Tue, 21 Nov 2023 12:23:11 +0000 (12:23 +0000)]
gdb.threads/step-over-thread-exit.exp improvements
This commit makes the following improvements to
gdb.threads/step-over-thread-exit.exp:
- Add a third axis to stepping over the breakpoint with displaced vs
inline stepping -- also test with no breakpoint at all.
- Check that when GDB reports "Command aborted, thread exited.", the
selected thread is the thread that exited. This is always true
currently on GNU/Linux by coincidence, but a similar testcase on AMD
GPU exposed a problem here. Better make the testcase catch any
potential regression.
- Fixes a race that Simon ran into with GDBserver testing.
(gdb) next
[New Thread 2143071.2143438]
Thread 3 "step-over-threa" hit Breakpoint 2, 0x000055555555524e in my_exit_syscall () at .../testsuite/lib/my-syscalls.S:74
74 SYSCALL (my_exit, __NR_exit)
(gdb) FAIL: gdb.threads/step-over-thread-exit.exp: displaced-stepping=auto: non-stop=on: target-non-stop=on: schedlock=off: cmd=next: ns_stop_all=0: command aborts when thread exits
I was not able to reproduce it, but I believe that what happens is
the following:
Once we continue, the thread 2 exits, and the main thread thus
unblocks from its pthread_join, and spawns a new thread. That new
thread may hit the breakpoint at my_exit_syscall very quickly. GDB
could then see/process that breakpoint event before the thread exit
event for the thread we care about, which would result in the
failure seen above.
The fix here is to not loop and start a new thread at all in the
scenario where the race can happen. We only need to loop and spawn
new threads when testing with "cmd=continue" and schedlock off, in
which case GDB doesn't abort the command when the thread exits.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I90c95c32f00630a3f682b1541c23aff52451f9b6