| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
gprofng uses insn_type in print_address_func().
But insn_type is always zero on aarch64.
opcodes/ChangeLog:
2023-09-07 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
* opcodes/aarch64-dis.c (print_insn_aarch64_word): Set insn_type for
branch instructions.
|
|
While investigating this [1], I initially had no idea what register
"fioff" stood for, making it difficult to map it to something in the
Intel or AMD manuals. Similarly, I can imaging someone familiar with
x87 to want to print the "x87 last instruction address", and have no
clue that GDB makes it available as register "fioff". The names of the
x87 state fields don't seem to be standardized, they even change between
sections of the Intel manual (between the FSAVE, FXSAVE and XSAVE area
descriptions).
Add some details to the doc to help one map GDB register names to x87
state fields.
[1] https://inbox.sourceware.org/gdb-patches/20230908022722.430741-1-simon.marchi@efficios.com/T/#u
Change-Id: I0ea1eb648358e62da4aa87eea3515ee8a09f2762
Approved-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Pedro Alves <pedro@palves.net>
|
|
I'm looking to add some x86-specific information to the doc, but I find
the naming of this section odd. It doesn't really talk about issues, it
just gives generally useful information. Also, the sections about other
architectures don't mention "issues", just the architecture name.
Also, at least in the HTML version of the doc, the name is inconsistent
between the main table of content, where it appears as "x86
Architecture-specific Issues", and the sub-table of contents of the
"Architectures" section, where it appears as "i386".
Rename the section to just "x86".
Change-Id: I0a119ff1ab5e7b83c9afa3c3977eb085e88f52ca
Approved-By: Eli Zaretskii <eliz@gnu.org>
|
|
set_expected_error is no longer used. It has been replaced by
more specific error messages.
|
|
I ran test-case gdb.dwarf2/dwzbuildid.exp with target board cc-with-gdb-index,
and noticed that compilation failure for one exec prohibited testing of all
execs.
Fix this by restructuring the test-case, such that we have:
...
PASS: gdb.dwarf2/dwzbuildid.exp: testname=ok: set debug-file-directory
PASS: gdb.dwarf2/dwzbuildid.exp: testname=ok: print the_int
UNSUPPORTED: gdb.dwarf2/dwzbuildid.exp: testname=mismatch: compilation failed
UNSUPPORTED: gdb.dwarf2/dwzbuildid.exp: testname=fallback: compilation failed
...
Tested on x86_64-linux.
|
|
When running test-case gdb.dwarf2/dwzbuildid.exp using target board readnow, I
get:
...
(gdb) file dwzbuildid-mismatch^M
Reading symbols from dwzbuildid-mismatch...^M
warning: File "dwzbuildid5.o" has a different build-id, file skipped^M
could not find '.gnu_debugaltlink' file for dwzbuildid-mismatch^M
(gdb) delete breakpoints^M
(gdb) info breakpoints^M
No breakpoints or watchpoints.^M
(gdb) break -qualified main^M
No symbol table is loaded. Use the "file" command.^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) FAIL: gdb.dwarf2/dwzbuildid.exp: mismatch: gdb_breakpoint: set breakpoint at main
...
This is PR symtab/26797: when using readnow, a failure in reading the dwarf
results in the minimal symbols not being available.
Add a corresponding KFAIL.
Tested on x86_64-linux.
|
|
While investigating the execs of gdb.dwarf2/dwzbuildid.exp using readelf I ran
into a warning:
...
$ readelf -w dwzbuildid-ok > READELF
readelf: Warning: .debug_info offset of 0x2e in .debug_aranges section does not
point to a CU header.
...
AFAICT, the warning is incorrect, I've filed PR binutils/30835 about that.
While looking at the .debug_aranges section, I noticed that the entries for
the CUs generated by the dwarf assembler are missing.
Fix this by adding the missing .debug_aranges entries.
Tested on x86_64-linux.
|
|
When looking at the execs from test-case gdb.dwarf2/dwzbuildid.exp using
readelf, I run into:
...
$ readelf -w dwzbuildid-ok > READELF
readelf: Warning: Corrupt debuglink section: .gnu_debugaltlink
readelf: Warning: Build-ID is too short (0x6 bytes)
...
Fix this by ensuring the Build-IDs are the required 20 bytes.
Tested on x86_64-linux.
|
|
In commit:
commit 3ce8f906be7a55d8c0375e6d360cc53b456d86ae
Date: Tue Aug 8 10:45:20 2023 +0100
gdb: MI stopped events when unwindonsignal is on
a new test, gdb.mi/mi-condbreak-throw.exp, was added. Unfortunately,
this test would fail when using the native-gdbserver board (and other
similar boards).
The problem was that one of the expected output patterns included some
output from the inferior. When using the native-gdbserver board, this
output is not printed to GDB's tty, but is instead printed to
gdbserver's tty, the result is that the expected output no longer
matches, and the test fails.
Additionally, as the output is actually from the C++ runtime, rather
than the test's source file, changes to the C++ runtime could cause
the output to change.
To solve both of these issues, in this commit, I'm removing the
reference to the inferior's output, and replacing it with '.*', which
will skip the output if it is present, but is equally happy if the
output is not present.
After this commit gdb.mi/mi-condbreak-throw.exp now passes on all
boards, including native-gdbserver.
|
|
Avoid triggering the respective abort() in output_insn().
|
|
It is a trivial wrapper around the supports_command_editing method,
remove it.
Change-Id: I0fe3d7dc69601b3b89f82e055f7fe3d4af1becf7
Approved-By: Tom Tromey <tom@tromey.com>
|
|
It is a trivial wrapper around the pre_command_loop method, remove it.
Change-Id: Idb2c61f9b68988528006a9a9b2b528f43781eef4
Approved-By: Tom Tromey <tom@tromey.com>
|
|
|
|
The modified test in function-calls.exp actually passes with ifort and
ifx. The particular fail seems to be specific to gfortran. When the
test was introduced it was only tested with gfortran (actually the
whole patch was written with gfortran and the GNU Fortran argument
passing convention in mind).
Approved-by: Tom Tromey <tom@tromey.com>
|
|
The modified tests array-slices-bad.exp and vla-type.exp both set a
breakpoint at the first real statement in the respective executables.
Normally, the expected behavior of fortran_runto_main for these would be
the stopping of the debugger at exactly the first statment in the code.
Strangely, neither gfortran nor ifx seem to do this for these tests.
Instead, issuing 'start' in ifx (for either of the 2 tests) lets GDB
stop at the 'program ...' line and gfortran stops at a variable
declaration line. E.g. for vla-type it stops at
41 type(five) :: fivearr (2)
So, actually, ifort's behavior can be considered to be a bit more
'correct' here. This patch remove the fortran_runto_main in the
two tests and instead uses runto to directly run to the first breakpoint
set at the first program statement. This works with both compiler
behaviors and makes the tests more robust.
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
There were a couple of places in the testsuite where instructions like
var = var
were written in the source code of tests. These were usually dummy
statements meant to generate a line table entry at that line on which
to break later on.
This worked fine for gfortran and ifx, but it seems that, when compiled
with ifort (2021.6.0) these statements do not actually create any
assmbler instructions and especially no line table entries. Consider
the program
program test
Integer var :: var = 1
var = var
end program
compiled with gfortran (13.0.0, -O0 -g). The linetable as emitted by
'objdump --dwarf=decodedline ./a.out' looks like
test.f90:
File name Line number Starting address View Stmt
test.f90 1 0x401172 x
test.f90 3 0x401176 x
test.f90 4 0x401182 x
test.f90 4 0x401185 x
test.f90 4 0x401194 x
test.f90 - 0x4011c0
actually containing line table info for line 3. Running gdb, breaking
at 3 and checking the assembly we see
0x0000000000401172 <+0>: push %rbp
0x0000000000401173 <+1>: mov %rsp,%rbp
=> 0x0000000000401176 <+4>: mov 0x2ebc(%rip),%eax # 0x404038 <var.1>
0x000000000040117c <+10>: mov %eax,0x2eb6(%rip) # 0x404038 <var.1>
0x0000000000401182 <+16>: nop
0x0000000000401183 <+17>: pop %rbp
0x0000000000401184 <+18>: ret
so two mov instructions are being issued for this assignment one copying
the value into a register and one writing it back to the same memory.
Ifort (2021.6.0, -O0 -g) on the other hand does not emit anything here
and also has no line table entry:
test.f90:
File name Line number Starting address View Stmt
test.f90 1 0x4040f8 x
test.f90 4 0x404109 x
test.f90 4 0x40410e x
test.f90 - 0x404110
As I do not think that this is really a bug (on either side, gfortran/ifx or
ifort), and as I don't think this behavior is covered in the Fortran
standard, I changed these lines to become actual value assignments.
This removes a few FAILs in the testsuite when ran with ifort.
Approved-by: Tom Tromey <tom@tromey.com>
|
|
In the gdb.fortran/mixed-lang-stack.exp test when somewhere deep in a
bunch of nested function calls we issue and test a 'info args' command
for the mixed_func_1b function (when in that function's frame).
The signature of the function looks like
subroutine mixed_func_1b(a, b, c, d, e, g)
use type_module
implicit none
integer :: a
real(kind=4) :: b
real(kind=8) :: c
complex(kind=4) :: d
character(len=*) :: e
character(len=:), allocatable :: f
TYPE(MyType) :: g
and usually one would expect arguments a, b, c, d, e, and g to be
emitted here. However, due to some compiler dependent treatment of the
e array the actual output in the test (with gfortran/ifx) is
(gdb) info args
a = 1
b = 2
c = 3
d = (4,5)
e = 'abcdef'
g = ( a = 1.5, b = 2.5 )
_e = 6
where the compiler generated '_e' is emitted as the length of e. While
ifort also generates an additional length argument, the naming (which is
up to the compilers here I think, I could not find anything in the
Fortran standard about this) is different and we see
(gdb) info args
a = 1
b = 2
c = 3
d = (4,5)
e = 'abcdef'
g = ( a = 1.5, b = 2.5 )
.tmp.E.len_V$4a = 6
To make both outputs pass the test, I kept the additional argument for now and
made the regex for the emitted name of the last variable match any
arbitrary name.
Approved-by: Tom Tromey <tom@tromey.com>
|
|
Signed-off-by: Ijaz, Abdul B <abdul.b.ijaz@intel.com>
|
|
* testsuite/gas/kvx/fat-bundles.s: New test.
* testsuite/gas/kvx/kv3-1-fat-bundles.d: New test.
* testsuite/gas/kvx/kv3-2-fat-bundles.d: New test.
|
|
While the patch already committed for pr30793 prevents the asan error,
there is a problem: Now the last element of bundle_words never gets
written. That's very likely wrong, or KVXMAXBUNDLEWORDS is too big.
So this patch rearranges things a little to support writing of all of
bundle_words and does the parallel bit checking only when filling
bundle_words. In the normal case, kvx_reassemble_bundle will see
bundle_words[word_count-1] with the parallel bit clear and all other
words having it set. In the error case where all words in
bundle_words have the parallel bit set, kvx_reassemble_bundle will be
passed a wordcount of KVXMAXBUNDLEWORDS + 1. I've also made
kvx_reassemble_bundle return true for success rather than zero, and
removed the unnecessary check for zero wordcount.
PR 30793
* kvx-dis.c (kvx_reassemble_bundle): Return bool, true on success.
Fail if wordcount is too large. Don't check for wordcount zero.
Don't check kvx_has_parallel_bit.
(print_insn_kvx): Rewrite code reading bundle_words as a for loop.
Don't stop reading at KVXMAXBUNDLEWORDS - 1.
(decode_prologue_epilogue_bundle): Similarly.
|
|
This bug points out that if one uses -var-set-visualizer with "None"
-- to disable a pretty-printer for a varobj -- then
-var-evaluate-expression will still use pretty-printing.
This is a combination of bugs. First, setting the visualizer does not
update the display text; and second, computing the display text should
use "raw" when Python is available but no visualizer is desired.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11738
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
variable_default_display has a single caller now, so remove it.
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
varobj_set_display_format takes an enum and exhaustively switches on
the values -- but also has a default. This default case is dead code.
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
A user noticed that, while a pretty-printer can return Python strings
from its "children" method, this does not really work for MI. I
tracked this down to my_value_of_variable calling into
c_value_of_variable, which specially handles arrays and structures --
not using the actual contents of the string.
Now, this part of MI seems bad to me, but rather than change that,
this applies the fix to only dynamic varobjs, which is the only
scenario where a string like this can really be returned.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18282
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
With test-case gdb.ada/same_enum.exp and target board dwarf4-gdb-index we run
into:
...
(gdb) print red^M
No definition of "red" in current context.^M
(gdb) FAIL: gdb.ada/same_enum.exp: print red
...
[ This is a regression since commit 844a72efbce ("Simplify gdb_index writing"),
so this is broken in gdb 12 and 13. ]
The easiest way to see what's going wrong is with readelf. We have in section
.gdb_index:
...
[7194] pck__red:
2 [static, variable]
3 [static, variable]
...
which points to the CUs 2 and 3 in the CU list (shown using "2" and "3"), but
should be pointing to the TUs 2 and 3 in the TU list (shown using "T2" and
"T3").
Fix this by removing the counter / types_counter distinction in
write_gdbindex, such that we get the expected:
...
[7194] pck__red:
T2 [static, variable]
T3 [static, variable]
...
[ While reading write_gdbindex I noticed a few oddities related to dwz
handling, I've filed PR30829 about this. ]
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR symtab/30827
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30827
|
|
When running test-case gdb.ada/local-enum.exp with target board debug-types, I
run into:
...
(gdb) print v1(three)^M
No name 'three' in enumeration type 'local__e1'^M
(gdb) FAIL: gdb.ada/local-enum.exp: print v1 element
...
The array V1 is of type A1 which is an array with index type E1, containing
"three" as enumerator:
...
type E1 is (one, two, three);
type A1 is array (E1) of Integer;
V1 : A1 := (0, 1, 2);
...
There's also a type E2 that contains three as enumerator:
...
type E2 is (three, four, five);
...
When doing "print v1(three)", it's the job of ada_resolve_enum to resolve
"three" to type E1 rather than type E2.
When using target board debug-types, the enums E1 and E2 are replicated in the
.debug_types section, and consequently in ada_resolve_enum the type
equivalence check using a pointer comparison fails:
...
for (int i = 0; i < syms.size (); ++i)
{
/* We already know the name matches, so we're just looking for
an element of the correct enum type. */
if (ada_check_typedef (syms[i].symbol->type ()) == context_type)
return i;
}
...
Fix this by also trying a structural comparison using
ada_identical_enum_types_p.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR ada/29335
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29335
|
|
When running test-case gdb.ada/arr_acc_idx_w_gap.exp with target board
cc-with-dwz, I run into:
...
(gdb) print enum_with_gaps'enum_rep(lit3)^M
'Enum_Rep requires argument to have same type as enum^M
(gdb) FAIL: gdb.ada/arr_acc_idx_w_gap.exp: enum_rep
...
With target_board unix, we have instead:
...
(gdb) print enum_with_gaps'enum_rep(lit3)^M
$16 = 13^M
(gdb) PASS: gdb.ada/arr_acc_idx_w_gap.exp: enum_rep
...
Conversely, when I add this test to the test-case:
...
gdb_test "print enum_with_gaps'enum_rep(lit3)" " = 13" \
"enum_rep"
+ gdb_test "print enum_subrange'enum_rep(lit3)" " = 13" \
+ "other enum_rep"
...
the extra test passes with target board cc-with-dwz, but fails with target
board unix.
The problem is here in remove_extra_symbols:
...
if (symbols_are_identical_enums (syms))
syms.resize (1);
...
where one of the two identical enums is picked before the enum_rep handling
can resolve lit3 to one of the two.
Fix this by moving the code to ada_resolve_variable.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR ada/30726
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30726
|
|
block_find_symbol takes a callback function, but only two callbacks
are ever passed to it -- and they are similar enough that it seems
cleaner to just have block_find_symbol do the work itself. Also,
block_find_symbol can take a lookup_name_info as an argument,
following the general idea of pushing the construction of these
objects as high in the call chain as feasible.
Regression tested on x86-64 Fedora 38.
Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
|
|
Following the commit f818c32ba459 ("gdb/mi: fix ^running record with
multiple MI interpreters"), I thought it would make sense to make
current_token a field of mi_interp. This variable contains the token of
the currently handled MI command, like the 222 in:
222-exec-continue
I didn't find any bug related to that, it's just a "that seems nicer"
cleanup, since the current token is a fundamentally per-interp thing.
mi_execute_command needs a check similar to what we already have in
mi_cmd_gdb_exit: when invoked from Python's gdb.execute_mi, the current
interpreter is not an mi_interp. When using the Python gdb.execute_mi
function, there is no such concept of token, so we can just skip that.
There should be no user-visible change.
Change-Id: Ib52b3c0cba4b7c9d805b432c809692a86e4945ad
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Change-Id: Ib841a77a9494648aee9f970141424363664ff6e8
|
|
|
|
Subtraction for labels that require static relocation
usually generates ADD32/64 and SUB32/64.
If subsy of BFD_RELOC_32/64 and PC in same segment,
and disable relax or PC at start of subsy or enable
relax but not in SEC_CODE, we generate 32/64_PCREL
to replace a pair of ADD32/64 and SUB32/64.
|
|
The vendor operands should be named starting with `X', and preferably the
second letter (or multiple following letters) is enough to differentiate
them from other vendors.
Therefore, added letter `t' after `X' for t-head operands, to differentiate
from future different vendor's operands.
bfd/
* elfxx-riscv.c (riscv_supported_vendor_x_ext): Removed the vendor
document link since it should already be recorded in the
gas/doc/c-riscv.texi.
gas/
* config/tc-riscv.c (validate_riscv_insn): Added `t' after `X' for
t-head operands. Minor updates for indents and comments.
(riscv_ip): Likewise.
* doc/c-riscv.texi: Minor updates.
opcodes/
* riscv-dis.c (print_insn_args): Added `t' after `X' for t-head
operands. Minor updates for indents and comments.
* riscv-opc.c (riscv_opcode): Likewise.
|
|
The std::basic_string template type is only specified for
instantiations using character types. Newer (LLVM) libc++
implementations no longer allow non-character integer types
to be used.
gold/
* output.cc: Include <uchar.h>.
(Output_section::add_merge_input_section): Use char16_t and
char32_t for 2- and 4-byte entry size, respectively.
* stringpool.cc: Include <uchar.h>.
(Stringpool_template): Explicitly instantiate for char16_t,
char32_t instead of uint16_t, uint32_t.
* merge.cc (Output_merge_string): Likewise.
|
|
|
|
Commit 3bab069c29b3 carelessly allowed "string" to be released from
the notes obstack twice, with the second call to obstack_free
releasing memory for a fixup that just happened to be the same size as
the original string. The fixup then of course was overwritten.
This patch fixes that problem, and another that could occur on an
error path.
PR 30828
* stabs.c (s_stab_generic): Don't free string twice. Don't
blow away entire notes obstack on a missing string.
|
|
Test-case gdb.ada/same_enum.exp is supposed to be a regression test for this
bit of code in remove_extra_symbols:
...
if (symbols_are_identical_enums (syms))
syms.resize (1);
...
The test-case does "print red" and expects one of these two choices to be
picked by remove_extra_symbols:
...
type Color is (Black, Red, Green, Blue, White);
type RGB_Color is new Color range Red .. Blue;
...
but because only the type Color is used:
...
FC : Color := Red;
SC : Color := Green;
...
the RGB_Color type is eliminated from the debug info, and consequently
remove_extra_symbols has no effect for the test-case.
In other words, we have:
...
(gdb) ptype Color ^M
type = (black, red, green, blue, white)^M
(gdb) ptype RGB_Color^M
No definition of "rgb_color" in current context.^M
...
Fix this by changing the type of SC to RGB_Color, and add prints of the two
types to check that they're both available.
With the test-case fixed, if we disable the bit of code in
remove_extra_symbols we get:
...
(gdb) print red^M
Multiple matches for red^M
[0] cancel^M
[1] pck.color'(pck.red) (enumeral)^M
[2] pck.rgb_colorB'(pck.red) (enumeral)^M
> FAIL: gdb.ada/same_enum.exp: print red (timeout)
...
in other words, the test-case now properly functions as a regression test.
Tested on x86_64-linux.
|
|
When running test-case gdb.python/py-symbol.exp with target board
cc-with-dwz-m, we run into:
...
(gdb) python print (len (gdb.lookup_static_symbols ('rr')))^M
4^M
(gdb) FAIL: gdb.python/py-symbol.exp: \
print (len (gdb.lookup_static_symbols ('rr')))
...
while with target board unix we have instead:
...
(gdb) python print (len (gdb.lookup_static_symbols ('rr')))^M
2^M
(gdb) PASS: gdb.python/py-symbol.exp: \
print (len (gdb.lookup_static_symbols ('rr')))
...
The problem is that the loop in gdbpy_lookup_static_symbols loops over compunits
representing both CUs and PUs:
...
for (compunit_symtab *cust : objfile->compunits ())
...
When doing a lookup on a PU, the user link is followed until we end up at a CU,
and the lookup is done in that CU.
In other words, when doing a lookup in the loop for a PU we duplicate the
lookup for a CU that is already handled by the loop.
Fix this by skipping PUs in the loop in gdb.lookup_static_symbols.
Tested on x86_64-linux.
PR symtab/25261
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25261
|
|
When running test-case gdb.base/setshow.exp with target board cc-with-dwz I
run into:
...
(gdb) info line 1^M
Line 1 of "setshow.c" is at address 0x400527 <main> but contains no code.^M
Line 1 of "setshow.c" is at address 0x400527 <main> but contains no code.^M
(gdb) FAIL: gdb.base/setshow.exp: test_setshow_annotate: annotation_level 1
...
while the expected output is:
...
Line 1 of "setshow.c" is at address 0x400527 <main> but contains no code.
��setshow.c:1:0:beg:0x400527
...
The second line of the expected output is missing due to the first line of the
expected output being repeated, so the problem is that the "Line 1" line is
printed twice.
This happens because the PU imported by the CU reuses the filetab of the CU,
and both the CU and PU are visited by iterate_over_some_symtabs.
Fix this by skipping PUs in iterate_over_some_symtabs.
Tested on x86_64-linux, target boards unix, cc-with-dwz and cc-with-dwz-m.
Approved-By: Tom Tromey <tom@tromey.com>
PR symtab/30797
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30797
|
|
Without this, a simulator build breaks when building from a tarball
made by "./src-release.sh -b sim", when building e.g. bfd and
libsframe. See also previous similar commits for GDB_SUPPORT_DIRS.
The libctf library does not needed to be built, but building
libsframe requires libctf/swap.h, with no dependencies on built or
configured contents. Do as for the single gdb files and include
explicitly only that file.
|
|
|
|
In gprofng testing, we need a tempory gprofng installation to resolve run-time
dependencies on libraries (libgprofng, libopcodes, libbfd, etc).
We set LD_LIBRARY_PATH and GPROFNG_SYSCONFDIR to find our libraries and
configuration file. These variables must be set for all gprofng tests.
Tested on aarch64 and x86_64 with and without --enable-shared and --target=<>.
gprofng/ChangeLog
2023-08-31 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
PR gprofng/30808
* testsuite/config/default.exp: Make a temporary install dir.
Set LD_LIBRARY_PATH, GPROFNG_SYSCONFDIR.
* testsuite/lib/Makefile.skel: Move LD_LIBRARY_PATH and
GPROFNG_SYSCONFDIR setting in testsuite/config/default.exp.
|
|
When a GDB stub is run via "target remote |", it sometimes produces
extra output that ends up mixed with GDB's own output. For example,
QEMU's built-in GDB stub responds to the vKill packet by printing
nios2-elf-qemu-system: QEMU: Terminated via GDBstub
before exiting.
This patch fixes the regexp in gdb.base/hook-stop.exp to allow such
messages between GDB's "continuing" and "Inferior killed" messages.
Reviewed-By: Tom Tromey <tom@tromey.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
These testcases assume host==build or that the remote host has a Posix
shell to run commands in. Don't try to run them if that's not the case.
Reviewed-By: Tom Tromey <tom@tromey.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This patch fixes some testcases that formerly had patterns with
hardwired "/" pathname separators in them, which broke when testing on
(remote) Windows host.
Reviewed-By: Tom Tromey <tom@tromey.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Some embedded targets don't have full support for argc/argv. argv
may print as "0x0" or as an address with a symbol name following.
This causes problems for the regexps in the style.exp line-wrapping
tests that assume it always prints as an ordinary address in backtrace
output.
This patch generalizes the regexps to handle these additional forms
and reworks some of the line-wrapping tests to account for the argv
address string being shorter or longer than a regular address.
Reviewed-By: Tom Tromey <tom@tromey.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This changes the no-op pretty printers -- used by DAP -- to handle
array- and string-like objects known by the gdb core. Two new tests
are added, one for Ada and one for Rust.
|
|
gdb's language code may know how to display values specially. For
example, the Rust code understands that &str is a string-like type, or
Ada knows how to handle unconstrained arrays. This knowledge is
exposed via val-print, and via varobj -- but currently not via DAP.
This patch adds some support code to let DAP also handle these cases,
though in a somewhat more generic way.
Type.is_array_like and Value.to_array are added to make Python aware
of the cases where gdb knows that a structure type is really
"array-like".
Type.is_string_like is added to make Python aware of cases where gdb's
language code knows that a type is string-like.
Unlike Value.string, these cases are handled by the type's language,
rather than the current language.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
Right now, if a program uses multiple languages, DAP value formatting
will always use the language of the innermost frame. However, it is
better to use the variable's defining frame instead. This patch does
this by selecting the frame first.
This also fixes a possibly latent bug in the "stepOut" command --
"finish" is sensitive to the selected frame, but the DAP code may
already select other frames when convenient. The DAP stepOut request
only works on the newest frame, so be sure to select it before
invoking "finish".
|
|
This adds the type::is_array_like method and the value_to_array
function.
The former can be used to see whether a given type is known to be
"array-like". This is the currently the case for certain
compiler-generated structure types; in particular both the Ada and
Rust compilers do this.
|
