Community
Participate
Working Groups
Build Identifier: M20120208-0800 Currently, GDB errors are only discovered by the user in GDB Traces. It would improve usability if errors and warnings from GDB traces filtered up to the user without having to switch to the GDB Traces console. This would require a new class to handle the errors and display the windows. I'm working on making it extendable, so much of the handling can be done at a higher level. The main problem that I've run into is getting some errors to display every time, but have others not display repeatedly (i.e, Could not read memory). Reproducible: Always
You may be interested in using the new GdbStatusHandler that Mikhail recently added.
I've pushed patch set 1 for gerrit review: https://git.eclipse.org/r/#/c/6498/
I've revised the patch set to move things around. I wanted the error handler to be at the dsf.gdb layer instead of the UI layer, so it can be notified of errors by AbstractMIControl. Because it will need to push errors up to the UI layer, I've added a small listener implementation into the StatusHandler. I think this is a much better way to handle the procedure.
When starting a new process in multi-process mode, GDB can reject the request for different reasons. Currently the only way for the user to understand why a process was not started is to look at the gdb traces. This is not obvious and can be very confusing. For example when trying to start a 64bit binary when the session is 32bit: -file-exec-and-symbols --thread-group i2 factorial.64 &"warning: Selected architecture i386:x86-64 is not compatible with reported target architecture i386\n" ^error,msg="Architecture of file not recognized."
