0

I am currently making a library which overrides certain libC functions (such as strcpy). The problem is when I call one of these functions which in its code call another function (which may be in LibC), it calls LibC's instead of the other one currently in library.

Example: The instruction call strcpy WRT ..plt will call LibC's strcpy instead of mine present in the Shared Object file.

How can I make it so it calls in priority the function from my own library instead of LibC's ?

Edit:

Here is a minimal testable example:

memmove.asm

bits 64
    global memmove:function
    extern malloc
    extern memcpy
    extern free

    section .text:
    ; void *memmove(void *dest, const void *src, size_t n)
memmove:
    ; RDI = dest
    ; RSI = src
    ; RDX = n

    push rdi    ; RSP + 0x10
    push rsi    ; RSP + 0x8
    push rdx    ; RSP

    mov rdi, [rsp]  ; n (Restore RDX)
    call malloc WRT ..plt

    mov rdi, rax    ; dest
    mov rsi, [rsp + 0x8]    ; src (Restore RSI)
    mov rdx, [rsp]  ; n (Restore RDX)
    call memcpy WRT ..plt

    mov rdi, [rsp + 0x10]   ; dest (Restore RDI)
    mov rsi, rax
    mov rdx, [rsp]
    ;push rax
    call memcpy WRT ..plt

    ;pop rdi
    ;call free WRT ..plt

    pop rdx
    pop rsi
    pop rdi

    ret

memcpy.asm

    bits 64
    global memcpy:function

    section .text:
    ; void *memcpy(void *dest, const void *src, size_t n)
memcpy:
    ; RDI = dest
    ; RSI = src
    ; RDX = n

    xor rcx, rcx

    .loop_begin:
    cmp rcx, rdx
    je short .loop_end
    mov r9b, BYTE [rsi + rcx]
    mov BYTE [rdi + rcx], r9b
    inc rcx
    jmp short .loop_begin

    .loop_end:
    mov rax, rdi

    ret
Ra'Jiska
  • 979
  • 2
  • 11
  • 23
  • That sounds like a linking problem. Make sure your linker searches your library first. – Jester Mar 04 '18 at 13:08
  • @Jester What do you mean ? Maybe have I not been clear enough, this is a library which I am doing. Some functions within my library call functions which are both in LibC and mine. The problem is that LibC's function seems to be called before searching within its own function list. – Ra'Jiska Mar 04 '18 at 13:39
  • Yes, I understand you. You have not provided a [MCVE] so it's really hard to be more specific. – Jester Mar 04 '18 at 13:52
  • @Jester You are right, I just added an example using the `memmove` function which should call my own `memcpy` function but which ends up calling LibC's. – Ra'Jiska Mar 04 '18 at 14:04
  • Works fine here. But of course you still haven't posted what commands you use to assemble and link, and also no test program. – Jester Mar 04 '18 at 14:19
  • Just FYI, your `memcpy` implementation is about as slow as it's possible to be. At least you didn't use the slow `loop` instruction, but this has so much loop overhead it can't even copy 1 byte per clock cycle on Haswell, for example (and even less than that on Sandybridge / Ivybridge because of the indexed addressing modes). See https://stackoverflow.com/questions/47783926/why-are-loops-always-compiled-like-this. – Peter Cordes Mar 04 '18 at 21:08
  • But even if you reduce loop overhead so you don't bottleneck on the front-end, you bottleneck on both 1 store per clock (regardless of width), and on merging a byte into the low byte of `r9` (use `movzx r9d, byte [rsi + rcx]` / `mov BYTE [rdi + rcx], r9b`, or better use `eax`/`al`, or copy rdi to rax earlier and use pointer increments.) See also https://stackoverflow.com/questions/41573502/why-doesnt-gcc-use-partial-registers re: partial register merging, and https://stackoverflow.com/questions/26046634/micro-fusion-and-addressing-modes re: indexed addressing modes on Sandybridge. – Peter Cordes Mar 04 '18 at 21:11
  • This is a linking problem. You need something like -Bsymbolic to tell runtime linker resolve name within library itself. – llllllllll Mar 05 '18 at 07:17

0 Answers0