[
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
|
> On 31 Jan 2017, at 18:42, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx> wrote:
>
>
> > # macOS 10.12.2, GDB 7.10 (since 7.12 crashes on macOS)
>
> Just to mark off issues, we agree that GDB 7.12 crashing on Mac is not related to CDT.
that's correct, GDB 7.12 crashes on macOS even when started by hand in a terminal.
> When you say 'old console' you mean the console shown in the Console view.
> While the 'new console' is the one shown in the Debugger Console.
right
> Your plugins only use the "basic" console.
yes. too old.
> BTW, the "full GDB console" is the real improvement that I called "awesome".
> It provides a complete command-line experience to the user with: ...
yes, for those who use these features, I'm convinced the full console is awesome.
> > - terminate triggers a windows error dialog box ('arm-none-eabi-gdb.exe has stopped working')
>
> This is new. Can you open a bug if you feel it could be CDT related.
in this case probably it would be useful to test again with GDB Hardware Debug.
> > - the new console title is not right, macro substitutions were not performed.
>
> This may be a modification in your plugin that does not work with the Debugger
> console view change. Should be easy to fix. I can have a quick look.
it might be a missing setting in my plug-in, that had a different default in the old implementation.
> > ... on macOS the console output was split between two tabs:
>
> That's an interesting detail for the bug to track the crashing GDB.
it is an interesting detail, but I don't think it has to do with the crashing GDB; as I mentioned, GDB crashes on macOS always, even when invoked from a terminal.
this detail is interesting because to me it suggests a bug in the way consoles are now routed to the new view.
to be sure we get things correctly, this happens when I **do not** set the attribute to the GDB process.
I'm not sure, but it looks like stdout is forwarded to one console, and stderr to the other. even if this is a marginal case, I expected all output to go to the same console. if it is a bug, it might affect output from other processes, we never know.
regards,
Liviu
