Nat!'s Web Journal

How I bricked my iTunes Server

Sun, 21 Feb 2010 23:19:36 +0100

for a while...

As soon as it was available in Germany I bought a Sheeva Plug Computer (ca. EUR 100) and a 1 TB Imation external USB disk (ca. EUR 100). My plan was to use this a fileserver, mainly as a DAAP iTunes Music server.

The Imation disk is great. It's covered with an absorber material, and I only hear it when I put my ear on it. It's also supposed to use very little energy.
The Sheeva Plug is not so great. The USB connections have too little friction, so it is extremely easy to lose the connection. I already had to format the USB disk twice, because it became unusable, when the USB cabled didn't connect properly any more... Also I think, it could be a little smaller. It's quite a beefy plug.

There are a lot of guides out there, that cover what to do with the Sheeva, once you get it. For a fileserver like mine, you only need three packages: avahi-daemon for Zeroconf, mt-daapd for Daap/iTunes and samba for filesharing. I also wanted netatalk for completeness sake.

I just want to write down a few notes, that I didn't see covered elsewhere on the web. There are a lot of good guides out there.

netatalk - gave me some weird address family errors, but when I turned off the ATALKD daemon and just use AFPD daemon (see /etc/defult/netatalk/. It worked OK. I don't really use AFP now, I use samba, it seems so much faster.
hostname - append a .local to the name you come up with. Zeroconf will then be able to properly resolve it.
fstab - try to replace as much as possible of the /var hierarchy with tmpfs mounts. You will lose persistent logs, but that should reduce writes to the flash memory of the plug.

As a final buff, I wanted to mount the root file system as read only. Truely an idiotic maneuvre in planning in execution, but here's what I did, no kidding...

Edited /etc/fstab to read rootfs / rootfs ro 00 instead of rootfs / rootfs rw 0 0, hoping that this would just work
Rebooted
Checked with mount that it worked, it didn't (rootfs on / type rootfs (rw))
Decided to revert /etc/fstab to avoid confusion later in life
Noticed about three times in a row that saving the changed file didn't work.
Examined fstab file permissions and my user id (root)
Failed to see any reason, why it shouldn't work.
Abandoned this problem and tried to figure out some other aesthetic problem in the boot process
Figured out that I needed strings for that
Tried apt-get install strings, knowing that it wouldn't work, which it didn't. Dimly rememberd something about "bin-utils"...
Gave up on this, but noticed a warning that apt-get gave about not being able to use a read-only /var/lib/dpkg/lock.
Figured, that probably /var/lib/dpkg was missing and needed creation
Noticed, that this wasn't the case.
Experienced a rare moment, that I wouldn't call lucid, but nevertheless had a somewhat dim-but-brighter-than-pitch-black quality. The root filesystem was indeed mounted read only, and mount had lied to me!
Moaned as I realized, that to install anything on the root file system I had to edit fstab and reboot. But everything on the root file system is read only now.
Dealt with the pain, by writing this blog entry
Rememberd the remount option mount -o remount,rw / ;)

A mysterious and largely unknown gcc builtin function

Tue, 12 Jan 2010 12:11:25 +0100

#include 

main()
{
   int  x;

   // \\\\\\\\\\\  ///////////// 
   // ||    POWERFUL MAGIC    ||
   // //////////   \\\\\\\\\\\\\
   x = __powerful_magic__( 1848);
   printf( "%d\n", x);

   return( 0);
}

deprecation, deprecation, deprecation - Part 2

Wed, 06 Jan 2010 18:39:51 +0100

So out of curiosity I figured I'd like to check the deprecation statistics.

Here's the unix command I used to get the statistics. I am collecting recursive all the header files inside an SDK directory, unique them by filename (which is a bug, but better than not doing it) and check for the AVAILABLE...BUT..DEPRECATED string. Then I massage the output a little, so I can easily put it in a table:

