A simple solution to unbuffering for a debugger

A problem which I have run into recently is the fact that pipes in Windows are not recognized as interactive and thus the C standard library routines does full buffering.  I am using two pipes to implement the stdin, stdout and stderr for C/C++ programs being debugged.  My luck was great with Linux and OSX - not so good with Windows.  On Windows I had to do fflush(stdout) to see the test printed by printf.  (and also cout using \n rather than endl)  The problem exists in the library code which inspects the attached file descriptors (or handles) and decides that this is a batch type operation and buffering perhaps 4096 bytes is perfect.

The solution I came up with is to mix C and C++.  It works just fine with gcc compiling a C program and g++ compiling a C class file and finally linking the 2 object files with g++.  The trick is to take advantage of the fact that C++ constructors for static objects are called before main is called.  Fortunately they are called after the library has prepared all the I/O routines for normal use.

Here is my C++ code:


#include <cstdio>

class __UnBuffer
{
public:
    __UnBuffer();
    int x;
};

__UnBuffer::__UnBuffer()
{
    printf("Here we go\n");
    setbuf(stdout,NULL);
}

__UnBuffer _unBuffer;

The constructor is called for the one __UnBuffer object which sets the buffering to unbuffered for stdout and also prints a message.  This message was printed first in  my test and the data made it through the pipe immediately.  Surprisingly I got some 1 byte messages which I will have to accommodate in the Qt ebe, but at least I have a simple solution which works well.

I ran into other folks who were writing GUI debuggers and they seemed to have difficulties.  I am not sure how they coped, but I didn't read a solution from any of those people.  Hopefully they will run into my solution and get past this stupid issue.

Ebe with toolbars

To make ebe more colorful I have added 3 toolbars.  After adding them I think they may actually be useful, though I was only trying to make it look better.

New and improved ebe

Recently I decided to bite the bullet and rewrite the ebe integrated development environment using Qt.  I was getting quite tired of coping with the large number of windows used in the original ebe.  I also needed to update ebe so that class and structs could be properly displayed while debugging.  It was a fairly interesting adventure.

You can see how it looks using Qt.  The various windows are now implemented using a main widget for the editing and a collection of dock widgets.  The dock widgets can be moved around and resized.  They can even be moved out of the main window if desired.  Perhaps more useful is the ability to drop dock widgets on top of each other forming a collection of tabs.  In the image above the terminal, project and back trace dock widgets are stacked making it simple to select one of the 3 to display.

The data window is now a dock widget containing a "tree" widget which has little "arrows" to the left of items which can be expanded.  You can expand class objects and arrays to drill down into the data of a program.  The tree widget turned out to be exactly what was needed to display the data.  This simplified the effort involved in revising the data display.

The terminal was previously an xterm window under Linux and a cmd.exe window under Windows.  These separate windows complicated the management of fonts.  Now you can increase or decrease the fonts in all the widgets using Control+ or Control-.

Qt had some extra capabilities which I had not expected.  There is a QCompleter class designed to aid in implementing word completion for a variety of widgets.  I used this to make editing easier.  There is a QSyntaxHighlighter class designed for implementing syntax.  I also used Qt's QTabWidget to manage editing a collection of files as tabs in the source frame.  It allows you to open all the files in a project when you start ebe.

Overall I found it easier to implement this version of ebe compared to the previous version based on Python.  It requires more effort to get started coding with Qt, but the rather large class collection ends up saving time.  It was also nice for me to use C++ which I have more experience with.

I think the program would look better with a collection of toolbars with colorful icons.  I can't think of appropriate icons for use in debugging, but I will probably add a toolbar of file/edit operations so it doesn't look so boring.

OS X xmm/ymm registers in gdb

I made it to the floating point math chapter in my book and discovered that ebe was showing 0's for the xmm registers and wouldn't display the ymm registers.  I checked and a program which loaded 3.25 into xmm0 ended up with xmm0.v4_float = {0.0, 0.0, 0.0, 3.25} while the same program under Linux shows it as {3.25, 0.0, 0.0, 0.0}.  I don't think the CPU has an option for reversing the order of the floating point values in the xmm registers.

I checked the version for gdb and found that I was using 6.3 under OS X and 7.5 under Linux, so I checked MacPorts and 7.5 is available, so I installed it.  Then the fun began.  It must be codesigned which requires greating a code signed certificate.  I have done that and signed it still fails to run with this message when I try the run command on a program:


Unable to find Mach task port for process-id 58919: (os/kern) failure (0x5).
 (please check gdb is codesigned - see taskgated(8))

The more I poke at OS X the less I like it.  Installing gdb is trivial under Linux.  Is there some extra permission involved with Linux?  I doubt it, but at least it just works.

Just for grins I did "sudo gdb fpadd" and it now lets the program run, though I get a slew of BFD unknown load command errors.

I will return to this later when I know more.

Well, 1 day later and no closer to understanding this nonsense.  I have managed to run gdb 7.5 which solves the problem with the xmm register values being reversed.  I still have problems running gdb as seyfarth instead of root.  I tried installing a newer version of gcc which does not help.  For my test code I am linking with gcc so it seems possible that some linker options might result in an exe file which gdb recognizes as having a need for avx support.

I suppose I will get this solved, but will I end up with a clearly defined way for people to configure their own Macs to support floating point properly with ebe?  I think I will refrain from entering a complete discussion in the book and refer to a web site so that I can adjust the description as I learn more.

After a couple more days of poking around I have reached a decision.  I have implemented a xmm:reverse ini parameter which will allow someone who is using a "defective" gdb to see the xmm registers properly.  I expect that in a few months OS X will have an easily installable gdb with proper xmm/ymm register support.  I will point out that there is a problem with some versions of gdb in the book and suggest where to look on my web site for further information.

I did find a workable solution using the lldb debugger which comes with xcode.  This would make ebe unnecessarily complex for a few months.  There would be enough changes to make it likely that there would be additional bugs.  I decided to exercise a little patience.  No matter which choice I made I would have to document it in the book.  Using the gdb which came with xcode makes it less trouble to use at the cost of setting a value in .ebe.ini.

OS X Stupidity

Why did Apple choose to make X Windows an afterthought?  They caused some grief with was not necessary.

UNIX systems have had a network based windowing system for about 30 years.  This is extremely handy.  For my needs this allows me to use ssh to connect to a Linux computer and run ebe over the network.

But this doesn't work if I use ssh to connect to my Mac.  My ebe script succeeds in running xterm which is an X application, but the python tkinter windows never show up, because they are using the stupid OS X Windows (not X Windows).

Today I tried to find a good tool for doing screen captures for my book.  The ImageMagick import tool works wonderfully well under Linux and it compiles under OS X, but it won't capture the stupid OS X Windows.  I can capture xclock and the xterm window of ebe, but the main parts of ebe are off-limits.

I tried the xcreencapture program and it works fairly well, but it includes the title bar in the image.  I don't want the title bar.  Furthermore it has color which is not acceptable in a black and white book.

So I ask again:  Why did Apple choose to make X Windows an afterthought?  Is this designed to prevent users from being able to run apps on a Mac remotely?  I suppose in order to sell MS Office on the Mac they had to guarantee that no one could run Office remotely.  That might hurt sales.

Hey, Apple, there are other ways to force people to pay up for MS licenses.  X Windows was a good idea 30 years ago and it is still a good idea today.

It looks like I may have to use a GUI tool to trim images.  Perhaps I can use one of the ImageMagick tools to delete the titlebars.

Another problem which did not have to exist.  Apple could have made this all so easy.  I am sure it would have been easier for Apple to use X Windows than to invent their own substandard system.