| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Remove a stray trailing backslash from `test-integer' in settings.exp.
It is harmless as only white space follows in the next line before the
closing brace, so it merely swallows the newline character, but it may
look confusing to the reader.
|
|
Copyright-paperwork-exempt: yes
|
|
If an auto-load script cannot be found and objfile is a separate
debuginfo whose filename does not match the name found in the parent
file's .gnu_debuglink section, then repeat the search using the
parent's filename where the last component is replaced with the
.gnu_debuglink name.
For example if the parent's filename is "/usr/lib/libxyz.so" and the
name in its .gnu_debuglink section is "libxyz.so.debug", then
if no auto-load script is otherwise found the search will be
repeated with the filename "/usr/lib/libxyz.so.debug".
This helps gdb locate auto-load scripts when debuginfo files do not have
the expected filename, such as when they are aquired from debuginfod.
|
|
across mi / (gdb)info source
Source files downloaded from debuginfod currently use their original DWARF
filename as their "fullname". This causes a mismatch between the fullname
and the actual location of the source file in the debuginfod client cache.
MI consumers such as VSCode will fail to open debuginfod-downloaded
source files due to this. Also 'info source' will fail to include the
true paths of these files.
To fix this, use the debuginfod cache path as the fullname for debuginfod-
downloaded source files.
|
|
Fix for PR gdb/20684. When invoking MI commands with --thread and/or
--frame, the user selected thread and frame was not preserved:
(gdb)
info thread
&"info thread\n"
~" Id Target Id Frame \n"
~"* 1 Thread 0x7ffff7c30740 (LWP 19302) \"user-selected-c\" main () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:60\n"
~" 2 Thread 0x7ffff7c2f700 (LWP 19306) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n"
~" 3 Thread 0x7ffff742e700 (LWP 19307) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n"
^done
(gdb)
info frame
&"info frame\n"
~"Stack level 0, frame at 0x7fffffffdf90:\n"
~" rip = 0x555555555207 in main (/home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:60); saved rip = 0x7ffff7c5709b\n"
~" source language c.\n"
~" Arglist at 0x7fffffffdf80, args: \n"
~" Locals at 0x7fffffffdf80, Previous frame's sp is 0x7fffffffdf90\n"
~" Saved registers:\n "
~" rbp at 0x7fffffffdf80, rip at 0x7fffffffdf88\n"
^done
(gdb)
-stack-info-depth --thread 3
^done,depth="4"
(gdb)
info thread
&"info thread\n"
~" Id Target Id Frame \n"
~" 1 Thread 0x7ffff7c30740 (LWP 19302) \"user-selected-c\" main () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:60\n"
~" 2 Thread 0x7ffff7c2f700 (LWP 19306) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n"
~"* 3 Thread 0x7ffff742e700 (LWP 19307) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n"
^done
(gdb)
info frame
&"info frame\n"
~"Stack level 0, frame at 0x7ffff742dee0:\n"
~" rip = 0x555555555169 in child_sub_function (/home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30); saved rip = 0x555555555188\n"
~" called by frame at 0x7ffff742df00\n"
~" source language c.\n"
~" Arglist at 0x7ffff742ded0, args: \n"
~" Locals at 0x7ffff742ded0, Previous frame's sp is 0x7ffff742dee0\n"
~" Saved registers:\n "
~" rbp at 0x7ffff742ded0, rip at 0x7ffff742ded8\n"
^done
(gdb)
This caused problems for frontends that provide access to CLI because UI
may silently change the context for CLI commands (as demonstrated above).
This commit fixes the problem by restoring thread and frame in
mi_cmd_execute (). With this change, there are only two GDB/MI commands
that can change user selected context: -thread-select and -stack-select-frame.
This allows us to remove all and rather complicated logic of notifying
about user selected context change from mi_execute_command (), leaving it
to these two commands themselves to notify.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20684
|
|
As has been discussed here:
https://sourceware.org/pipermail/gdb-patches/2022-January/184910.html
Python 2 support will be removed from GDB after GDB 12 has branched.
This commit places an entry in the NEWS file to inform users of this
decision.
|
|
There's an interesting property of the 'char' type in C and C++, the
three types 'char', 'unsigned char', and 'signed char', are all
considered distinct.
In contrast, and 'int' is signed by default, and so 'int' and 'signed
int' are considered the same type.
This commit adds a test to ensure that this edge case is visible to a
user from Python.
It is worth noting that for any particular compiler implementation (or
the flags a compiler was invoked with), a 'char' will be either signed
or unsigned; it has to be one or the other, and a user can access this
information by using the Type.is_signed property. However, for
something like function overload resolution, the 'char' type is
considered distinct from the signed and unsigned variants.
There's no change to GDB with this commit, this is just adding a new
test to guard some existing functionality.
|
|
Add a new read-only property, Type.is_signed, which is True for signed
types, and False otherwise.
This property should only be read on types for which Type.is_scalar is
true, attempting to read this property for non-scalar types will raise
a ValueError.
I chose 'is_signed' rather than 'is_unsigned' in order to match the
existing Architecture.integer_type method, which takes a 'signed'
parameter. As far as I could find, that was the only existing
signed/unsigned selector in the Python API, so it seemed reasonable to
stay consistent.
|
|
Add a new read-only property which is True for scalar types,
otherwise, it's False.
|
|
Following on from the previous commit, where the -add-inferior command
now uses the same connection as the current inferior, this commit adds
a --no-connection option to -add-inferior.
This new option matches the existing option of the same name for the
CLI version of add-inferior; the new inferior is created with no
connection.
I've added a new 'connection' field to the MI output of -add-inferior,
which includes the connection number and short name. I haven't
included the longer description field, this is the MI after all. My
expectation would be that if the frontend wanted to display all the
connection details then this would be looked up from 'info
connection' (or the MI equivalent if/when such a command is added).
The existing -add-inferior tests are updated, as are the docs.
|
|
Prior to the multi-target support commit:
commit 5b6d1e4fa4fc6827c7b3f0e99ff120dfa14d65d2
Date: Fri Jan 10 20:06:08 2020 +0000
Multi-target support
When a new inferior was added using the MI -add-inferior command, the
new inferior would be using the same target as all the other
inferiors. This makes sense, GDB only supported a single target stack
at a time.
After the above commit, each inferior has its own target stack.
To maintain backward compatibility, for the CLI add-inferior command,
when a new inferior is added the above commit has the new inferior
inherit a copy of the target stack from the current inferior.
Unfortunately, this same backward compatibility is missing for the MI.
This commit fixes this oversight.
Now, when the -add-inferior MI command is used, the new inferior will
inherit a copy of the target stack from the current inferior.
|
|
GDB has a dbx emulation mode that adds a few aliases and helper
commands. This mode is barely documented and is very superficial
besides. I suspect it is rarely used, and I would like to propose
deprecating it for GDB 12, and then removing it in GDB 13.
|
|
infrun.c:handle_one calls find_inferior_ptid unnecessarily, since we
already have a thread pointer handy, and the thread has a pointer to
the inferior. This commit removes the unnecessary lookup.
Change-Id: I2ae18601dd75346c6c91068e9a4f9a6484fb3339
|
|
ada_print_floating rewrites a floating-point string representation to
conform to Ada syntax. However, if you managed to get a floating
point error, you might see:
(gdb) print whatever
$2 = <invalid float valu.0e>
What's happening here is that ada_print_floating doesn't recognize
this error case, and proceeds to modify the error text.
This patch fixes this problem.
|
|
Sometimes it is convenient to be able to specify the exact bits of a
floating-point literal. For example, you may want to set a
floating-point register to a denormalized value, or to a particular
NaN.
In C, you can do this by combining the "{}" cast with an array
literal, like:
(gdb) p {double}{0x576488BDD2AE9FFE}
$1 = 9.8765449999999996e+112
This patch adds a somewhat similar idea to Ada. It extends the lexer
to allow "l" and "f" suffixes in a based literal. The "f" indicates a
floating-point literal, and the "l"s control the size of the
floating-point type.
Note that this differs from Ada's based real literals. I believe
those can also be used to control the bits of a floating-point value,
but they are a bit more cumbersome to use (simplest is binary but
that's also very lengthy). Also, these aren't implemented in GDB.
I chose not to allow this extension to work with based integer
literals with exponents. That didn't seem very useful.
|
|
While working on another patch, I noticed that Ada integer literals
with exponents did not work. For example, with one form you get an
error:
(gdb) print 8e2
Invalid digit `e' in based literal
And with another form you get an incorrect value:
(gdb) print 16#8#e2
$2 = 8
This patch fixes the bugs and adds tests.
|
|
PR ada/28115 points out that gdb.ada/arrayptr.exp works with GNAT 12,
but fails with minimal encodings in earlier versions.
This patch updates the test to try to report the results correctly. I
tried this with the Fedora 34 system gcc (GCC 11) and with a GCC 12
built from git trunk sometime relatively recently.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28115
|
|
Ada allows non-ASCII identifiers, and GNAT supports several such
encodings. This patch adds the corresponding support to gdb.
GNAT encodes non-ASCII characters using special symbol names.
For character sets like Latin-1, where all characters are a single
byte, it uses a "U" followed by the hex for the character. So, for
example, thorn would be encoded as "Ufe" (0xFE being lower case
thorn).
For wider characters, despite what the manual says (it claims
Shift-JIS and EUC can be used), in practice recent versions only
support Unicode. Here, characters in the base plane are represented
using "Wxxxx" and characters outside the base plane using
"WWxxxxxxxx".
GNAT has some further quirks here. Ada is case-insensitive, and GNAT
emits symbols that have been case-folded. For characters in ASCII,
and for all characters in non-Unicode character sets, lower case is
used. For Unicode, however, characters that fit in a single byte are
converted to lower case, but all others are converted to upper case.
Furthermore, there is a bug in GNAT where two symbols that differ only
in the case of "Y WITH DIAERESIS" (and potentially others, I did not
check exhaustively) can be used in one program. I chose to omit
handling this case from gdb, on the theory that it is hard to figure
out the logic, and anyway if the bug is ever fixed, we'll regret
having a heuristic.
This patch introduces a new "ada source-charset" setting. It defaults
to Latin-1, as that is GNAT's default. This setting controls how "U"
characters are decoded -- W/WW are always handled as UTF-32.
The ada_tag_name_from_tsd change is needed because this function will
read memory from the inferior and interpret it -- and this caused an
encoding failure on PPC when running a test that tries to read
uninitialized memory.
This patch implements its own UTF-32-based case folder. This avoids
host platform quirks, and is relatively simple. A short Python
program to generate the case-folding table is included. It simply
relies on whatever version of Unicode is used by the host Python,
which seems basically acceptable.
Test cases for UTF-8, Latin-1, and Latin-3 are included. This
exercises most of the new code paths, aside from Y WITH DIAERESIS as
noted above.
|
|
rust-parse.c has a #define for the host-specific UTF-32 charset name.
A later patch needs the same thing, so this patch moves the definition
to charset.h for easier reuse.
|
|
Currently, ada_decode pre-sizes the output string, filling it with 'X'
characters. However, it's a bit simpler and more flexible to let
std::string do the work here, and simply append characters to the
string as we go. This turns out to be useful for a subsequent patch.
|
|
ada-lex.l uses "%option case-insensitive", so there is no need for
regular expressions to match upper case.
|
|
This changes iterate_over_block_local_vars and
iterate_over_block_arg_vars to take a gdb::function_view rather than a
function pointer and a user-data. In one spot, this allows us to
remove a helper structure and helper function. In another spot, this
looked more complicated, so I changed the helper function to be an
"operator()" -- also a simplification, just not as big.
|
|
I happened to notice a couple of unnecessary casts in hppa-tdep.c, and
then I saw that the use of objfile_key could be simplified -- removing
some code and using the default deleter rather than noop_deleter.
Tested by rebuilding. Let me know what you think.
|
|
In a following patch, I have a const value I want to copy using a
value_copy. However, value_copy takes a non-const source value, at the
moment. Change the paramter to be const,
If the source value is not lazy, we currently call
value_contents_all_raw, which calls allocate_value_contents, to get a
view on the contents. They both take a non-const value, that's a
problem. My first attempt at solving it was to add a const version of
value_contents_all_raw, make allocate_value_contents take a const value,
and either:
- make value::contents mutable
- make allocate_value_contents cast away the const
The idea being that allocating the value contents buffer does modify the
value at the bit level, but logically that doesn't change its state.
That was getting a bit complicated, so what I ended up doing is make
value_copy not call value_contents_all_raw. We know at this point that
the value is not lazy, so value::contents must have been allocate
already.
Change-Id: I3741ab362bce14315f712ec24064ccc17e3578d4
|
|
No kind of internal var uses it remove it. This makes the transition to
using a variant easier, since we don't need to think about where this
should be called (in a destructor or not), if it can throw, etc.
Change-Id: Iebbc867d1ce6716480450d9790410d6684cbe4dd
|
|
The vDSO objfile is not a real file, so mark it as such. I noticed
this because, when playing with debuginfod, I saw:
Downloading 0.01 MB separate debug info for /tmp/system-supplied DSO at 0x7ffff7fc9000
That "/tmp" is wrong -- it's just gdb's cwd. This patch corrects the
problem, resulting in:
Downloading 0.01 MB separate debug info for system-supplied DSO at 0x7ffff7fc9000
Regression tested on x86-64 Fedora 34.
|
|
GDB prints the wrong type for typedefs in case there is another typedef
available for the same raw type (gdb/16040). The reason is that the
current hashmap based substitution mechanism always compares the target
type of a typedef and not its scoped name.
The original output of GDB for a program like
~~~~
namespace ns
{
typedef double scoped_double;
}
typedef double global_double;
class TypedefHolder
{
public:
double a;
ns::scoped_double b;
global_double c;
private:
typedef double class_double;
class_double d;
double method1(ns::scoped_double) { return 24.0; }
double method2(global_double) { return 24.0; }
};
int main()
{
TypedefHolder th;
return 0;
}
~~~~
is
~~~~
(gdb) b 27
Breakpoint 1 at 0x1131: file TypedefHolder.cc, line 27.
(gdb) r
Starting program: /tmp/typedefholder
Breakpoint 1, main () at TypedefHolder.cc:27
27 return 0;
(gdb) ptype th
type = class TypedefHolder {
public:
class_double a;
class_double b;
class_double c;
private:
class_double d;
class_double method1(class_double);
class_double method2(class_double);
typedef double class_double;
}
~~~~
Basically all attributes of a class which have the raw type "double" are
substituted by "class_double".
With the patch the output is the following
~~~~
type = class TypedefHolder {
public:
double a;
ns::scoped_double b;
global_double c;
private:
class_double d;
double method1(ns::scoped_double);
double method2(global_double);
typedef double class_double;
}
~~~~
|
|
On some systems, the gnulib configuration will decide to define open
and/or close as macros to replace the POSIX C functions. This
interferes with using those names in C++ class or namespace scopes.
gdbsupport/
* event-pipe.cc (event_pipe::open): Renamed to ...
(event_pipe::open_pipe): ... this.
(event_pipe::close): Renamed to ...
(event_pipe::close_pipe): ... this.
* event-pipe.h (class event_pipe): Updated.
gdb/
* inf-ptrace.h (async_file_open, async_file_close): Updated.
gdbserver/
* gdbserver/linux-low.cc (linux_process_target::async): Likewise.
|
|
Update the information accordingly.
|
|
When execute the following command:
make check-gdb TESTS="gdb.base/gdb-caching-proc.exp"
we can see there exist some failed testcases:
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 0: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 1: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 2: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 3: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 4: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 5: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 6: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 7: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 8: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 9: can spawn for attach (got interactive prompt)
here are the detailed messages in gdb/testsuite/gdb.log:
attach 873776
A program is being debugged already. Kill it? (y or n) n
Not killed.
(gdb) FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 0: can spawn for attach (got interactive prompt)
so handle the case "A program is being debugged already. Kill it" in
can_spawn_for_attach to fix the failed testcases.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
This request is present on all modern *BSD/i386 systems (those
released since mid-2006), and the *BSD/i386 targets now assume it is
present unconditionally.
|
|
NetBSD has included PT_GETXMMREGS since 1.6 released in September
2002. OpenBSD has included PT_GETXMMREGS since 3.8 released in
November 2005.
|
|
PT_GETXMMREGS was first added in FreeBSD 6.0 released in November 2005.
The last FreeBSD release without support was 5.5 released in May 2006.
|
|
FreeBSD recently added a real vDSO in its shared page for the amd64
architecture. The vDSO is mapped at the address given by the
AT_KPRELOAD ELF auxiliary vector entry. To find the end of the
mapping range, parse the list of virtual map entries used by 'info
proc mappings' either from the NT_PROCSTAT_VMMAP core dump note, or
via the kinfo_getvmmap function for native targets (fetched from the
native target as the TARGET_OBJECT_FREEBSD_VMMAP object).
This silences warnings on recent FreeBSD/amd64 kernels due to not
finding symbols for the vdso:
warning: Could not load shared library symbols for [vdso].
Do you need "set solib-search-path" or "set sysroot"?
|
|
I think gdb is probably better off having fewer languages involved
when generating code. 'sh' is unavoidable for build-time generation,
but for other things, let's use Python.
This rewrites make-target-delegates in Python. I've stuck pretty
closely to the original code in this rewrite, so it may look slightly
weird from a Python perspective.
The only output difference is that a copyright header is now
generated, using the code introduced in the previous patch.
make-target-delegates.py is simpler to invoke, as it knows the correct
input file to scan and it creates the output file itself.
|
|
This moves the copyright code from gdbarch.py to a new Python source
file, gdbcopyright.py. The function in this file will find the
copyright dates by scanning the calling script. This will be reused
in a future patch.
This involved minor changes to the output of gdbarch.py. Also, I've
updated copyright.py to remove the reference to gdbarch.sh. We don't
need to mention gdbarch.py there, either.
|
|
PR build/12440 points out that "make distclean" is broken in gdb.
Most of the breakage comes from other projects in the tree, but we can
fix some of the issues, which is what this patch does.
Note that the yacc output files, like c-exp.c, are left alone. In a
source distribution, these are included in the tarball, and if the
user builds in-tree, we would not want to remove them.
While that seems a bit obscure, it seems to me that "distclean" is
only really useful for in-tree builds anyway -- out-of-tree I simply
delete the entire build directory and start over.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12440
|
|
PR cli/17332, filed around 8 years ago, points out a typo in the docs
-- in one example, the command and its output are obviously out of
sync. This patch fixes it. I'm checking this in as obvious.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17332
|
|
If /proc/sys/kernel/yama/ptrace_scope is 1, when execute the test case
gdb.base/attach-pie-noexec.exp without superuser, the gdb.log shows the
following info:
(gdb) attach 6500
Attaching to process 6500
ptrace: Operation not permitted.
(gdb) PASS: gdb.base/attach-pie-noexec.exp: attach
It is obviously wrong, the expected result should be UNSUPPORTED in such
a case.
It is better to make can_spawn_for_attach to return false for this case.
It would have to setup a small test program, compile it to exec, spawn it
and try to attach to it.
With this patch, we can see "Operation not permitted" in the log info,
and then we can do the following processes to test:
(1) set ptrace_scope as 0
$ echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
$ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp"
(2) use sudo
$ sudo make check-gdb TESTS="gdb.base/attach-pie-noexec.exp"
Additionally, handle the other cases when test with RUNTESTFLAGS=
"--target_board=native-extended-gdbserver".
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
In the current code, there is no test result when execute the following
commands:
$ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp" RUNTESTFLAGS="--target_board=remote-gdbserver-on-localhost"
$ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp" RUNTESTFLAGS="--target_board=native-gdbserver"
It is better to print explicit test result in can_spawn_for_attach.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
The patch series "gdb: Add basic support for LoongArch" has been
merged into master, list Tiezhu Yang as LoongArch maintainer.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
Running mi-exec-run.exp on native-extended-gdbserver/-m{32,64}
causes several Tcl errors to appear. For example,
(gdb)
ERROR: : spawn id exp20 not open
while executing
"expect {
-i exp11 -timeout 10
-i "$inferior_spawn_id"
-re ".*Cannot exec.*Permission denied" {
set saw_perm_error 1
verbose -log "saw..."
("uplevel" body line 1)
invoked from within
"uplevel $body" NONE : spawn id exp20 not open
UNRESOLVED: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=1: run failure detected (eof)
This is happening because of the way this test is implemented:
while {1} {
gdb_expect {
-i "$inferior_spawn_id"
-re ".*Cannot exec.*Permission denied" {
set saw_perm_error 1
verbose -log "saw mi error"
}
-i "$gdb_spawn_id"
-re "\\^error,msg=\"During startup program exited with code 127" {
set saw_mi_error 1
verbose -log "saw mi error"
}
# and so on
}
}
The first time this loop is executed, `inferior_spawn_id' is valid. When the
first branch of the expect statement is reached, gdbserver has exited, closing
the spawn_id. Since we haven't seen the gdb-side error yet, the loop is executed
again. The first branch now refers to a non-existent spawn_id, leading to the error.
This can be fixed by using exp_continue to loop in expect instead of looping around
expect, which is the approach I have used[1]. Note I've had to update the expected
message for the "During startup..." error message when running with gdbserver.
One other small change I've made is to add a log entry which spills the values of
the two variables, saw_mi_error and saw_perm_error (and updated the log output
for the later). This should make the log output clearer about why the test failed.
With this patch installed, all the ERRORs disappear, leaving previously masked
FAILs (which I have not attempted to fix).
[1] Anyone know why this test doesn't simply use gdb_test_multiple? I can only
assume that it was intentionally written this way, and I've modified the code with
that assumption. I have tested a version using gdb_test_multiple, and that appears
to work fine, too, if that is preferred. [It still employs exp_continue to fix the
spawn_id errors.]
|
|
I found a few spots where filename styling ought to be applied, but is
not.
|
|
I got this warning from py-infthread.c using the Fedora 34 system GCC:
../../binutils-gdb/gdb/python/py-infthread.c:102:30: warning: ‘extra_info’ may be used uninitialized in this function [-Wmaybe-uninitialized]
I think this happens because GDB_PY_HANDLE_EXCEPTION expands to an
'if' whose condition is always true -- but GCC can't know this. This
patch avoids the warning by adding a harmless initialization.
|
|
As noted in an earlier patch, the Ada lexer does not handle multi-byte
bracket sequences. This patch adds support for these for character
literals. gdb does not generally seem to handle the Ada wide string
types, so for the time being these continue to be excluded -- but an
explicit error is added to make this more clear.
|
|
In Ada, an enum can contain character literals. GNAT encodes these
values in a special way. For example, the Unicode character U+0178
would be represented as 'QW0178' in the DWARF:
<3><112f>: Abbrev Number: 2 (DW_TAG_enumerator)
<1130> DW_AT_name : (indirect string, offset: 0x19ff): QW0178
<1134> DW_AT_const_value : 2
gdb handles this reasonably well, but failed to handle the 'QWW'
encoding, which is used for characters outside the base plane.
Also, while working on this, I noticed that gdb will print the decimal
value for an enum character constant:
(gdb) print Char_X
$2 = 1 'x'
This is a nice feature, IMO, because in this situation the 'x' enum
constant does not have its usual decimal value -- it has the value
that's assigned based on the enumeration type.
However, gdb did not do this when it decided to print the constant
using the bracket notation:
(gdb) print Char_Thorn
$3 = ["de"]
This patch changes gdb to print the decimal value here as well, and to
put the bracket notation in single quotes -- otherwise gdb will be
printing something that it can't then read. Now it looks like:
(gdb) print Char_Thorn
$3 = 4 '["de"]'
Note that gdb can't read longer bracket notations, like the other ones
printed in this test case:
(gdb) print Char_King
$4 = 3 '["01fa00"]'
While I think this is a bug, I plan to fix it separately.
Finally, in the new test case, the copyright dates are chosen this way
because this all started as a copy of an existing test.
|
|
This adds a new read-only attribute gdb.InferiorThread.details, this
attribute contains a string, the results of target_extra_thread_info
for the thread, or None, if target_extra_thread_info returns nullptr.
As the string returned by target_extra_thread_info is unstructured,
this attribute is only really useful for echoing straight through to
the user, but, if a user wants to write a command that displays the
same, or a similar 'Thread Id' to the one seen in 'info threads', then
they need access to this string.
Given that the string produced by target_extra_thread_info varies by
target, there's only minimal testing of this attribute, I check that
the attribute can be accessed, and that the return value is either
None, or a string.
|
|
This is a snafu that I encountered while implementing the previous
patch, which attempted to use gdb_is_target_native. This proc and
gdb_is_target_remote both rely on gdb_is_target_1, which actually
cannot be called without gdb already running.
This patch adds appropriate warning comments to these procs and
causes gdb_is_target_1 to issue a Tcl error if it is called without a
gdb instance already running. This should prevent unwitting callers
from using this at the wrong time.
|
|
When running the gdb.fortran tests array-slices.exp and lbound-ubound.exp,
the test suite throws several ERRORs on native-gdbserver/-m{32,64},
and native-extended-gdbsever/-m{32,64}:
[on native-extended-gdbserver/-m64]
Running /home/keiths/work/gdb/branches/testsuite-errors/linux/gdb/testsuite/../../../src/gdb/testsuite/gdb.fortran/array-slices.exp ...
ERROR: failed to extract expected results
ERROR: failed to extract expected results
Running /home/keiths/work/gdb/branches/testsuite-errors/linux/gdb/testsuite/../../../src/gdb/testsuite/gdb.fortran/lbound-ubound.exp ...
ERROR: failed to extract expected results for lbound
This occurs because the tests require inferior I/O which we do not have
access to while using these targets.
This patch skips these tests when running on non-native targets.
|
|
I came across this problem when testing gdb.base/gdb-sigterm.exp
on a machine with a pre-release version of glib-2.34 installed:
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) Recursive internal problem.
FAIL: gdb.base/gdb-sigterm.exp: expect eof #0 (GDB internal error)
Resyncing due to internal error.
ERROR: : spawn id exp11 not open
while executing
"expect {
-i exp11 -timeout 10
-re "Quit this debugging session\\? \\(y or n\\) $" {
send_gdb "n\n" answer
incr count
}
-re "Create..."
("uplevel" body line 1)
invoked from within
"uplevel $body" NONE : spawn id exp11 not open
ERROR: Could not resync from internal error (timeout)
gdb.base/gdb-sigterm.exp: expect eof #0: stepped 9 times
UNRESOLVED: gdb.base/gdb-sigterm.exp: 50 SIGTERM passes
I don't have a problem with the latter ERROR nor the UNRESOLVED
messages. However the first ERROR regarding the exp11 spawn id
not being open is not especially useful.
This commit handles the "Recursive internal problem" case, avoiding
the problematic ERROR shown above.
With this commit in place, the log messages look like this instead:
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) Recursive internal problem.
FAIL: gdb.base/gdb-sigterm.exp: expect eof #15 (GDB internal error)
Resyncing due to internal error.
ERROR: Could not resync from internal error (recursive internal problem)
gdb.base/gdb-sigterm.exp: expect eof #15: stepped 12 times
UNRESOLVED: gdb.base/gdb-sigterm.exp: 50 SIGTERM passes
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_internal_error_resync): Handle "Recursive
internal problem".
|