( for i in `find /Developer/SDKs/MacOSX10.4u.sdk/ -name "*.h" -print` ; do file=`basename $i`; echo "$file" "$i"; done | awk '{ files[ $1] = $2 } END { for ( x in files) print files[ x] }' | xargs egrep -H "AVAILABLE_MAC_OS_X_VERSION_10_._AND_LATER_BUT_DEPRECATED_IN_MAC_OS_X_VERSION_10_." ) | egrep -v "#define|#ifdef|#ifndef|\ \*\ .*AVA" | sed 's/.*$AVAILABLE_.*_10_.$.*/\1/' | sort | uniq -c | sed 's/AVAILABLE_MAC_OS_X_VERSION_10_$.*$_AND_LATER_BUT_DEPRECATED_IN_MAC_OS_X_VERSION_10_$.*$/\1 \2/'

which exposes that the JavaVM.framework is apparently broken in the 10.6 SDK, but who uses Java anyway ;)
egrep: /Developer/SDKs/MacOSX10.6.sdk//System/Library/Frameworks/JavaVM.framework/Versions/A/Headers/jvmdi.h: No such file or directory egrep: /Developer/SDKs/MacOSX10.6.sdk//System/Library/Frameworks/JavaVM.framework/Versions/A/Headers/jvmpi.h: No such file or directory

Anway here are the results:

How to read this chart. On the left side is the released version. The bars show the number of symbols deprecated of previous OS X versions. So for example the top entry 10.1, shows that it deprecates less than 10 function from 10.0. Then 10.3 deprecates a few symbols from 10.0 and 10.2 and so on. Further interpretation of the data is left to the reader.

What is kind of interesting is to compare the raw numbers for the various SDKs. I checked 10.4.u.sdk, 10.5.sdk and 10.6.sdk. The horizontal axis has the version that deprecates, the vertical axis has the version that suffers deprecation:

10.4u.sdk	10.1	10.2	10.3	10.4	10.5
10.0	2	5	31	1119	82
10.1		1	3	24
10.2				20
10.3				12
10.4
10.5

10.5.sdk	10.1	10.2	10.3	10.4	10.5
10.0	2	6	38	1107	682
10.1			1	37	37
10.2			9	22	19
10.3				14	32
10.4					7
10.5

10.6.sdk	10.1	10.2	10.3	10.4	10.5	10.6
10.0	2	5	37	1082	640	97
10.1			1	18	3	2
10.2			9	21	12	3
10.3				18	19	106
10.4					7	13
10.5						8

Some quick observations:

10.4u.sdk seems to be broken, as it has deprecations from 10.5 already
since deprecations seem to disappear over time, this could mean, that either symbols were really removed, or that some symbols were wrongly deprecated

The methodology used here isn't perfect, because I am not checking all headers. But I hate scrapping the whole entry ;)

deprecation, deprecation, deprecation - Part 1

Wed, 06 Jan 2010 18:11:47 +0100

The initial grievance for this posting is this warning:

foo.m:17: warning: 'NSLookupSymbolInImage' is deprecated 
(declared at /Developer/SDKs/MacOSX10.5.sdk/usr/include/mach-o/dyld.h:182)

When I look into the header I find this:

/*
 * The following dyld API's are deprecated as of Mac OS X 10.5.  They are either  
 * no longer necessary or are superceeded by dlopen and friends in .
 * dlopen/dlsym/dlclose have been available since Mac OS X 10.3 and work with 
 * dylibs and bundles.  
 *
 *    NSAddImage                           -> dlopen
 *    NSLookupSymbolInImage                -> dlsym
 *    NSCreateObjectFileImageFromFile      -> dlopen
 *    NSDestroyObjectFileImage             -> dlclose
 *    NSLinkModule                         -> not needed when dlopen used
 *    NSUnLinkModule                       -> not needed when dlclose used
 *    NSLookupSymbolInModule               -> dlsym
 *    _dyld_image_containing_address       -> dladdr
 *    NSLinkEditError                      -> dlerror
 *
 */

and

extern NSSymbol NSLookupSymbolInModule(NSModule module, const char* symbolName)
AVAILABLE_MAC_OS_X_VERSION_10_1_AND_LATER_BUT_DEPRECATED_IN_MAC_OS_X_VERSION_10_5;

So it appeared in 10.1 and it's plug gets pulled in 10.5. Short lived API, I would say.

