Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Neon.2 does not start GDB 7.12 on macOS

> From: cdt-dev-bounces@xxxxxxxxxxx <cdt-dev-bounces@xxxxxxxxxxx> on behalf of Liviu Ionescu <ilg@xxxxxxxxxx>
> Sent: January 30, 2017 13:42
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Neon.2 does not start GDB 7.12 on macOS
>  
> > On 30 Jan 2017, at 16:37, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx> wrote:
> > 
> > This is the other known bug of CDT 9.2 related to GDB 7.12.
> >    Bug 509812 - Unable to interrupt arm remote target with Neon and GDB 7.12
> >    (http://eclip.se/509812)
> > Note that this affects all 'GDB Hardware debugging' launches, as well as all launches
> > on Windows and Mac.
> aha, it seems to be the same problem I faced.
> > having been found, I don't mind doing a special 9.2.1 release very soon and a 9.2.2 for March.
> > Let me know if that would be useful (so I don't spend time for nothing).
> if you have a nightly build for CDT that includes this fix, I can test it before you taking the time to make the release.

Can you try the build at:
https://ci.eclipse.org/cdt/job/cdt-9.2/35/artifact/releng/org.eclipse.cdt.repo/target/org.eclipse.cdt.repo.zip


I believe it has all the fixes you need.


> > The problems actually originate in CDT's use of GDB 7.12's new awesome full console support.
> it might be awesome for most of the users, but for the average GNU ARM Eclipse user, the GDB console is 
> pretty ignored/useless, and the previous version of the console was more then enough.

I think, once the console works nicely, you will not regret having it.
That being said, we did make it easy for extenders to automatically disable the full console, but programatically
only.  I'll have a look at your plugins to see if I can suggest something.

> as such, without offending anyone, could you consider adding a Preferences option to enable/disable the new debug console?

I would prefer to avoid a preference.  I don't feel a user would ever want to turn off the new console.  Again, assuming it
works well, there really would be no reason to want to use the basic console, it is really a very bad user experience.

> another annoying behaviour of the new console is that clicking on the GDB process does not set the focus to the 
> new console, as it does when clicking all other processes.

When you select the GDB process, the Debugger Console view will not be brought to the top, but that view
will show the full console that corresponds to that GDB.  Bringing the view to the top was too intrusive.
However, what people do is move that view to a different place in the perspective so that I can stay
visible when the standard console view is visible.  The nice think about that is that you can use
the GDB console while looking at the output of the program you are debugging.

> > The actual root cause of the problem is CDT's lack of broad testing.
> > We need more attention for Windows and for Mac, and for Hardware debugging.
> > These three areas are not covered by the core CDT Debug committers and 
> > are the three areas that experienced serious bugs in the 9.2 release.
> as I said, if there are nightly builds, I can install them on a test Eclipse from time to time. 
> if not, I might consider a configuration that uses the live git, but it is more tedious, and I cannot 
> dedicate full time to these tests.

We have nightly builds for every upcoming release as soon as we start coding on that branch.
If you update to these builds regularly for your work, you will notice quickly if something breaks.
For example, when working on CDT, we use the upcoming Eclipse platform (Oxygen in this case)
as soon as we can, to avoid late surprises.

> > P.S.  There is another bug reported from someone using the GNU ARM plugins
> > Bug 507429 - The problem with the launch SEGGER J-Link GDB Server
> > http://eclip.se/507429
> it looks like the initial bug report used the version that created the GDB server process with the GDB console attribute. it should be fixed now.

Great.  I saw you answer on the bug.  Once the person that opened the bug confirms this theory we'll close
it and I think we'll have addressed all urgent issues.

BR,
Marc


Back to the top