Re: Is there a way to detect a null reference function pointer during assembly or linking ?

[Michael Matz <matz at suse dot de>]

Hello,

On Sun, 1 Dec 2019, William Tambe wrote:

> > Could I please have pointers to examples of code that implement "if 
> > (func)" when -fPIC ?
> 
> I meant, could I have pointers in the compiler source that shows the use 
> of the GOT if -fPIC code for "if (func)" where func is a weak symbol ?

You would have to tell us which compiler you're using, but even then it's 
outside of binutils capabilities to handle.  But e.g. look at what GCC 
emits for this on any of the mainstream architectures (here x86-64):

% cat x.c
extern void weakfn (void) __attribute__((weak));
extern void strgfn (void);

int main () {
    if (weakfn)
      weakfn();
    if (strgfn)
      strgfn();
}
% gcc -fPIC -S -o - x.c
...
        movq    weakfn@GOTPCREL(%rip), %rax
        testq   %rax, %rax
        je      .L2
        call    weakfn@PLT
.L2:
        call    strgfn@PLT
...

(also compare to compiling with -fno-PIC, in particular how that would use 
a PC-relative reference to weakfn, running into the exact same problem you 
are having)

The value of the funcion pointer is loaded from the GOT slot (which itself 
is reachable via PC-relative addressing here, so this is still position 
independend).  That GOT slot is expected to hold the final relocation 
address; for weak undefined symbols on ELF that would be zero.  In 
particular the relocation used for the value in the GOT slot must be 
absolute, not PC-relative.

If your compiler is not emitting something like the above with -fPIC, then 
that is a compiler bug, not to be fixed in binutils.

If your compiler _is_ emitting some indirection through memory for 
addresses of weak symbols, but the final linked result nevertheless again 
uses an PC-relative access to get at it, then indeed you've a binutils 
bug.  Probably somewhere in the handling of weak symbols, possibly in the 
way Florian mentioned (where the reference from the call causes a PLT slot 
and a symbol named 'weakfn' emitted making it look as if there'd be an 
definition of the symbol, where in reality there isn't).

If you have a compiler bug, then probably in the parts that do constant 
evaluation of comparisons of addresses of symbols with zero.  Without weak 
symbols all such addresses can always be assumed to be non-zero and the 
whole comparison be folded away (like above for the strgfn() case).  With 
weak symbols such addresses might not always be non-zero, and hence code 
needs to be generated for this.


Ciao,
Michael.

> 
> 
> > >
> > > You have a linker problem if ld is emitting dynamic relocs, or
> > > resolving symbols and/or editing code so that what wasn't a relative
> > > offset in the relocatable object file becomes one in the final
> > > executable.
> > >
> > > --
> > > Alan Modra
> > > Australia Development Lab, IBM
> >
>