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.

Assembly Language: Linux vs OS X

I have had a Mac Mini computer for roughly a month and I have learned enough to do fairly well with 64 bit assembly language programming.  Both Linux and OS X use the System V AMD64 Application Binary Interface which makes 64 bit assembly programming very similar between the two systems.  By contrast Windows uses the Microsoft x64 ABI.  Despite using the same ABI there are a couple of differences which make it difficult to write portable assembly language programs for Linux and OS X.

Naming conventions

Brand New Mac Mini

I have had my second Mac Mini for about a week now with none of the problems from the lemon Mini which was a refurbished machine.  I have bought refurbished machines before which were quite useful.  I had expected that my need for a Mac would be for several months while I prepared a Mac version of my assembly book.  After that I could survive a failure.

In any case the new Mini is a keeper.  I replaced the RAM with 2 8 GB SODIMMs the day after it arrived.  It was pretty sluggish before with 4 GB, but runs pretty well with 16.

Package tracking system

There should be more accurate package tracking systems for sites like UPS, FedEx, etc.  Each package is already given an identifier.  When a package is added to a container, the container would have an ID which would be used to track the package.  When a package or container is placed in a truck then the truck's ID would be used to track the package or container.  Similarly packages could be associated with planes or ships.  At the vehicle level tracking could be done using a GPS system on the vehicle connected to the shipper's network.

With this system I could see that a package left Memphis 3 hours ago and was now passing through Yazoo City.  With the current system packages frequently retain the same status for a day or more.  I really doubt that many packages sit still for more than an hour or two here and there.

I wonder if someone already has a patent on this improved package tracking system?