This instalment of “A look under ARC’s hood” is all about the new @autoreleasepool directive. LLVM tells us that the semantics of autorelease pools has changed with LLVM 3.0 and in particular, I thought it might be interesting to see what ARC is doing when it comes to these.

Read the rest of this entry »

Whilst I was doing some work with images recently I was in desperate need for some sample images which were tagged with the EXIF orientation flag for each of the 8 orientations which are supported by UIImage in its UIImageOrientation metadata. I couldn’t find any already out there, so I made my own. And now I’m posting them here for anyone who might also find this useful. I now have these saved on my iPhone and use them in apps as test images.

Download All

Read the rest of this entry »

I had been struggling with some code that I had to rotate an image whilst drawing it so I decided to sit down and work out a nice way to visualise it as I hadn’t seen anything out there really that explained it very well. This is what I came up with…

Read the rest of this entry »

Following on from my first post about looking at how ARC works under the hood I thought I would share another little snippet that I found interesting. This time I was wondering what happened when you pulled an object out of an array and returned it from a method. Pre-ARC, you would retain the object then return it autoreleased. With ARC we can get rid of those memory management calls but it just feels wrong. So I decided to check ARC was doing the right thing.

Read the rest of this entry »

After a conversation on Twitter with @jacobrelkin I decided to write a little post about how ARC works under the hood and how you can go about seeing what it’s doing. In this post I’ll explain about how ARC adds in retain, release and autorelease calls accordingly.

Read the rest of this entry »

So we have just released a new version of BeerMap which is an iPhone app that I created with a couple of friends. It’s had a long life and has changed significantly in this latest update because, to be honest, it was quite confusing to use. We didn’t really have a plan for it before but now we do and we’re executing it step by step.

Since 2.2 went live we’ve seen a lot more uptake of the app with more people reviewing beers and even some of the social media integration being used in the app which is exactly what we wanted. We wanted to push the app in a more social direction rather than just reviewing beers and pubs. If you’re simply reviewing beers and pubs then you need critical mass of users before any of that data becomes usable. So opting for the more Twitter-like style of a review now being a “Taste” and having a timeline of realtime “Tastes” coming in, the idea becomes like a way to tell the world what you think about the beer you’re drinking right now. We kept the idea of pubs (or places as we call them, because it might be a pub, a bar, a beer festival, etc) but you cannot actually review a pub. This serves the purpose of making the app simpler to understand because there’s just one first class citizen and that’s the “Taste”.

But, I’m sad now. Why is it that people decide for themselves what an app should do? Why is it that people writing reviews for apps cannot be constructive? Why is it that people think that free apps should be 100% perfect straight away? Here’s a review we got a day after 2.2 came out:

[1 star] – Why hasn’t beerintheevening got an app? This is not a satisfactory substitute – it neither adequately provides user reviews of pubs nor does it review beers. FAIL.

This was coupled with a support email request which goes further to complain about the app and how they failed to read the instructions for adding a new pub (it’s really not that complicated).

We’ll see what the future holds for BeerMap. I sincerely hope that it’s good things because I think that there’s a definite use for an app like this, especially in the UK where beer can vary between parts of the country so you want a way to find a pub that’s great.

GiffGaff: Great for iPad!

November 12th, 2011

I’ve heard about GiffGaff from a lot of people but it was only when I realised how good it would be for my iPad that I decided to give it a go. So I got a SIM, topped up £10 and now I can spend just 20p each day and get 20MB of data! It’s great for my iPad because I can use it whilst out and about and just pay for each day that I want mobile data, which is quite rare for me really.

So if you’ve got an iPad and want cheap data for it then go grab a GiffGaff SIM and away you go!

I came across another interesting compiler bug today. I’m not going to go into too much detail about it, but the problem code is this:

void a() {
    int a = 0;
    int b = 0;
    __asm__("\n"
            "\tmov %0, 0\n"
            "\tldr %0, %1\n"
            "\tmov %1, 0\n"
            : "=r"(a), "+m"(b)
           );
}

