EBlink Live variables with other IDE

[dliebler]

Hi,
I think live variables are one of the biggest advantages of EBlink, and it works great with EmBitz.
But i am trying to integrate it into my workflow, and got really stuck using live variables without EmBitz.
Is there any information on how to use live variables with eblink?

I guess a real documentation on this does not exist, but i think even only looking at the parts of the
sourcecode where embitz does the live variables configuration and polling would help me greatly.

Thanks in advance!

[embitz]

What are you trying to achieve?

Live variables in Embitz are possible because the whole chain EBlink - GDB - EmBitz is optimized for this. I have modified GDB and wrote EBlink because of live variables and wrote  the Embitz debugger plugin to make full use of live variables. I introduced debugger plugin plugins like OSview and a upcoming debugger plugin HeapView with realtime heap visualisation about allocation and fragmentation.

If you want to use EBlink standalone in your test workflow then it is only possible on address level. But you could write an ELF parser to get address location from the debug info.

[dliebler]

Oh, I didn't notice you also modified the GDB client. I thought you used it like that: EBlink-standard GNU GDB client-EmBitz.

I am trying to integrate it into my debug workflow. In the final form, I want to have live updates for a few variables/watches while debugging with my chain with EBlink-standard GDB-Debugger.
So my thought was if I use EBlink as the GDB Server, I could use your optimizations to also access the live variables. From the readme.md on Github, it seemed to me as if EBlink would not be only exclusive for EmBitz. Its great that EmBitz is getting all these fancy features. But I don't really need them without an os running on the target and have a few other reasons to go with another IDE for this project.

But as far as I understand, I think your last idea would be a solution. Having working live watches on address level would be the first stage. If this would work, I am confident I can develop my own solution to solve the variable to address resolution in the debugger.

Do you think it is possible to give me a bit of advice on getting the first stage running? I dont want to cause a lot of work for you describing it for me.
I am unsure how you achieved the live variables? Are you working in asynchronous gdb mode, do you set up a second connection to gdb to run monitor commands while the program is running or how do you read memory while running?

[embitz]

Yes, GDB is used in asynchronous mode, with some additional features added to GDB and EBlink. Many MI commands have also been modified with more or improved options, so that the IDE does not have to use more queries than necessary to collect all information.

But I still don't understand what you want to achieve. Would you like to have a third application that shows variables while you debug in EmBitz?

[dliebler]

Maybe I have to go deeper into my usecase.
I use another IDE for developing due to better integration with other tools.
Currently, I have to switch IDEs back and forth between developing and Embitz for debugging.
Now, from my view it should be doable to integrate the live watches as a pane in the UI in my developing IDE.
That would improve my workflow, because I wouldn't have to swap IDEs all the time.
I know that since you are developing both embitz and eblink, you might not be particularly happy to help me use another IDE, but I thought asking couldn't hurt.

Integrating it into the UI shouldn't be that hard, but I would still need the information on the contents of the live variables. So I thought that if I use eblink similarly to how embitz does, I should be able to query that data. But I don't know where to find information on how embitz does this.

[embitz]

I don't mind how you want to use Embitz. It's up to you.

But I can not help you with this because I don't know how the other ide is working. Live variables in Embitz is a tight integration of 3 tools working closely together.