Monday, November 05, 2012

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.

2 comments:

Anonymous said...

Hi ray!
Well I am a beginning Assembly Language learner. I am taking a Assembly language class this fall and I was excited to learn until I started four days ago. My professor gave us instructions to learn Assembly language before classes start and he point us towards your book. So I buy the book and I start reading it on my iPad. I download Nasm because my professor stated that we will be using this compiler. My very first obstacle was your first example. I could not compile it so off to search for information. After compiling it I tried to link it and what did I behold a wall of errors. I could not figure out why. After more searching I found out that I had to put -f macho. I did not read the date that the information was posted so I compiled yet again and got more errors. After more searching I found out I had to use macho64. Also I could not use 1 as the exit syscall number. It took me about two hours to find the answer that instead of using 1 I had to use 0x200001; still don't know why. Boy Assembly Language is tiring. After compiling again I linked it using ld. Yay!! finally no errors. I run the executable and it works. My next problem hit in Chapter three and I still cannot resolve. It compiles and links fine but I get segmentation fault: 11. I decide to skip and hopefully learn what many of these terms in the program mean. Now Chapter 5, well lets say I had to do more searching in order to get this one to work. The first example was simple but I tried to use dgb to debug but for some odd reason I cannot use list to see which line of code are going to be executed. But the whole point of the exercise was to see how the constants were being moved to registers. After that, the second example has me cold on my tracks. I copied the example as you have it. I try to compile it and its telling me that "Mach-O 64-bit format does not support 32-bit absolute addresses
" At this point I'm am just tired of searching for solution.
It seems that learning Assembly Language on a mac is absolutely impossible. With very limited information on Assembly Language for mac os x and just error after error I am just not liking Assembly Language. Now I'm thinking about giving up learning on my mac and learn using a Virtualbox with Ubuntu and that is a pity because I love using my mac os. I wish your book for Mac was available. I just have to keep on trucking. Hope your having a ball with your retirement.

-- Tired student

Unknown said...

I'm sorry that you have run into this pile of problems. You are reading a book designed for Linux, while your operating system is OS X. You have shown a lot of talent and determination in discovering solutions. I have been working on OS X with plans to publish an updated book covering Linux along with OS X, but the book is not yet ready.

I do have some help for you. If you go to qtebe.sf.net you will find ebe, my newer IDE designed for Assembly. It will work well under OS X. There are a few issues with OS X which might bite you. First labels are prefixed with underscore. ebe will handle prefixing underscore for main, printf, ..., but not all. If you need a label repaired I have a macro named cname which will do this.

There is 1 more difference. OS X uses rip-relative addressing which affects things only a little. You can't mov an address into a register; instead you must use lea. Also you can't use a label as part of a memory address along with an offset or index. Instead the best plan is to use lea and then reference the data.

If you want to continue with OS X, I suggest emailing me and I can provide some help including the source code used for the examples in the book all working with ebe under OS X. This might get you over the hump with little difficulty. I can also assist with getting ebe installed under OS X. There is an OS X installer, but it hasn't been used much. The better plan is to clone the source using git and build the program on your computer.

Once again, I congratulate you on your persistence. I suspect that simply getting the example code might get you over the hump.

If you are already into git, you can clone using

git clone git://git.code.sf.net/p/qtebe/code ebe

After that you would do

./qrc
qmake
make

Good luck!