To break that down a bit, the function is doing this:

  1.     int a = 0;
        int b = 0;
    

    Initialise a couple of variables and set them to 0.

  2.     __asm__("\n"
                "\tmov %0, 0\n"
                "\tldr %0, %1\n"
                "\tmov %1, 0\n"
                : "=r"(a), "+m"(b)
               );
    

    Then perform some inline assembly using the variables. This just puts 0 into the register that will hold our ‘a’ variable, then loads the value of ‘b’ into ‘a’, then sets ‘b’ to 0.

This is of course a contrived example, but it illustrates the bug. The output assembly from LLVM-GCC or clang is (for ARM architecture):

        .globl  _a
        .align  2
        .code   16
        .thumb_func     _a
_a:
        sub     sp, #8
        movs    r0, #0
        movt    r0, #0
        str     r0, [sp, #4]
        str     r0, [sp]
        mov     r0, sp
        @ InlineAsm Start

        mov r0, 0
        ldr r0, [r0]
        mov [r0], 0

        @ InlineAsm End
        str     r0, [sp, #4]
        add     sp, #8
        bx      lr

The interesting bit is the inline assembly. You’ll notice that it’s doing something very stupid. It’s choosing the same register for both operands (it’s choosing r0). This is completely wrong, and will lead to a runtime crash in this case due to the dereference of 0.

I did a bit of hunting and it appears to be a problem in generating the LLVM bytecode as the problem manifests itself before the LLVM bytecode is compiled down into instructions, like so:

define void @a() nounwind ssp {
  %a = alloca i32, align 4
  %b = alloca i32, align 4
  store i32 0, i32* %a, align 4
  store i32 0, i32* %b, align 4
  %1 = call i32 asm "\0A\09mov $0, 0\0A\09ldr $0, $1\0A\09mov $1, 0\0A", "=r,=*m,*m"(i32* %b, i32* %b) nounwind, !srcloc !0
  store i32 %1, i32* %a, align 4
  ret void
}

You can see here that the ‘%a’ (i.e. variable ‘a’) is never referenced, only ‘%b’ (i.e. variable ‘a’). This is not what we’d expect at all given we’re referencing both variables in the code.

I found this quite interesting :-) .

[Update]

I’ve actually found out that this isn’t a bug! That’s good news, right? It’s quite a subtle thing, but the heart of the problem can be explained after understanding the modifiers to operands on inline assembly. The problem is that we’re not specifying that ‘a’ is clobbered early. In the assembly, we’re writing to it before reading we’ve finished using all input operands (only ‘b’ in this case) so we’re meant to mark it like that. It’s just luck that GCC does the right thing – Apple’s LLVM is doing the right thing and using less registers!

So the correct code is this:

void a() {
    int a = 0;
    int b = 0;
    __asm__("\n"
            "\tmov %0, 0\n"
            "\tldr %0, %1\n"
            "\tmov %1, 0\n"
            : "=&r"(a), "+m"(b)
           );
}

Which results in the following assembly:

        .globl  _a
        .align  2
        .code   16
        .thumb_func     _a
_a:
        sub     sp, #8
        movs    r0, #0
        movt    r0, #0
        str     r0, [sp, #4]
        str     r0, [sp]
        mov     r0, sp
        @ InlineAsm Start

        mov r1, 0
        ldr r1, [r0]
        mov [r0], 0

        @ InlineAsm End
        str     r1, [sp, #4]
        add     sp, #8
        bx      lr

And the following LLVM:

define void @a() nounwind ssp {
  %a = alloca i32, align 4
  %b = alloca i32, align 4
  store i32 0, i32* %a, align 4
  store i32 0, i32* %b, align 4
  %1 = call i32 asm "\0A\09mov $0, 0\0A\09ldr $0, $1\0A\09mov $1, 0\0A", "=&r,=*m,*m"(i32* %b, i32* %b) nounwind, !srcloc !0
  store i32 %1, i32* %a, align 4
  ret void
}

Review: Sensible TableView

April 21st, 2011

Every iOS developer should be very familiar with the UITableView. It’s the main building block of most applications (excluding OpenGL based games, of course). So back when I started developing applications when iOS was on version 2.0, I created a tutorial for creating custom UITableViewCell objects. Since then application developers are finding more and more that they need to push the boundaries of what they can do with a simple UITableViewCell. In iOS 3.0 Apple introduced a style attribute for cells, which certainly helped with a lot of situations but there is still the tedious process of creating custom cells with anything more than the standard 1 or 2 text labels.
Read the rest of this entry »

I came across a very strange bug whilst developing an iOS application whereby the application would seg fault and whilst stepping through the code I found it was going all over the place. This lead me to run the application through otool, and I discovered that half the code for a function was missing!

Here is an example of what happened…

Consider the following C file. It’s just a very simple function that has some inline assembly (to count down from 10 to 0) and a very simple function that does absolutely nothing.

void func() {
    int tmp;
    __asm__ __volatile__ (
        "\tmov %0, #10\n"

        ".loop:\n"
        "\tsubs %0, %0, #1\n"
        "\tbne .loop\n"

        : "=r" (tmp)
        : "r" (tmp)
    );
}

void funcB() {
}

Let’s see what happens when we compile it for iOS…

        .section __TEXT,__text,regular
        .section __TEXT,__textcoal_nt,coalesced
        .section __TEXT,__const_coal,coalesced
        .section __TEXT,__picsymbolstub4,symbol_stubs,none,16
        .text
        .align 2
        .globl _func
_func:
        @ args = 0, pretend = 0, frame = 4
        @ frame_needed = 1, uses_anonymous_args = 0
        stmfd   sp!, {r7, lr}
        add     r7, sp, #0
        sub     sp, sp, #4
        ldr     r3, [sp]
                mov r3, #10
.loop:
        subs r3, r3, #1
        bne .loop

        str     r3, [sp]
        sub     sp, r7, #0
        ldmfd   sp!, {r7, pc}
        .align 2
        .globl _funcB
_funcB:
        @ args = 0, pretend = 0, frame = 0
        @ frame_needed = 1, uses_anonymous_args = 0
        stmfd   sp!, {r7, lr}
        add     r7, sp, #0
        ldmfd   sp!, {r7, pc}
        .subsections_via_symbols

That all looks fairly normal and we could quite happily believe that was going to work just fine. So, let’s use this function in a test application. The code below is just a very simple application that calls the ‘func()’ function and then returns.

void func();
int main() {
    func();
    return 0;
}

So now let’s see what happens when we link this with the same options that you would have on by default in an iOS application (hint: -dead_strip is active).

Output from ‘otool -vV -t’ on the linked application:

_main:
00002fa0        e92d4080        push    {r7, lr}
00002fa4        e28d7000        add     r7, sp, #0      @ 0x0
00002fa8        eb000002        bl      _func
00002fac        e3a03000        mov     r3, #0  @ 0x0
00002fb0        e1a00003        mov     r0, r3
00002fb4        e8bd8080        pop     {r7, pc}
_func:
00002fb8        e92d4080        push    {r7, lr}
00002fbc        e28d7000        add     r7, sp, #0      @ 0x0
00002fc0        e24dd004        sub     sp, sp, #4      @ 0x4
00002fc4        e59d3000        ldr     r3, [sp]
00002fc8        e3a0300a        mov     r3, #10 @ 0xa

What?! Where’s the rest of the ‘func()’ code?! Not only is it missing, but it would appear that ‘func()’ just simply stops without ever returning?! That looks very suspicious… So, let’s compile it without the ‘-dead_strip’ option:

Output from ‘otool -vV -t’ on the linked application:

_main:
00002f80        e92d4080        push    {r7, lr}
00002f84        e28d7000        add     r7, sp, #0      @ 0x0
00002f88        eb000002        bl      _func
00002f8c        e3a03000        mov     r3, #0  @ 0x0
00002f90        e1a00003        mov     r0, r3
00002f94        e8bd8080        pop     {r7, pc}
_func:
00002f98        e92d4080        push    {r7, lr}
00002f9c        e28d7000        add     r7, sp, #0      @ 0x0
00002fa0        e24dd004        sub     sp, sp, #4      @ 0x4
00002fa4        e59d3000        ldr     r3, [sp]
00002fa8        e3a0300a        mov     r3, #10 @ 0xa
.loop:
00002fac        e2533001        subs    r3, r3, #1      @ 0x1
00002fb0        1afffffd        bne     .loop
00002fb4        e58d3000        str     r3, [sp]
00002fb8        e247d000        sub     sp, r7, #0      @ 0x0
00002fbc        e8bd8080        pop     {r7, pc}
_funcB:
00002fc0        e92d4080        push    {r7, lr}
00002fc4        e28d7000        add     r7, sp, #0      @ 0x0
00002fc8        e8bd8080        pop     {r7, pc}

Ah, that’s better! The loop is back and so is the return. Also, ‘funcB()’ is still in there. So, what has happened you may ask. Well, -dead_strip is designed to remove symbols from a binary that are not required. So we’d expect ‘funcB’ to be removed, but not .loop as it’s part of ‘func’. However, if we look closer, what has happened is that ‘.loop’ has become a top level symbol rather than a symbol local to the ‘func’ symbol. So -dead_strip assumed that it was a symbol not used anywhere (as it’s only accessed from within .loop itself) and so it removed it, resulting in a completely mangled application binary.

To stop this happening you must always prefix your local symbols with ‘L’ (as per the GCC documentation!). But I think this is an excellent example of what can go wrong if you just do 1 tiny thing wrong with inline assembly.

As a side note, I decided to try compiling/assembling/linking all of the above for Android as well. Interestingly the results were different. First I’ll show the outputs of the various stages and then explain the results.

The assembly generated for Android:

        .arch armv6
        .fpu softvfp
        .eabi_attribute 20, 1
        .eabi_attribute 21, 1
        .eabi_attribute 23, 3
        .eabi_attribute 24, 1
        .eabi_attribute 25, 1
        .eabi_attribute 26, 2
        .eabi_attribute 30, 6
        .eabi_attribute 18, 4
        .file   "test.c"
        .text
        .align  2
        .global func
        .type   func, %function
func:
        @ args = 0, pretend = 0, frame = 8
        @ frame_needed = 1, uses_anonymous_args = 0
        @ link register save eliminated.
        str     fp, [sp, #-4]!
        add     fp, sp, #0
        sub     sp, sp, #12
        ldr     r3, [fp, #-8]
#APP
@ 3 "test.c" 1
                mov r3, #10
.loop:
        subs r3, r3, #1
        bne .loop

@ 0 "" 2
        str     r3, [fp, #-8]
        add     sp, fp, #0
        ldmfd   sp!, {fp}
        bx      lr
        .size   func, .-func
        .align  2
        .global funcB
        .type   funcB, %function
funcB:
        @ args = 0, pretend = 0, frame = 0
        @ frame_needed = 1, uses_anonymous_args = 0
        @ link register save eliminated.
        str     fp, [sp, #-4]!
        add     fp, sp, #0
        add     sp, fp, #0
        ldmfd   sp!, {fp}
        bx      lr
        .size   funcB, .-funcB
        .ident  "GCC: (GNU) 4.4.3"
        .section        .note.GNU-stack,"",%progbits

Disassembly of linked app for Android (without stripping):

000082e0 <main>:
    82e0:       e92d4800        push    {fp, lr}
    82e4:       e28db004        add     fp, sp, #4      ; 0x4
    82e8:       eb000002        bl      82f8 <func>
    82ec:       e3a03000        mov     r3, #0  ; 0x0
    82f0:       e1a00003        mov     r0, r3
    82f4:       e8bd8800        pop     {fp, pc}

000082f8 <func>:
    82f8:       e52db004        push    {fp}            ; (str fp, [sp, #-4]!)
    82fc:       e28db000        add     fp, sp, #0      ; 0x0
    8300:       e24dd00c        sub     sp, sp, #12     ; 0xc
    8304:       e51b3008        ldr     r3, [fp, #-8]
    8308:       e3a0300a        mov     r3, #10 ; 0xa

0000830c <.loop>:
    830c:       e2533001        subs    r3, r3, #1      ; 0x1
    8310:       1afffffd        bne     830c <.loop>
    8314:       e50b3008        str     r3, [fp, #-8]
    8318:       e28bd000        add     sp, fp, #0      ; 0x0
    831c:       e8bd0800        pop     {fp}
    8320:       e12fff1e        bx      lr

00008324 <funcB>:
    8324:       e52db004        push    {fp}            ; (str fp, [sp, #-4]!)
    8328:       e28db000        add     fp, sp, #0      ; 0x0
    832c:       e28bd000        add     sp, fp, #0      ; 0x0
    8330:       e8bd0800        pop     {fp}
    8334:       e12fff1e        bx      lr

Disassembly of linked app for Android (after using strip command):

000082e0 <main>:
    82e0:       e92d4800        push    {fp, lr}
    82e4:       e28db004        add     fp, sp, #4      ; 0x4
    82e8:       eb000002        bl      82f8 <func>
    82ec:       e3a03000        mov     r3, #0  ; 0x0
    82f0:       e1a00003        mov     r0, r3
    82f4:       e8bd8800        pop     {fp, pc}

000082f8 <func>:
    82f8:       e52db004        push    {fp}            ; (str fp, [sp, #-4]!)
    82fc:       e28db000        add     fp, sp, #0      ; 0x0
    8300:       e24dd00c        sub     sp, sp, #12     ; 0xc
    8304:       e51b3008        ldr     r3, [fp, #-8]
    8308:       e3a0300a        mov     r3, #10 ; 0xa
    830c:       e2533001        subs    r3, r3, #1      ; 0x1
    8310:       1afffffd        bne     830c <func+0x14>
    8314:       e50b3008        str     r3, [fp, #-8]
    8318:       e28bd000        add     sp, fp, #0      ; 0x0
    831c:       e8bd0800        pop     {fp}
    8320:       e12fff1e        bx      lr

You can see that the Android GCC has done a much better job at stripping out the symbols. This is because of a subtle “.size” attribute given to functions in the assembly for Linux (and therefore Android) which tells the assembler how big the function is. However, this doesn’t exist on Mac and the size is calculated by taking the distance between the start of a symbol and the next symbol.

This actually helps us to understand a bit more what actually went wrong. If you look back up at the assembly generated for iOS and Android you’ll see that the ‘.loop’ appears as a top level symbol, which is confirmed by running ‘nm’ on the resulting object file. This sounds all wrong, since the .loop symbol should really be local to the ‘func()’ function. The reason being because you need to prefix local symbols with ‘L’. If we change ‘.loop’ for ‘Lloop’ in the sample file, then these are the resulting outputs showing the iOS linker doing the right thing this time even with -dead_strip enabled.

Compiled output:

        .section __TEXT,__text,regular
        .section __TEXT,__textcoal_nt,coalesced
        .section __TEXT,__const_coal,coalesced
        .section __TEXT,__picsymbolstub4,symbol_stubs,none,16
        .text
        .align 2
        .globl _func
_func:
        @ args = 0, pretend = 0, frame = 4
        @ frame_needed = 1, uses_anonymous_args = 0
        stmfd   sp!, {r7, lr}
        add     r7, sp, #0
        sub     sp, sp, #4
        ldr     r3, [sp]
                mov r3, #10
Lloop:
        subs r3, r3, #1
        bne Lloop

        str     r3, [sp]
        sub     sp, r7, #0
        ldmfd   sp!, {r7, pc}
        .align 2
        .globl _funcB
_funcB:
        @ args = 0, pretend = 0, frame = 0
        @ frame_needed = 1, uses_anonymous_args = 0
        stmfd   sp!, {r7, lr}
        add     r7, sp, #0
        ldmfd   sp!, {r7, pc}
        .subsections_via_symbols

Disassembly of linked application:

_main:
00002f8c        e92d4080        push    {r7, lr}
00002f90        e28d7000        add     r7, sp, #0      @ 0x0
00002f94        eb000002        bl      _func
00002f98        e3a03000        mov     r3, #0  @ 0x0
00002f9c        e1a00003        mov     r0, r3
00002fa0        e8bd8080        pop     {r7, pc}
_func:
00002fa4        e92d4080        push    {r7, lr}
00002fa8        e28d7000        add     r7, sp, #0      @ 0x0
00002fac        e24dd004        sub     sp, sp, #4      @ 0x4
00002fb0        e59d3000        ldr     r3, [sp]
00002fb4        e3a0300a        mov     r3, #10 @ 0xa
00002fb8        e2533001        subs    r3, r3, #1      @ 0x1
00002fbc        1afffffd        bne     0x2fb8
00002fc0        e58d3000        str     r3, [sp]
00002fc4        e247d000        sub     sp, r7, #0      @ 0x0
00002fc8        e8bd8080        pop     {r7, pc}

This all serves to illustrate the point that it’s worth knowing about the options of your compiler, assembler & linker and understanding how everything fits together.