"script" field of a breakpoint used to be output as a tuple (<= GDB 12),
though it is a list. There are cases of flags that can be applied to
get old or new behaviour too.
This code handles both cases transparently.
See https://sourceware.org/bugzilla/show_bug.cgi?id=24285
Part of #816
For Core Build System local debug target. If there is no absolute path
set in the Debugger tab of the launch configuration, try to find the
debugger first in the selected toolchain. If the debugger is not found
in the toolchain, let GdbLaunch search in PATH.
If an absolute path is set, GdbLaunch will use that.
Fixes#1008
The CDT Debug Activites was originally added when we had two
distinct debuggers in CDT, the DSF one and the CDI one. To
eliminate confusion the preferences for the respective
debug infrastructures were only displayed if users actually
ran such a debug session.
Now with just one debug infrastructure, we should always display
the preference pages. It also removes some confusion that some
preference pages weren't visible until after you started the
debug session. So for example, users couldn't turn on or off
a bunch of default settings until after creating and launching
a debug session.
I have left the enableActivity call in GdbLaunchDelegate in
case any extenders were hiding some of their UI behind that key.
The only exception in the above is the View Performance preference
page which was misplaced in the top level Run/Debug preference
tree, even though it is CDT specific. That preference page has
been re-parented to C/C++ -> Debug
Fixes https://github.com/eclipse-cdt/cdt/issues/972
Do not check for binaries in the project directory if the user defined
a binary in the Main tab. This supports the case where the user
disables auto build and selects a binary outside the project directory.
Otherwise the binaries check would stop the launch with the message
that no binaries are found in the project.
The launch configuration for local Core Build projects got the
Debugger and Source tabs in debug mode. Now the user can set the stop
at startup, a specific debugger, and all other Debug options as we
know from Managed Build projects.
The GdbLaunch class automatically picks up all the debug settings from
these new tabs. No additional code was needed for that.
The composition of Core Build tab groups is now fully done via the
launchConfigurationTabGroups extension-point.
This change relates to #758. It affects all Core Build projects,
including CMake projects.
A new Main Tab was created for Core Build local projects based on the Main
Tab used for the classic Managed Build projects. It adds these
features:
* Option to select a different binary.
* Option to control launch pre-builds.
The default value for the binary is empty string. With empty string
the behaviour for binary selection stays the same as it was.
The project name is fixed and cannot be changed. A Core Build launch
configuration is created with the project and tied to it.
There is no option to select a build configuration, because for Core
Build projects this is selected via the LaunchBar's Launch Mode.
This change relates to #758. It affects all Core Build projects,
including CMake projects.
When launching a GDB debug session using the Launch Bar and a Launch
Target, now the launch takes into account a REMOTE_TCP value in the
launch configuration before considering the type of the Launch Target.
Improves the change submitted in:
Bug 547881 - Allow targets to set ATTR_REMOTE_TCP
Fixes issue #622
Some bundles are bumped because dev happened between 11.2 release and
this version bump. The most significant change that happened
was the bump in Tycho version which changed ECJ version and
hence some class files changed
Part of #420
Looking at the logs, it seems that the regression is caused at 8bec791
where support for multi-process was added. We removed breakpoints
tracking support from final launch sequence and moved it to debug new
process and attach to process logic but none of these are run for remote
attach launch, hence breakpoint tracking is not started for remote
attach launch.
To fix the problem, IGDBProcesses.attachDebuggerToProcess(..) is updated
to handle remote attach launch as well instead of final launch sequence
handling it.
This commit is created after reverting 7bddb5f and 96839a0 which is the
older fix done to fix this issue and the other commit was to fix the
regression caused by the old fix.
The problem with older fix was that for non-stop mode, attach to process
was not working for remote launches when there is already a process
being debugged. Note that to use this feature, gdbserver should be
started with --multi option.
* Revert "Bug 580259: Not all remote session have a connected process"
This reverts commit 96839a029d.
* Revert "Bug 528145 - Attach debugger to a gdbserver remote session"
This reverts commit 7bddb5f4cb.
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
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 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.
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
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>
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
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
'/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
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>
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
- Added null check to prevent NPE.
- Fixed the collector used in doTargetBreakpointsSynchronized method.
Change-Id: I1ea48b9231882923fe364321e42d0202a0924bf3
Signed-off-by: Umair Sair <umair_sair@hotmail.com>
