Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Problem with executing dsf-gdb JUnit tests

At 03:19 AM 3/8/2010, sneha_apte wrote:
As explained in the below link, after executing the JUnitPluginTests for test suite 6.8, .exe files are generated and placed in data/launch/bin folder. These binaries seem to be generated for the .cc programs present in the data/launch/src folder (as given in theMakefile)
No other binaries are seen to be generated.
Thus it seems that binaries are not getting built for 6.8 tests.
Is there are any step which I might be missing?

What other binaries are you expecting? Only one set of binaries are supposed to be generated. There isn't going to be a set for each gdb version.


As mentioned in below email, I debugged the code in class FinalLaunchSequence at the step that sends the command MIFileExecAndSymbol. For the package org.eclipse.cdt.test.dsf.gdb.tests, the code returns valid path for execPath variable and thus the command MIFileExecAndSymbol gets queued successfully.
However for package org.eclipse.cdt.test.dsf.gdb.tests.tests_6_8
the code does not get value for execPath and thus the command: MIFileExecAndSymbols is not queued.

I had a doubt regarding the name of binary being specified. As per below mail,
"The binary is specified in the @BeforeClass of each test
by setting the ATTR_PROGRAM_NAME configuration attribute."

Above mentioned configuration attribute is set in class ExampleTest of the package org.eclipse.cdt.test.dsf.gdb.tests. The @BeforeClass of tests in the 6.8 test package do not set the above mentioned attribute.

Is the above mentioned observation expected?

The base class of each version-specific test class does. JUnit calls the @BeforeClass of not only the class being tested but of its super classes. The super class is called before the subclass.



Back to the top