| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This commit improves the output of this previous commit:
commit 2dc3457a454a35d0617dc1f9cc1db77468471f95
Date: Fri Oct 14 13:22:55 2022 +0100
gdb: include breakpoint number in testing condition error message
The earlier commit extended the error message:
Error in testing breakpoint condition:
to include the breakpoint number, e.g.:
Error in testing breakpoint condition 3:
This commit extends takes this further, and includes the location
number if the breakpoint has multiple locations, so we might now see:
Error in testing breakpoint condition 3.2:
Just as with how GDB reports a normal breakpoint stop, if a breakpoint
only has a single location then the location number is not included,
this keeps things nice and consistent.
I've extended one of the tests to cover the new functionality.
Approved-By: Pedro Alves <pedro@palves.net>
|
|
Currently, the Fortran test suite does not run with NVIDIA's Fortran
compiler (nvfortran).
The goal here is to get the tests running and preventing further
regressions during future work. This change does not do anything to fix
existing failures.
Teach the compiler detection about nvfortran. There is no underlying
information about whether this compiler is related to flang classic or
flang, so we cannot reuse the main and type definitions. Therefore, we
explicitly record the main method and type information observed when
using nvfortran.
The main name was extracted by trying to set breakpoints on both MAIN_
and MAIN__.
The following mapping of test to type names was used to extract how
nvfortran reports types.
info-types.exp: fortran_int4, fortran_int8, fortran_real4,
fortran_logical4
common-block.exp: fortran_real8
complex.exp: fortran_complex4 fortran_complex8
logical.exp: fortran_character1. Ran ptype on "c".
Types defined as fortran_complex16 do not compile with nvfortran, so it
was left unset.
gdb.fortran regression tests run with GNU, Intel, Intel LLVM and ACfL.
No regressions detected.
The gdb.fortran test results with nvfortran 23.3 are as follows.
Before:
# of expected passes 523
# of unexpected failures 107
# of known failures 2
# of unresolved testcases 1
# of untested testcases 7
# of duplicate test names 2
After:
# of expected passes 5696
# of unexpected failures 271
# of known failures 12
# of untested testcases 9
# of unsupported tests 5
As can be seen from the above, there are now considerably more passing
assertions.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
When debugging C++ programs, it is possible to trigger a spurious assert
failure when attempting to set a breakpoint on a malformed symbol name.
Names of the form 'A>::B' and 'A)::B' trigger this assert failure in
cp_lookup_bare_symbol:
$ gdb gdb
[...]
(gdb) br test>::assert
Function "test>::assert" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (test>::assert) pending.
(gdb) start
[...]
cp-namespace.c:181: internal-error: cp_lookup_bare_symbol: Assertion `strstr (name, "::") == NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
0x5217e2 gdb_internal_backtrace_1
/home/amerey/binutils-gdb/gdb/bt-utils.c:122
0x521885 _Z22gdb_internal_backtracev
/home/amerey/binutils-gdb/gdb/bt-utils.c:168
0xaf8303 internal_vproblem
/home/amerey/binutils-gdb/gdb/utils.c:396
0xaf86be _Z15internal_verrorPKciS0_P13__va_list_tag
/home/amerey/binutils-gdb/gdb/utils.c:476
0xccdb3f _Z18internal_error_locPKciS0_z
/home/amerey/binutils-gdb/gdbsupport/errors.cc:58
0x5dded9 cp_lookup_bare_symbol
/home/amerey/binutils-gdb/gdb/cp-namespace.c:181
0x5de39d cp_lookup_symbol_in_namespace
/home/amerey/binutils-gdb/gdb/cp-namespace.c:328
[...]
Currently this assert is skipped if the symbol name contains '<' or '('.
Fix this spurious failure by also skipping the assert when the symbol
name contains '>' or ')'.
Regression tested on F38 x86_64.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
A co-worker, Andry, noticed that the DAP setExpression implementation
returned the wrong fields -- it used "result" rather than "value", and
included "memoryReference", which isn't in the spec (an odd oversight,
IMO).
This patch fixes the problems.
|
|
I noticed that the printf code for strings, printf_c_string and
printf_wide_c_string, don't take max-value-size into account, but do
load a complete string from the inferior into a GDB buffer.
As such it would be possible for an badly behaved inferior to cause
GDB to try and allocate an excessively large buffer, potentially
crashing GDB, or at least causing GDB to swap lots, which isn't
great.
We already have a setting to protect against this sort of thing, the
'max-value-size'. So this commit updates the two function mentioned
above to check the max-value-size and give an error if the
max-value-size is exceeded.
If the max-value-size is exceeded, I chose to continue reading
inferior memory to figure out how long the string actually is, we just
don't store the results. The benefit of this is that when we give the
user an error we can tell the user how big the string actually is,
which would allow them to correctly adjust max-value-size, if that's
what they choose to do.
The default for max-value-size is 64k so there should be no user
visible changes after this commit, unless the user was previously
printing very large strings. If that is the case then the user will
now need to increase max-value-size.
|
|
Given this test program:
#include <wchar.h>
const wchar_t wide_str[] = L"wide string";
int
main (void)
{
return 0;
}
I observed this GDB behaviour:
$ gdb -q /tmp/printf-wchar_t
Reading symbols from /tmp/printf-wchar_t...
(gdb) start
Temporary breakpoint 1 at 0x40110a: file /tmp/printf-wchar_t.c, line 8.
Starting program: /tmp/printf-wchar_t
Temporary breakpoint 1, main () at /tmp/printf-wchar_t.c:8
25 return 0;
(gdb) printf "%ls\n", wide_str
(gdb)
Notice that the printf results in a blank line rather than the
expected 'wide string' output.
I tracked the problem down to printf_wide_c_string (in printcmd.c), in
this function we do this:
struct type *wctype = lookup_typename (current_language,
"wchar_t", NULL, 0);
int wcwidth = wctype->length ();
the problem here is that 'wchar_t' is a typedef. If we look at the
comment on type::length() we see this:
/* Note that if thistype is a TYPEDEF type, you have to call check_typedef.
But check_typedef does set the TYPE_LENGTH of the TYPEDEF type,
so you only have to call check_typedef once. Since value::allocate
calls check_typedef, X->type ()->length () is safe. */
What this means is that after calling lookup_typename we should call
check_typedef in order to ensure that the length of the typedef has
been setup correctly. We are not doing this in printf_wide_c_string,
and so wcwidth is incorrectly calculated as 0. This is what leads GDB
to print an empty string.
We can see in c_string_operation::evaluate (in c-lang.c) an example of
calling check_typedef specifically to fix this exact issue.
Initially I did fix this problem by adding a check_typedef call into
printf_wide_c_string, but then I figured why not move the
check_typedef call up into lookup_typename itself, that feels like it
should be harmless when looking up a non-typedef type, but will avoid
bugs like this when looking up a typedef. So that's what I did.
I can then remove the extra check_typedef call from c-lang.c, I don't
see any other places where we had extra check_typedef calls. This
doesn't mean we definitely had bugs -- so long as we never checked the
length, or, if we knew that check_typedef had already been called,
then we would be fine.
I don't see any test regressions after this change, and my new test
case is now passing.
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
The license header on a file I recently contributed was incorrect.
The file was added in commit:
commit 087969169836f802a09b1cd0502d2f22d7a8f7dc
Date: Tue May 23 11:25:21 2023 +0100
gdb: handle core files with .reg/0 section names
The problems were:
- GPLv2 instead of GPLv3,
- Use the FSF postal address rather than their URL.
Nobody else has touched the file since I merged it, so I don't believe
there are any problems with me changing the license, this commit does
just that.
|
|
Only a few types in the Python API currently have __repr__()
implementations. This patch adds a few more of them. specifically: it
adds __repr__() implementations to gdb.Symbol, gdb.Architecture,
gdb.Block, gdb.Breakpoint, gdb.BreakpointLocation, and gdb.Type.
This makes it easier to play around the GDB Python API in the Python
interpreter session invoked with the 'pi' command in GDB, giving more
easily accessible tipe information to users.
An example of how this would look like:
(gdb) pi
>> gdb.lookup_type("char")
<gdb.Type code=TYPE_CODE_INT name=char>
>> gdb.lookup_global_symbol("main")
<gdb.Symbol print_name=main>
The gdb.Block.__repr__() method shows the first 5 symbols from the
block, and then a message to show how many more were elided (if any).
|
|
The previous commit added the test gdb.arch/core-file-pid0.exp which
tests GDB's ability to load a core file containing threads with an
lwpid of 0, which is something we GDB can encounter when loading a
vmcore file -- a core file generated by the Linux kernel. The threads
with an lwpid of 0 represents idle cores.
While the previous commit added the test, which confirms GDB doesn't
crash when confronted with such a core file, there are still some
problems with GDB's handling of these core files. These problems all
originate from the fact that the core file (once opened by bfd)
contains multiple sections called .reg/0, these sections all
represents different threads (cpu cores in the original vmcore dump),
but GDB gets confused and thinks all of these .reg/0 sections are all
referencing the same thread.
Here is a GDB session on an x86-64 machine which loads the core file
from the gdb.arch/core-file-pid0.exp, this core file contains two
threads, both of which have a pid of 0:
$ ./gdb/gdb --data-directory ./gdb/data-directory/ -q
(gdb) core-file /tmp/x86_64-pid0-core.core
[New process 1]
[New process 1]
Failed to read a valid object file image from memory.
Core was generated by `./segv-mt'.
Program terminated with signal SIGSEGV, Segmentation fault.
The current thread has terminated
(gdb) info threads
Id Target Id Frame
2 process 1 0x00000000004017c2 in ?? ()
The current thread <Thread ID 1> has terminated. See `help thread'.
(gdb) maintenance info sections
Core file: `/tmp/x86_64-pid0-core.core', file type elf64-x86-64.
[0] 0x00000000->0x000012d4 at 0x00000318: note0 READONLY HAS_CONTENTS
[1] 0x00000000->0x000000d8 at 0x0000039c: .reg/0 HAS_CONTENTS
[2] 0x00000000->0x000000d8 at 0x0000039c: .reg HAS_CONTENTS
[3] 0x00000000->0x00000080 at 0x0000052c: .note.linuxcore.siginfo/0 HAS_CONTENTS
[4] 0x00000000->0x00000080 at 0x0000052c: .note.linuxcore.siginfo HAS_CONTENTS
[5] 0x00000000->0x00000140 at 0x000005c0: .auxv HAS_CONTENTS
[6] 0x00000000->0x000000a4 at 0x00000714: .note.linuxcore.file/0 HAS_CONTENTS
[7] 0x00000000->0x000000a4 at 0x00000714: .note.linuxcore.file HAS_CONTENTS
[8] 0x00000000->0x00000200 at 0x000007cc: .reg2/0 HAS_CONTENTS
[9] 0x00000000->0x00000200 at 0x000007cc: .reg2 HAS_CONTENTS
[10] 0x00000000->0x00000440 at 0x000009e0: .reg-xstate/0 HAS_CONTENTS
[11] 0x00000000->0x00000440 at 0x000009e0: .reg-xstate HAS_CONTENTS
[12] 0x00000000->0x000000d8 at 0x00000ea4: .reg/0 HAS_CONTENTS
[13] 0x00000000->0x00000200 at 0x00000f98: .reg2/0 HAS_CONTENTS
[14] 0x00000000->0x00000440 at 0x000011ac: .reg-xstate/0 HAS_CONTENTS
[15] 0x00400000->0x00401000 at 0x00002000: load1 ALLOC LOAD READONLY HAS_CONTENTS
[16] 0x00401000->0x004b9000 at 0x00003000: load2 ALLOC READONLY CODE
[17] 0x004b9000->0x004e5000 at 0x00003000: load3 ALLOC READONLY
[18] 0x004e6000->0x004ec000 at 0x00003000: load4 ALLOC LOAD HAS_CONTENTS
[19] 0x004ec000->0x004f2000 at 0x00009000: load5 ALLOC LOAD HAS_CONTENTS
[20] 0x012a8000->0x012cb000 at 0x0000f000: load6 ALLOC LOAD HAS_CONTENTS
[21] 0x7fda77736000->0x7fda77737000 at 0x00032000: load7 ALLOC READONLY
[22] 0x7fda77737000->0x7fda77f37000 at 0x00032000: load8 ALLOC LOAD HAS_CONTENTS
[23] 0x7ffd55f65000->0x7ffd55f86000 at 0x00832000: load9 ALLOC LOAD HAS_CONTENTS
[24] 0x7ffd55fc3000->0x7ffd55fc7000 at 0x00853000: load10 ALLOC LOAD READONLY HAS_CONTENTS
[25] 0x7ffd55fc7000->0x7ffd55fc9000 at 0x00857000: load11 ALLOC LOAD READONLY CODE HAS_CONTENTS
[26] 0xffffffffff600000->0xffffffffff601000 at 0x00859000: load12 ALLOC LOAD READONLY CODE HAS_CONTENTS
(gdb)
Notice when the core file is first loaded we see two lines like:
[New process 1]
And GDB reports:
The current thread has terminated
Which isn't what we'd expect from a core file -- the core file should
only contain threads that are live at the point of the crash, one of
which should be the current thread. The above message is reported
because GDB has deleted what we think is the current thread!
And in the 'info threads' output we are only seeing a single thread,
again, this is because GDB has deleted one of the threads.
Finally, the 'maintenance info sections' output shows the cause of all
our problems, two sections named .reg/0. When GDB sees the first of
these it creates a new thread. But, when we see the second .reg/0 GDB
tries to create another new thread, but this thread has the same
ptid_t as the first thread, so GDB deletes the first thread and
creates the second thread in its place.
Because both these threads are created with an lwpid of 0 GDB reports
these are 'New process NN' rather than 'New LWP NN' which is what we
would normally expect.
The previous commit includes a little more of the history of GDB
support in this area, but these problems were discussed on the mailing
list a while ago in this thread:
https://inbox.sourceware.org/gdb-patches/AANLkTi=zuEDw6qiZ1jRatkdwHO99xF2Qu+WZ7i0EQjef@mail.gmail.com/
In this commit I propose a solution to these problems.
What I propose is that GDB should spot when we have .reg/0 sections
and, when these are found, should rename these sections using some
unique non-zero lwpid.
Note in the above output we also have sections like .reg2/0 and
.reg-xstate/0, these are additional register sets, this commit also
renumbers these sections inline with their .reg section.
The user is warned that some section renumbering has been performed.
GDB takes care to ensure that the new numbers assigned are unique and
don't clash with any of the pid's that might already be in use --
remember, in a real vmcore file, 0 is used to indicate an idle core,
non-idle cores will have the pid of whichever process was running on
that core, so we don't want GDB to assign an lwpid that clashes with
an actual pid that is in use in the core file.
After this commit here's the updated GDB session output:
$ ./gdb/gdb --data-directory ./gdb/data-directory/ -q
(gdb) core-file /tmp/x86_64-pid0-core.core
warning: found threads with pid 0, assigned replacement Target Ids: LWP 1, LWP 2
[New LWP 1]
[New LWP 2]
Failed to read a valid object file image from memory.
Core was generated by `./segv-mt'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00000000004017c2 in ?? ()
[Current thread is 1 (LWP 1)]
(gdb) info threads
Id Target Id Frame
* 1 LWP 1 0x00000000004017c2 in ?? ()
2 LWP 2 0x000000000040dda5 in ?? ()
(gdb) maintenance info sections
Core file: `/tmp/x86_64-pid0-core.core', file type elf64-x86-64.
[0] 0x00000000->0x000012d4 at 0x00000318: note0 READONLY HAS_CONTENTS
[1] 0x00000000->0x000000d8 at 0x0000039c: .reg/1 HAS_CONTENTS
[2] 0x00000000->0x000000d8 at 0x0000039c: .reg HAS_CONTENTS
[3] 0x00000000->0x00000080 at 0x0000052c: .note.linuxcore.siginfo/1 HAS_CONTENTS
[4] 0x00000000->0x00000080 at 0x0000052c: .note.linuxcore.siginfo HAS_CONTENTS
[5] 0x00000000->0x00000140 at 0x000005c0: .auxv HAS_CONTENTS
[6] 0x00000000->0x000000a4 at 0x00000714: .note.linuxcore.file/1 HAS_CONTENTS
[7] 0x00000000->0x000000a4 at 0x00000714: .note.linuxcore.file HAS_CONTENTS
[8] 0x00000000->0x00000200 at 0x000007cc: .reg2/1 HAS_CONTENTS
[9] 0x00000000->0x00000200 at 0x000007cc: .reg2 HAS_CONTENTS
[10] 0x00000000->0x00000440 at 0x000009e0: .reg-xstate/1 HAS_CONTENTS
[11] 0x00000000->0x00000440 at 0x000009e0: .reg-xstate HAS_CONTENTS
[12] 0x00000000->0x000000d8 at 0x00000ea4: .reg/2 HAS_CONTENTS
[13] 0x00000000->0x00000200 at 0x00000f98: .reg2/2 HAS_CONTENTS
[14] 0x00000000->0x00000440 at 0x000011ac: .reg-xstate/2 HAS_CONTENTS
[15] 0x00400000->0x00401000 at 0x00002000: load1 ALLOC LOAD READONLY HAS_CONTENTS
[16] 0x00401000->0x004b9000 at 0x00003000: load2 ALLOC READONLY CODE
[17] 0x004b9000->0x004e5000 at 0x00003000: load3 ALLOC READONLY
[18] 0x004e6000->0x004ec000 at 0x00003000: load4 ALLOC LOAD HAS_CONTENTS
[19] 0x004ec000->0x004f2000 at 0x00009000: load5 ALLOC LOAD HAS_CONTENTS
[20] 0x012a8000->0x012cb000 at 0x0000f000: load6 ALLOC LOAD HAS_CONTENTS
[21] 0x7fda77736000->0x7fda77737000 at 0x00032000: load7 ALLOC READONLY
[22] 0x7fda77737000->0x7fda77f37000 at 0x00032000: load8 ALLOC LOAD HAS_CONTENTS
[23] 0x7ffd55f65000->0x7ffd55f86000 at 0x00832000: load9 ALLOC LOAD HAS_CONTENTS
[24] 0x7ffd55fc3000->0x7ffd55fc7000 at 0x00853000: load10 ALLOC LOAD READONLY HAS_CONTENTS
[25] 0x7ffd55fc7000->0x7ffd55fc9000 at 0x00857000: load11 ALLOC LOAD READONLY CODE HAS_CONTENTS
[26] 0xffffffffff600000->0xffffffffff601000 at 0x00859000: load12 ALLOC LOAD READONLY CODE HAS_CONTENTS
(gdb)
Notice the new warning which is issued when the core file is being
loaded. The threads are announced as '[New LWP NN]', and we see two
threads in the 'info threads' output. The 'maintenance info sections'
output shows the result of the section renaming.
The gdb.arch/core-file-pid0.exp test has been update to check for the
improved GDB output.
Reviewed-By: Kevin Buettner <kevinb@redhat.com>
|
|
This patch contains a test for this commit:
commit c820c52a914cc9d7c63cb41ad396f4ddffff2196
Date: Fri Aug 6 19:45:58 2010 +0000
* thread.c (add_thread_silent): Use null_ptid instead of
minus_one_ptid while getting rid of stale inferior_ptid.
This is another test that has been carried in the Fedora GDB tree for
some time, and I thought that it would be worth merging to master. I
don't believe there is any test like this currently in the testsuite.
The original issue was reported in this thread:
https://inbox.sourceware.org/gdb-patches/AANLkTi=zuEDw6qiZ1jRatkdwHO99xF2Qu+WZ7i0EQjef@mail.gmail.com/
The problem was that when GDB was used to open a vmcore (core file)
image generated by the Linux kernel GDB would (sometimes) crash with
an assertion failure:
thread.c:884: internal-error: switch_to_thread: Assertion `inf != NULL' failed.
To understand what's going on we need some background; a vmcore file
represents each processor core in the same way that a standard
application core file represents threads. Thus, we might say, a
vmcore file represents cores as threads.
When writing a vmcore file, the kernel will store the pid of the
process currently running on that core as the thread's lwpid.
However, if a core is idle, with no process currently running on it,
then the lwpid for that thread is stored as 0 in the vmcore file. If
multiple cores are idle then multiple threads will have a lwpid of 0.
Back in 2010, the original issue reported tried to change the kernel's
behaviour in this thread:
https://lkml.org/lkml/2010/8/3/75
This change was rejected by the kernel team, the current
behaviour (lwpid of 0) was considered correct. I've checked the
source of a recent kernel. The code mentioned in the lkml.org posting
has moved, it's now in the function crash_save_cpu in the file
kernel/kexec_core.c, but the general behaviour is unchanged, an idle
core will have an lwpid of 0, so I think GDB still needs to be able to
handle this case.
When GDB loads a vmcore file (which is handled just like any other
core file) the sections are processed in core_open to generate the
threads for the core file. The processing is done by calling
add_to_thread_list, a function which looks for sections named .reg/NN
where NN is the lwpid of the thread, GDB then builds a ptid_t for the
new thread and calls add_thread.
Remember, in our case the lwpid is 0. Now for the first thread this
is fine, if a little weird, 0 isn't usually a valid lwpid, but that's
OK, GDB creates a thread with lwpid of 0 and carries on.
When we find the next thread (core) with lwpid of 0, we attempt to
create another thread with an lwpid of 0. This of course clashes with
the previously created thread, they have the same ptid_t, so GDB tries
to delete the first thread.
And it was within this thread delete code that we triggered a bug
which would then cause GDB to assert -- when deleting we tried to
switch to a thread with minus_one_ptid, this resulted in a call to
find_inferior_pid (passing in minus_one_ptid's pid, which is -1), the
find_inferior_pid call fails and returns NULL, which then triggered an
assert in switch_to_thread.
The actual details of the why the assert triggered are really not
important. What's important (I think) is that a vmcore file might
have this interesting lwpid of 0 characteristic, which isn't something
we see in "normal" application core files, and it is this that I think
we should be testing.
Now, you might be thinking: isn't deleting the first thread the wrong
thing to do? If the vmcore file has two threads that represent two
cores, and both have an lwpid of 0 (indicating both cores are idle),
then surely GDB should still represent this as two threads? You're
not wrong. This was mentioned by Pedro in the original GDB mailing
list thread here:
https://inbox.sourceware.org/gdb-patches/201008061057.03037.pedro@codesourcery.com/
This is indeed a problem, and this problem is still present in GDB
today. I plan to try and address this in a later commit, however,
this first commit is about getting a test in place to confirm that GDB
at a minimum doesn't crash when loading such a vmcore file.
And so, finally, what's in this commit?
This commit contains a new test. The test doesn't actually contain a
vmcore file. Instead I've created a standard application core file
that contains two threads, and then manually edited the core file to
set the lwpid of each thread to 0.
To further reduce the size of the core file (as it will be stored in
git), I've zeroed all of the LOAD-able segments in the core file.
This test really doesn't care about that part of the core file, we
only really care about loading the register's, this is enough to
confirm that the GDB doesn't crash.
Obviously as the core file is pre-generated, this test is architecture
specific. There are already a few tests in gdb.arch/ that include
pre-generate core files. Just as those existing tests do, I've
compressed the core file with bzip2, which reduces it to just 750
bytes. I have structured the test so that if/when this patch is
merged I can add some additional core files for other architectures,
however, these are not included in this commit.
The test simply expands the core file, and then loads it into GDB.
One interesting thing to note is that GDB reports the core file
loading like this:
(gdb) core-file ./gdb/testsuite/outputs/gdb.arch/core-file-pid0/core-file-pid0.x86-64.core
[New process 1]
[New process 1]
Failed to read a valid object file image from memory.
Core was generated by `./segv-mt'.
Program terminated with signal SIGSEGV, Segmentation fault.
The current thread has terminated
(gdb)
There's two interesting things here: first, the repeated "New process
1" message. This is caused because linux_core_pid_to_str reports
anything with an lwpid of 0 as a process, rather than an LWP. And
second, the "The current thread has terminated" message. This is
because the first thread in the core file is the current thread, but
when GDB loads the second thread (which also has lwpid 0) this causes
the first thread to be deleted, as a result GDB thinks that the
current (first) thread has terminated.
As I said previously, both of these problems are a result of the lwpid
0 aliasing, which is not being fixed in this commit -- this commit is
just confirming that GDB doesn't crash when loading this core file.
Reviewed-By: Kevin Buettner <kevinb@redhat.com>
|
|
Commit 80eaec735e ("[gdb/symtab] Handle named DW_TAG_unspecified_type
DIE") changed the handling of DW_TAG_unspecified_type. Before this
change, such types were not entered into the symbol table.
It turns out that, when such a type is in the symtab, it can cause
failures in Ada. In particular, a private type in another package may
be seen locally as "void".
Now, it would probably be better to fix this via check_typedef.
However, that is somewhat difficult given the state of the DWARF
reader -- in particular with gdb_index, this would require expanding
potentially many CUs to find the correct type.
Instead, this patch changes gdb to not enter a symbol for an
unspecified type -- but only for Ada.
|
|
This testcase sometimes gets stuck in a loop for hours when running in our
CI. The problem is that due to an issue unrelated to reverse debugging the
inferior exits early, and because of the overly generic ".*" pattern the
testcase keeps sending the "next" command without noticing that the
inferior is gone.
gdb_test_multiple has a pattern to detect that "The program is not being
run.", but since it is placed after the patterns from the caller it won't
be triggered. It also has a timeout pattern but because it is triggered
between successful matches, each time the test matches the '-re -wrap ".*"'
this counts as a successful match and the timeout is reset.
Since the test binary is compiled with debug information, fix by changing
one of the generic patterns to match entering the main function and the
other one to match the source code line number that is shown by GDB right
after the "step" command.
Also, as a precaution add a maximum number of times the "next" command will
be sent.
Co-Authored-By: Tom de Vries <tdevries@suse.de>
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
Python 3.11 changed the AttributeError message - see commit
0cb765b2cec9 ("bpo-46730: Add more info to @property AttributeError
messages (GH-31311)"). Add the new message to the expectations.
Approved-By: Tom Tromey <tom@tromey.com>
Link: https://sourceware.org/pipermail/gdb-patches/2023-June/200433.html
|
|
In commit e2adba909e7 ("[gdb/testsuite] Clean up before compilation in
gdb.ada/call-no-debug.exp") I added some code in the test-case to remove some
files at the start of the test-case:
...
remote_file host delete [standard_output_file prog.o]
remote_file host delete [standard_output_file prog.ali]
...
Then in commit b7b77500dc5 ("[gdb/testsuite] Clean standard_output_file dir in
gdb_init") I tried to do this more structurally, by cleaning up the entire
standard_output_file directory, for all test-cases.
This caused a regression when using "make check -j 2", due to the cleanup
removing the active gdb.log, so I reverted the commit.
Try again, this time handling the two cases separately.
If the standard_output_file directory contains an active gdb.log, check that
the directory contains no files other than gdb.log and gdb.sum. This puts
the reponsibility for the cleanup at the callers in gdb/testsuite/Makefile.in
which use --outdir.
If the standard_output_file directory doesn't contain an active gdb.log, clean
it by removing the entire directory.
An exception is made for performance tests, where cleaning up the
standard_output_file dir is the wrong thing to do, because an invocation with
GDB_PERFTEST_MODE == run is intended to reuse binaries left there by an
earlier invocation with GDB_PERFTEST_MODE == compile.
Tested on x86_64-linux.
Suggested-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Tom Tromey <tom@tromey.com>
Tested-By: Luis Machado <luis.machado@arm.com>
|
|
A DAP client can request that an expression be evaluated in "hover"
context, meaning that it should not cause side effects. In gdb, this
can be implemented by temporarily setting a few "may-" parameters to
"off".
In order to make this work, I had to also change "may-write-registers"
so that it can be changed while the program is running. I don't think
there was any reason for this prohibition in the first place.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30476
|
|
DAP allows a source breakpoint to specify a log message. When this is
done, the breakpoint acts more like gdb's dprintf: it logs a message
but does not cause a stop.
I looked into implement this using dprintf with the new %V printf
format. However, my initial attempt at this did not work, because
when the inferior is continued, the dprintf output is captured by the
gdb.execute call. Maybe this could be fixed by having all
inferior-continuation commands use the "&" form; the main benefit of
this would be that expressions are only parsed a single time.
|
|
A bug report about the supportsVariablePaging capability in DAP
resulted in a clarification: when this capability is not present, DAP
implementations should ignore the paging parameters to the "variables"
request. This patch implements this clarification.
|
|
When creating a DAP breakpoint, a failure should be returned by
setting "verified" to False. gdb didn't properly implement this, and
there was a FIXME comment to this effect. This patch fixes the
problem.
|
|
DAP specifies a breakpoint's hitCondition as a string, meaning it is
an expression to be evaluated. However, gdb implemented this as if it
were an integer instead. This patch fixes this oversight.
|
|
With test-case gdb.tui/pr30056.exp, I run into:
...
sh: warning: setlocale: LC_ALL: cannot change locale (C.UTF-8)^M
...
and then subsequently into:
...
WARNING: timeout in accept_gdb_output
FAIL: gdb.tui/pr30056.exp: Control-C
...
This is on a CentOS 7 distro for powerpc64le.
Either it has no C.UTF-8 support, or it's not installed:
...
$ locale -a | grep ^C
C
$
...
Fix this by:
- adding a new proc have_host_locale, and
- using it in all test-cases using setenv LC_ALL.
Tested on powerpc64le-linux and x86_64-linux.
|
|
PR testsuite/30458 reports the following FAIL:
...
PASS: gdb.tui/wrap-line.exp: width-auto-detected: cli: wrap
^CQuit
(gdb) WARNING: timeout in accept_gdb_output
Screen Dump (size 50 columns x 24 rows, cursor at column 6, row 3):
0 Quit
1 (gdb) 7890123456789012345678901234567890123456789
2 W^CQuit
3 (gdb)
...
FAIL: gdb.tui/wrap-line.exp: width-auto-detected: cli: prompt after wrap
...
The problem is that the regexp doesn't account for the ^C:
...
gdb_assert { [Term::wait_for "^WQuit"] } "prompt after wrap"
...
The ^C occurs occasionally. This is something we'd like to fix. It's
reported as a readline problem here (
https://lists.gnu.org/archive/html/bug-readline/2023-06/msg00000.html ).
For now, fix this by updating the regexp, and likewise in another place in the
test-case where we use ^C.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30458
|
|
Say we run test-case gdb.tui/basic.exp. It calls Term::enter_tui, which does:
...
command_no_prompt_prefix "tui enable"
...
The proc command_no_prompt_prefix is documented as:
...
# As proc command, but don't wait for an initial prompt. This is used for
# initial terminal commands, where there's no prompt yet.
...
Indeed, before the "tui enable" command, the tuiterm is empty, so there is no
prompt and just before switching to TUI we have in the tuiterm:
...
tui enable
...
The reason that there is no prompt, is that:
- in order for tuiterm to show something, its input processing procs need to
be called, and
- the initial gdb prompt, and subsequent prompts generated by gdb_test-style
procs, are all consumed by those procs instead.
This is in principle not a problem, but the absence of a prompt makes a
tuiterm session look less like a session on an actual xterm.
Add a new proc gen_prompt, that:
- generates a prompt using echo
- consumes the response before the prompt using gdb_expect
- consumes the prompt using Term::wait_for "".
This allows us to reimplement Term::command_no_prompt_prefix using
Term::command, and just before switching to TUI we have in the tuiterm:
...
(gdb) tui enable
...
Tested on x86_64-linux.
|
|
The semantics of Term::wait_for is:
...
# Accept some output from gdb and update the screen. WAIT_FOR is
# a regexp matching the line to wait for. Return 0 on timeout, 1
# on success.
proc wait_for {wait_for} {
...
Note that besides the regexp, also a subsequent gdb prompt is matched.
I recently used wait_for "" in a few test-cases, thinking that this would
match just a prompt, but in fact that's not the case.
Fix this in wait_for, and add a corresponding test in gdb.tui/tuiterm-2.exp.
Tested on x86_64-linux.
|
|
This reverts commit b7b77500dc56e5bc21473dd4f3dde2543d894557.
|
|
Python formatting errors fixed, introduced by this commit.
|
|
v6:
Fix comments.
Fix copyright
Remove unnecessary test suite stuff. save_var had to stay, as it mutates
some test suite state that otherwise fails.
v5:
Did what Tom Tromey requested in v4; which can be found here: https://pi.simark.ca/gdb-patches/87pmjm0xar.fsf@tromey.com/
v4:
Doc formatting fixed.
v3:
Eli:
Updated docs & NEWS to reflect new changes. Added
a reference from the .ptid attribute of the ThreadExitedEvent
to the ptid attribute of InferiorThread. To do this,
I've added an anchor to that attribute.
Tom:
Tom requested that I should probably just emit the thread object;
I ran into two issues for this, which I could not resolve in this patch;
1 - The Thread Object (the python type) checks it's own validity
by doing a comparison of it's `thread_info* thread` to nullptr. This
means that any access of it's attributes may (probably, since we are
in "async" land) throw Python exceptions because the thread has been
removed from the thread object. Therefore I've decided in v3 of this
patch to just emit most of the same fields that gdb.InferiorThread has, namely
global_num, name, num and ptid (the 3-attribute tuple provided by
gdb.InferiorThread.ptid).
2 - A python user can hold a global reference to an exiting thread. Thus
in order to have a ThreadExit event that can provide attribute access
reliably (both as a global reference, but also inside the thread exit
handler, as we can never guarantee that it's executed _before_ the
thread_info pointer is removed from the gdbpy thread object),
the `thread_info *` thread pointer must not be null. However, this
comes at the cost of gdb.InferiorThread believing it is "valid" - which means,
that if a user holds takes a global reference to that
exiting event thread object, they can some time later do `t.switch()` at which
point GDB will 'explode' so to speak.
v2:
Fixed white space issues and NULL/nullptr stuff,
as requested by Tom Tromey.
v1:
Currently no event is emitted for a thread exit.
This adds this functionality by emitting a new gdb.ThreadExitedEvent.
It currently provides four attributes:
- global_num: The GDB assigned global thread number
- num: the per-inferior thread number
- name: name of the thread or none if not set
- ptid: the PTID of the thread, a 3-attribute tuple, identical to
InferiorThread.ptid attribute
Added info to docs & the NEWS file as well.
Added test to test suite.
Fixed formatting.
Feedback wanted and appreciated.
|
|
Test-case gdb.ada/catch_ex_std.exp passes for me with package
libada7-debuginfo installed, but after removing it I get:
...
(gdb) catch exception some_kind_of_error^M
Your Ada runtime appears to be missing some debugging information.^M
Cannot insert Ada exception catchpoint in this configuration.^M
(gdb) FAIL: gdb.ada/catch_ex_std.exp: catch exception some_kind_of_error
...
The test-case contains a require gnat_runtime_has_debug_info to deal with
this, but the problem is that this checks the static gnat runtime, while this
test-case uses the shared one.
Fix this by introducing shared_gnat_runtime_has_debug_info, and requiring that
one instead.
Tested on x86_64-linux.
PR testsuite/30094
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30094
|
|
In commit e2adba909e7 ("[gdb/testsuite] Clean up before compilation in
gdb.ada/call-no-debug.exp") I added some code in the test-case to remove some
files at the start of the test-case:
...
remote_file host delete [standard_output_file prog.o]
remote_file host delete [standard_output_file prog.ali]
...
Replace this with cleaning up the entire directory instead, for all
test-cases.
Tested on x86_64-linux.
Suggested-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
on openSUSE Leap 42.3, with python 3.4, I run into a
"SyntaxError: invalid syntax" due to usage of an f-string in test-case
gdb.python/py-unwind.py.
Fix this by using string concatenation using '+' instead.
Tested on x86_64-linux.
|
|
When running test-case gdb.arch/i386-disp-step.exp with target board
unix/-m32/-fPIE/-pie we run into:
...
gdb compile failed, ld: i386-disp-step0.o: warning: relocation in read-only section `.text'
ld: warning: creating DT_TEXTREL in a PIE
...
Fix this by adding nopie in the compilation flags.
Likewise in a few other test-cases.
Tested on x86_64-linux.
|
|
In test-case gdb.dwarf2/implptr.exp I noticed:
...
} elseif {![is_x86_like_target]} {
# This test can only be run on x86 targets.
unsupported "needs x86-like target"
return 0
}
...
Use instead "require is_x86_like_target".
Tested on x86_64-linux.
|
|
Running test-case gdb.ada/call-no-debug.exp with target board unix/-m64 works
fine, but if we run it again with target board unix-m32, we run into:
...
gnatlink prog.ali -m32 -g -o prog^M
ld: i386:x86-64 architecture of input file `b~prog.o' is incompatible with \
i386 output^M
...
This is due to compiling with no-force.
The test-case:
- first compiles pck.adb into pck.o (without debug info), and
- then compiles prog.adb and pck.o into prog (with debug info).
Using no-force in the second compilation make sure that pck.adb is not
compiled again, with debug info.
But it also means it will pick up intermediate files related to prog.adb from
a previous compilation.
Fix this by removing prog.o and prog.ali before compilation.
Tested on x86_64-linux.
|
|
In commit 0f2cd53cf4f ("[gdb/testsuite] Handle missing .note.GNU-stack") I
updated a gdb.arch/arm*.S test-case to use %progbits rather than @progbits,
but failed to do so for gdb.arch/thumb*.S. Fix this oversight.
Tested on arm-linux-gnueabihf.
|
|
In test-case gdb.base/step-over-exit.exp, we set a breakpoint on _exit and
continue, expecting to hit the breakpoint.
Without glibc debug info installed, we have with target board unix/-m64:
...
Thread 2.1 "step-over-exit" hit Breakpoint 2.2, 0x00007ffff7d46aee in \
_exit () from /lib64/libc.so.6^M
(gdb) PASS: gdb.base/step-over-exit.exp: continue to exit
...
and with target board unix/-m32:
...
Thread 2.1 "step-over-exit" hit Breakpoint 2.2, 0xf7d84c25 in _exit () from \
/lib/libc.so.6^M
(gdb) PASS: gdb.base/step-over-exit.exp: continue to exit
...
However after installing debug info (packages glibc-debuginfo and
glibc-32bit-debuginfo), we have for -m64 (note: __GI__exit instead of _exit):
...
Thread 2.1 "step-over-exit" hit Breakpoint 2.2, \
__GI__exit (status=<optimized out>) at \
../sysdeps/unix/sysv/linux/_exit.c:27^M
27 {^M
(gdb) PASS: gdb.base/step-over-exit.exp: continue to exit
...
and -m32 (note: _Exit instead of _exit):
...
Thread 2.1 "step-over-exit" hit Breakpoint 2.2, _Exit () at \
../sysdeps/unix/sysv/linux/i386/_exit.S:24^M
24 ../sysdeps/unix/sysv/linux/i386/_exit.S: No such file or directory.^M
(gdb) FAIL: gdb.base/step-over-exit.exp: continue to exit
...
The gdb_test allows for both _exit and __GI__exit, but not _Exit:
...
gdb_test "continue" \
"Continuing\\..*Breakpoint $decimal.*_exit \\(.*\\).*" \
"continue to exit"
...
Fix this by allowing _Exit as well.
Tested on x86_64-linux.
|
|
When running test-case gdb.tui/long-prompt.exp with check-read1, we get:
...
(gdb) FAIL: gdb.tui/long-prompt.exp: prompt size == width + 1: \
end of screen: at last line
...
The problem is in these commands:
...
Term::command "echo \\n"
Term::command "echo \\n"
Term::command "echo \\n"
Term::command "echo \\n"
...
The last one makes the terminal scroll, and the scrolling makes the expected
output match on a different line.
Fix this by replacing the sequence with a single command:
...
Term::command "echo \\n\\n\\n\\n\\n\\n"
...
which avoids scrolling.
Tested on x86_64-linux.
|
|
There is a test-case that contains a unit test for tuiterm:
gdb.tui/tuiterm.exp.
However, this only excercises the tuiterm itself, and not the functions that
interact with it, like Term::command.
Add a new test-case gdb.tui/tuiterm-2.exp that:
- overrides proc accept_gdb_output (to be able simulate incorrect responses
while avoiding the timeout),
- overrides proc send_gdb (to be able to call Term::command without a gdb
instance, such that all tuiterm input is generated by the test-case).
- issues Term::command calls, and
- checks whether they behave correctly.
This exposes a problem in Term::command. The "prompt before command" regexp
starts with a bit that is supposed to anchor the prompt to the border:
...
set str "(^|\|)$gdb_prompt $str"
...
but that doesn't work due to insufficient escaping. Fix this by adding the
missing escape:
...
set str "(^|\\|)$gdb_prompt $str"
...
Futhermore, the "prompt after command" regexp in Term::wait_for has no
anchoring at all:
...
set prompt_wait_for "$gdb_prompt \$"
...
so add that as well.
Tested on x86_64-linux.
|
|
Currently proc with_override does not work with procs with default value args.
Fix this, and add a test-case excercising this scenario.
Tested on x86_64-linux.
|
|
On openSUSE Leap 15.4 with system python 3.6, I run into:
...
(gdb) python check_everything()^M
(gdb) FAIL: gdb.dap/type_check.exp: type checker
...
In check_everything, the hasattr test fails silently:
...
def check_everything():
# Older versions of Python can't really implement this.
if hasattr(typing, "get_origin"):
...
and that makes the gdb_test in the test-case fail.
Fix this by emitting UNSUPPORTED instead in check_everything, and detecting
this in the test-case.
Tested on x86_64-linux.
|
|
We recently realized that symbol_needs_eval_fail.exp and
symbol_needs_eval_timeout.exp invalidly dereference an int (4 bytes on
x86_64) by reading 8 bytes (the size of a pointer).
Here how it goes:
In gdb/testsuite/gdb.dwarf2/symbol_needs_eval.c a global variable is
defined:
int exec_mask = 1;
and later both tests build some DWARF using the assembler doing:
set exec_mask_var [gdb_target_symbol exec_mask]
...
DW_TAG_variable {
{DW_AT_name a}
{DW_AT_type :$int_type_label}
{DW_AT_location {
DW_OP_addr $exec_mask_var
DW_OP_deref
...
}
}
The definition of the DW_OP_deref (from Dwarf5 2.5.1.3 Stack Operations)
says that "The size of the data retrieved from the dereferenced address
is the size of an address on the target machine."
On x86_64, the size of an int is 4 while the size of an address is 8.
The result is that when evaluating this expression, the debugger reads
outside of the `a` variable.
Fix this by using `DW_OP_deref_size $int_size` instead. To achieve
this, this patch adds the necessary steps so we can figure out what
`sizeof(int)` evaluates to for the current target.
While at it, also change the definition of the int type in the assembled
DWARF information so we use the actual target's size for an int instead
of the literal 4.
Tested on x86_64 Linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Currently the Fortran test suite does not run with armflang because the
compiler detection fails. This in turn means fortran_runto_main does not
know which main method to use to start a test case.
Fortran compiler detection was added in 44d469c5f85; however, the commit
message notes that it was not tested with armflang.
This commit tests and fixes up a minor issue to get the detection
working.
The goal here is to get the tests running and preventing further
regressions during future work. This change does not do anything to fix
existing failures.
>From what I can understand, the auto detection leverages the
preprocessor to extract the Fortran compiler identity from the defines.
This preprocessor output is then evaluated by the test suite to import
these defines.
In the case of armflang, this evaluation step is disrupted by the
presence of the following warning:
$ armflang -E -fdiagnostics-color=never testsuite/lib/compiler.F90 -o compiler.exp
$ clang-13: warning: argument unused during compilation: '-fdiagnostics-color=never' [-Wunused-command-line-argument]
The evaluation logic is already set up to filter this warning, but the
prefix differs.
This commit fixes the issue by updating the filter to exclude the
armflang flavour of warning.
gdb.fortran regression tests run with GNU, Intel and Intel LLVM. No
regressions detected.
The gdb.fortran test results with ACfL 23.04.1 are as follows.
Before:
# of expected passes 560
# of unexpected failures 113
# of unresolved testcases 2
# of untested testcases 5
# of duplicate test names 2
After:
# of expected passes 5388
# of unexpected failures 628
# of known failures 10
# of untested testcases 8
# of unsupported tests 5
# of duplicate test names 5
As can be seen from the above, there are now considerably more passing
assertions.
Reviewed-By: Luis Machado <luis.machado@arm.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I realized that I had only implemented DAP breakpoint conditions for
exception breakpoints, and not other kinds of breakpoints. This patch
corrects the oversight.
|
|
This implements the DAP breakpointLocations request.
|
|
Co-workers who work on a program that uses DAP asked for the ability
to have gdb stop at the main subprogram when launching. This patch
implements this extension.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
This adds a new "target" to the DAP attach request. This is passed to
"target remote". I thought "attach" made the most sense for this,
because in some sense gdb is attaching to a running process. It's
worth noting that all DAP "attach" parameters are defined by the
implementation.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
A DAP client can report the supportsVariableType capability in the
initialize request. In this case, gdb can include the type of a
variable or expression in various results.
|
|
This implements the DAP setExpression request.
|
|
This adds an 'assign' method to gdb.Value. This allows for assignment
without requiring the use of parse_and_eval.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
It occurred to me recently that gdb's DAP implementation should
probably check the types of objects coming from the client. This
patch implements this idea by reusing Python's existing type
annotations, and supplying a decorator that verifies these at runtime.
Python doesn't make it very easy to do runtime type-checking, so the
core of the checker is written by hand. I haven't tried to make a
fully generic runtime type checker. Instead, this only checks the
subset that is needed by DAP. For example, only keyword-only
functions are handled.
Furthermore, in a few spots, it wasn't convenient to spell out the
type that is accepted. I've added a couple of comments to this effect
in breakpoint.py.
I've tried to make this code compatible with older versions of Python,
but I've only been able to try it with 3.9 and 3.10.
|
|
I neglected to write a test for the DAP "pause" request. This patch
adds one.
|
|
A few DAP requests support a "singleThread" parameter, which is
somewhat similar to scheduler-locking. This patch implements support
for this.
|