What bothers me, that one of the ideas behind Foundation is, that it should isolate me from the OS layer and abstract to a common denominator, that remains stable. Yet here, the Foundation functions are deprecated and I am suposed to use dyld directly, although Foundation still could (and probably does) do the work using dyld.

I don't get this.

Nat! vs. evil code elves: Final fishings before christmas

Wed, 23 Dec 2009 00:41:10 +0100

Moving the framework to different start addresses:

Start Address	Result
0x34200000	no crash
0x00f50000	no crash
0x35210000	no crash
0x35200000	crash
0x75200000	no crash

So it it crashes with 0x35200000, well that I already did know.

Isolating the bug

I was able to isolate the bug eventually into a much much smaller project. Strangely enough, if I put the code into a .dylib then there is no problem, but if I use a .framework it crashes or fails. If I had tried a framework two days ago instead of a dylib, it would have saved me quite a bit of headache. Also I know now, that AppKit doesn't need to be present. A Foundation tool shows the same problem.

The same code does not crash on another computer.

Hilarious! After three days I know now much more about the bug, still, it seems to make no sense whatsoever. On a hunch I would say this has something to do with virtualization on the CPU in some way. It will be interesting to figure out, how to debug that.

As this is the last entry before christmas. Happy Christmas and New Years. More to come next year, if I don't die of old age in the mean time.

The plot thickens in the fight vs. the bug elves

Tue, 22 Dec 2009 21:46:58 +0100

The VPN is up again and I rearranged the code a little, and now I get a EXC_BAD_ACCESS in a completely different place:

0x35204e9f  <+0042>  mov    (%eax),%eax
0x35204ea1  <+0044>  mov    %eax,0x4(%esp)
0x35204ea5  <+0048>  mov    %edx,(%esp)
0x35204ea8  <+0051>  call   0x35236170 
0x35204ead  <+0056>  lea    0x2c2a1(%ebx),%eax
0x35204eb3  <+0062>  mov    (%eax),%eax
0x35204eb5  <+0064>  cmp    %eax,0x14(%ebp)

compared to the original troublesome code

0x35204ea6  <+0000>  push   %ebp
0x35204ea7  <+0001>  mov    %esp,%ebp
0x35204ea9  <+0003>  sub    $0x8,%esp
0x35204eac  <+0006>  mov    0x8(%ebp),%eax
0x35204eaf  <+0009>  mov    0x8(%eax),%eax
0x35204eb2  <+0012>  leave  
0x35204eb3  <+0013>  ret

Is it really a different place ? Actually in terms of adresses it's almost but not quite identical. Yes that still makes no sense whatsoever to me.

More fishing around

Dump of the shared library binary at the appropriate place. (I have put in four nops 0x90, so I can easily identify it. (It stlll EXC_BAD_ACCESS crashes with the four nops)

00004ea0: 0489 1424 e8c7 1203 0090 9090 908d 83a5  ...$............
00004eb0: c202 008b 0039 4514 7411 8d83 a1c2 0200  .....9E.t.......
00004ec0: 8b00 3945 140f 85ff 0000 0083 7d18 000f  ..9E........}...

It's interesting to note, that the offset into the linker file, is the same as the offset into a virtual memory page. And here's the same memory seen by gdb post EXC_BAD_ACCESS crash:

0x35204ea0: 0x8904 0x2414 0xc7e8 0x0312 0x9000 0x9090 0x8d90 0xa583
0x35204eb0: 0x02c2 0x8b00 0x3900 0x1445 0x1174 0x838d 0xc2a1 0x0002
0x35204ec0: 0x008b 0x4539 0x0f14 0xff85 0x0000 0x8300 0x187d 0x0f00

One dump was made by emacs and the other with gdb and the endianness is different, but the instructions are identical.

One more nop and the crash is gone

So this is currently the code that gives the EXC_BAD_ACCESS at 0x35204eb3

0x35204ea9  <+0056>  nop    
0x35204eaa  <+0057>  nop    
0x35204eab  <+0058>  nop    
0x35204eac  <+0059>  nop    
0x35204ead  <+0060>  lea    0x2c2a5(%ebx),%eax
0x35204eb3  <+0066>  mov    (%eax),%eax
0x35204eb5  <+0068>  cmp    %eax,0x14(%ebp)

