| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Regenerate syscalls/{ppc64,ppc}-linux.xml on a system with 5.14 kernel.
|
|
In test-case gdb.base/catch-syscall.exp, proc test_catch_syscall_multi_arch we
test for supported targets using istarget, like so:
...
if { [istarget "i*86-*-*"] || [istarget "x86_64-*-*"] } {
...
} elseif { [istarget "powerpc-*-linux*"] \
|| [istarget "powerpc64*-linux*"] } {
...
...
but the tests excercised there can all be executed if gdb is configured with
--enable-targets=all.
Rewrite the proc to iterate over all cases, and check if the test is supported
by trying "set arch $arch1" and "set arch $arch2".
Tested on x86_64-linux, with:
- a gdb build with --enable-targets=all, and
- a gdb build build with my usual --enable-targets setting (too long to
include here) which means the sparc vs sparc:v9 case is unsupported.
|
|
When running test-case gdb.reverse/fstatat-reverse.exp with target board
unix/-m32 on openSUSE Tumbleweed, I run into:
...
(gdb) PASS: gdb.reverse/fstatat-reverse.exp: set breakpoint at marker2
continue^M
Continuing.^M
Process record and replay target doesn't support syscall number 383^M
Process record: failed to record execution log.^M
^M
Program stopped.^M
0xf7fc5555 in __kernel_vsyscall ()^M
(gdb) FAIL: gdb.reverse/fstatat-reverse.exp: continue to breakpoint: marker2
...
The problems is that while with native we're trying to record these syscalls
(showing strace output):
...
openat(AT_FDCWD, "/", O_RDONLY|O_PATH) = 3
newfstatat(3, ".", {st_mode=S_IFDIR|0755, st_size=146, ...}, 0) = 0
...
with unix/-m32 we have instead:
...
openat(AT_FDCWD, "/", O_RDONLY|O_PATH) = 3
statx(3, ".", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT, STATX_BASIC_STATS, \
{stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=STATX_ATTR_MOUNT_ROOT, \
stx_mode=S_IFDIR|0755, stx_size=146, ...}) = 0
...
and statx is not supported.
Fix this by adding support for recording syscall statx.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28461
|
|
$ objdump -d outputs/gdb.base/large-frame/large-frame-O2
0000000120000b20 <func>:
120000b20: 67bdbff0 daddiu sp,sp,-16400
120000b24: ffbc4000 sd gp,16384(sp)
120000b28: 3c1c0002 lui gp,0x2
120000b2c: 679c8210 daddiu gp,gp,-32240
120000b30: 0399e02d daddu gp,gp,t9
120000b34: df998058 ld t9,-32680(gp)
120000b38: ffbf4008 sd ra,16392(sp)
120000b3c: 0411ffd8 bal 120000aa0 <blah>
...
The disassembly of the above func function shows that we may use
instructions such as daddiu/daddu, so add "daddiu $gp,$gp,n",
"daddu $gp,$gp,$t9" and "daddu $gp,$t9,$gp" to the mips32_scan_prologue
function to fix the large-frame.exp test case.
Before applying the patch:
backtrace
#0 blah (a=0xfffffee220) at .../gdb/testsuite/gdb.base/large-frame-1.c:24
#1 0x0000000120000b44 in func ()
Backtrace stopped: frame did not save the PC
(gdb) FAIL: gdb.base/large-frame.exp: optimize=-O2: backtrace
# of expected passes 5
# of unexpected failures 1
After applying the patch:
# of expected passes 6
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
|
|
The GDB style is to write 'if (readbuf != nullptr)', and the same for
writebuf.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
PR build/29110 points out that GDB fails to build on mingw when the
"win32" thread model is in use. It turns out that the Fedora cross
tools using the "posix" thread model, which somehow manages to support
std::future, whereas the win32 model does not.
While looking into this, I found that the configuring with
--disable-threading will also cause a build failure.
This patch fixes this build by introducing a compatibility wrapper for
std::future.
I am not able to test the win32 thread model build, but I'm going to
ask the reporter to try this patch.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29110
|
|
If you try to set a breakpoint at a function such as "b
f(std::string)", and the current language is C, the breakpoint fails
to be set, like so:
(gdb) set language c
break f(std::string)
Function "f(std::string)" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n
(gdb)
The problem is that the code in GDB that expands the std::string
typedef hits this in c-typeprint.c:
/* If we have "typedef struct foo {. . .} bar;" do we want to
print it as "struct foo" or as "bar"? Pick the latter for
C++, because C++ folk tend to expect things like "class5
*foo" rather than "struct class5 *foo". We rather
arbitrarily choose to make language_minimal work in a C-like
way. */
if (language == language_c || language == language_minimal)
{
if (type->code () == TYPE_CODE_UNION)
gdb_printf (stream, "union ");
else if (type->code () == TYPE_CODE_STRUCT)
{
if (type->is_declared_class ())
gdb_printf (stream, "class ");
else
gdb_printf (stream, "struct ");
}
else if (type->code () == TYPE_CODE_ENUM)
gdb_printf (stream, "enum ");
}
I.e., std::string is expanded to "class std::..." instead of just
"std::...", and then the "f(class std::..." symbol doesn't exist.
Fix this by making cp-support.c:inspect_type print the expanded
typedef type using the language of the symbol whose type we're
expanding the typedefs for -- in the example in question, the
"std::string" typedef symbol, which is a C++ symbol.
Use type_print_raw_options as it seems to me that in this scenario we
always want raw types, to match the real symbol names.
Adjust the gdb.cp/break-f-std-string.exp testcase to try setting a
breakpoint at "f(std::string)" in both C and C++.
Change-Id: Ib54fab4cf0fd307bfd55bf1dd5056830096a653b
|
|
The next patch will want to do language->print_type(type, ...), to
print a type in a given language, avoiding a dependency on the current
language. That doesn't work correctly currently, however, because
most language implementations of language_defn::print_type call
c_print_type without passing down the language. There are two
overloads of c_print_type, one that takes a language, and one that
does not. The one that does not uses the current language, defeating
the point of calling language->print_type()...
This commit removes the c_print_type overload that does not take a
language, and adjusts the codebase throughout to always pass down a
language. In most places, there's already an enum language handy.
language_defn::print_type implementations naturally pass down
this->la_language. In a couple spots, like in ada-typeprint.c and
rust-lang.c there's no enum language handy, but the code is written
for a specific language, so we just hardcode the language.
In gnuv3_print_method_ptr, I wasn't sure whether we could hardcode C++
here, and we don't have an enum language handy, so I made it use the
current language, just like today. Can always be improved later.
Change-Id: Ib54fab4cf0fd307bfd55bf1dd5056830096a653b
|
|
Currently, on any remotely modern GNU/Linux system,
gdb.cp/no-dmgl-verbose.exp fails like so:
break 'f(std::string)'
Function "f(std::string)" not defined.
(gdb) FAIL: gdb.cp/no-dmgl-verbose.exp: gdb_breakpoint: set breakpoint at 'f(std::string)'
break 'f(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)'
Function "f(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)" not defined.
(gdb) PASS: gdb.cp/no-dmgl-verbose.exp: DMGL_VERBOSE-demangled f(std::string) is not defined
This testcase was added back in 2011, here:
[patch] Remove DMGL_VERBOSE
https://sourceware.org/pipermail/gdb-patches/2011-June/083081.html
Back then, the testcase would pass cleanly. It turns out that the
reason it fails today is that the testcase is exercising something in
GDB that only makes sense if the program is built for the pre-C++11
libstc++ ABI. Back then the C++11 ABI didn't exist yet, but nowadays,
you need to compile with -D_GLIBCXX_USE_CXX11_ABI=0 to use the old
ABI. See "Dual ABI" in the libstdc++ manual, at
<https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html>.
If we tweak the gdb.cp/no-dmgl-verbose.exp testcase to force the old
ABI with -D_GLIBCXX_USE_CXX11_ABI=0, then it passes cleanly.
So why is it that setting a breakpoint at "f(std::string)" fails with
modern ABI, but passes with old ABI?
This is where libiberty demangler's DMGL_VERBOSE option comes in. The
Itanium ABI mangling scheme has a shorthand form for std::string (and
some other types). See
<https://itanium-cxx-abi.github.io/cxx-abi/abi.html>:
"In addition, the following catalog of abbreviations of the form "Sx" are used:
<substitution> ::= St # ::std::
<substitution> ::= Sa # ::std::allocator
<substitution> ::= Sb # ::std::basic_string
<substitution> ::= Ss # ::std::basic_string < char,
::std::char_traits<char>,
::std::allocator<char> >
<substitution> ::= Si # ::std::basic_istream<char, std::char_traits<char> >
<substitution> ::= So # ::std::basic_ostream<char, std::char_traits<char> >
<substitution> ::= Sd # ::std::basic_iostream<char, std::char_traits<char> >
"
When the libiberty demangler encounters such a abbreviation, by
default, it expands it to the user-friendly typedef "std::string",
"std::iostream", etc.. If OTOH DMGL_VERBOSE is specified, the
abbreviation is expanded to the underlying, non-typedefed fullname
"std::basic_string<char, std::char_traits<char>, std::allocator<char> >"
etc. as documented in the Itanium ABI, and pasted above. You can see
the standard abbreviations/substitutions in
libiberty/cp-demangle.c:standard_subs.
Back before Jan's patch in 2011, there were parts of GDB that used
DMGL_VERBOSE, and others that did not, leading to mismatches. The
solution back then was to stop using DMGL_VERBOSE throughout.
GDB has code in place to let users set a breakpoint at a function with
typedefs in its parameters, like "b f(uint32_t)". Demangled function
names as they appear in the symbol tables almost (more on this is in a
bit) never have typedefs in them, so when processing "b f(uint32_t)"
GDB first replaces "uint32_t" for its underlying type, and then sets a
breakpoint on the resulting prototype, in this case "f(unsigned int)".
Now, if DMGL_VERBOSE is _not_ used, then the demangler demangles the
mangled name of a function such as "void f(std::string)" that was
mangled using the standard abbreviations mentioned above really as:
"void f(std::string)".
For example, the mangled name of "void f(std::string)" if you compile
with old pre-C++11 ABI is "_Z1fSs". That uses the abbreviation "Ss",
so if you demangle that without DMGL_VERBOSE, you get:
$ echo "_Z1fSs" | c++filt --no-verbose
f(std::string)
while with DMGL_VERBOSE you'd get:
$ echo "_Z1fSs" | c++filt
f(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)
If, when the user sets a breakpoint at "f(std::string)", GDB would
replace the std::string typedef for its underlying type using the same
mechanism I mentioned for the "f(uint32_t)" example above, then GDB
would really try to set a breakpoint at "f(std::basic_string<char,
std::char_traits<char>, std::allocator<char> >)", and that would fail,
as the function symbol GDB knows about for that function, given no
DMGL_VERBOSE, is "f(std::string)".
For this reason, the code that expands typedefs in function parameter
names has an exception for std::string (and other standard
abbreviation types), such that "std::string" is never
typedef-expanded.
And here lies the problem when you try to do "b f(std::string)" with a
program compiled with the C++11 ABI. In that case, std::string
expands to a different underlying type, like so:
f(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)
and this symbol naturally mangles differently, as:
_Z1fNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
and then because this doesn't use the shorthand mangling abbreviation
for "std::string" anymore, it always demangles as:
f(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)
Now, when using the C++11 ABI, and you set a breakpoint at
"f(std::string)", GDB's typedefs-in-parameters expansion code hits the
exception for "std::string" and doesn't expand it, so the breakpoint
fails to be inserted, because the symbol that exists is really the
f(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)
one, not "f(std::string)".
So to fix things for C++11 ABI, clearly we need to remove the
"std::string" exception from the typedef-in-parameters expansion
logic. If we do just that, then "b f(std::string)" starts working
with the C++11 ABI.
However, if we do _just_ that, and nothing else, then we break
pre-C++11 ABI...
The solution is then to in addition switch GDB to always use
DMGL_VERBOSE. If we do this, then pre-C++11 ABI symbols works the
same as C++11 ABI symbols overall -- the demangler expands the
standard abbreviation for "std::string" as "std::basic_string<char,
std::char_traits<char>, std::allocator<char> >" and letting GDB expand
the "std::string" typedef (etc.) too is no longer a problem.
To avoid getting in the situation where some parts of GDB use
DMGL_VERBOSE and others not, this patch adds wrappers around the
demangler's entry points that GDB uses, and makes those force
DMGL_VERBOSE.
The point of the gdb.cp/no-dmgl-verbose.exp testcase was to try to
ensure that DMGL_VERBOSE doesn't creep back in:
gdb_test {break 'f(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)'} \
{Function ".*" not defined\.} \
"DMGL_VERBOSE-demangled f(std::string) is not defined"
This obviously no longer makes sense to have, since we now depend on
DMGL_VERBOSE. So the patch replaces gdb.cp/no-dmgl-verbose.exp with a
new gdb.cp/break-f-std-string.exp testcase whose purpose is to make
sure that setting a breakpoint at "f(std::string)" works. It
exercises both pre-C++11 ABI and C++11 ABI.
Change-Id: Ib54fab4cf0fd307bfd55bf1dd5056830096a653b
|
|
This commit fixes two regressions introduced by
891e4190ba705373eec7b374209478215fff5401.
Reason for the failures was, that on a 32 bit machine the maximum
array length as well as the maximum allocatable memory for arrays
(in bytes) both seem to be limited by the maximum value of a 4
byte (signed) Fortran integer. This lead to compiler errors/unexpected
behavior when compiling/running the test with the -m32 board. This
behavior is compiler dependent and can differ for different compiler
implementations, but generally, it seemed like a good idea to simply
avoid such situations.
The affected tests check for GDB's overflow behavior when using KIND
parameters with GDB implemented Fortran intrinsic functions. If these
KIND parameters are too small to fit the actual intrinsic function's
result, an overflow is expected. This was done for 1, 2, and 4
byte overflows. The last one caused problems, as it tried to allocate
arrays of length/byte-size bigger than the 4 byte signed integers which
would then be used with the LBOUND/UBOUND/SIZE intrinsics.
The tests were adapted to only execute the 4 byte overflow tests when
running on targets with 64 bit. For this, the compiled tests evaluate the
byte size of a C_NULL_PTR via C_SIZEOF, both defined in the ISO_C_BINDING
module. The ISO_C_BINDING constant C_NULL_PTR is a Fortran 2003, the
C_SIZEOF a Fortran 2008 extension. Both have been implemented in their
respective compilers for while (e.g. C_SIZEOF is available since
gfortran 4.6). If this byte size evaluates to less than 8 we skip the
4 byte overflow tests in the compiled tests of size.f90 and
lbound-ubound.f90. Similarly, in the lbound-ubound.exp testsfile we skip
the 4 byte overflow tests if the procedure is_64_target evaluates to false.
In size.f90, additionally, the to-be-allocated amount of bytes did not
fit into 4 byte signed integers for some of the arrays, as it was
approximately 4 times the maximum size of a 4 byte signed integer. We
adapted the dimensions of the arrays in question as the meaningfulness
of the test does not suffer from this.
With this patch both test run fine with the unix/-m32 board and
gcc/gfortran (9.4) as well as the standard board file.
We also thought about completely removing the affected test from the
testsuite. We decided against this as the 32 bit identification comes
with Fortran 2008 and removing tests would have decreased coverage.
A last change that happened with this patch was due to gfortran's and
ifx's type resolution when assigning big constants to Fortran Integer*8
variables. Before the above changes this happened in a parameter
statement. Here, both compilers happily accepted a line like
integer*8, parameter :: var = 2147483647 + 5.
After this change the assignment is not done as a parameter
anymore, as this triggered compile time overflow errors. Instead,
the assignment is done dynamically, depending on the kind of machine one
is on. Sadly, just changing this line to
integer*8 :: var
var = 2147483647 + 5
does not work with ifx (or flang for that matter, they behave similarly
here). It will create an integer overflow in the addition as ifx deduces
the type the additon is done in as Integer*4. So var will actually
contain the value -2147483644 after this. The lines
integer*8 :: var
var = 2147483652
on the other hand fail to compile with gfortran (9.4.0) as the compiler
identifies an Integer overflow here. Finally, to make this work with
all three compilers an additional parameter has been introduced
integer*8, parameter :: helper = 2147483647
integer*8 :: var
var = helper + 5.
This works on all 3 compilers as expected.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29053
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29054
|
|
In bug PR gdb/29036, another failure was reported for the test
gdb.mi/mi-multi-commands.exp. This test sends two commands to GDB as
a single write, and then checks that both commands are executed.
The problem that was encountered here is that the output of the first
command, which looks like this:
^done,value="\"FIRST COMMAND\""
Is actually produced in parts, first the '^done' is printed, then the
',value="\"FIRST COMMAND\"" is printed.
What was happening is that some characters from the second command
were being echoed after the '^done' had been printed, but before the
value part had been printed. To avoid this issue I've relaxed the
pattern that checks for the first command a little. With this fix in
place the occasional failure in this test is no longer showing up.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29036
|
|
- Add a script syscalls/gen-header.py, based on syscalls/arm-linux.py.
- Add a script syscalls/update-linux.sh (alongside update-freebsd.sh and
update-netbsd.sh).
- Use syscalls/update-linux.sh to update syscalls/{amd64,i386}-linux.xml.in.
- Regenerate syscalls/{amd64,i386}-linux.xml using syscalls/Makefile.
In gdb/syscalls/i386-linux.xml.in, updating has the following notable effect:
...
- <syscall name="madvise1" number="220"/>
- <syscall name="getdents64" number="221"/>
- <syscall name="fcntl64" number="222"/>
+ <syscall name="getdents64" number="220"/>
+ <syscall name="fcntl64" number="221"/>
...
I've verified in ./arch/x86/entry/syscalls/syscall_32.tbl that the numbers are
correct.
Tested on x86_64-linux.
|
|
Add a Makefile in gdb/syscalls that can be used to translate
gdb/syscalls/*.xml.in into gdb/syscalls/*.xml.
Calling make reveals that bfin-linux.xml is missing, so add it.
Tested on x86_64-linux.
|
|
When execute the following command on LoongArch:
make check-gdb TESTS="gdb.base/async.exp"
there exist the following failed testcases:
FAIL: gdb.base/async.exp: finish& (timeout)
FAIL: gdb.base/async.exp: jump& (timeout)
FAIL: gdb.base/async.exp: until& (timeout)
FAIL: gdb.base/async.exp: set exec-done-display off (GDB internal error)
we can see the following messages in gdb/testsuite/gdb.log:
finish&
Run till exit from #0 foo () at /home/loongson/gdb.git/gdb/testsuite/gdb.base/async.c:9
(gdb) /home/loongson/gdb.git/gdb/gdbarch.c:2646: internal-error: gdbarch_return_value: Assertion `gdbarch->return_value != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
In order to fix the above failed testcases, implement the return_value
gdbarch method on LoongArch.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
This fix relates to PR gdb/29032, this makes the test more stable by
ensuring that the Ctrl-D is only sent once the prompt has been
displayed. This issue was also discussed on the mailing list here:
https://sourceware.org/pipermail/gdb-patches/2022-April/187670.html
The problem identified in the bug report is that sometimes the Ctrl-D
(that the test sends to GDB) arrives while GDB is processing a
command. When this happens the Ctrl-D is handled differently than if
the Ctrl-D is sent while GDB is waiting for input at a prompt.
The original intent of the test was that the Ctrl-D be sent while GDB
was waiting at a prompt, and that is the case the occurs most often,
but, when the Ctrl-D arrives during command processing, then GDB will
ignore the Ctrl-D, and the test will fail.
This commit ensures the Ctrl-D is always sent while GDB is waiting at
a prompt, which makes this test stable.
But, that still leaves an open question, what should happen when the
Ctrl-D arrives while GDB is processing a command? This commit doesn't
attempt to answer that question, which is while bug PR gdb/29032 will
not be closed once this commit is merged.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29032
|
|
Do:
...
-record btrace <name> <email>
+record
+ btrace <name> <email>
...
to clarify that the listed maintainer is only maintainer of the btrace part of
record.
|
|
With test-case gdb.base/catch-syscall.exp and target board unix/-m32, we run
into:
...
(gdb) catch syscall pipe2^M
Unknown syscall name 'pipe2'.^M
(gdb) FAIL: gdb.base/catch-syscall.exp: determine pipe syscall: catch syscall pipe2
...
Fix this by:
- adding a pipe2 entry in gdb/syscalls/i386-linux.xml.in, and
- regenerating gdb/syscalls/i386-linux.xml using
"xsltproc --output i386-linux.xml apply-defaults.xsl i386-linux.xml.in".
Tested on x86_64-linux with native and unix/-m32.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29056
|
|
When running test-case gdb.reverse/pipe-reverse.exp on openSUSE Tumbleweed,
I run into:
...
(gdb) continue^M
Continuing.^M
^M
Catchpoint 2 (returned from syscall pipe2), in pipe () from /lib64/libc.so.6^M
(gdb) FAIL: gdb.base/catch-syscall.exp: without arguments: \
syscall pipe has returned
...
The current glibc on Tumbleweed is 2.35, which contains commit
"linux: Implement pipe in terms of __NR_pipe2", and consequently syscall pipe2
is used instead of syscall pipe.
Fix this by detecting whether syscall pipe or pipe2 is used before running the
tests.
Tested on x86_64-linux, specifically on:
- openSUSE Tumbleweed (with glibc 2.35), and
- openSUSE Leap 15.3 (with glibc 2.31).
On openSUSE Tumbleweed + target board unix/-m32, this exposes:
...
(gdb) catch syscall pipe2^M
Unknown syscall name 'pipe2'.^M
...
which will be fixed in a folllow-up patch.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29056
|
|
When running test-case gdb.reverse/pipe-reverse.exp on openSUSE Tumbleweed,
I run into:
...
(gdb) continue^M
Continuing.^M
Process record and replay target doesn't support syscall number 293^M
Process record: failed to record execution log.^M
^M
Program stopped.^M
0x00007ffff7daabdb in pipe () from /lib64/libc.so.6^M
(gdb) FAIL: gdb.reverse/pipe-reverse.exp: continue to breakpoint: marker2
...
The current glibc on Tumbleweed is 2.35, which contains commit
"linux: Implement pipe in terms of __NR_pipe2", and consequently syscall pipe2
is used in stead of syscall pipe.
There is already support added for syscall pipe2 for aarch64 (which only has
syscall pipe2, not syscall pipe), so enable the same for amd64, by:
- adding amd64_sys_pipe2 in enum amd64_syscall
- translating amd64_sys_pipe2 to gdb_sys_pipe2 in amd64_canonicalize_syscall
Tested on x86_64-linux, specifically on:
- openSUSE Tumbleweed (with glibc 2.35), and
- openSUSE Leap 15.3 (with glibc 2.31).
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29056
|
|
When running test-case gdb.tui/scroll.exp, I get:
...
Box Dump (80 x 8) @ (0, 0):
0 $17 = 16
1 (gdb) p 17
2 $18 = 17
3 (gdb) p 18
4 $19 = 18
5 (gdb) p 19
6 $20 = 19
7 (gdb)
PASS: gdb.tui/scroll.exp: check cmd window in flip layout
...
but with check-read1 I get instead:
...
Box Dump (80 x 8) @ (0, 0):
0 (gdb) 15
1 (gdb) p 16
2 $17 = 16
3 (gdb) p 17
4 $18 = 17
5 (gdb) p 18
6 $19 = 18
7 (gdb) p 19
FAIL: gdb.tui/scroll.exp: check cmd window in flip layout
...
The "p 19" command is handled by Term::command, which sends the command and then
does Term::wait_for "^$gdb_prompt [string_to_regexp $cmd]", which:
- matches the line with "(gdb) p 19", and
- tries to match the following prompt "(gdb) "
The problem is that scrolling results in reissuing output before the "(gdb) p
19", and the second matching triggers on that. Consequently, wait_for no
longer translates gdb output into screen actions, and the screen does not
reflect the result of "p 19".
Fix this by using a new proc wait_for_region_contents, which in contrast to
wait_for can handle a multi-line regexp.
Tested on x86_64-linux with make targets check and check-read1.
|
|
When running test-case gdb.cp/casts.exp with target board unix/-m32, I run
into:
...
(gdb) print (unsigned long long) &gd == gd_value^M
$31 = false^M
(gdb) FAIL: gdb.cp/casts.exp: print (unsigned long long) &gd == gd_value
...
With some additional printing, we can see in more detail why the comparison
fails:
...
(gdb) print /x &gd^M
$31 = 0xffffc5c8^M
(gdb) PASS: gdb.cp/casts.exp: print /x &gd
print /x (unsigned long long)&gd^M
$32 = 0xffffc5c8^M
(gdb) PASS: gdb.cp/casts.exp: print /x (unsigned long long)&gd
print /x gd_value^M
$33 = 0xffffffffffffc5c8^M
(gdb) PASS: gdb.cp/casts.exp: print /x gd_value
print (unsigned long long) &gd == gd_value^M
$34 = false^M
(gdb) FAIL: gdb.cp/casts.exp: print (unsigned long long) &gd == gd_value
...
The gd_value is set by this assignment:
...
unsigned long long gd_value = (unsigned long long) &gd;
...
The problem here is directly casting from a pointer to a non-pointer-sized
integer.
Fix this by adding an intermediate cast to std::uintptr_t.
Tested on x86_64-linux with native and target board unix/-m32.
|
|
In OBS, on aarch64-linux, with a gdb 11.1 based package, I run into:
...
(gdb) builtin_spawn -pty^M
new-ui mi /dev/pts/5^M
New UI allocated^M
(gdb) =thread-group-added,id="i1"^M
(gdb) ERROR: MI channel failed
warning: Error detected on fd 11^M
thread 1.1^M
Unknown thread 1.1.^M
(gdb) UNRESOLVED: gdb.mi/user-selected-context-sync.exp: mode=non-stop: \
test_cli_inferior: reset selection to thread 1.1
...
with many more UNRESOLVED following.
The ERROR is a common problem, filed as
https://sourceware.org/bugzilla/show_bug.cgi?id=28561 .
But the many UNRESOLVEDs are due to not checking whether the setup as done in
the test_setup function succeeds or not.
Fix this by:
- making test_setup return an error upon failure
- handling test_setup error at the call site
- adding a "setup done" pass/fail to be turned into an unresolved
in case of error during setup.
Tested on x86_64-linux, by manually triggering the error in
mi_gdb_start_separate_mi_tty.
|
|
When running test-case gdb.ada/catch_ex_std.exp on target board
remote-gdbserver-on-localhost, I run into:
...
(gdb) continue^M
Continuing.^M
[Inferior 1 (process 15656) exited with code 0177]^M
(gdb) FAIL: gdb.ada/catch_ex_std.exp: runto: run to main
Remote debugging from host ::1, port 49780^M
/home/vries/foo: error while loading shared libraries: libsome_package.so: \
cannot open shared object file: No such file or directory^M
...
Fix this by adding the usual shared-library + remote-target helper
"gdb_load_shlib $sofile".
Tested on x86_64-linux with native and target board
remote-gdbserver-on-localhost.
|
|
When running test-case gdb.threads/fork-plus-threads.exp with check-readmore,
I run into:
...
[Inferior 11 (process 7029) exited normally]^M
[Inferior 1 (process 6956) exited normally]^M
FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: \
inferior 1 exited (timeout)
...
The problem is that the regexp consuming the "Inferior exited normally"
messages:
- consumes more than one of those messages at a time, but
- counts only one of those messages.
Fix this by adopting a line-by-line approach, which deals with those messages
one at a time.
Tested on x86_64-linux with native, check-read1 and check-readmore.
|
|
Simon pointed out that some recent patches of mine broke "catch
syscall". Apparently I forgot to finish the conversion of this code
when removing init_catchpoint. This patch completes the conversion
and fixes the bug.
|
|
After these two commits:
commit 4fb7bc4b147fd30b781ea2dad533956d0362295a
Date: Mon Mar 7 13:49:21 2022 +0000
readline: back-port changes needed to properly detect EOF
commit 91395d97d905c31ac38513e4aaedecb3b25e818f
Date: Tue Feb 15 17:28:03 2022 +0000
gdb: handle bracketed-paste-mode and EOF correctly
It was observed that, if a previous command is selected at the
readline prompt using the up arrow key, then when the command is
accepted (by pressing return) an unexpected 'quit' message will be
printed by GDB. Here's an example session:
(gdb) p 123
$1 = 123
(gdb) p 123
quit
$2 = 123
(gdb)
In this session the second 'p 123' was entered not by typing 'p 123',
but by pressing the up arrow key to select the previous command. It
is important that the up arrow key is used, typing Ctrl-p will not
trigger the bug.
The problem here appears to be readline's EOF detection when handling
multi-character input sequences. I have raised this issue on the
readline mailing list here:
https://lists.gnu.org/archive/html/bug-readline/2022-04/msg00012.html
a solution has been proposed here:
https://lists.gnu.org/archive/html/bug-readline/2022-04/msg00016.html
This patch includes a test for this issue as well as a back-port of
(the important bits of) readline commit:
commit 2ef9cec8c48ab1ae3a16b1874a49bd1f58eaaca1
Date: Wed May 4 11:18:04 2022 -0400
fix for setting RL_STATE_EOF in callback mode
That commit also includes some updates to the readline documentation
and tests that I have not included in this commit.
With this commit in place the unexpected 'quit' messages are resolved.
|
|
On PowerPC, the stop in the printf function is of the form:
Breakpoint 2, 0x00007ffff7c6ab08 in printf@@GLIBC_2.17 () from /lib64/libc.so.6
On other architectures the output looks like:
Breakpoint 2, 0x0000007fb7ea29ac in printf () from /lib/aarch64-linux-gnu/libc.so.6
The following patch modifies the printf test by matchine any character
starting immediately after the printf. The test now works for PowerPC
output as well as the output from other architectures.
The test has been run on a Power 10 system and and Intel x86_64 system.
|
|
This introduces a catchpoint class that is used as the base class for
all catchpoints. init_catchpoint is rewritten to be a constructor
instead.
This changes the hierarchy a little -- some catchpoints now inherit
from base_breakpoint whereas previously they did not. This isn't a
problem, as long as re_set is redefined in catchpoint.
|
|
This adds some initializers to tracepoint. I think right now these
may not be needed, due to obscure rules about zero initialization.
However, this will change in the next patch, and anyway it is clearer
to be explicit.
|
|
This removes init_raw_breakpoint_without_location, replacing it with a
constructor on 'breakpoint' itself. The subclasses and callers are
all updated.
|
|
It seems to me that breakpoint should use DISABLE_COPY_AND_ASSIGN.
This patch does this.
|
|
This adds a constructor to exception_catchpoint and simplifies the
caller.
|
|
This adds a constructor to syscall_catchpoint and simplifies the
caller.
|
|
This adds a constructor to signal_catchpoint and simplifies the
caller.
|
|
This adds a constructor to solib_catchpoint and simplifies the caller.
|
|
This adds a constructor to fork_catchpoint and simplifies the caller.
|
|
catch_exec_command_1 clears the new catchpoint's "exec_pathname"
field, but this is already done by virtue of calling "new".
|
|
This constifies breakpoint::print_recreate.
|
|
This constifies breakpoint::print_mention.
|
|
This constifies breakpoint::print_one.
|
|
This constifies breakpoint::print_it. Doing this pointed out some
code in ada-lang.c that can be simplified a little as well.
|
|
works_in_software_mode is only useful for watchpoints. This patch
moves it from breakpoint to watchpoint, and changes it to return bool.
|
|
This changes breakpoint::explains_signal to return bool.
|
|
The breakpoint::ops field is set but never used. This removes it.
|
|
This changes print_recreate_thread to be a method on breakpoint. This
function is only used as a helper by print_recreate methods, so I
thought this transformation made sense.
|
|
The break point after the stepi on Intel is the entry point of the user
signal handler function test_signal_handler. The code at the break point
looks like:
0x<hex address> <test_signal_handler>: endbr64
On PowerPC with a Linux 5.9 kernel or latter, the address where gdb stops
after the stepi is in the vdso code inserted by the kernel. The code at the
breakpoint looks like:
0x<hex address> <__kernel_start_sigtramp_rt64>: bctrl
This is different from other architectures. As discussed below, recent
kernel changes involving the vdso for PowerPC have been made changes to the
signal handler code flow. PowerPC is now stopping in function
__kernel_start_sigtramp_rt64. PowerPC now requires an additional stepi to
reach the user signal handler unlike other architectures.
The bp-permanent.exp and kill-after-signal tests run fine on PowerPC with an
kernel that is older than Linux 5.9.
The PowerPC 64 signal handler was updated by the Linux kernel 5.9-rc1:
commit id: 0138ba5783ae0dcc799ad401a1e8ac8333790df9
powerpc/64/signal: Balance return predictor stack in signal trampoline
An additional change to the PowerPC 64 signal handler was made in Linux
kernel version 5.11-rc7 :
commit id: 24321ac668e452a4942598533d267805f291fdc9
powerpc/64/signal: Fix regression in __kernel_sigtramp_rt64() semantics
The first kernel change, puts code into the user space signal handler (in
the vdso) as a performance optimization to prevent the call/return stack
from getting out of balance. The patch ensures that the entire
user/kernel/vdso cycle is balanced with the addition of the "brctl"
instruction.
The second patch, fixes the semantics of __kernel_sigtramp_rt64(). A new
symbol is introduced to serve as the jump target from the kernel to the
trampoline which now consists of two parts.
The above changes for PowerPC signal handler, causes gdb to stop in the
kernel code not the user signal handler as expected. The kernel dispatches
to the vdso code which in turn calls into the signal handler. PowerPC is
special in that the kernel is using a vdso instruction (bctrl) to enter the
signal handler.
I do not have access to a system with the first patch but not the second. I did
test on Power 9 with the Linux 5.15.0-27-generic kernel. Both tests fail on
this Power 9 system. The two tests also fail on Power 10 with the Linux
5.14.0-70.9.1.el9_0.ppc64le kernel.
The following patch fixes the issue by checking if gdb stopped at "signal
handler called". If gdb stopped there, the tests verifies gdb is in the kernel
function __kernel_start_sigtramp_rt64 then does an additional stepi to reach the
user signal handler. With the patch below, the tests run without errors on both
the Power 9 and Power 10 systems with out any failures.
|
|
When running test-case gdb.dwarf2/locexpr-data-member-location.exp with
target board unix/-fno-PIE/-no-pie/-m32 I run into:
...
(gdb) step^M
26 return 0;^M
(gdb) FAIL: gdb.dwarf2/locexpr-data-member-location.exp: step into foo
...
The problem is that the test-case tries to mimic some gdb_compile_shlib
behaviour using:
...
set flags {additional_flags=-fpic debug}
get_func_info foo $flags
...
but this doesn't work with the target board setting, because we end up doing:
...
gcc locexpr-data-member-location-lib.c -fpic -g -lm -fno-PIE -no-pie -m32 \
-o func_addr23029.x
...
while gdb_compile_shlib properly filters out the -fno-PIE -no-pie.
Consequently, the address for foo determined by get_func_info doesn't match
the actual address of foo.
Fix this by printing the address of foo using the result of gdb_compile_shlib.
|
|
gdbarch_iterate_over_objfiles_in_search_order callback
A rather straightforward patch to change an instance of callback +
void pointer to gdb::function_view, allowing pasing lambdas that
capture, and eliminating the need for the untyped pointer.
Change-Id: I73ed644e7849945265a2c763f79f5456695b0037
|
|
native-extended-gdbserver board
Running
$ make check TESTS="gdb.gdb/unittest.exp" RUNTESTFLAGS="--target_board=native-extended-gdbserver"
I get some failures:
Running selftest regcache::cooked_write_test::i386.^M
Self test failed: target already pushed^M
Running selftest regcache::cooked_write_test::i386:intel.^M
Self test failed: target already pushed^M
Running selftest regcache::cooked_write_test::i386:x64-32.^M
Self test failed: target already pushed^M
Running selftest regcache::cooked_write_test::i386:x64-32:intel.^M
Self test failed: target already pushed^M
Running selftest regcache::cooked_write_test::i386:x86-64.^M
Self test failed: target already pushed^M
Running selftest regcache::cooked_write_test::i386:x86-64:intel.^M
Self test failed: target already pushed^M
Running selftest regcache::cooked_write_test::i8086.^M
Self test failed: target already pushed^M
This is because the native-extended-gdbserver automatically connects GDB
to a GDBserver on startup, and therefore pushes a remote target on the
initial inferior. cooked_write_test is currently written in a way that
errors out if the current inferior has a process_stratum_target pushed.
Rewrite it to use scoped_mock_context, so it doesn't depend on the
current inferior (the current one upon entering the function).
Change-Id: I0357f989eacbdecc4bf88b043754451b476052ad
|
|
My patches yesterday to unify the DWARF index base classes had a bug
-- namely, I did the wholesale dynamic_cast-to-static_cast too hastily
and introduced a crash. This can be seen by trying to add an index to
a file that has an index, or by running a test like gdb-index-cxx.exp
using the cc-with-debug-names.exp target board.
This patch fixes the crash by introducing a new virtual method and
removing some of the static casts.
|
