The fix for bug 327617 came after API freeze, so I
couldn't add the hook I needed to IMIBackend.
That interface has getMIInputStream() and
getMIOutputStream() but does not have getMIErrorStream()
The way I found to work around this limitation was to
get the gdbProcess from GDBBackend directly,
but that method is not part of an interface
either.
I assume that your version of IGDBBackend does not extend GDBBackend and that you are
getting
an NPE?
I think overriding startCommandProcessing() is your
best approach.
The other thing you could do is have your IGDBBackend
service extend GDBackend which is probably
more change than
overriding.
I suggest writing a bug to properly use IMIBackend for
this.
Thanks
Marc
I am migrating to CDT8. In DSF debug I have customized
IGDBBackend for specific implementations.
New in CDT8, the AbstractMIControl.startCommandProcessing()
method creates a stderr stream thread to fix bug 327617. However when creating
the error thread it uses the concrete GDBBackend class so that my customized
IGDBBackend class is not being used.
Is there a reason why this method uses the concrete class
not the interface? Is there a way I can work around this without overriding
this method with my customized control?
Thanks, Andy
|