Re: [cdt-dev] [DSF] why does AbstractMIControl.startCommandProcessing do

[Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>]

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

---

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Andy Jin
Sent: Wednesday, June 29, 2011 9:38 AM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] [DSF] why does AbstractMIControl.startCommandProcessing does use concrete GDBBackend class name?

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