Factor out the code for testSettingVariableWithSet and
testSettingVariableWithPrint.
testSettingVariableWithSetWithMemory is not exactly the same, so I
didn't factor it out.
Change-Id: Ib4e79eda4851ec2291fcf32054694b76e40c65ca
Signed-off-by: Simon Marchi <simon.marchi@polymtl.ca>
Catching the exception and asserting false just hides the real reason,
making failures harder to debug.
Change-Id: I1a73fb5893da2762d0b9a9a496749643471f75b4
Signed-off-by: Simon Marchi <simon.marchi@polymtl.ca>
Reviewed-on: https://git.eclipse.org/r/39787
Reviewed-by: Marc Khouzam <marc.khouzam@ericsson.com>
Tested-by: Marc Khouzam <marc.khouzam@ericsson.com>
runToLine uses gdb's -exec-until, which has a very strange and
unpredictable behaviour. It is safer to use runToLocation, which uses a
temporary breakpoint + continue.
Change-Id: If7bbbdd12570b50f38eb92f1748d10dff96f1f45
Signed-off-by: Simon Marchi <simon.marchi@polymtl.ca>
Reviewed-on: https://git.eclipse.org/r/39769
Tested-by: Hudson CI
Reviewed-by: Marc Khouzam <marc.khouzam@ericsson.com>
Tested-by: Marc Khouzam <marc.khouzam@ericsson.com>
A change in gdb showed that we shouldn't rely on the order of threads
when they are all created at the same time.
The solution is to break after each thread is created, so that gdb takes
note of the new thread before we spawn another one. This way, they'll
always be in the same order.
Change-Id: Ia62dc0476163ad44bba52d51df95cf747d27da84
Signed-off-by: Simon Marchi <simon.marchi@polymtl.ca>
Reviewed-on: https://git.eclipse.org/r/39712
Reviewed-by: Marc Khouzam <marc.khouzam@ericsson.com>
Tested-by: Marc Khouzam <marc.khouzam@ericsson.com>
This patch attempts to standardize the naming and factor out the variables
that refer to source or executable files throughout the debug tests.
It removes definitions of paths that are already defined in BaseTestCase.
Also, it tries to name these consistently:
- filename of executable: EXEC_NAME
- filename of source: SOURCE_NAME
Finally, it replaces hardcoded paths at various places by constants at the top
of the test class.
Change-Id: Ib2ea3e46b41185fb9614ae6ad9d41c3b70154884
Signed-off-by: Simon Marchi <simon.marchi@polymtl.ca>
Reviewed-on: https://git.eclipse.org/r/38068
Reviewed-by: Marc Khouzam <marc.khouzam@ericsson.com>
Tested-by: Hudson CI
Tested-by: Marc Khouzam <marc.khouzam@ericsson.com>
This new location lends itself better to using our new GDB download
script
dsf-gdb/org.eclipse.cdt.tests.dsf.gdb/scripts/download-build-gdb.sh
Signed-off-by: Marc Khouzam <marc.khouzam@ericsson.com>
-Make sure getopt command is present (not included by default on Mac but
available through MacPorts
-Patch wrong include
Change-Id: I3ad1e19091896f8644ededa9d8200efe40bae82b
Signed-off-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
Reviewed-on: https://git.eclipse.org/r/39438
Reviewed-by: Simon Marchi <simon.marchi@polymtl.ca>
Change-Id: Ia40f8fd676a7e2c302f06efa4ccf9fb77dc6dfc9
Signed-off-by: Marc Khouzam <marc.khouzam@ericsson.com>
Reviewed-on: https://git.eclipse.org/r/39421
Tested-by: Hudson CI
Reviewed-by: Simon Marchi <simon.marchi@polymtl.ca>
Hardcoding line numbers in tests make it a pain to modify the test sources.
The approach adopted in the gdb testsuite is to look for a specific string
in the source file and return the line number where it is found. I made a
similar system for the CDT debug tests.
I dubbed this system breakpoint tags, a tag being the string we look for in
the source file.
I modified the MIRunControlTest as an example, as well as GDBProcessesTest
and MIRegistersTest because they are re-using the same breakpoints.
SOURCE_PATH and EXEC_PATH were duplicated in many test cases, so I factored
them in BaseTestCase.
Change-Id: Id1e64b2064914005ab1d87e16704866aa1c8b9ec
Signed-off-by: Simon Marchi <simon.marchi@polymtl.ca>
Reviewed-on: https://git.eclipse.org/r/36872
Tested-by: Hudson CI
Reviewed-by: Elena Laskavaia <elaskavaia.cdt@gmail.com>
This script can be used to download and build automatically multiple
versions of gdb, which is necessary when working on the CDT debug tests.
Change-Id: Ibf9ddac4efe8f80f480ae2bc9702b722bdc97192
Signed-off-by: Simon Marchi <simon.marchi@polymtl.ca>
Reviewed-on: https://git.eclipse.org/r/38737
Tested-by: Hudson CI
Reviewed-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
Tested-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
Reviewed-by: Marc Khouzam <marc.khouzam@ericsson.com>
Tested-by: Marc Khouzam <marc.khouzam@ericsson.com>
This patch adds SyncUtil.getThreadData to make it easy to get the thread
data from the gdb thread number.
Change-Id: I948a8b87cc3afa64f3d73de23d4ace12ef4c0c1a
Signed-off-by: Simon Marchi <simon.marchi@polymtl.ca>
Reviewed-on: https://git.eclipse.org/r/36870
Reviewed-by: Alvaro Sanchez-Leon <alvsan09@gmail.com>
Tested-by: Alvaro Sanchez-Leon <alvsan09@gmail.com>
Having a compatibility layer for threading operations, like the one we
have for sleep, will allow removing a lot of platform dependent code in
the test sources, therefore simplifying the tests themselves.
I changed MultiThread.cc and MultiThreadRunControl.cc as examples, but
there are other tests files that could benefit from it.
I also changed MultiThread.cc to remove all the synchronization based on
sleeps. It now works using thread barriers, which should make the tests
less prone to random failure (although I don't think these ones were
particularly flaky) and run faster (since we don't wait for nothing).
The fallouts of that change on the Java part of the tests are taken care
of as well.
Change-Id: I7be86a5727877638c0ff0a489d263ee6bbe84764
Signed-off-by: Simon Marchi <simon.marchi@polymtl.ca>
Reviewed-on: https://git.eclipse.org/r/36814
Reviewed-by: Marc Khouzam <marc.khouzam@ericsson.com>
Tested-by: Hudson CI
Tested-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
Reviewed-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
Using more specific assert functions (e.g. assertEquals(a, b) rather than
assertTrue(a.equals(b)) helps a bit to make the test more readable. It can
also improve the display in the JUnit view, by showing expected and actual
values.
Also, there is no need to manually catch an exception and fail the test. If
an exception is thrown, the test will fail automatically.
Change-Id: I333cfd0d0ade41463dc773ab02e14df4b063a22f
Signed-off-by: Simon Marchi <simon.marchi@polymtl.ca>
Reviewed-on: https://git.eclipse.org/r/38617
Reviewed-by: Alvaro Sanchez-Leon <alvsan09@gmail.com>
Tested-by: Alvaro Sanchez-Leon <alvsan09@gmail.com>
When catching the exception and failing the test manually, we loose the
information about the root cause of the problem. We let the exception
propagate so that JUnit will show a useful trace.
Change-Id: I1df26283f42b58b4dda68ab9e8c11cca27ae81c8
Signed-off-by: Simon Marchi <simon.marchi@polymtl.ca>
Reviewed-on: https://git.eclipse.org/r/38771
Reviewed-by: Marc Khouzam <marc.khouzam@ericsson.com>
Tested-by: Marc Khouzam <marc.khouzam@ericsson.com>
-gdwarf-2 was added specifically when the default debug format was
stabs, to force using the DWARF format. It is irrelevant nowadays, and
we want to let the compiler choose the DWARF version it prefers.
Change-Id: I300fab09b492704ca3d3a61446b8dd0ce36167c2
Signed-off-by: Simon Marchi <simon.marchi@polymtl.ca>
Reviewed-on: https://git.eclipse.org/r/38766
Tested-by: Hudson CI
Reviewed-by: Marc Khouzam <marc.khouzam@ericsson.com>
Tested-by: Marc Khouzam <marc.khouzam@ericsson.com>
When executing the launch sequence in testSourceGdbInit, gdb 7.1 inserts
an extraneous \n in one of its replies, causing an assert to be hit.
Since we don't actively support that version, let's just disable the
test.
Change-Id: I9544835ead72e1701766d76fafa0e63f3b88911d
Signed-off-by: Simon Marchi <simon.marchi@polymtl.ca>
Reviewed-on: https://git.eclipse.org/r/38768
Reviewed-by: Marc Khouzam <marc.khouzam@ericsson.com>
Tested-by: Marc Khouzam <marc.khouzam@ericsson.com>
When catching the exception and failing the test manually, the root cause
exception is hidden. If we let the exception propagate, JUnit will fail
the test automatically, and will provide a detailed stack trace.
Change-Id: Ife099d4598109dd0901b14d482b89545cfd01d68
Signed-off-by: Simon Marchi <simon.marchi@polymtl.ca>
Reviewed-on: https://git.eclipse.org/r/38765
Tested-by: Hudson CI
Reviewed-by: Marc Khouzam <marc.khouzam@ericsson.com>
Tested-by: Marc Khouzam <marc.khouzam@ericsson.com>
For older GDBs, we don't support resuming the entire process. The tests
in GDBMultiNonStopRunControlTest were trying to resume the entire
process as a shortcut and it was failing for GDB 7.1 and probably older
ones too.
This change loops over all suspended threads of the process and resumes
them individually.
Change-Id: Ie1056aa9775114c3a0d795a49d87d6efe431785d
Signed-off-by: Marc Khouzam <marc.khouzam@ericsson.com>
Reviewed-on: https://git.eclipse.org/r/38742
Tested-by: Hudson CI
Over the years GDB is showing more registers than before. When the
GDBPatternMatching tests were first written, some random registers were
used. This update uses registers that are available for both old and
new gdb versions, as well as 32bit and 64bit architectures.
Change-Id: Ibbbd50d240f295e1a745fae217013f21aeabff8a
Signed-off-by: Marc Khouzam <marc.khouzam@ericsson.com>
Reviewed-on: https://git.eclipse.org/r/38736
Tested-by: Hudson CI
The following tests fail with gdb 7.0 and 7.1:
- testStopAtMainWithReverse(Restart)?
- testStopAtOtherWithReverse(Restart)?
The reason is that execution crosses getenv() while recording is
enabled. gdb has some trouble with that, and outputs an error such as:
warning: Process record ignores the memory change of instruction at address 0x7ffff7de951f because it can't get the value of the segment register.
warning: Process record ignores the memory change of instruction at address 0x7ffff7de9576 because it can't get the value of the segment register.
Process record doesn't support instruction 0xfef at address 0x7ffff7a9e5e2.
Process record: failed to record execution log.
[process 6993] #1 stopped.
0x00007ffff7a9e5e0 in strlen () from /lib/x86_64-linux-gnu/libc.so.6
We could either make the test "easier" to make it pass on those gdb
versions, or disable it for those gdb versions. By "easier", I mean just
execute some simple arithmetic instead of some calls to libc.
I think it is counter-productive to reduce the span of the tests just to
make some old gdb versions happy, so I chose to disable it for those.
Actually, the best would be to write a new test which covers less but
passes for all versions.
Change-Id: I98499fbb5c099232bc39dad3906d7348912b89af
Signed-off-by: Simon Marchi <simon.marchi@polymtl.ca>
Reviewed-on: https://git.eclipse.org/r/38735
Reviewed-by: Marc Khouzam <marc.khouzam@ericsson.com>
Tested-by: Hudson CI
gdb only started reporting thread names at version 7.3. On Windows, they
are never reported.
If somebody wants to enhance the check for MAC OS X, feel free to do it!
Change-Id: I9d028b24930b632678941682da65cd51da9e88dd
Signed-off-by: Simon Marchi <simon.marchi@polymtl.ca>
Reviewed-on: https://git.eclipse.org/r/38728
Reviewed-by: Marc Khouzam <marc.khouzam@ericsson.com>
Tested-by: Marc Khouzam <marc.khouzam@ericsson.com>
When a breakpoint is set directly at the start of a function, and you step
into that function, gdb <= 7.3 will generate a "stopped" event with two
reason fields. The first to indicate that the step range ended and the
other to indicate that a breakpoint was hit. While this is not really
correct from gdb to include the same field twice in a single event,
the implementation of MIRunControlEventProcessor_7_0 will generate two
distinct MIStoppedEvent events. This confuses the step-into-selection
mechanism, who will issue two finish/step-return instead of one.
For all gdbs, we will have a test where the breakpoint is a not at the
function entry.
Then, for gdb > 7.3, we will have the same test but with the breakpoint
at the function entry, to test that particular case. This case is known
to be broken with gdb <= 7.3 (rather old) and will stay that way unless
somebody feels like fixing it.
So, for both:
- atDoubleMethodStopAtBreakpoint
- atDoubleMethodSkipBreakpoint
I extracted the code in a common function which takes in parameter the
line to set the breakpoint at.
Change-Id: I2ae4bc527afe0ab195e9b066279ed92f74d652f3
Signed-off-by: Simon Marchi <simon.marchi@polymtl.ca>
Reviewed-on: https://git.eclipse.org/r/38717
Tested-by: Hudson CI
Reviewed-by: Marc Khouzam <marc.khouzam@ericsson.com>
Tested-by: Marc Khouzam <marc.khouzam@ericsson.com>
Currently, I get the following error:
g++ -gdwarf-2 -pthread -o ../bin/MultiThreadRunControl.exe
MultiThreadRunControl.cc
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe:
cannot find -lpthread
I could install the pthreads package for mingw, and it would probably
work, but we don't use pthreads on windows, so it's better to just not
link with it.
Change-Id: I5deb58c5b69a98b77e9e9a4a744c6815c830cf20
Signed-off-by: Simon Marchi <simon.marchi@polymtl.ca>
Signed-off-by: Marc Khouzam <marc.khouzam@ericsson.com>
Reviewed-on: https://git.eclipse.org/r/37611
Bug 235747: Move register group actions to the command framework.
Change-Id: Ife5aefc1a1609309724db01d92a35750e25def24
Signed-off-by: Alvaro Sanchez-Leon <alvsan09@gmail.com>
Signed-off-by: Marc Khouzam <marc.khouzam@ericsson.com>
Reviewed-on: https://git.eclipse.org/r/13980
Tested-by: Hudson CI
Change-Id: I3e04a56d218fdb2f189c06968c4f2d2671327838
Signed-off-by: Simon Marchi <simon.marchi@polymtl.ca>
Reviewed-on: https://git.eclipse.org/r/36435
Tested-by: Hudson CI
Reviewed-by: Marc Khouzam <marc.khouzam@ericsson.com>
Tested-by: Marc Khouzam <marc.khouzam@ericsson.com>
The targets that define dsf.gdb.tests.timeout.multiplier need extra time to execute in resumeUntilStopped.
Change-Id: I2de513ea2de63d4276a49fb6daa4aa6892a5e843
Signed-off-by: Simon Marchi <simon.marchi@polymtl.ca>
Reviewed-on: https://git.eclipse.org/r/35907
Reviewed-by: Marc Khouzam <marc.khouzam@ericsson.com>
Tested-by: Marc Khouzam <marc.khouzam@ericsson.com>
We could go more complicated and only rebuild those source files that are
affected by the changes in the header files, but I think this is a good
compromise.
Change-Id: I508e8ca0176408c68a16e09c51f005446aace099
Signed-off-by: Simon Marchi <simon.marchi@polymtl.ca>
Reviewed-on: https://git.eclipse.org/r/36797
Tested-by: Hudson CI
Reviewed-by: Marc Khouzam <marc.khouzam@ericsson.com>
Tested-by: Marc Khouzam <marc.khouzam@ericsson.com>
I don't see any reason to take a String for a line number. This avoids
doing Integer.toString in a few places.
Change-Id: I4618b8c783100a406ff25d229b3b703b1d24f772
Signed-off-by: Simon Marchi <simon.marchi@polymtl.ca>
Reviewed-on: https://git.eclipse.org/r/36876
Reviewed-by: Marc Khouzam <marc.khouzam@ericsson.com>
Tested-by: Marc Khouzam <marc.khouzam@ericsson.com>
This changes the Makefile that builds test apps so that it uses the
proper Makefile structures, rather than a single shell command.
Also, this will compile .c files with gcc and .cc files with g++,
allowing to have both.
Also, I changed the .exe extension justification from "so that CVS does
not include it when making a patch" to "so that files are named the same
way in Linux and Windows". It seems more reasonable.
Change-Id: I4414b1dc5c31a9eaa7edaed30e53363b9a76dd8f
Signed-off-by: Simon Marchi <simon.marchi@polymtl.ca>
Reviewed-on: https://git.eclipse.org/r/36488
Tested-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
Tested-by: Hudson CI
Reviewed-by: Marc Khouzam <marc.khouzam@ericsson.com>
Tested-by: Marc Khouzam <marc.khouzam@ericsson.com>
We are getting intermittend failures on the GDBConsoleBreakpointsTest
due to the fact that we create and then try to delete a breakpoint so
fast that the MIBreakpointsManager does not have enough time to update
its data structures.
This is something specific to automated tests, as a user won't be able
to delete a breakpoint so fast.
Change-Id: I4b220cc859b7ee45e1b8dbde0edbcaa38b9dfe34
Signed-off-by: Marc Khouzam <marc.khouzam@ericsson.com>
Reviewed-on: https://git.eclipse.org/r/33432
Tested-by: Hudson CI
Reviewed-by: Alvaro Sanchez-Leon <alvsan09@gmail.com>
This will make the build not fail but complete with errors.
Also, only build the test apps if we are going to run the tests.
Change-Id: I1a16eb812df45279d973ead37038683b5b0a5dff
Signed-off-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
Reviewed-on: https://git.eclipse.org/r/33406
Tested-by: Hudson CI
Reviewed-by: Alvaro Sanchez-Leon <alvsan09@gmail.com>
Jacoco arguments are missing when executing certain tests. This happens when
argLine is being overriden. We had the same problem in Linux Tools. We solved
it by prepending the argLine with ${tycho.testArgLine}. This should help
improving the Code coverage metric in Sonar.
Also update the jacoco version to fix a bug when building with Java 8.
Change-Id: I7f73f40488efc01fc7d643940c1ac0d5950c900d
Signed-off-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
Reviewed-on: https://git.eclipse.org/r/32507
Tested-by: Hudson CI
Reviewed-by: Alvaro Sanchez-Leon <alvsan09@gmail.com>
