On Tue, May 9, 2023, at 14:51, Drew DeVault wrote:
> %.1 =l copy $fred
> call %.1()

Note that qbe will hastily get rid of the copy and
just turn this code into:

call $fred()

Thx for the clarification Quentin. So now I’m just left with 
the linker problem. I can call printf directly but not get it’s
address. Here’s what I currently have:


export function w $main() {
@body.1
    storel $fred, $pfred # stores the address of fred into pfred
    %.1 =l loadl $pfred # loads an address from pfred
    call %.1(l $str_hello)
    %.lf =w call $LF()
    call $printf(l $str_a_char, ..., ub %.lf)

    # storel $printf, $pfred
    # %.2 =l loadl $pfred
    # call %.2(l $str_a_char, ..., ub %.lf)

    ret 0
}

# replace w with ub once fix tested
function w $LF() {
@body.1
    ret 10
}

function $fred(l %.1) {
@body.1
    call $printf(l %.1)
    ret
}

data $pfred = { l 0 }
data $str_hello = { b "hello", b 0 }
data $str_a_char = { b "%c", b 0 }




i.e. this is okay
    adrp x1, _pfred@page
    add x1, x1, _pfred@pageoff

But this is not when I uncomment the above
    adrp x0, _printf@page
    add x0, x0, _printf@pageoff


Might this be a linker bug on macOS? (I hit some posts from several
years ago). I’m just linking with -cl on clang.

On Tue, May 9, 2023, at 17:43, info wrote:
> i.e. this is okay
>     adrp x1, _pfred@page
>     add x1, x1, _pfred@pageoff
>
> But this is not when I uncomment the above
>     adrp x0, _printf@page
>     add x0, x0, _printf@pageoff

The difference is that pfred is in the object you are
compiling while printf will end up being dynamically
linked. Right now, qbe does not support taking the
address of dynamically linked symbols. Adding this
support should not be very difficult since the work
on thread-local symbols paved the way.

The issue you encounter with stderr has the same root
cause.