Community
Participate
Working Groups
Thanks to the solution to bug 321084, FinalLaunchSequence is easier to extend. GDBJtagDSFFinalLaunchSequence was a copy of FinalLaunchSequence which should now extend it instead, to get the benefits.
Created attachment 177856 [details] Fix This patch makes GDBJtagDSFFinalLaunchSequence extend FinalLaunchSequence. Since there is currently no API in ReflectionSequence to insert/remove steps into/from a base sequence, I used Elena's suggestion of bug 321084 comment #40, and used a List. I still find that the insert operation is brittle, since it bases itself on the name of an relatively arbitrary step of the base sequence, but I don't have a better suggestion. I can't commit this fix because I cannot test it. When Andy or Elena have a chance to test it, we can commit it. Until then, it can still be used as an example of how we can extend FLS.
I thought Mikhail and/or Volodya may be interested in this example of extending FinalLaunchSequence.
Created attachment 177860 [details] Better fix I made a mistake in the way I used list. This patch is better.
Created attachment 177971 [details] Yet another small improvement I was thinking of how to make the overriding of steps as solid as we can with the current API (or lack of), and I thought that using the same step name would be more robust.
Marc, your most recent version of the patch is dated 2010-09-01 so may need some further work for CDT head. I am happy to look at this and/or test your own changes. Are you aware of any reason why we should not use stepNewProcess() within the JTAG launcher?
(In reply to comment #5) > Marc, your most recent version of the patch is dated 2010-09-01 so may need > some further work for CDT head. I am happy to look at this and/or test your > own changes. I've been meaning to give you a patch to test but things keep getting in the way. If you want to give it a shot, please let me know. The tricky part is that we'll need multiple versions, called by the different GDBJTagControl*, while trying to use inheritance as much as possible. > Are you aware of any reason why we should not use stepNewProcess() within > the JTAG launcher? Not off the top of my head. I'd like us to re-use as much of the other code as possible.
I pushed a prototype of this to Gerrit: https://git.eclipse.org/r/10202 I believe we cannot run the "stepNewProcess" step, so I had to compensate. This change is not as valuable as I hoped, although it does allow to re-use code. This prototype is for GDB <= 7.1. It will need a small update for newer GDBs. John, if you have an GDB <= 7.1, can you try this out to make sure the behavior is correct? I only coded things based on comparing it to the old code, I'm not even sure what the behavior really should be, so I'm counting on your for that.
I've updated the patch to support newer GDBs and pushed it to gerrit. I believe this should fix Bug 396764 as well. But that should not be the main concern; the main concern now is to see if this new JTAG launch sequence does what it should. John, please let me know how things go.
Marc, thank you for the patch. I will evaluate with GDB 6.8.50 and 7.0. What is missing for GDB > 7.1 single process?
(In reply to comment #9) > Marc, thank you for the patch. I will evaluate with GDB 6.8.50 and 7.0. > > What is missing for GDB > 7.1 single process? Path 2 on gerrit should now address those versions. I haven't worked out the API-compatibility problem yet, but I wanted to see if this even worked as expected before spending more time.
Marc, patch set 2 on Gerrit appears to be functional in the case of a single threaded application for GDB (arm-eabi-gdb) 6.8.50.20080706, 7.0 and 7.3.1. I am still observing bug 394183 if I set a temporary breakpoint via the launch settings (frequently observed with GDB 6.8.50.20080706). Thread filtering is working for GDB 6.8.50.20080706 and GDB 7.3.1. It was previously broken for GDB 7.3.1 (bug 396764). With GDB 7.0, the thread filter dialog shows breakpoints on all threads disabled initially. Attempts to enable/disable breakpoints on individual threads are persisted at the UI level but otherwise ignored (there are no resulting GDB commands). This is a regression in behaviour. Bug 396764 was not previously observed with GDB 7.0. Please let me know if there are further details that would help.
Thanks John! So the launch is behaving as you would expect? Breakpoints are being set and connections are being made as expected? Great. I'll look into your findings
How can I try the thread filtering? Since I don't have a JTag device, I just use the launch directly, but nothing actually starts execution of the process. How does execution start on when using JTag?
(In reply to comment #13) > How can I try the thread filtering? Since I don't have a JTag device, I > just use the launch directly, but nothing actually starts execution of the > process. How does execution start on when using JTag? In the general case, there is code already running on the board. The launch settings typically dictate that the JTAG probe should halt the processor and so CDT shows that the target is suspended at the end of the launch sequence. All threads of execution are suspended and resumed together since the JTAG probe is simply halting and resuming the processor. It is also possible to connect to a GDB server rather than a JTAG probe using the JTAG launcher if that helps.
(In reply to comment #14) > It is also possible to connect to a GDB server rather than a JTAG probe > using the JTAG launcher if that helps. Ok, I'm able to use the launch by telling it to load symbols and to connect to a gdbserver running a multi-threaded programs. I pushed an updated version to gerrit (patch set 3) that I believe is final (and does not break the API). (In reply to comment #11) > I am still observing bug 394183 if I set a temporary breakpoint via the > launch settings (frequently observed with GDB 6.8.50.20080706). That has been fixed separately in bug 394183. > With GDB 7.0, the thread filter dialog shows breakpoints on all threads > disabled initially. Attempts to enable/disable breakpoints on individual > threads are persisted at the UI level but otherwise ignored (there are no > resulting GDB commands). This is a regression in behaviour. Bug 396764 was > not previously observed with GDB 7.0. I believe I've fixed this issue in this latest patch. This patch also fixes bug 396764 (which was the reason for this fix :)). John, if you can confirm that this patch works as expected, I can commit it.
Marc, I've been evaluating patch set 3. Thread filtering behaviour is now looking good for GDB versions 6.8.50.x, 7.0 and 7.3.1. We need a trivial GDBJtagControl_7_4 class (extending GDBControl_7_4 and referenced from GdbJtagDebugServicesFactory) for use with GDB 7.4 and above. This is critical for 7.5.x where "maintenance set python print-stack" will cause the launch sequence to fail. I can provide a patch on request, but it may be quicker for you to add this class yourself (copying from GDBJtagControl_7_2) than process a patch. With GDB 7.4.1 and 7.5.1, the thread filtering UI behaves correctly and appears to drive GDB correctly, but thread filtering behaviour while debugging seems erratic. > This patch also fixes bug 396764 (which was the reason for this fix :)). Yes, I believe the problem reported in 396764 is indeed fixed by this patch set. From my perspective, I think patch set 3 can be committed. I will continue to investigate erratic thread filtering observed with 7.4.1 and 7.5.1. If there is a real issue here, I will open a separate bug report. Many thanks for all your help with this.
(In reply to comment #16) > We need a trivial GDBJtagControl_7_4 class (extending GDBControl_7_4 and > referenced from GdbJtagDebugServicesFactory) for use with GDB 7.4 and above. Thanks John! That was a big oversight on my part. I have fixed it and tried a session with GDB 7.5 successfully. > > This patch also fixes bug 396764 (which was the reason for this fix :)). > > Yes, I believe the problem reported in 396764 is indeed fixed by this patch > set. Great, I'll also mark that one as fixed. > From my perspective, I think patch set 3 can be committed. I will continue > to investigate erratic thread filtering observed with 7.4.1 and 7.5.1. If > there is a real issue here, I will open a separate bug report. > > Many thanks for all your help with this. And thanks to you also, your help is essential for the launch type. I've pushed a new version to gerrit and committed to master.
