I have a custom CLI debugger for which I'm interested in a GUI. The debugger exposes an API with simple functions such as GetMemory(), SetMemory(), GetRegister(), Run(), Stop(), Address2Line() etc. through a TCP socket using a very simple protocol.
I'm looking for the easiest, fastest way of connecting it to a GUI. It seems there are many very good graphical debuggers, so after some research I think these are my best options:
Write a GDB translator - that will act as a gdbserver on one hand, translating all requests for the debugger, and also translate all events from the debugger to gdb compatible events. Then I can use any of the many gdb front-ends.
Write a Visual Studio Debug Engine
Write a plug-in for Eclipse (or some other open IDE)
Write a fresh GUI myself
So which will take the least effort / time ? Is there another way? Is there maybe a graphical debugger where I can easily define custom functions for debugging?
I would write an adapter so you can interact with something standard like GDB or Eclipse. Writing custom GUI code would be a waste of effort
Related
I am developing a cross platform application (OS X, Linux, Windows) in C++11 that should provide a custom debug shell as an external application.
This debug shell is used to invoke methods that are exposed by the public interface of the application. Mainly it should allow to perform the same operations that are available from the app GUI.
Debug shell and application will run on the same machine (remote access would be a plus, so it is not necessary).
I was wondering which approach I could use to assure portability (different OS), performance and code reuse (I would like to share the same model for GUI and debug shell).
My first idea was to use gRPC and Google Protocol Buffer to access to the application interface from both GUI and debug shell, but I am afraid that such solution would add performance and design overhead.
Do you have any design and technical suggestion about?
gRPC should be fine for this use.
On Mac and Linux you could make use of unix domain sockets to do this.
Since you want to be portable to Windows too, you'd be better off binding to localhost, as is done in the helloworld examples in the github repository: https://github.com/grpc/grpc/tree/master/examples/cpp/helloworld.
gRPC uses very little CPU while nothing is happening, and the serialization and network overhead in making a request will be well within interactive usage latencies (expect 100's of microseconds at worst).
I'm trying to find a good GUI library I could use to create a program on the computer that connects to a microcontroller by USB. I've never done any GUI work before but I have done a lot of webpage design/tools. We are going to program the microcontroller with C but I don't think the GUI will need to be C. It needs to work on Windows, so probably compile on Windows too. I've also never done any USB transmission but I'm hoping to take it one step at a time.
Right now I'm looking at using GTK but it needs a bunch of other things to download with it. I'm also going to look at QT and someone else suggested making a Windows Forms Application. There's a lot of options out there so I'm having trouble figuring it out.
As for my requirement, it just needs to be a very simple GUI that has a few control buttons, a display area (info from microcontroller), a notification area (basically error messages go here), and maybe a graph. I've included a prototype GUI help give you an idea of what I'm doing.
Edit: It needs to run and compile on Windows. We don't really have a budget for it, free open source is preferred. I don't need something elaborate and fancy, I just want to get it done as fast as possible.
We are using a TTL-232R cable, UART interface. I know nothing about USB transmission, school has crushed me.
From what you've specified, I would set base-camp up at Java.
Java in Eclipse to write the code.
Java Swing libraries (helped by the WindowBuilder plugin for Eclipse) to "draw" the GUI. It is very easy to create "Windowsy" GUIs using these.
JFreeGraph libaries to allow you to create graphs very easily, again from within Eclipse.
RXTX library for "virtual COM port" serial communication within Java (it doesn't sound like you're using proper USB, but just RS232 with a USB adapter).
Your created GUI would run on any machine with Java installed, which is not a big ask for the end user. You can even create a Windows executable/installer from the resulting Java files if you wanted it to be a (apparently) native Windows application.
And - bonus - all the tools mentioned are free as a bird.
It will kind of depend on what kind of compiler, IDE, etc you will settle on. If you are going to windows cold, and
money is an issue, then open source is always a good thing to look at. I have enjoyed using eclipse and Code::Blocks IDEs. For C/C++, I use minGW. In terms of GUI plug-ins, HERE are some conversation with GUI recommendations specifically for use with Code::Blocks.
If money is not an issue, I have use National Instruments LabWindows/CVI full dev kit forever. It is one of the easiest ANSI C compilers/IDE I have ever used. It is only ANSI C, but has extensions to make using instrumentation easy. I have written a little USB stuff (not much), sockets, instrumentation, and many GUI apps.
Please comment what tools you currently prefer, I may have other suggestions.
Lazarus CodeTyphon has cross platform native compiler with GUI working on every supported platform. It supports 8 OS-CPU host layers (Win32, Win64, Linux32, Linux64, FreeBSD32, FreeBSD64, Solaris32 and Solaris64), and 25+ OS-CPU target layers. It also incorporates many graphical widgets and SCADA like behaviour with PascalSCADA and other components. There are wrappers for LibUSB.
I would use Microsoft Visual Studio to develop the GUI. They offer a free version called Express. I would use the C# language but MSVS supports other languages as well so just choose whichever you're most comfortable with. The best thing about MSVS is that there are millions of developers out there, which means that you will be able to search for and find lots of examples for how to use an RS-232 COM port or USB interface. I'm guessing that you'll be able to find GUI objects for graphing and other objects as well. (The basic stuff like buttons and edit boxes is all built into MSVS.)
BTW, you need to sort out whether you're using an RS-232 COM port or a USB interface. They're both serial interfaces but they're not the same thing. Either could work.
How are operating systems typically debugged? They cannot be stepped through with a debugger like simple console programs, and the build times are too large to repeatedly make small changes and recompile the whole thing.
They aren't debugged as a multi-gigabyte programs! :)
If you mean the individual user-mode components, they can mainly be debugged just like normal programs and libraries (because they are normal programs/libraries!).
For kernel-mode components, though, each OS has its own mechanism; here is some information regarding the way that we do kernel debugging in Windows. It can be done using the help of another machine connected to the machine you're debugging, via a serial port or something. I'm not familiar with the process itself, but that's the gist of how they work. (You need to set some boot loader options so that the system is ready for the debugger to be connected as early as possible.)
It depends on which part of the operating system you're talking about. When I worked at MSFT, I worked on the IE team. We debugged IE and the shell (Windows Explorer) in Visual Studio and stepped through them line by line all day long. Though, sometimes, it's easier to debug using a command line tool such as NTSD.
If, however, you want to debug anything in Kernel land such as the OS kernel or device drivers, which I suspect is really what you're asking, then you must use the Kernel debugger. For Windows that is a command line tool called kd, and generally you run the debugger on one machine and remotely debug the target.
There are a whole set of techniques throughout history from flashing lights on the console, to the use of hardware devices like an ICE, to more modern techniques utilizing fairly standard debuggers. One technique that is more common among OS developers then application developers is the analysis of a core dump. Look at something like mdb on solaris for ideas about how Solaris kernel developers do some of their debugging. Also tracing technologies are used. Anywhere from fairly straightforward logging packages to more modern techniques like dtrace.
Also note that the techniques used depend on the layer of software. Initial boot tends to be a fairly hard place to get your fingers into. But after that the environment of modern operation systems looks more and more like the application setting you are use to. In the end, it is all code :)
I am talking about a small game engine using C# for game programming.
So, I have a C++ app embedding mono runtime (I call it 'launcher'). And I have an assembly written in C# which is my game engine class library. The launcher launches the assembly as it is suggested in Embedding Mono.
And now the interesting part!
The launcher implements in C++ miscelaneous functions which are exposed to the mono runtime as internal methods of my game engine classes. That is why my game engine assembly is nothing without the launcher which implements a huge part of the engine in C++.
The question: How am I supposed to debug my C# assembly? And what is more important, how am I supposed to debug a Game which I am going to write in C# ???
As you understand I cannot debug the assembly using MonoDevelop Debugger because it won't receive internal C++ implementations of some of its methods.
What I need is to run the Launcher. The launcher then will launch C# assembly using embedded mono runtime. And then I need something to connect to the launched assembly to allow its debugging.
Or any other way. Thank you!
I recommend using the Mono Soft Debugger. It's been included in the Mono runtime since Mono 2.6, and is more reliable than the old hard debugger, and also much more portable.
The Mono soft debugger can be started by passing options using the --debugger-agent commandline argument to the Mono runtime. This can be done from an embedding host by constructing a fake set of commandline arguments and passing it to mono_jit_parse_options. For example, the Moonlight browser plugin uses the debugger agent values from MOON_SOFT_DEBUG environment variable if it is set.
Typically debugger options are something like
--debugger-agent="transport=dt_socket,address=$ADDRESS:$PORT"
which will cause the app to try to connect to debugger listening on the given address, and pause until it establishes a connection. Note that the connection is established over TCP/IP, which means remote debugging is very easy to set up, and even on the local machine you would use localhost. Additional options are documented on Mono's man page.
The other piece you need is the debugger GUI/controller, to listen for the connection from your app, and handle stepping/visualizing, etc. I would suggest using MonoDevelop. There's a library for the debugger wire protocol called Mono.Debugger.Soft.dll, but it's fairly low-level, and although Mono Tools for Visual Studio supports connecting to the soft debugger, it's not yet extensible in a way that would allow debugging Mono embedding hosts.
Using MonoDevelop to accept debugger connections from embedding hosts currently requires creating an addin, but this is fairly straightforward. Take a look at the Moonlight debugger addin for an example. For simple use cases I would suggest that you don't define a whole new project type but just create a debug handler that handles existing DotNetExecutionCommand projects, so you can run->run with...->your custom debugger.
The monodevelop-list mailing list is a good resource if you have more questions.
Make use of network debugging.
You could use the Soft Debugger to debug the Mono parts, and then use remote debugging for the C++ parts.
Can anyone tell me about using (Steel Bank) Common Lisp for writing GUIs via system calls? I know there are some libraries out there but this is a language learning exercise, so I want to do it myself.
I'm developing on Kubuntu 8.10 and SBCL 1.0.18.
Thanks.
You can take a closer look at the sb-posix-package. But as the page sais "The functionality contained in the package SB-UNIX is for SBCL internal use only; its contents are likely to change from version to version."
Another Possibility - the one I would choose - is to include the C-syscall(2)-Instruction via CFFI, and then perform it.
To create a windowed GUI, you must use X11, at least to give you a Window to paint on. Therefore, you must know the X11-Specifications to create a window, and implement the Syscalls for accessing Unix Domain Sockets, or initiating shm-devices etc.
If you just want graphics on a console, you could think of using the framebuffer-device /dev/fb*. You need ioctl(2)'s and the syscalls for read(2)ing and write(2)ing to use it, but still, I think this would be a lot easier than using X11 for this (even though still a lot of work). Maybe you shoudld look at the sourcecode for libFB or something similar to see how to initialize it, etc.
Is this really what you want to do? This is a lot of work, you will learn a lot, but more about the linux system infrastructure, rather than about SBCL, I think. If you want to use Syscalls under SBCL, maybe its better to try to open TCP-Sockets only with Linux-Syscalls - alone this can take hours of frustration.
By writing GUI via system calls you mean not using any GUI toolkit such as Gtk+ or Qt? In such case, you should talk directly to the X-server via socket and implement all the X11 protocol (or use CLX) and GUI on top of it. But that is not an easisest task, because X11 is complex.
In case you decide to dig into X11, there are some links for specifications: http://www.xfree86.org/current/specindex.html
http://www.freedesktop.org/wiki/Specifications?action=show&redirect=Standards