| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
When writing an unwinder it is necessary to create a new class to act
as a frame-id. This new class is almost certainly just going to set a
'sp' and 'pc' attribute within the instance.
This commit adds a little helper class gdb.unwinder.FrameId that does
this job. Users can make use of this to avoid having to write out
standard boilerplate code any time they write an unwinder.
Of course, if the user wants their FrameId class to be more
complicated in some way, then they can still write their own class,
just like they could before.
I've simplified the example code in the documentation to now use the
new helper class, and I've also made use of this helper within the
testsuite.
Any existing user code will continue to work just as it did before
after this change.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
Currently when creating a gdb.UnwindInfo object a user must call
gdb.PendingFrame.create_unwind_info and pass a frame-id object.
The frame-id object should have at least a 'sp' attribute, and
probably a 'pc' attribute too (it can also, in some cases have a
'special' attribute).
Currently all of these frame-id attributes need to be gdb.Value
objects, but the only reason for that requirement is that we have some
code in py-unwind.c that only handles gdb.Value objects.
If instead we switch to using get_addr_from_python in py-utils.c then
we will support both gdb.Value objects and also raw numbers, which
might make things simpler in some cases.
So, I started rewriting pyuw_object_attribute_to_pointer (in
py-unwind.c) to use get_addr_from_python. However, while looking at
the code I noticed a problem.
The pyuw_object_attribute_to_pointer function returns a boolean flag,
if everything goes OK we return true, but we return false in two
cases, (1) when the attribute is not present, which might be
acceptable, or might be an error, and (2) when we get an error trying
to extract the attribute value, in which case a Python error will have
been set.
Now in pending_framepy_create_unwind_info we have this code:
if (!pyuw_object_attribute_to_pointer (pyo_frame_id, "sp", &sp))
{
PyErr_SetString (PyExc_ValueError,
_("frame_id should have 'sp' attribute."));
return NULL;
}
Notice how we always set an error. This will override any error that
is already set.
So, if you create a frame-id object that has an 'sp' attribute, but
the attribute is not a gdb.Value, then currently we fail to extract
the attribute value (it's not a gdb.Value) and set this error in
pyuw_object_attribute_to_pointer:
rc = pyuw_value_obj_to_pointer (pyo_value.get (), addr);
if (!rc)
PyErr_Format (
PyExc_ValueError,
_("The value of the '%s' attribute is not a pointer."),
attr_name);
Then we return to pending_framepy_create_unwind_info and immediately
override this error with the error about 'sp' being missing.
This all feels very confused.
Here's my proposed solution: pyuw_object_attribute_to_pointer will now
return a tri-state enum, with states OK, MISSING, or ERROR. The
meanings of these states are:
OK - Attribute exists and was extracted fine,
MISSING - Attribute doesn't exist, no Python error was set.
ERROR - Attribute does exist, but there was an error while
extracting it, a Python error was set.
We need to update pending_framepy_create_unwind_info, the only user of
pyuw_object_attribute_to_pointer, but now I think things are much
clearer. Errors from lower levels are not blindly overridden with the
generic meaningless error message, but we still get the "missing 'sp'
attribute" error when appropriate.
This change also includes the switch to get_addr_from_python which was
what started this whole journey.
For well behaving user code there should be no visible changes after
this commit.
For user code that hits an error, hopefully the new errors should be
more helpful in figuring out what's gone wrong.
Additionally, users can now use integers for the 'sp' and 'pc'
attributes in their frame-id objects if that is useful.
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
While refactoring some other code in gdb/python/* I wanted to merge
two code paths. One path calls value_as_address, while the other
calls unpack_pointer.
I suspect calling value_as_address is the correct choice, but, while
examining the code I noticed that value_as_address calls unpack_long
rather than unpack_pointer.
Under the hood, unpack_pointer does just call unpack_long so there's
no real difference here, but it feels like value_as_address should
call unpack_pointer.
I've updated the code to use unpack_pointer, and changed a related
comment to say that we call unpack_pointer. I've also adjusted the
header comment on value_as_address. The existing header refers to
some code that is now commented out.
Rather than trying to describe the whole algorithm of
value_as_address, which is already well commented within the function,
I've just trimmed the comment on value_as_address to be a brief
summary of what the function does.
There should be no user visible changes after this commit.
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
It is not currently possible to directly create gdb.UnwindInfo
instances, they need to be created by calling
gdb.PendingFrame.create_unwind_info so that the newly created
UnwindInfo can be linked to the pending frame.
As such there's no tp_init method defined for UnwindInfo.
A consequence of all this is that it doesn't really make sense to
allow sub-classing of gdb.UnwindInfo. Any sub-class can't call the
parents __init__ method to correctly link up the PendingFrame
object (there is no parent __init__ method). And any instances that
sub-classes UnwindInfo but doesn't call the parent __init__ is going
to be invalid for use in GDB.
This commit removes the Py_TPFLAGS_BASETYPE flag from the UnwindInfo
class, which prevents the class being sub-classed. Then I've added a
test to check that this is indeed prevented.
Any functional user code will not have any issues with this change.
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
Having a useful __repr__ method can make debugging Python code that
little bit easier. This commit adds __repr__ for gdb.PendingFrame and
gdb.UnwindInfo classes, along with some tests.
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
The gdb.Frame class has far more methods than gdb.PendingFrame. Given
that a PendingFrame hasn't yet been claimed by an unwinder, there is a
limit to which methods we can add to it, but many of the methods that
the Frame class has, the PendingFrame class could also support.
In this commit I've added those methods to PendingFrame that I believe
are safe.
In terms of implementation: if I was starting from scratch then I
would implement many of these (or most of these) as attributes rather
than methods. However, given both Frame and PendingFrame are just
different representation of a frame, I think there is value in keeping
the interface for the two classes the same. For this reason
everything here is a method -- that's what the Frame class does.
The new methods I've added are:
- gdb.PendingFrame.is_valid: Return True if the pending frame
object is valid.
- gdb.PendingFrame.name: Return the name for the frame's function,
or None.
- gdb.PendingFrame.pc: Return the $pc register value for this
frame.
- gdb.PendingFrame.language: Return a string containing the
language for this frame, or None.
- gdb.PendingFrame.find_sal: Return a gdb.Symtab_and_line object
for the current location within the pending frame, or None.
- gdb.PendingFrame.block: Return a gdb.Block for the current
pending frame, or None.
- gdb.PendingFrame.function: Return a gdb.Symbol for the current
pending frame, or None.
In every case I've just copied the implementation over from gdb.Frame
and cleaned the code slightly e.g. NULL to nullptr. Additionally each
function required a small update to reflect the PendingFrame type, but
that's pretty minor.
There are tests for all the new methods.
For more extensive testing, I added the following code to the file
gdb/python/lib/command/unwinders.py:
from gdb.unwinder import Unwinder
class TestUnwinder(Unwinder):
def __init__(self):
super().__init__("XXX_TestUnwinder_XXX")
def __call__(self,pending_frame):
lang = pending_frame.language()
try:
block = pending_frame.block()
assert isinstance(block, gdb.Block)
except RuntimeError as rte:
assert str(rte) == "Cannot locate block for frame."
function = pending_frame.function()
arch = pending_frame.architecture()
assert arch is None or isinstance(arch, gdb.Architecture)
name = pending_frame.name()
assert name is None or isinstance(name, str)
valid = pending_frame.is_valid()
pc = pending_frame.pc()
sal = pending_frame.find_sal()
assert sal is None or isinstance(sal, gdb.Symtab_and_line)
return None
gdb.unwinder.register_unwinder(None, TestUnwinder())
This registers a global unwinder that calls each of the new
PendingFrame methods and checks the result is of an acceptable type.
The unwinder never claims any frames though, so shouldn't change how
GDB actually behaves.
I then ran the testsuite. There was only a single regression, a test
that uses 'disable unwinder' and expects a single unwinder to be
disabled -- the extra unwinder is now disabled too, which changes the
test output. So I'm reasonably confident that the new methods are not
going to crash GDB.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
This commit copies the pattern that is present in many other py-*.c
files: having a single macro to check that the Python object is still
valid.
This cleans up the code a little throughout the py-unwind.c file.
Some of the exception messages will change slightly with this commit,
though the type of the exceptions is still ValueError in all cases.
I started writing some tests for this change and immediately ran into
a problem: GDB would crash. It turns out that the PendingFrame
objects are not being marked as invalid!
In pyuw_sniffer where the pending frames are created, we make use of a
scoped_restore to invalidate the pending frame objects. However, this
only restores the pending_frame_object::frame_info field to its
previous value -- and it turns out we never actually give this field
an initial value, it's left undefined.
So, when the scoped_restore (called invalidate_frame) performs its
cleanup, it actually restores the frame_info field to an undefined
value. If this undefined value is not nullptr then any future
accesses to the PendingFrame object result in undefined behaviour and
most likely, a crash.
As part of this commit I now initialize the frame_info field, which
ensures all the new tests now pass.
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
Spotted a redundant nullptr check in python/py-frame.c in the function
frapy_block. This was introduced in commit 57126e4a45e3000e when we
expanded an earlier check in return early if the pointer in question
is nullptr.
There should be no user visible changes after this commit.
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
This commit makes a few related changes to the gdb.unwinder.Unwinder
class attributes:
1. The 'name' attribute is now a read-only attribute. This prevents
user code from changing the name after registering the unwinder. It
seems very unlikely that any user is actually trying to do this in
the wild, so I'm not very worried that this will upset anyone,
2. We now validate that the name is a string in the
Unwinder.__init__ method, and throw an error if this is not the
case. Hopefully nobody was doing this in the wild. This should
make it easier to ensure the 'info unwinder' command shows sane
output (how to display a non-string name for an unwinder?),
3. The 'enabled' attribute is now implemented with a getter and
setter. In the setter we ensure that the new value is a boolean,
but the real important change is that we call
'gdb.invalidate_cached_frames()'. This means that the backtrace
will be updated if a user manually disables an unwinder (rather than
calling the 'disable unwinder' command). It is not unreasonable to
think that a user might register multiple unwinders (relating to
some project) and have one command that disables/enables all the
related unwinders. This command might operate by poking the enabled
attribute of each unwinder object directly, after this commit, this
would now work correctly.
There's tests for all the changes, and lots of documentation updates
that both cover the new changes, but also further improve (I think)
the general documentation for GDB's Unwinder API.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
The test case in this patch shows an unusual situation: an Ada array
has a dynamic bound, but the bound comes from a frame that's referred
to by the static link. This frame is correctly found when evaluating
the array variable itself, but is lost when evaluating the array's
bounds.
This patch fixes the problem by passing this frame through to
value_at_lazy in the DWARF expression evaluator.
|
|
This patch adds a 'frame' parameter to value_at_lazy and ensures that
it is passed down to the call to resolve_dynamic_type. This required
also adding a frame parameter to value_from_contents_and_address.
Nothing passes this parameter to value_at_lazy yet, so this patch
should have no visible effect.
|
|
This adds a frame parameter to resolve_dynamic_type and arranges for
it to be passed through the call tree and, in particular, to all calls
to dwarf2_evaluate_property.
Nothing passes this parameter yet, so this patch should have no
visible effect.
A 'const frame_info_ptr *' is used here to avoid including frame.h
from gdbtypes.h.
|
|
version_at_least is a less capable variant of version_compare, so this
patch removes it.
|
|
This rewrites version_compare to allow the input lists to have
different lengths, then rewrites rust_at_least to use version_compare.
|
|
This adds a 'rust_at_least' helper proc, for checking the version of
the Rust compiler in use. It then changes various tests to use this
with 'require'.
|
|
With test-case gdb.ada/verylong.exp and gnatmake 7.5.0 I run into:
...
compilation failed: gcc ... $src/gdb/testsuite/gdb.ada/verylong/prog.adb
prog.adb:16:11: warning: file name does not match unit name, should be "main.adb"
prog.adb:17:08: "Long_Long_Long_Integer" is undefined (more references follow)
gnatmake: "prog.adb" compilation error
FAIL: gdb.ada/verylong.exp: compilation prog.adb
...
AFAICT, support for Long_Long_Long_Integer was added in gcc 11.
Fix this by requiring gnatmake version 11 or higher in the test-case.
Tested on x86_64-linux.
|
|
Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>
|
|
The ERROR_NO_INFERIOR macro is already called at the beginning of the
function continue_command. Since target/inferior are not switched in-between,
the second call to it is redundant.
Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>
|
|
It was pointed out during review of another patch that the function
displaced_step_dump_bytes really isn't specific to displaced stepping,
and should really get a more generic name and move into gdbsupport/.
This commit does just that. The function is renamed to
bytes_to_string and is moved into gdbsupport/common-utils.{cc,h}. The
function implementation doesn't really change. Much...
... I have updated the function to take an array view, which makes it
slightly easier to call in a couple of places where we already have a
gdb::bytes_vector. I've then added an inline wrapper to convert a raw
pointer and length into an array view, which is used in places where
we don't easily have a gdb::bytes_vector (or similar).
Updated all users of displaced_step_dump_bytes.
There should be no user visible changes after this commit.
Finally, I ended up having to add an include of gdb_assert.h into
array-view.h. When I include array-view.h into common-utils.h I ran
into build problems because array-view.h calls gdb_assert.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
While investigating a displaced stepping issue I wanted an easy way to
see what GDB thought the original instruction was, and what
instruction GDB replaced that with when performing the displaced step.
We do print out the address that is being stepped, so I can track down
the original instruction, I just need to go find the information
myself.
And we do print out the bytes of the new instruction, so I can figure
out what the replacement instruction was, but it's not really easy.
Also, the code that prints the bytes of the replacement instruction
only prints 4 bytes, which clearly isn't always going to be correct.
In this commit I remove the existing code that prints the bytes of the
replacement instruction, and add two new blocks of code to
displaced_step_prepare_throw. This new code prints the original
instruction, and the replacement instruction. In each case we print
both the bytes that make up the instruction and the completely
disassembled instruction.
Here's an example of what the output looks like on x86-64 (this is
with 'set debug displaced on'). The two interesting lines contain the
strings 'original insn' and 'replacement insn':
(gdb) step
[displaced] displaced_step_prepare_throw: displaced-stepping 2892655.2892655.0 now
[displaced] displaced_step_prepare_throw: original insn 0x401030: ff 25 e2 2f 00 00 jmp *0x2fe2(%rip) # 0x404018 <puts@got.plt>
[displaced] prepare: selected buffer at 0x401052
[displaced] prepare: saved 0x401052: 1e fa 31 ed 49 89 d1 5e 48 89 e2 48 83 e4 f0 50
[displaced] fixup_riprel: %rip-relative addressing used.
[displaced] fixup_riprel: using temp reg 2, old value 0x7ffff7f8a578, new value 0x401036
[displaced] amd64_displaced_step_copy_insn: copy 0x401030->0x401052: ff a1 e2 2f 00 00 68 00 00 00 00 e9 e0 ff ff ff
[displaced] displaced_step_prepare_throw: prepared successfully thread=2892655.2892655.0, original_pc=0x401030, displaced_pc=0x401052
[displaced] displaced_step_prepare_throw: replacement insn 0x401052: ff a1 e2 2f 00 00 jmp *0x2fe2(%rcx)
[displaced] finish: restored 2892655.2892655.0 0x401052
[displaced] amd64_displaced_step_fixup: fixup (0x401030, 0x401052), insn = 0xff 0xa1 ...
[displaced] amd64_displaced_step_fixup: restoring reg 2 to 0x7ffff7f8a578
0x00007ffff7e402c0 in puts () from /lib64/libc.so.6
(gdb)
One final note. For many targets that support displaced stepping (in
fact all targets except ARM) the replacement instruction is always a
single instruction. But on ARM the replacement could actually be a
series of instructions.
The debug code tries to handle this by disassembling the entire
displaced stepping buffer. Obviously this might actually print more
than is necessary, but there's (currently) no easy way to know how
many instructions to disassemble; that knowledge is all locked in the
architecture specific code. Still I don't think it really hurts, if
someone is looking at this debug then hopefully they known what to
expect.
Obviously we can imagine schemes where the architecture specific
displaced stepping code could communicate back how many bytes its
replacement sequence was, and then our debug print code could use this
to limit the disassembly. But this seems like a lot of effort just to
save printing a few additional instructions in some debug output.
I'm not proposing to do anything about this issue for now.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Fix test-case gdb.guile/scm-symbol.exp for remote host by making a regexp less
strict.
Likewise in gdb.guile/scm-symtab.exp.
Tested on x86_64-linux.
|
|
Fix test-case gdb.guile/scm-parameter.exp for remote host by taking into
account that gdb_reinitialize_dir has no effect for remote host.
Tested on x86_64-linux.
|
|
Fix test-case gdb.guile/scm-objfile-script.exp using gdb_remote_download.
Tested on x86_64-linux.
|
|
Fix test-case gdb.guile/scm-objfile-script.exp using host_standard_output_file.
Tested on x86_64-linux.
|
|
Fix test-case gdb.guile/scm-cmd.exp using readline_is_used.
Tested on x86_64-linux.
|
|
Fix test-case gdb.guile/guile.exp for remote host using gdb_remote_download.
Tested on x86_64-linux.
|
|
Per an earlier discussion, this patch renames the existing "raw" APIs
to use the word "unrelocated" instead.
|
|
This changes minimal symbols to use unrelocated_addr. I believe this
detected a latent bug in add_pe_forwarded_sym.
|
|
This changes psymbols themselves to use unrelocated_addr. This
transform is largely mechanical. I don't think it finds any bugs.
|
|
This changes partial symbol tables to use unrelocated_addr for the
text_high and text_low members. This revealed some latent bugs in
ctfread.c, which are fixed here.
|
|
This moves the definition of unrelocated_addr a bit earlier in
symtab.h, so that it can be used elsewhere in the file.
|
|
This changes gdb_bfd_lookup_symbol to use a function_view. This
simplifies the code a little bit.
|
|
Fix test-case gdb.btrace/multi-inferior.exp for remote host using
gdb_remote_download.
Tested on x86_64-linux.
|
|
Fix test-case gdb.btrace/gcore.exp for remote host using
host_standard_output.
Tested on x86_64-linux.
|
|
Fix test-case gdb.btrace/reconnect.exp for target board
remote-gdbserver-on-localhost using gdb_remote_download.
Tested on x86_64-linux.
|
|
PR mi/11335 points out that an MI varobj will not display the result
of a pretty-printer's "to_string" method. Instead, it always shows
"{...}".
This does not seem very useful, and there have been multiple
complaints about it over the years. This patch changes varobj to emit
this string when possible, and updates the test suite.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11335
|
|
When an allow_* proc returns false, it can be a bit difficult what check
failed exactly, if the procedure does multiple checks. To make
investigation easier, I propose to allow the "require" callbacks to be
able to return a list of two elements: the zero/non-zero value, and a
reason string.
Use the new feature in allow_hipcc_tests to demonstrate it (it's also
where I hit actually hit this inconvenience). On my computer (where GDB
is built with amd-dbgapi support but where I don't have a suitable GPU
target), I get:
UNSUPPORTED: gdb.rocm/simple.exp: require failed: allow_hipcc_tests (no suitable amdgpu targets found)
vs before:
UNSUPPORTED: gdb.rocm/simple.exp: require failed: allow_hipcc_tests
Change-Id: Id1966535b87acfcbe9eac99f49dc1196398c6578
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
Fix test-case gdb.server/server-kill-python.exp for remote host using
gdb_remote_download.
Tested on x86_64-linux.
|
|
Fix test-case gdb.server/sysroot.exp for remote host, by:
- using gdb_remote_download, and
- disabling the "local" scenario for remote host/target, unless
remote host == remote target.
Tested on x86_64-linux.
|
|
Require non-remote host for test-case gdb.server/multi-ui-errors.exp, because
it uses "spawn -pty", which creates a pty on build, which gdb cannot use on
remote host.
Tested on x86_64-linux.
|
|
Fix test-case gdb.server/solib-list.exp for remote host using
gdb_remote_download.
Likewise in another test-case.
Tested on x86_64-linux.
|
|
Fix test-case gdb.server/file-transfer.exp for remote host using
gdb_remote_download and host_standard_output_file.
Tested on x86_64-linux.
|
|
When running test-case gdb.server/stop-reply-no-thread-multi.exp with
host+target board local-remote-host-native, I run into a time-out:
...
(gdb) PASS: gdb.server/stop-reply-no-thread-multi.exp: target-non-stop=off: \
to_disable=: disconnect
builtin_spawn /usr/bin/ssh -t -l vries 127.0.0.1 gdbserver --once \
localhost:2346 stop-reply-no-thread-multi^M
Process stop-reply-no-thread-multi created; pid = 32600^M
Listening on port 2346^M
set remote threads-packet off^M
FAIL: gdb.server/stop-reply-no-thread-multi.exp: target-non-stop=off: \
to_disable=: set remote threads-packet off (timeout)
...
This is due to this line in ${board}_spawn:
...
set board_info($board,fileid) $spawn_id
...
We have the following series of events:
- gdb is spawned, setting fileid
- a few gdb commands (set height etc) are send using fileid, arrive at gdb and
are successful
- gdbserver is spawned, overwriting fileid
- the next gdb command is sent using fileid, so it's send
to gdbserver instead of gdb, and we run into the timeout.
There is some notion of current gdb, tracked in both gdb_spawn_id and fileid
of the host board (see switch_gdb_spawn_id). And because the host and target
board are the same, spawning something on the target overwrites the fileid on
host, and consequently the current gdb.
Fix this by only setting fileid when spawning gdb.
Tested on x86_64-linux.
Now gdb.server/*.exp passes for host+target board local-remote-host-native,
except for file-transfer.exp.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29734
|
|
When running update-freebsd.sh on FreeBSD, I see the following
modification in freebsd.xml,
-<!-- Copyright (C) 2009-2023 Free Software Foundation, Inc.
+<!-- Copyright (C) 2009-2020 Free Software Foundation, Inc.
It means that each time, when we running the update-freebsd.sh on
FreeBSD, we have to correct the year of copyright manually. So fix this
issue by using dynamic year.
Tested by regenerating freebsd.xml on FreeBSD/amd64.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
remote-gdbserver-on-localhost
With test-case gdb.server/non-existing-program.exp and native, I have reliably:
...
(gdb) builtin_spawn gdbserver stdio non-existing-program^M
stdin/stdout redirected^M
/bin/bash: line 0: exec: non-existing-program: not found^M
During startup program exited with code 127.^M
Exiting^M
PASS: gdb.server/non-existing-program.exp: gdbserver exits cleanly
...
But with target board remote-gdbserver-on-localhost I sometimes have:
...
(gdb) builtin_spawn /usr/bin/ssh -t -l remote-target localhost gdbserver \
stdio non-existing-program^M
stdin/stdout redirected^M
/bin/bash: line 0: exec: non-existing-program: not found^M
During startup program exited with code 127.^M
Exiting^M
Connection to localhost closed.^M^M
PASS: gdb.server/non-existing-program.exp: gdbserver exits cleanly
...
and sometimes the exact same output, but a FAIL instead.
Fix this by replacing "Exiting\r\n$" with "Exiting\r\n" in the regexps.
Tested on x86_64-linux.
|
|
Proc allow_rust_tests returns 0 when there's no rust compiler, but that gives
the wrong answer for gdb.rust/expr.exp, which doesn't require it.
Fix this by using can_compile rust in the test-cases that need it, and just
returning 1 in allow_rust_tests.
Tested on x86_64-linux.
|
|
If I deinstall the rust compiler, I get:
...
gdb compile failed, default_target_compile: Can't find rustc --color never.
UNTESTED: gdb.rust/watch.exp: failed to prepare
...
Fix this by adding can_compile rust, and using it in allow_rust_tests, such
that we have instead:
...
UNSUPPORTED: gdb.rust/watch.exp: require failed: allow_rust_tests
...
Since the rest of the code in allow_rust_tests is also about availability of
the rust compiler, move it to can_compile.
Tested on x86_64-linux.
|
|
With test-case gdb.rust/watch.exp and remote host I run into:
...
Executing on host: gcc watch.rs -g -lm -o watch (timeout = 300)
...
ld:watch.rs: file format not recognized; treating as linker script
ld:watch.rs:1: syntax error
...
UNTESTED: gdb.rust/watch.exp: failed to prepare
...
The problem is that find_rustc returns "" for remote host, so we fall back to gcc, which fails.
Fix this by returning 0 in allow_rust_tests for remote host.
Tested on x86_64-linux.
|
|
Fix gnat_runtime_has_debug_info for remote host by checking for
allow_ada_tests.
This fixes an error for test-case gdb.testsuite/gdb-caching-proc.exp and
remote host.
Tested on x86_64-linux.
|
|
Use GDB_SIGNAL_TRAP instead of SIGTRAP. This is a no-op since the
value of SIGTRAP on FreeBSD matches the value of GDB_SIGNAL_TRAP, but
it is more correct.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
