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>
- add check for flatpak environment variable in
GDBBackend_7_12.isFullGdbConsoleSupported() method
and return false if variable is set
Change-Id: I667a63395592e2671ab3bf6f255e7428371086b3
While most of these commands don't actually have spaces in them, or
their arguments, avoid the deprecated methods.
Change-Id: If7b4324695699d5a6d9a2f8a979657977486d8a4
Improvements in SyncUtil's addBreakpoint and runToLocation
methods to make them support hardware breakpoint
Change-Id: If358bf11cab426f48edb8854e9ece911c2839815
Signed-off-by: Abdullah Khalid <abdullah.dev0@gmail.com>
Eclipse CDT supports GDB version 6.6 and newer. Some features
in Eclipse CDT require newer versions of GDB. The Eclipse CDT
project focuses its testing time on GDB version 8.0 and newer.
Change-Id: Ifb7cd77c9fae4b9d1b82e0aa8a2cea206a4298b7
In some situations, it makes sense to have a build structure parallel
with the source tree, and it this case, the build results may not be
part of the resources visible in the Eclipse workspace.
Current implementation allows absolute paths to the binary to debug.
While it works, it's a cumbersome way to handle the above situation.
By resolving the relative path outside of Eclipse scope allows to point
to files that are not part of the Eclipse workspace, allthough the path
is relative to a project in the workspace.
Contributed by STMicroelectronics
Change-Id: I284a5dad61e692dae4029e5f142d23d8cda98ed0
Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com>
this fixes cases where a single test failing does not clean up
properly causing subsequent tests to then fail.
Change-Id: I4bd9c08e5ce1a4cd2ccd5e710a446e6e96c4d353
Instead make the tests non-intermittent. If tests are flaky, they
should be moved to JUnit5 and marked with the flaky tag.
Change-Id: I9c165ec8f16c65383d93d64d17047c0a2597b81c
Many of the disabled tests were failing because they were dependent
on specific combinations of GDB + GCC and where exactly code
stops and steps effect when entering functions. The old code
mostly ran to a function and then stepped a known number of times.
But what changes between GDB versions is how many steps are needed.
Therefore for all failing tests update to run to a specific line
number by using tags in the .cc file and running to them to make
sure the test is precisely on that line.
This partially reverts commit 8220215a2e
and 92272c6465
Reason for revert: These tests were "temporarily" disabled a while ago
as part of the JIRO migration in Bug 545624.
Change-Id: I703429c8a81c856360f1cb4e899026200527f7c6