but if I put another nop there the crash is gone. Unfortunately as you can see, there is also a subtle shift of the code involved, which is due to the linker, which is out of my control (see: previous entry).

0x35204ea5  <+0056>  nop    
0x35204ea6  <+0057>  nop    
0x35204ea7  <+0058>  nop    
0x35204ea8  <+0059>  nop    
0x35204ea9  <+0060>  nop    
0x35204eaa  <+0061>  lea    0x2c2a9(%ebx),%eax
0x35204eb0  <+0067>  mov    (%eax),%eax
0x35204eb2  <+0069>  cmp    %eax,0x14(%ebp)

The idiocy of too strong typing

Tue, 22 Dec 2009 18:15:19 +0100

While perusing the Xcode Users mailing list archives I found this beauty:

I'd like to write a quick function template to change a function pointer from type " return_type (*)(void) " to "return_type (*)(...)". I thought this would work:

template 
RetT (*convert_ptr(...)) ( RetT (*src)(void) ) { 
   typedef RetT (*rt)(...); 
  return reinterpret_cast(src); 
  //ERROR: "src" was not declared in this scope.
}

The whole code functionally is a big bag of nothing. It's all syntax. Spending time programming this stuff is about as worthwhile as reformatting TPS reports.

The C-solution is (or should be, if it hasn't been broken by some committee by now) convert_ptr = (void *) src , which means: I know what I am doing, don't bother me even with warnings, I have better things to do.

Some more fishing around the evil elves conspiracy

Sun, 20 Dec 2009 22:02:39 +0100

I wrote another shorter program, that just did the same piece of code at the same place. To write this was harder than expected (see this cry for help) for some more details or check out the gruesome project SimpleBestBugVerify.

In any case, as was sort of expected, the bug doesn't manifest itself there at all.

Unfortunately I can't reproduce the bug in the original code currently, because as fate has it, the certificate for the VPN that carries the database connection just expired and now it's christmas and the guy responsible for it (Hey Oli! ;)) might not be able to fix it so quickly.

It's like evil elves are conspiring against me, but I am used to that.

Fishing for clues for "my best bug ever"

Thu, 17 Dec 2009 21:51:44 +0100

(gdb) x/128x 0x30de800
0x30de800: 0x508152eb 0x50899500 0x50899b14 0x508152de
0x30de810: 0x50898e84 0x50899b14 0x508152d1 0x5089caa9
0x30de820: 0x508986b8 0x50815269 0x508983f2 0x508986b8
0x30de830: 0x5081520b 0x55105c35 0x50899b14 0x508151fe
0x30de840: 0x508a46aa 0x508986b8 0x5081510f 0x00095555
0x30de850: 0x00d0dff0 0x010011c0 0x00000009 0x00000000
0x30de860: 0x00000004 0x00020000 0xa0912ba4 0x00000000
0x30de870: 0x00000000 0x00000000 0x00000000 0x00000000
0x30de880: 0x00d0dff0 0x01001180 0x00000009 0x00000000
0x30de890: 0x00000004 0x00030000 0xa0912ba4 0x00000000
0x30de8a0: 0x00000000 0x00000000 0x00000000 0x00000000
0x30de8b0: 0x00d609f0 0x00000009 0x03078710 0x15627a70
0x30de8c0: 0x00000001 0x030dfc30 0x00000000 0x00000000
0x30de8d0: 0x04a24dc0 0x00000002 0x00000014 0x00000019
0x30de8e0: 0x030decf0 0x00000000 0x00000000 0x00000000
0x30de8f0: 0x04a24a20 0x00000000 0x00000000 0x03240960
0x30de900: 0x030dea70 0x00000000 0x00000000 0x00000000
0x30de910: 0x00000000 0x00000000 0x00000000 0x00000000
0x30de920: 0x00d0a590 0x01001384 0x00000083 0x00000083
0x30de930: 0x00000000 0x030de940 0x00000000 0x00000000
0x30de940: 0x454c4553 0x75205443 0x45422e30 0x5a54554e
0x30de950: 0x535f5245 0x4b454c45 0x4e4f4954 0x3075202c
0x30de960: 0x4d414e2e 0x75202c45 0x44492e30 0x53555a5f
0x30de970: 0x444e4154 0x3075202c 0x5f44492e 0x5453414d
0x30de980: 0x535f5245 0x4b454c45 0x4e4f4954 0x3075202c
0x30de990: 0x414c4b2e 0x2c455353 0x2e307520 0x5245554b
0x30de9a0: 0x2c4c455a 0x2e307520 0x4d4d554e 0x46205245
0x30de9b0: 0x204d4f52 0x5f544448 0x45424154 0x20454c4c
0x30de9c0: 0x00003075 0x00000000 0x00000000 0x00000000
0x30de9d0: 0x00d01af0 0x352f00d8 0x500afa60 0x00000000
0x30de9e0: 0x00000000 0x00000000 0x00000000 0x00000000
0x30de9f0: 0x35231f20 0x925c93a8 0x04a053c0 0x00d7dfa0

