| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
On s390x-linux, I run into:
...
(gdb) p (short []) s1^M
$3 = {0, 1, 0, <optimized out>}^M
(gdb) FAIL: gdb.dwarf2/shortpiece.exp: p (short []) s1
...
while this is expected:
...
(gdb) p (short []) s1^M
$3 = {1, 0, 0, <optimized out>}^M
(gdb) PASS: gdb.dwarf2/shortpiece.exp: p (short []) s1
...
The type of s1 is:
...
(gdb) ptype s1
type = struct S {
myint a;
myushort b;
}
...
so the difference is due the fact that viewing an int as two shorts gives
different results depending on the endianness.
Fix this by allowing both results.
Tested on x86_64-linux and s390x-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I noticed that we started using "string cat", which has been available since
tcl version 8.6.2.
Add a local implementation for use with older tcl versions.
Tested on x86_64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
In commit 1a7d840a216 ("[gdb/tdep] Fix ARM_LINUX_JB_PC_EABI"), in absense of
osabi settings for newlib and uclibc for arm, I chose a best-effort approach
using ifdefs.
Post-commit review [1] pointed out that this may be causing more problems than
it's worth.
Fix this by removing the ifdefs and simply defining ARM_LINUX_JB_PC_EABI to 1.
Rebuild on x86_64-linux with --enable-targets=all.
Fixes: 1a7d840a216 ("[gdb/tdep] Fix ARM_LINUX_JB_PC_EABI")
[1] https://sourceware.org/pipermail/gdb-patches/2024-June/209779.html
|
|
Commit 97033da5070 ("[gdb/build] Cleanup gdb/features/feature_to_c.sh")
factored out new file gdb/features/feature_to_c.awk out of
gdb/features/feature_to_c.sh, but failed to add the GPL header comment, so add
this now.
Tested on x86_64-linux.
|
|
The xsave_ymm_avx512_offset data structure contains the xsave
offset to the upper 128 bits of a ymm register. Similarly, for zmm this
offset is described by xsave_avx512_zmm_h_offset, h indicating the
high bits. This commit renames the xsave_ymm_avx512_offset to
xsave_ymm_h_avx512_offset - as well as the associated define from
XSAVE_YMM_AVX512_ADDR to XSAVE_YMM_H_AVX512_ADDR - to make this
more consistent.
Note, that the regnum defines already included the 'h' for ymm, like
I387_YMM16H_REGNUM and I387_YMMH_AVX512_END_REGNUM.
Co-authored-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
When running test-case gdb.fortran/array-indices.exp on a system without
fortran compiler, I run into a duplicate:
...
Running /home/vries/gdb/src/gdb/testsuite/gdb.fortran/array-indices.exp ...
gdb compile failed, default_target_compile: Can't find gfortran.
UNTESTED: gdb.fortran/array-indices.exp: array-indices.exp
gdb compile failed, default_target_compile: Can't find gfortran.
UNTESTED: gdb.fortran/array-indices.exp: array-indices.exp
DUPLICATE: gdb.fortran/array-indices.exp: array-indices.exp
...
Fix this by adding a with_test_prefix at the toplevel.
Likewise in gdb.fortran/array-repeat.exp.
Tested on x86_64-linux.
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
|
|
This changes tui_register_info::highlight to be private, renaming it
to m_highlight.
|
|
This TUI code calls fflush on stdout, but I don't believe this is
useful in gdb.
|
|
Clean up script gdb/features/feature_to_c.sh by:
- fixing shellcheck warnings,
- moving an embedded awk script out of the file, reducing the amount of
escaping in the awk script, making it more readable and maintainable, and
- adding emacs / vi settings for local tab size 2 (copied from ./ltmain.sh).
Tested on x86_64-linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
Fix shellcheck warnings in script lib/dg-add-core-file-count.sh.
Tested on x86_64-linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
In emacs, on gdb/contrib/cc-with-tweaks.sh, do:
- M-x whitespace-cleanup,
- M-x mark-whole-buffer and M-x indent-region, and
- and undo the unwanted changes in the header comment.
Only whitespace changes.
Tested on x86_64-linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
Fix shellcheck warnings in script gdb/contrib/cc-with-tweaks.sh.
Tested on x86_64-linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
Clean up script gdb/contrib/expect-read1.sh by:
- fixing shellcheck warnings,
- using mktemp (which takes TMPDIR into account) instead of a hardcoded
"/tmp/expect-read1.$$.so",
- adding comments, and
- adding emacs / vi settings for local tab size 2 (copied from ./ltmain.sh).
Tested on x86_64-linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
This patch simplifies ada_lookup_encoded_symbol by having it return
its result, rather than returning void and having an out parameter.
|
|
This introduces the new method language_defn::lookup_symbol_local, and
then changes lookup_symbol_local to use it. This removes an explicit
language check from this function, and makes it easier for other
languages to hook into this code.
|
|
lookup_local_symbol checks whether 'function' is null before calling
block::inlined_p, but this is not necessary.
|
|
This simplifies lookup_local_symbol a little, by having it check
whether the current block is the static or global block, instead of
first searching for the static block.
|
|
This changes lookup_local_symbol to directly examine any attached
template symbols, rather than gating this lookup on the use of C++ or
Fortran. As mentioned in an earlier patch, these objects are not
necessarily C++-specific, and doing the search generically seems
better.
This also renames cp_lookup_symbol_imports_or_template now that the
"template" part has been removed.
|
|
This moves search_symbol_list to symtab.c and exports it. It will be
useful in a later patch.
|
|
This patch renames is_cplus_template_function to is_template_function.
There is nothing C++-specific about this code, and the code in the
DWARF reader that creates these objects is not C++-specific. In fact
this may already be used by Rust (though I didn't check).
|
|
Since this commit:
commit 0ee6b1c511c0e2a6793568692d2e5418cd6bc10d
Date: Wed May 18 13:32:04 2022 -0700
Use aarch64_features to describe register features in target descriptions.
There has been an issue with how aarch64 target descriptions are
cached within gdbserver, and specifically, how this caching impacts
the in process agent (IPA).
The function initialize_tracepoint_ftlib (gdbserver/tracepoint.cc) is
part of the IPA, this function is a constructor function, i.e. is
called as part of the global initialisation process. We can't
guarantee the ordering of when this function is called vs when other
global state is initialised.
Now initialize_tracepoint_ftlib calls initialize_tracepoint, which
calls initialize_low_tracepoint, which for aarch64 calls
aarch64_linux_read_description.
The aarch64_linux_read_description function lives in
linux-aarch64-tdesc.cc and after the above commit, depends on a
std::unordered_map having been initialized.
Prior to the above commit aarch64_linux_read_description used a global
C style array, which obviously requires no runtime initialization.
The consequence of the above is that any inferior linked with the IPA
(for aarch64) will experience undefined behaviour (access to an
uninitialized std::unordered_map) during startup, which for me
manifests as a segfault.
I propose fixing this by moving the std::unordered_map into the
function body, but leaving it static. The map will now be initialized
the first time the function is called, which removes the undefiend
behaviour.
The same problem exists for the expedited_registers global, however
this global can just be made into a function local instead. The
expedited_registers variable is used to build a pointer list which is
then passed to init_target_desc, however init_target_desc copies the
values it is given so expedited_registers does not need to live longer
than its containing function.
On most of the AArch64 machines I have access too tracing is not
supported, and so the gdb.trace/*.exp tests that use the IPA just exit
early reporting unsupported. I've added a test which links an
inferior with the IPA and just starts the inferior. No tracing is
performed. This exposes the current issue even on hosts that don't
support tracing. After this patch the test passes.
|
|
This commit builds on the previous series of commits to share the
target description caching code between GDB and gdbserver for
x86/Linux targets.
The objective of this commit is to move the four functions (2 each of)
i386_linux_read_description and amd64_linux_read_description into the
gdb/arch/ directory and combine them so we have just a single copy of
each. Then GDB, gdbserver, and the in-process-agent (IPA) will link
against these shared functions.
One curiosity with this patch is the function
x86_linux_post_init_tdesc. On the gdbserver side the two functions
amd64_linux_read_description and i386_linux_read_description have some
functionality that is not present on the GDB side, there is some
additional configuration that is performed as each target description
is created, to setup the expedited registers.
To support this I've added the function x86_linux_post_init_tdesc.
This function is called from the two *_linux_read_description
functions, but is implemented separately for GDB and gdbserver.
An alternative approach that avoids adding x86_linux_post_init_tdesc
would be to have x86_linux_tdesc_for_tid return a non-const target
description, then in x86_target::low_arch_setup we could inspect the
target description to figure out if it is 64-bit or not, and modify
the target description as needed. In the end I think that adding the
x86_linux_post_init_tdesc function is the simpler solution.
The contents of gdbserver/linux-x86-low.cc have moved to
gdb/arch/x86-linux-tdesc-features.c, and gdbserver/linux-x86-tdesc.h
has moved to gdb/arch/x86-linux-tdesc-features.h, this change leads to
some updates in the #includes in the gdbserver/ directory.
This commit also changes how target descriptions are cached.
Previously both GDB and gdbserver used static C-style arrays to act as
the tdesc cache. This was fine, except for two problems. Either the
C-style arrays would need to be placed in x86-linux-tdesc-features.c,
which would allow us to use the x86_linux_*_tdesc_count_1() functions
to size the arrays for us, or we'd need to hard code the array sizes
using separate #defines, which we'd then have to keep in sync with the
rest of the code in x86-linux-tdesc-features.c.
Given both of these problems I decided a better solution would be to
just switch to using a std::unordered_map to act as the cache. This
will resize automatically, and we can use the xcr0 value as the key.
At first inspection, using xcr0 might seem to be a problem; after all
the {i386,amd64}_create_target_description functions take more than
just the xcr0 value. However, this patch is only for x86/Linux
targets, and for x86/Linux all of the other flags passed to the tdesc
creation functions have constant values and so are irrelevant when we
consider tdesc caching.
For testing I've done the following:
- Built on x86-64 GNU/Linux for all targets, and just for the native
target,
- Build on i386 GNU/Linux for all targets, and just for the native
target,
- Build on a 64-bit, non-x86 GNU/Linux for all targets, just for the
native target, and for targets x86_64-*-linux and i386-*-linux.
Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>
|
|
This commit is part of a series to share more of the x86 target
description creation code between GDB and gdbserver.
Unlike previous commits which were mostly refactoring, this commit is
the first that makes a real change, though that change should mostly
be for gdbserver; I've largely adopted the "GDB" way of doing things
for gdbserver, and this fixes a real gdbserver bug.
On a x86-64 Linux target, running the test:
gdb.server/connect-with-no-symbol-file.exp
results in two core files being created. Both of these core files are
from the inferior process, created after gdbserver has detached.
In this test a gdbserver process is started and then, after gdbserver
has started, but before GDB attaches, we either delete the inferior
executable, or change its permissions so it can't be read. Only after
doing this do we attempt to connect with GDB.
As GDB connects to gdbserver, gdbserver attempts to figure out the
target description so that it can send the description to GDB, this
involves a call to x86_linux_read_description.
In x86_linux_read_description one of the first things we do is try to
figure out if the process is 32-bit or 64-bit. To do this we look up
the executable via the thread-id, and then attempt to read the
architecture size from the executable. This isn't going to work if
the executable has been deleted, or is no longer readable.
And so, as we can't read the executable, we default to an i386 target
and use an i386 target description.
A consequence of using an i386 target description is that addresses
are assumed to be 32-bits. Here's an example session that shows the
problems this causes. This is run on an x86-64 machine, and the test
binary (xx.x) is a standard 64-bit x86-64 binary:
shell_1$ gdbserver --once localhost :54321 /tmp/xx.x
shell_2$ gdb -q
(gdb) set sysroot
(gdb) shell chmod 000 /tmp/xx.x
(gdb) target remote :54321
Remote debugging using :54321
warning: /tmp/xx.x: Permission denied.
0xf7fd3110 in ?? ()
(gdb) show architecture
The target architecture is set to "auto" (currently "i386").
(gdb) p/x $pc
$1 = 0xf7fd3110
(gdb) info proc mappings
process 2412639
Mapped address spaces:
Start Addr End Addr Size Offset Perms objfile
0x400000 0x401000 0x1000 0x0 r--p /tmp/xx.x
0x401000 0x402000 0x1000 0x1000 r-xp /tmp/xx.x
0x402000 0x403000 0x1000 0x2000 r--p /tmp/xx.x
0x403000 0x405000 0x2000 0x2000 rw-p /tmp/xx.x
0xf7fcb000 0xf7fcf000 0x4000 0x0 r--p [vvar]
0xf7fcf000 0xf7fd1000 0x2000 0x0 r-xp [vdso]
0xf7fd1000 0xf7fd3000 0x2000 0x0 r--p /usr/lib64/ld-2.30.so
0xf7fd3000 0xf7ff3000 0x20000 0x2000 r-xp /usr/lib64/ld-2.30.so
0xf7ff3000 0xf7ffb000 0x8000 0x22000 r--p /usr/lib64/ld-2.30.so
0xf7ffc000 0xf7ffe000 0x2000 0x2a000 rw-p /usr/lib64/ld-2.30.so
0xf7ffe000 0xf7fff000 0x1000 0x0 rw-p
0xfffda000 0xfffff000 0x25000 0x0 rw-p [stack]
0xff600000 0xff601000 0x1000 0x0 r-xp [vsyscall]
(gdb) info inferiors
Num Description Connection Executable
* 1 process 2412639 1 (remote :54321)
(gdb) shell cat /proc/2412639/maps
00400000-00401000 r--p 00000000 fd:03 45907133 /tmp/xx.x
00401000-00402000 r-xp 00001000 fd:03 45907133 /tmp/xx.x
00402000-00403000 r--p 00002000 fd:03 45907133 /tmp/xx.x
00403000-00405000 rw-p 00002000 fd:03 45907133 /tmp/xx.x
7ffff7fcb000-7ffff7fcf000 r--p 00000000 00:00 0 [vvar]
7ffff7fcf000-7ffff7fd1000 r-xp 00000000 00:00 0 [vdso]
7ffff7fd1000-7ffff7fd3000 r--p 00000000 fd:00 143904 /usr/lib64/ld-2.30.so
7ffff7fd3000-7ffff7ff3000 r-xp 00002000 fd:00 143904 /usr/lib64/ld-2.30.so
7ffff7ff3000-7ffff7ffb000 r--p 00022000 fd:00 143904 /usr/lib64/ld-2.30.so
7ffff7ffc000-7ffff7ffe000 rw-p 0002a000 fd:00 143904 /usr/lib64/ld-2.30.so
7ffff7ffe000-7ffff7fff000 rw-p 00000000 00:00 0
7ffffffda000-7ffffffff000 rw-p 00000000 00:00 0 [stack]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
(gdb)
Notice the difference between the mappings reported via GDB and those
reported directly from the kernel via /proc/PID/maps, the addresses of
every mapping is clamped to 32-bits for GDB, while the kernel reports
real 64-bit addresses.
Notice also that the $pc value is a 32-bit value. It appears to be
within one of the mappings reported by GDB, but is outside any of the
mappings reported from the kernel.
And this is where the problem arises. When gdbserver detaches from
the inferior we pass the inferior the address from which it should
resume. Due to the 32/64 bit confusion we tell the inferior to resume
from the 32-bit $pc value, which is not within any valid mapping, and
so, as soon as the inferior resumes, it segfaults.
If we look at how GDB (not gdbserver) figures out its target
description then we see an interesting difference. GDB doesn't try to
read the executable. Instead GDB uses ptrace to query the thread's
state, and uses this to figure out the if the thread is 32 or 64 bit.
If we update gdbserver to do it the "GDB" way then the above problem
is resolved, gdbserver now sees the process as 64-bit, and when we
detach from the inferior we give it the correct 64-bit address, and
the inferior no longer segfaults.
Now, I could just update the gdbserver code, but better, I think, to
share one copy of the code between GDB and gdbserver in gdb/nat/.
That is what this commit does.
The cores of x86_linux_read_description from gdbserver and
x86_linux_nat_target::read_description from GDB are moved into a new
file gdb/nat/x86-linux-tdesc.c and combined into a single function
x86_linux_tdesc_for_tid which is called from each location.
This new function does things mostly the GDB way, some changes are
needed to allow for the sharing; we now take some pointers for where
the shared code can cache the xcr0 and xsave layout values.
Another thing to note about this commit is how the functions
i386_linux_read_description and amd64_linux_read_description are
handled. For now I've left these function as implemented separately
in GDB and gdbserver. I've moved the declarations of these functions
into gdb/arch/{i386,amd64}-linux-tdesc.h, but the implementations are
left where they are.
A later commit in this series will make these functions shared too,
but doing this is not trivial, so I've left that for a separate
commit. Merging the declarations as I've done here ensures that
everyone implements the function to the same API, and once these
functions are shared (in a later commit) we'll want a shared
declaration anyway.
Reviewed-By: Felix Willgerodt <felix.willgerodt@intel.com>
Acked-By: John Baldwin <jhb@FreeBSD.org>
|
|
Currently, in i386_linux_core_read_description, if GDB fails to
extract an xcr0 value from the core file, then we will have a default
zero value for the xcr0 variable, we still call the
i386_linux_read_description function, which checks for this zero value
and returns nullptr.
Back in i386_linux_core_read_description we spot the nullptr return
value from i386_linux_read_description and call
i386_linux_read_description again, but this time passing a default
value for xcr0.
In the next commit I plan to rework i386_linux_read_description, and
in so doing I will remove the check for xcr0 == 0, this is inline with
how the amd64 code is written.
However, this means that the 'xcr0 == 0' check needs to move up the
stack to i386_linux_core_read_description, again, this brings the i386
code into line with the amd64 code.
This is just a refactor in preparation for the next commit, there
should be no user visible changes after this commit.
Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>
Approved-By: John Baldwin <jhb@FreeBSD.org>
|
|
This patch is part of a series that has the aim sharing the x86 Linux
target description creation code between GDB and gdbserver.
Within GDB part of this process involves reading the cs and ds state
from the 'struct user_regs_struct' using a ptrace call.
This isn't done by gdbserver, which is part of the motivation for this
whole series; the approach gdbserver takes is inferior to the approach
GDB takes (gdbserver relies on reading the file being debugged, and
extracting similar information from the file headers).
This commit moves the reading of cs and ds, which is used to figure
out if a thread is 32-bit or 64-bit (or in x32 mode), into the gdb/nat
directory so that the code can be shared with gdbserver, but at this
point I'm not actually using the code in gdbserver, that will come
later.
As such there should be no user visible changes after this commit, GDB
continues to do things as it did before (reading cs/ds), while
gdbserver continues to use its own approach (which doesn't require
reading cs/ds).
Approved-By: John Baldwin <jhb@FreeBSD.org>
Reviewed-By: Felix Willgerodt <felix.willgerodt@intel.com>
|
|
In a later commit I want to access have_ptrace_getregset from a .c
file in the nat/ directory. To achieve this I need access to the
declaration of have_ptrace_getregset.
Currently have_ptrace_getregset is declared (and defined) twice, once
in GDB and once in gdbserver.
This commit moves the declaration into nat/linux-nat.h, but leaves the
two definitions where they are. Now, in my later commit, I can pull
in the declaration from nat/linux-nat.h.
There should be no user visible changes after this commit.
Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>
|
|
The have_ptrace_getfpxregs global tracks whether GDB or gdbserver is
running on a kernel that supports the GETFPXREGS ptrace request.
Currently this global is declared twice (once in GDB and once in
gdbserver), I think it makes sense to move this global into the nat/
directory, and have a single declaration and definition.
While moving this variable I have converted it to a tribool, as that
was what it really was, if even used the same numbering as the tribool
enum (-1, 0, 1). Where have_ptrace_getfpxregs was used I have updated
in the obvious way.
However, while making this change I noticed what I think is a bug in
x86_linux_nat_target::read_description and x86_linux_read_description,
both of these functions can be called multiple times, but in both
cases we only end up calling i386_linux_read_description the first
time through in the event that PTRACE_GETFPXREGS is not supported.
This is because initially have_ptrace_getfpxregs will be
TRIBOOL_UNKNOWN, but after the ptrace call fails we set
have_ptrace_getfpxregs to TRIBOOL_FALSE. The next time we attempt to
read the target description we'll skip the ptrace call, and so skip
the call to i386_linux_read_description.
I've not tried to address this preexisting bug in this commit, this is
purely a refactor, there should be no user visible changes after this
commit. In later commits I'll merge the gdbserver and GDB code
together into the nat/ directory, and after that I'll try to address
this bug.
Reviewed-By: Felix Willgerodt <felix.willgerodt@intel.com>
|
|
Share the definition of I386_LINUX_XSAVE_XCR0_OFFSET between GDB and
gdbserver.
This commit moves the definition into gdbsupport/x86-xstate.h, which
allows the #define to be shared.
There should be no user visible changes after this commit.
Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>
|
|
This adds an overload of gdbpy_call_method that accepts a gdbpy_ref<>.
This is just a small convenience.
Reviewed-By: Tom de Vries <tdevries@suse.de>
|
|
This changes gdbpy_call_method to return a gdbpy_ref<>. This is
slightly safer because it makes it simpler to correctly handle
reference counts.
Reviewed-By: Tom de Vries <tdevries@suse.de>
|
|
Starting with gcc commit 80048aa13a6 ("debug/111409 - don't generate COMDAT
macro sections for split DWARF"), available from release gcc 14.1 onwards, gcc
produces a usable dwarf-5 32-bit .debug_macro.dwo section.
Add a test-case excercising this.
Tested on x86_64-linux.
Tested test-case using a current gcc trunk build, and gcc 14.
|
|
Test-case gdb.base/watchpoint-running.exp reports the following kfail:
...
KFAIL: $exp: all-stop: software: watchpoint hit (timeout) (PRMS: gdb/111111)
...
but the referenced gdb PR doesn't exist.
Fix this by using an actual PR.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31833
|
|
This removes the LS_TOKEN_STOKEN macro from linespec.c.
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
This removes the LS_TOKEN_KEYWORD macro from linespec.c.
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
This removes the PARSER_STREAM macro from linespec.c.
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
This removes the PARSER_EXPLICIT macro from linespec.c.
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
This removes the PARSER_RESULT macro from linespec.c.
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
This removes the PARSER_STATE macro from linespec.c.
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
With test-case gdb.server/server-kill-python.exp, I sometimes run into:
...
builtin_spawn gdb -nw -nx -q -iex set height 0 -iex set width 0 \
-data-directory data-directory^M
kill^M
(gdb) kill^M
file server-kill-python^M
The program is not being run.^M
(gdb) ERROR: Couldn't load server-kill-python into GDB.
...
The problem is that the spawn produces a prompt, but it's not explicitly
consumed.
This is a regression since commit 0f077fcae0f ("[gdb/testsuite] Simplify
gdb.server/server-kill-python.exp").
Fix this by consuming the initial prompt.
PR testsuite/31819
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31819
Fixes: 0f077fcae0f ("[gdb/testsuite] Simplify gdb.server/server-kill-python.exp"
|
|
In gdb/python/py-tui.c we have code like this:
...
gdbpy_ref<> result (PyObject_CallMethod (m_window.get(), "hscroll",
"i", num_to_scroll, nullptr));
...
The nullptr is superfluous, the format string already indicates that there's
only one method argument.
OTOH, passing no method args does use a nullptr:
...
gdbpy_ref<> result (PyObject_CallMethod (m_window.get (), "render",
nullptr));
...
Furthermore, choosing the right format string chars can be tricky.
Add a typesafe wrapper around PyObject_CallMethod that hides these
details, such that we can use the more intuitive:
...
gdbpy_ref<> result (gdbpy_call_method (m_window.get(), "hscroll",
num_to_scroll));
...
and:
...
gdbpy_ref<> result (gdbpy_call_method (m_window.get (), "render"));
...
Tested on x86_64-linux.
Co-Authored-By: Tom de Vries <tdevries@suse.de>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Currently it's not possible to call user-defined function call
operators, at least not without specifying operator() directly:
```
(gdb) l 1
1 struct S {
2 int operator() (int x) { return x + 5; }
3 };
4
5 int main () {
6 S s;
7
8 return s(23);
9 }
(gdb) p s(10)
Invalid data type for function to be called.
(gdb) p s.operator()(10)
$1 = 15
```
This now looks if an user-defined call operator is available when
trying to 'call' a struct value, and calls it instead, making this
possible:
```
(gdb) p s(10)
$1 = 15
```
The change in operation::evaluate_funcall is to make sure the type
fields are only used for function types, only they use them as the
argument types.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12213
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Add a new 'error_message' feature to the qSupported packet. When GDB
supports this feature then gdbserver is able to send
errors in the E.errtext format for the qRcmd and m packets.
Update qRcmd packet and m packets documentation as qRcmd newly
accepts errors in a E.errtext format.
Previously these two packets didn't support E.errtext style errors.
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Convert 'set/show debug separate-debug-file' to the new debug scheme.
Though I'm not sure if we can really call it "new" any more!
Approved-By: Tom Tromey <tom@tromey.com>
|
|
While working on a later patch in this series, I noticed that GDB
would print the message:
Reading /path/to/file from remote target...
Even when /path/to/file doesn't exist on the remote target.
GDB does indeed try to open /path/to/file, but I'm not sure we really
need to tell the user unless we actually manage to open the file, and
plan to read content from it.
If we consider how GDB probes for separate debug files, we can attempt
to open multiple possible files, most of them will not exist. When we
are native debugging we don't bother telling the user about each file
we're checking for, we just announce any file we finally use.
I think it makes sense to do a similar thing for remote files.
So, in remote_target::remote_hostio_open(), I'd like to move the block
of code that prints the above message to after the open call has been
made, and we should only print the message if the open succeeds.
Now GDB only tells the user about files that we actually open and read
from the remote.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
In build_id_to_bfd_suffix we look in each debug-file-directory for a
file matching the required build-id.
If we don't find one then we add the sysroot and perform the search
again.
However, the default sysroot is 'target:', and for a native target
this just means to search on the local machine. So by default, if the
debug information is not present, then we end up searching each
location twice.
I think we only need to perform the "with sysroot" check if either:
1. The sysroot is something other than 'target:'. If the user has
set it to '/some/directory' then we should check this sysroot. Or if
the user has set it to 'target:/some/other_directory', this is also
worth checking.
2. If the sysroot is 'target:', but the target's filesystem is not
local (i.e. the user is connected to a remote target), then we should
check using the sysroot as this will be looking on the remote
machine.
There's no tests for this as the whole point here is that I'm removing
duplicate work. No test regressions were seen though.
There should be no user visible changes after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
In remote.c lives remote_target::remote_hostio_send_command(), which
is used to handle sending a fileio packet to the remote, and for
parsing the reply packet.
Some commands, e.g. open, pwrite, close, send some arguments to the
remote, and then get back a single integer return value.
Other commands though, e.g. pread, readlink, fstat, send some
arguments and get back an integer return value and some additional
data. This additional data is called the attachment.
Except, we only get the attachment if the command completes
successfully. For example, calling readlink with a non existent path
will result in a return packet: 'F-1,2' with no attachment. This is
as expected.
Within remote_hostio_send_command we call remote_hostio_parse_result,
this parses the status code (-1 in our example above) and
then parses the errno value (2 in our example above).
Back in remote_hostio_parse_result we then hit this block:
/* Make sure we saw an attachment if and only if we expected one. */
if ((attachment_tmp == NULL && attachment != NULL)
|| (attachment_tmp != NULL && attachment == NULL))
{
*remote_errno = FILEIO_EINVAL;
return -1;
}
Which ensures that commands that expect an attachment, got an
attachment.
The problem is, we'll only get an attachment if the command
succeeded. If it didn't, then there is no attachment, and that is as
expected.
As remote_hostio_parse_result always sets the returned error number to
FILEIO_SUCCESS unless the packet contained an actual error
number (e.g. 2 in our example above), I suggest we should return early
if remote_hostio_parse_result indicates an error packet.
I ran into this issue while working on another patch. In that patch I
was checking the error code returned by a remote readlink call and
spotted that when I passed an invalid path I got EINVAL instead of
ENOENT. This patch fixes this issue.
Unfortunately the patch I was working on evolved, and my need to check
the error code went away, and so, right now, I have no way to reveal
this bug. But I think this is an obviously correct fix, and worth
merging even without a test.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The bitshift tests for opencl have these failures:
print /x (signed char) 0x0f << 8
No type named signed char.
(gdb) FAIL: gdb.base/bitshift.exp: lang=opencl: 8-bit, promoted: print /x (signed char) 0x0f << 8
print (signed char) 0x0f << 8
No type named signed char.
(gdb) FAIL: gdb.base/bitshift.exp: lang=opencl: 8-bit, promoted: print (signed char) 0x0f << 8
Apparently opencl doesn't have the 'signed' modifier for types, only
the 'unsigned' modifier.
Even 'char' is guaranteed to be signed if no modifier is used, so
this changes the casts to match this logic.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
On systems where long has 32-bit size you get these failures:
print 1 << (unsigned long long) 0xffffffffffffffff
Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295)
(gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print 1 << (unsigned long long) 0xffffffffffffffff
print 1 >> (unsigned long long) 0xffffffffffffffff
Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295)
(gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print 1 >> (unsigned long long) 0xffffffffffffffff
print -1 << (unsigned long long) 0xffffffffffffffff
Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295)
(gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print -1 << (unsigned long long) 0xffffffffffffffff
print -1 >> (unsigned long long) 0xffffffffffffffff
Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295)
(gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print -1 >> (unsigned long long) 0xffffffffffffffff
Fixed by changing the number-of-bits variable to ULONGEST.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
As seen in these test failures:
print -1 >> -1
warning: right shift count is negative
$N = 0
(gdb) FAIL: gdb.base/bitshift.exp: lang=c: neg lhs/rhs: print -1 >> -1
print -4 >> -2
warning: right shift count is negative
$N = 0
(gdb) FAIL: gdb.base/bitshift.exp: lang=c: neg lhs/rhs: print -4 >> -2
Fixed by restoring the logic from before the switch to gmp.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
PR31590 shows that right shift of negative numbers doesn't work
correctly since GDB 14:
(gdb) p (-3) >> 1
$1 = -1
GDB 13 and earlier returned the correct value -2.
And there actually is one test that shows the failure:
print -1 >> 1
$84 = 0
(gdb) FAIL: gdb.base/bitshift.exp: lang=asm: rsh neg lhs: print -1 >> 1
The problem was introduced with the change to gmp functions in
commit 303a881f87.
It's wrong because gdb_mpz::operator>> uses mpz_tdif_q_2exp, which
always rounds toward zero, and the gmp docu says this:
For positive n both mpz_fdiv_q_2exp and mpz_tdiv_q_2exp are simple
bitwise right shifts.
For negative n, mpz_fdiv_q_2exp is effectively an arithmetic right shift
treating n as two's complement the same as the bitwise logical functions
do, whereas mpz_tdiv_q_2exp effectively treats n as sign and magnitude.
So this changes mpz_tdiv_q_2exp to mpz_fdiv_q_2exp, since it
does right shifts for both positive and negative numbers.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31590
Approved-By: Tom Tromey <tom@tromey.com>
|
