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.
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.
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>
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>
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>
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>
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
In 2023-12-14 "gdb: make get_frame_register_bytes take the next frame"
(9fc79b4236), *_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>
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>
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>
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.
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.
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.
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.
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.
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.
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.
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".
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.
Commit d5cebea18e ("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 d5cebea18e 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
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.
