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.
