target-async is the old name for mi-async. mi-async came
into existence in GDB 7.8, but in later releases it becomes
a warning to use the old name.
Because we already have the version infra for 7.12 we
change to using mi-async from 7.12
A similar change was made for
[cdt-gdb-adapter a while ago](https://github.com/eclipse-cdt-cloud/cdt-gdb-adapter/blob/main/src/GDBBackend.ts#L114-L116)
Fixes#176
Note that FileBasedErrorParserTests had to change because of some
Tycho incompatibility with JUnit's ParameterizedTest. It works
in the IDE, but not in maven.
The correct fix is to resolve the tycho settings, see Bug 569949
for a previous example. It may also be simply resolved by updating
to Tycho 3.0.0. However I want to get this change in as
at the moment CDT.setup is broken and that is impeding developers.
These tests all had the same mistake, they had 5 x waitForEvent
with the comment "at this point all 5 threads should be stopped"
but there are actually 6 threads (5 spawned ones + main thread).
Most of the time all 6 threads would be stopped in time, but
sometimes one of them wouldn't be stopped, leading to a
"CoreException: Context is running" error in the test
This fixes the ThreadStackFrameSyncTest item
Part of #117
Warning in build.properties will be errors when they run
in the tycho build, like this:
```
Error: Failed to execute goal org.eclipse.tycho:tycho-packaging-plugin:2.7.5:package-plugin
(default-package-plugin) on project org.eclipse.cdt.core.tests:
/home/runner/work/cdt/cdt/core/org.eclipse.cdt.core.tests/build.properties:
bin.includes value(s) [test.xml] do not match any files. -> [Help 1]
```
So make them errors in the workspace so that the issue is
detected before push.
Some build.properties issues don't affect the build, but
are still indicative of a problem.
The long sleep at the end of each thread is to make sure that
while the test code is waiting for an event the "other" thread
doesn't finish. 3 seconds is not long enough for this.
This is similar to why we need dsf.gdb.tests.timeout.multiplier
for other tests. Especially on the build machines the tests
can run much slower causing the sleep to be insufficient.
Increasing this to 30 seconds doesn't make the test suites
take any longer, when they are all passing.
Fixes#119
The parser for dprintf parameters was much too simplistic and
prevents real uses cases from operating.
It is not necessary to remove the , between the arguments to
dprintf, so don't try to split on that anymore. That also
means we can't check for and error on mismatch between format
specifiers and number of arguments.
e.g. "===> XML_EVENT_TEXT(%s)\n", (char *)strtok(Text,"\n")
should be permitted.
The alternative would be to write a more complete parser for
both the printf specification and the arguments. Well out of
scope and unnecessary.
Some inputs may now be accepted by the GUI and then when
inserted with GDB fail. These errors are displayed in the
GUI already anyway.
This fixes numerous warnings like this:
Boolean is a value-based type which is a discouraged argument
for the synchronized statement
and:
Integer is a value-based type which is a discouraged argument
for the synchronized statement
- Fix the running so that the correct gdb is used.
- Only run DSF tests if dsf directories have been modified
- Default to using gdb,gdbserver on the PATH when running
tests
- Remove double reporting of test results
The root files in GitHub are a bit more prominent, so keep
that area clean and move this special ini to a subdir.
Change-Id: I12d95727e9dad29ebe4f50d47faa9e98753a52bc
Reason:
=======
The problem is that we use '-thread-info' command for each thread and
for each command, a lot of common conversation happen between gdb and
gdbserver for each command.
Solution:
=========
We should use '-list-thread-groups <group id>' instead which provides
the same required information for all the threads and minimizes the
communication between gdb and gdbserver. This command takes lesser time
than the collective time taken by all '-thread-info' commands.
Tested with 2 and 8 threaded application using gdb 7.1 and 11. The gain
is more prominent as the number of threads increases.
Signed-off-by: Umair Sair <umair_sair@hotmail.com>
Change-Id: Ie4824bf110f05d4136697f4e1ecbcc19dcf145a7
On Windows, the TabFolder and TabItem classes does not follow the
themeing in Eclipse. As a result, the tab selectors will be drawn with
the light theme while the rest of the Eclipse UI is in dark theme.
Contributed by STMicroelectronics
Change-Id: I9169c9e01f8c9a3af7b6bb6d1c673a043735e7e9
Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com>
This mostly is using diamond operator, but includes
adding missing @Override and organizing imports and
applying formatting improvements in the JDT formatter.
Change-Id: Id91cbff33b0a039cc5121945ffbc407ecba45866
The CDT Cleanup profile had a bunch of extra cleanups applied to it, this
prevents running the CDT cleanup profile manually to simulate running the
save actions on all Java files
Change-Id: Iad491e1258a4ba90d81d1457ea0f6779e3663e38
Since the fault in GDB is triggered when there is more than one MI
command sent before the response for the prior one is processed, limit
the number of concurrent commands to 1 for the affected versions.
Contributed by STMicroelectronics
Change-Id: I5b47fc64d90eefdc44c1d2ead0da99b35aadfa39
Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com>
All the about.html files are updated, so every bundle that hasn't
already had a bump in 10.7 needs one now
Change-Id: I6143d2fbe77a58a3a6d2f4a226d96087117f9ac1
We must ensure that memory data is initialized before the restoration of
persisted memory monitors is triggered.
Change-Id: I1fc2af877d27f331fbc4c516c05fb871dad410c4
Signed-off-by: John Dallaway <john@dallaway.org.uk>
The org.eclipse.remote.* version bumps were all because of
BREE change since the last release.
The api filters are removed because of the baseline bump
Change-Id: Ic7317dafa9872bb737502654a726823a35ec47b3
The current situation is that:
* launch configuration dialog tabs scroll correctly in the standard
Eclipse platform dialog, but not at all in the Launchbar-specific dialog
* some CDT-supplied launch configuration dialog tabs try to manage their
own scrolling behaviour to fix scrolling in the Launchbar-specific
dialog but this breaks scrolling for that tab in the standard Eclipse
platform dialog.
This change fixes the launchbar-specific editor dialog to use a scrolled
composite instead of a regular composite on which to layout the content
of each tab -- This gives the launchbar's configuration editing dialog
exactly the same scrolling behaviour as the standard Eclipse platform
configuration editing dialog.
And also fixes any CDT-supplied tabs that try to manage their own
scrolling behaviour so now all tabs have the same behaviour when viewed
in the Launchbar-specific dialog as they do when viewed in the standard
Eclipse platform dialog.
Change-Id: I0d7364a24ca48bb125cae9518728b4c93b93545d
Signed-off-by: Mat Booth <mat.booth@gmail.com>
When the UI layer is running the correct terminate adapter is returned,
when the UI layer is not running, the Launch.terminate code is a valid
fallback, and the org.eclipse.debug.internal.core.commands.TerminateCommand
is not an appropriate adapter to use.
Change-Id: I3c4c273b78b4e5bc9fe521b4a24ef5443852d3c0
The test used to fail on the -100.0 / 3.0 case if that was the first
condition tested. This change forces that to not be the first
condition tested which reduces the incidence of failures.
This does not resolve the unknown underlying issue which appears
to be on the GDB side that CDT is exposing. Upgrading GDB version
may also resolve the test failures, but for now I am going with
this fix so that we stop having UNSTABLE Jenkins CI builds.
Change-Id: Ibfa93a8350cfc08adf721723bc07566521bed812
'/tcp' suffix is not supported anymore with 'gdb',
so an IP address should be in form of HOST:PORT
(and not of HOST:PORT/PROTOCOL)
See: https://github.com/flathub/org.eclipse.Java/issues/36
Change-Id: I9eedc450da0d39305fc5d4cde851eb991c3c31f0
Signed-off-by: Victor Rubezhny <vrubezhny@redhat.com>