and

(gdb) set $eax = 0x30de9f4
(gdb) set $eip = 0x35204eaf
(gdb) stepi
(gdb) p/x $eax
$22 = 0x3075
(gdb) set $eax = 0x30de9ec
(gdb) set $eip = 0x35204eaf
(gdb) stepi
(gdb) p/x $eax
$23 = 0x45424154
(gdb)

hmm significant, I would say. It should be noted, that the address of the executable code and the memory address is somewhere in the middle of what I would expect a VM page to be, since these are supposed to be divisible by 4K as far as I know.

(gdb) x/64x 0x10000
0x10000: 0xffffff4c 0x8bb0148b 0xffff108d 0x18858bff
0x10010: 0xe8ffffff 0x00076f07 0x2785c646 0x01ffffff
0x10020: 0x858b0ceb 0xffffff10 0x0a74c085 0xb539f631
0x10030: 0xffffff50 0x858bc87f 0xffffff4c 0xe8240489
0x10040: 0x0011c3b6 0xff1c958b 0x9589ffff 0xffffff30
0x10050: 0xff2885c7 0x0000ffff 0x85c60000 0xffffff2f
0x10060: 0x1f8b8d00 0x890012c7 0xffff0c8d 0x7d838dff
0x10070: 0x8900120e 0xffff0885 0x83938dff 0x8900120e
0x10080: 0xffff0495 0x898b8dff 0x8900120e 0xffff008d
0x10090: 0x60858dff 0x89ffffff 0xfffefc85 0x8f938dff
0x100a0: 0x8900120e 0xfffef895 0x5c8d8dff 0x89ffffff
0x100b0: 0xfffef48d 0x0288e9ff 0x858b0000 0xffffff30
0x100c0: 0x00587880 0x0268840f 0xc0830000 0x20858948
0x100d0: 0xb9ffffff 0x00000007 0x0cb58bfc 0x89ffffff
0x100e0: 0xb8a6f3c7 0x00000000 0xb60f0a74 0xb60fff46
0x100f0: 0xc829ff4f 0x1d75c085 0x850c458b 0x2f840fc0
(gdb) set $eax = 0x100f0
(gdb) set $eip = 0x35204eaf
(gdb) stepi
(gdb) p/x $eax
$26 = 0xffffff30
(gdb) set $eax = 0x100f0
(gdb) set $eip = 0x35204c93
(gdb) stepi
(gdb) p/x $eax
$27 = 0x2f840fc0
(gdb) x/i 0x35204c93
0x35204c93 <-[xxx value]+9>:	mov    0xc(%eax),%eax
(gdb) x/i 0x35204eaf
0x35204eaf <-[xxx key]+9>:	mov    0x8(%eax),%eax
(gdb)

Just checking stuff with a different memory address and double checking the assembly code.

Try a different class in a different project with the same layout:

