eclipse-plugins icon indicating copy to clipboard operation
eclipse-plugins copied to clipboard

When j-link debugging 2 projects from single eclipse, setting breakpoint halts both targets

Open philipag opened this issue 9 years ago • 8 comments

Versions: Eclipse IDE for C/C++ Developers 4.5.1.20150917-1200 GNU ARM C/C++ J-Link Debugging 3.2.1.201512141335 Java 8 update 71 Windows 10 Pro I tried GCC 4.9,3 and 5.3 I tried Segger j-link install 5.00l and 5.1

Steps to repeat

  1. open j-link GDB server for both targets.
  2. open single eclipse instance and start debugging ProjectA and ProjectB
  3. open ProjectB source file and disable or enable a breakpoint

I expect only ProjectB target to be halted and breakpoint set. However, ProjectA is also halted (even though no breakpoint is set).

Segger logs for ProjectB are as expected:

Debugger requested to halt target... ...Target halted (PC = 0x00012BD2) Reading all registers Read 4 bytes @ address 0x00012BD2 (Data = 0x0380F3C3) Removing breakpoint @ address 0x000129EE, Size = 2 Starting target CPU...

Segger logs for ProjectA should be empty but show:

_Debugger requested to halt target... ...Target halted (PC = 0x0000D16C) Reading all registers Read 4 bytes @ address 0x0000D16C (Data = 0x00000000) Read 2 bytes @ address 0x0000D16C (Data = 0x0000) Starting target CPU... _

I think this might be a plug-in regressio

philipag avatar Feb 07 '16 14:02 philipag

this is a known CDT problem, the debugger does not differentiate breakpoints between projects, so you should not debug more than one project at a time.

ilg-ul avatar Feb 07 '16 18:02 ilg-ul

Thanks for the info.  Here are some observations that contradict what you said though:

1  I can actually set breakpoints for both projects and they all work correctly.  They are set only in the appropriate target. 2. If this were a CDT problem wouldn't the breakpoint get set in both j-link logs?  It is only being set in the correct target. 3. So you see, breakpoints are actually working perfectly with multiple projects EXCEPT for this stopping of all targets while breakpoints are being set.  Of course this could still be a CDT problem.

I would love to narrow this issue down more so if you can point me to any CDT bug/feature reports or relevant documentation maybe I can contribute to getting this resolved in the CDT...

Cheers

philipag avatar Feb 07 '16 20:02 philipag

i often debug multiple x86 application as multiple instance of same exe/project or different exe/project on window CDT (luna/mars) and this work perfectly. i can break in one continue second never it break nor stop all exe under debug

So to me it's not quite a CDT issue , it is more likely an issue on the h/w gdb or jlink plugin and it's derivative.

diabolo38 avatar Feb 07 '16 20:02 diabolo38

please use the web interface and do not reply by email.

let me try to repeat to see if I got your report right:

  • you have two j-link probes connected to the same machine (with both different serial numbers), accessed via two gdb servers (waiting on different ports)
  • you start two debug sessions on the same Eclipse, using the GNU ARM Eclipse J-Link plug-in
  • you set a breakpoint in one target
  • you start execution of both targets
  • when one target reaches the breakpoint, the other target halts too

additional questions:

  • do both targets run the same application?
  • if not, when you set the breakpoint in one target, does a file with the same name exist in the other target? is so, could you set a breakpoint in a file that does not exist in the other target?

please be sure you erase all breakpoints from both targets before setting the breakpoint in one target.

ilg-ul avatar Feb 07 '16 20:02 ilg-ul

it is more likely an issue on the h/w gdb or jlink plugin and it's derivative.

the j-link plug-in uses the gdb hardware plug-in, and does not change much in the actual debug sequences, it mostly starts the gdb server, the gdb client and various consoles.

I do not exclude a problem in the j-link plug-in, if cdt debug worked fine, the problem must be either in the j-link or in the hw debug plug-in.

could you try to use the h/w plug-in directly, without the j-link plug-in. if this works, the problem should be in my plug-in.

I would love to narrow this issue down

please do and let me know the results.

ilg-ul avatar Feb 07 '16 20:02 ilg-ul

ilg-ul, that is not what is happening.

  1. Yes, I do have 2 probes and 2 gdb servers on different ports.
  2. Yes, I start 2 debug sessions on the same Eclipse using gnu arm j-link plug-in
  3. No, I can set breakpoints on any target before or during execution and they all work correctly in the sense that the breakpoint is set in the correct target and each target only breaks on the breakpoints that belong to that target. So all breakpoints work as expected.

The problem is as follows:

  1. I start debugging both targets
  2. I create a breakpoint for TargetB
  3. The j-link log for TargetB shows that the CPU is stopped, registers are read, the breakpoint is set, and the CPU continues execution. This is correct.
  4. The problem is that the j-link log for TargetA also shows that the CPU is briefly stopped, registers are read, and the CPU continues execution. This is incorrect. The TargetA j-link log should not see any activity when I add a TargetB breakpoint.

The problem is that TargetA's algorithms are VERY sensitive to timing jitter and these constant stop-read_register-go sequences are causing problem.

In answer to your additional questions:

  1. no they are running different applications
  2. no, files names are mutually exclusive since that would cause all kinds of problems.

philipag avatar Feb 07 '16 20:02 philipag

So all breakpoints work as expected.

good, things might have improved with Mars, but in previous versions even debugging two applications in sequence sometimes messed breakpoints.

The j-link log for TargetB shows that the CPU is stopped ... The TargetA j-link log should not see any activity when I add a TargetB breakpoint.

yes, from your report it looks like a reentrancy problem in the plug-in. time permitting, I'll take a look, but can't promise a fix soon.

until then, as a safer workaround, you can split your workspace in two, one for each project, and use two different Eclipses.

ilg-ul avatar Feb 07 '16 21:02 ilg-ul

OK I agree. When you do have a fix, feel free to contact me through this bug post and I can test it before release.

Thanks for the great plug-in! I am donating now :)

philipag avatar Feb 07 '16 21:02 philipag