This changes a number of MI tests to use mi_clean_restart rather than
separate calls. This reduces the number of lines, which is nice, and
also provides a nicer model to copy for future tests.
A lot of the MI tests start gdb and only then build the executable.
This just seemed weird to me, so I've fixed this up. In this patch,
no other cleanups are done, the startup is just moved to a more
logical (to me) spot.
An early "return" in this test case prevents a test from running.
This seems to have been intentional and has been in place since:
commit d57cbee932
Author: Andrew Burgess <andrew.burgess@embecosm.com>
Date: Tue Dec 3 13:18:43 2019 +0000
gdb/testsuite/fortran: Fix info-modules/info-types for gfortran 8+
This patch removes the dead code.
clean_restart accepts a single optional argument. Rather than using
{args} and handling the argument by hand, change it to use Tcl's own
argument-checking.
There's a comment a few lines earlier saying that demand_copy_C_string
has already reported an error if it returns NULL. Given the proximity
I decided not to duplicate the comment.
* dwarf2dbg.c (dwarf2_directive_filename): Check return of
demand_copy_C_string for file.
Due to a GDB bug (visible when building with -D_GLIBCXX_DEBUG), GDB
crashes somewhere in the middle of gdb.cp/cpexprs.exp, and thus fails to
read the string, at gdb.cp/cpexprs.exp.tcl:725. The "correct" variable
doesn't get set, and I then see this TCL error:
ERROR: can't read "correct": no such variable
Avoid the TCL error by initializing the "correct" variable to a dummy
value.
Change-Id: I828968d9b2d105ef47f8da2ef598aa16a518c059
Prior to this patch, I get:
>>> {"seq": 17, "type": "request", "command": "disassemble", "arguments": {"memoryReference": "0x115d", "instructionCount": 1}}
Content-Length: 147
{"request_seq": 17, "type": "response", "command": "disassemble", "success": false, "message": "Cannot access memory at address 0x115d", "seq": 41}FAIL: gdb.dap/basic-dap.exp: disassemble one instruction success
FAIL: gdb.dap/basic-dap.exp: instructions in disassemble output
The problem is that the PC to disassemble is taken from the breakpoint
insertion response, which happens before running. With a PIE
executable, that PC is unrelocated, but the disassembly request happens
after relocation.
I chose to fix this by watching for a breakpoint changed event giving
the new breakpoint address, and recording the address from there. I
think this is an interesting way to fix it, because it adds a bit of
test coverage, I don't think these events are checked right now.
Other ways to fix it would be:
- Get the address by doing a breakpoint insertion after the program is
started, or some other way.
- Do the disassembly by symbol instead of by address.
- Do the disassembly before running the program.
Change-Id: I3c396f796ac4c8b22e7dfd2fa1c5467f7a47e84e
In the following patch, I change gdb.dap/basic-dap.exp such that after
waiting for some event, it checks if it received another event
meanwhile. To help with this, make dap_wait_for_event_and_check and
_dap_dap_wait_for_event return a list with everything received before
the event of interest. This is similar to what
dap_check_request_and_response returns.
Change-Id: I85c8980203a2dec833937e7552c2196bc137935d
I think that name describes a bit better what the proc does, it is
similar to "wait_for" in tuiterm.exp.
Change-Id: Ie55aa011e6595dd1b5a874db13881ba572ace419
The DAP helper functions generally return TON objects. However, callers
almost all immediately use ton::2dict to convert them to dicts, to
access their contents. This commits makes things a bit simpler for them
by having function return dicts directly instead.
The downside is that the TON objects contain type information. For
instance, a "2" in a TCL dict could have been the integer 2 or the
string "2" in JSON. By converting to TCL dicts, we lose that
information. If some tests specifically want to check the types of some
fields, I think we can add intermediary functions that return TON
objects, without having to complicate other callers who don't care.
Change-Id: I2ca47bea355bf459090bae8680c6a917350b5c3f
This catch didn't cause me any trouble, but for the same reason as the
preceding patch, I think it's a bit better to just let any exception
propagate, to make for easier debugging.
Change-Id: I1779e62c788b77fef2d50434edf4c3d2ec5e1c4c
Following some of my changes, dap_request_and_response was failing and I
didn't know why. I think it's better to make it not catch any
exception, and just make it do a simple "send request, read response".
If an exception is thrown while sending a request or reading a response,
things are going really badly, it's not like we'll want to recover from
that and continue the test.
Change-Id: I27568d3547f753c3a74e3e5a730d38a8caef9356
This helps following what happens when reading gdb.log. The downside is
that it becomes harder to tell what text is from GDB and what text is
going to GDB, but I think that seeing responses without seeing requests
is even more confusing. At least, the lines are prefix with >>>, so
when you see this, you know that until the end of the line, it's
something that was sent to GDB, and not GDB output.
Change-Id: I1ba1acd8b16f4e64686c5ad268cc41082951c874
Prefix some procs that are only used internally with an underscore, to
make it clear they are internal. If they need to be used by some test
later, we can always un-prefix them.
Change-Id: Iacb8e77363b5d1f8b98d9ba5a6d115aee5c8925d
The gcc 4.4.x (and earlier) compilers had the problem that the unwind info in
the epilogue was inaccurate.
In order to work around this in gdb, epilogue unwinders were added with a
higher priority than the dwarf unwinders in the amd64 and i386 targets:
- amd64_epilogue_frame_unwind, and
- i386_epilogue_frame_unwind.
Subsequently, the epilogue unwind info problem got fixed in gcc 4.5.0.
However, the epilogue unwinders prevented gdb from taking advantage of the
fixed epilogue unwind info, so the scope of the epilogue unwinders was
limited, bailing out for gcc >= 4.5.0.
There was no regression test added for this preference scheme, so if we now
declare epilogue unwind info from all gcc versions as trusted, no test will
start failing.
Fix this by adding an amd64 and i386 regression test for this.
I have no gcc 4.4.x lying around, so I fabricated the assembly files by:
- commenting out some .cfi directives to break the epilogue unwind info, and
- hand-editing the producer info to 4.4.7 to activate the fix.
Tested on x86_64-linux, target boards unix/{-m64,-m32}.
This extends PDB support to the aarch64 PE targets.
The changes to the test files are just to make it so they can be assembled as
either x86, x86_64, or aarch64, mainly by changing the comment style.
The only actual code change here is in adding the architecture constants
to pdb.c.
This patch resolves the performance issue reported in pr/29738 by
caching the values for the stack pointers for the inner frame. By
doing so, the impact can be reduced to checking the state and
returning the appropriate value.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>
When there is no dwarf2 data for a register, a function can be called
to provide the value of this register. In some situations, it might
not be trivial to determine the value to return and it would cause a
performance bottleneck to do the computation each time.
This patch allows the called function to have a "cache" object that it
can use to store some metadata between calls to reduce the performance
impact of the complex logic.
The cache object is unique for each function and frame, so if there are
more than one function pointer stored in the dwarf2_frame_cache->reg
array, then the appropriate pointer will be supplied (the type is not
known by the dwarf2 implementation).
dwarf2_frame_get_fn_data can be used to retrieve the function unique
cache object.
dwarf2_frame_allocate_fn_data can be used to allocate and retrieve the
function unique cache object.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>
I noticed some unusual code in mi-cmd-stack.c. This code is a switch,
where one of the cases appears in the middle of another block. It
seemed cleaner to me to have the earlier case just conditionally fall
through.
Pass -Wl,--no-as-needed to linker tests to fix
FAIL: Run pr19031
FAIL: Run got1
FAIL: Undefined weak symbol (-fPIE -no-pie)
FAIL: Undefined weak symbol (-fPIE -pie)
when --as-needed is passed to linker by compiler.
PR ld/30050
* testsuite/ld-i386/i386.exp: Pass -Wl,--no-as-needed to compiler
as needed.
This changes some tests to use require with 'is_remote', rather than
an explicit test. This adds uniformity helps clean up more spots
where a test might exit early without any notification.
A number of tests will exit early without saying why. This patch adds
"unsupported" at spots like this that I could readily find.
There are definitely more of these; for example dw2-ranges.exp fails
silently because a compilation fails. I didn't attempt to address
these as that is a much larger task.
A few tests work on two different targets that can't be detected with
a single call to istarget -- that proc only accepts globs, not regular
expressions.
This patch introduces a new is_any_target proc and then converts these
tests to use it in a 'require'.
This changes many tests to use require when checking 'istarget'. A
few of these conversions were already done in earlier patches.
No change was needed to 'require' to make this work, due to the way it
is written. I think the result looks pretty clear, and it has the
bonus of helping to ensure that the reason that a test is skipped is
always logged.
With test-case gdb.base/unwind-on-each-insn.exp and target board unix/-m32, I
now get:
...
# of expected passes 25
...
instead of:
...
# of expected passes 133
...
as I used to get before commit d25a8dbc7c ("[gdb/testsuite] Allow debug
srcfile2 in gdb.base/unwind-on-each-insn.exp"), due to the test-case trying to match
"rip = " and info frame printing "eip = " instead.
Fix this by dropping "rip" from the regexp.
Tested on x86_64-linux, target boards unix/{-m64,-m32}.
Test-case gdb.base/unwind-on-each-insn.exp compiles $srcfile with debug info, and
$srcfile2 without.
Occasionally, I try both files with debug info:
...
- $srcfile $debug_flags $srcfile2 $nodebug_flags]]} {
+ $srcfile $debug_flags $srcfile2 $debug_flags]]} {
...
This shortcuts the test due to no longer recognizing that stepi still lands
in foo.
Fix this by determining whether still in foo by checking the info frame output.
Tested on x86_64-linux.