0x00001f0f  <+0006>  push   %ebp
0x00001f10  <+0007>  mov    %esp,%ebp
0x00001f12  <+0009>  sub    $0x8,%esp
0x00001f15  <+0012>  mov    0x8(%ebp),%eax
0x00001f18  <+0015>  mov    0x8(%eax),%eax
0x00001f1b  <+0018>  leave  
0x00001f1c  <+0019>  ret 
(gdb) stepi
(gdb) p/x $eax
$2 = 0x403f20
(gdb) x/4x $eax
0x403f20: 0x00003030 0x924e24f8 0x00002024 0x00002034
(gdb) stepi
(gdb) p/x $eax
$4 = 0x2024
(gdb)

My best bug ever

Thu, 17 Dec 2009 17:38:22 +0100

This is obscure, but who said programming is always easy. Maybe more on this later, if I know whats going on. This is the disassembled code for -value:

0x35204c8a  <+0000>  push   %ebp
0x35204c8b  <+0001>  mov    %esp,%ebp
0x35204c8d  <+0003>  sub    $0x8,%esp
0x35204c90  <+0006>  mov    0x8(%ebp),%eax
0x35204c93  <+0009>  mov    0xc(%eax),%eax
0x35204c96  <+0012>  leave  
0x35204c97  <+0013>  ret

and this is -key:

0x35204ea6  <+0000>  push   %ebp
0x35204ea7  <+0001>  mov    %esp,%ebp
0x35204ea9  <+0003>  sub    $0x8,%esp
0x35204eac  <+0006>  mov    0x8(%ebp),%eax
0x35204eaf  <+0009>  mov    0x8(%eax),%eax
0x35204eb2  <+0012>  leave  
0x35204eb3  <+0013>  ret

I hightlighted the only difference in the assembly code between the two functions.

Stepping through the code, with the same object

There are breakpoints on 0x35204c90 and 0x35204eac -value works as expected but -key doesn't

(gdb) stepi
(gdb) p/x $eax
$16 = 0x30de9f0
(gdb) x/4 $eax
0x30de9f0: 0x35231f20 0x925c93a8 0x04a053c0 0x00d7dfa0
(gdb) x/x $eip
0x35204c93 <-[xxx value]+9>:	0xc90c408b
(gdb) stepi
(gdb) p/x $eax
$17 = 0xd7dfa0
(gdb) c
Continuing.
(gdb) stepi
(gdb) p/x $eax
$18 = 0x30de9f0
(gdb) x/4x 0x30de9f0
0x30de9f0: 0x35231f20 0x925c93a8 0x04a053c0 0x00d7dfa0
(gdb) x/x $eip
0x35204eaf <-[xxx key]+9>:	0xc908408b
(gdb) stepi
(gdb) p/x $eax
$19 = 0x20454c4c
(gdb) set $eip = 0x35204eaf
(gdb) set $eax = 0x30de9f0
(gdb) stepi
(gdb) p/x $eax
$20 = 0x20454c4c
(gdb) set $eip = 0x35204c93
(gdb) set $eax = 0x30de9f0
(gdb) stepi
(gdb) p/x $eax
$21 = 0xd7dfa0
(gdb) 
(gdb) x/4x 0x30de9f0
0x30de9f0: 0x35231f20 0x925c93a8 0x04a053c0 0x00d7dfa0

There is nothing ommitted, there is no other thread of mine running. 0xc908408b in Visual Studio is also mov eax,dword ptr [eax+8].

How to move an Impulse account to another machine without knowing your password or email address

Fri, 11 Dec 2009 18:09:17 +0100

What if you lost your password to Impulse and what if you gave Impulse a fake email address during registration. Who could be so stupid ? But hypothetically... what could you do, if you wanted to migrate to another machine ?

Use regedit.exe, locate \HKEY_CURRENT_USER\Software\Stardock and export this folder onto a USB stick or some such.

On the new machine just doubleclick on the created registry export file and ignore the warnings.

It worked for me.

SSD Fight: Samsung PM 800 256 GB vs Intel X-25M Postville

Thu, 10 Dec 2009 20:44:44 +0100

I am using the first version of the Intel X-25M in my MacBook and I am very happy with it. So now its time to upgrade the desktops. Since some time has passed since I bought my first SSD there are now actually alternatives to the X-25M on the market. The Samsung PM 800 seems to have the X-25M beat in every benchmark I have seen, except one, and that was random 4K block read/writes. In that benchmark the IBM was about 10 times faster than the Samsung.

My suspicion was, that this particular benchmark would be of great importance, to my foremost interest, when it comes to disk speed, which is compiling. Unfortunately this aspect is rarely benchmarked. So here goes. So I ordered both and tried them in my MacBook.

	Samsung	Intel X-25M Postville	Intel X-25M (Generation 1)
GB/€	0,50	0,42	-
SL Installation time (min)	27	31	-
Xcode Installation time (m:s)	6:21	6:21	-
Build time (m:s)	2:40	2:42	2:41

What I did was I put each SSD into my MacBook, partioned it to one partition and installed Snow Leopard 10.6 from DVD on it. I measured how many minutes that took. Than I installed Xcode and checked the installer log for the time elapsed. Finally I used xcodebuild to built a decently sized software package. The I did a clean and then I measured it with time xcodebuild.

Conclusion: In my tests on the white MacBook there is no big difference between both SSDs, but the Samsung seems to be the all around better pick on first look. The Intel is going into my Windows system and the Samsung will go into my G5.

An advantage the IBM package has, it comes with a 2.5" to 3.5" adaptor.

A small x86_64 optimization brainteaser [with complete solution]

Thu, 19 Nov 2009 12:54:16 +0100

Can you make this code - method abc - run faster with x86_64 ?

#import 

@interface Foo : NSObject 
{
   long  a;
   long  b;
   long  c;
}

- (long) abc;

@end

@implementation Foo

- (long) abc
{
   return( self->a + self->b + self->c);
}

@end

Hint: Think about reorganization or restructuring.
Reference toolchain is stock Xcode 3.2 with default gcc 4.2 and Release setting.

The solution is in the full text.

va_list is now an array of some (opaque ?) struct... gee thanks

Sun, 15 Nov 2009 00:46:10 +0100

A little trap in the new 64 bit ABI.

void   bar( va_list args)
{
   va_list   x;  
   
   x = args;
   return( va_arg( x, int));
}

does not work anymore. It gives the error

error: array type 'va_list' (aka 'struct __va_list_tag [1]') is not assignable

I was curious if there was any "obvious" change in functionality. Here is the part of a function calling bar disassembled for three different architectures. The disassembly shows, that it's the same internally, two pointers are pushed unto the stack (put into parameter registers).

x86_64
	movq	%rbx, %rsi
	movl	%r12d, %edi
	call	_bar

i386:
	movl	-12(%ebp), %eax
	movl	%eax, 4(%esp)
	movl	8(%ebp), %eax
	movl	%eax, (%esp)
	call	_bar

ppc:
	lwz r4,76(r1)
	mr r3,r29
	bl _bar

What does work in the old and the new world is

void   bar( va_list args)
{
   va_list   *x;  
   
   x = &args;
   return( va_arg( *x, int));
}

where I incur one pointer indirection due to syntax. I am still forming an opinion on that...

The beginning of a bigger change ?

Fri, 13 Nov 2009 21:12:13 +0100

So I try to compile some older code (10.5) on SnowLeopard and I get:

error: @defs is not supported in new abi

The offending code looks something like this

@interface Foo
{
   void   *table1_;
}
@endif

static inline BOOL   Foo_IsASpecialObject( Foo *self, id p)
{
   return( NSHashGet( ((struct { @defs( Foo) } *) self)->table1_, p) != nil);
}

If you find this a little obscure, I once wrote an article about it (look for Using inline functions instead of method calls)

These are all the solutions to this particular problem I came up with:

don't use the new ABI / abandon platform
pester ABI maintainer to support @defs
pester ABI maintainer to support static inline between @interface and @end
painstakingly create a shadow struct, that mimics the Foo class
unprotect inline accessed instance variables in Foo with @public

Just ignoring the ABI and sticking to 32 bit is a dead end on Mac OS X, so it's not an option. Option #2 and #3, well call me negative but I am also not buying lottery tickets because of the bad odds. Option #4 is extremely fragile, I don't want that. So for now I will have to make the instance variables @public. SIGH!