From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) by sourceware.org (Postfix) with ESMTPS id 7D8043858403 for ; Thu, 22 Sep 2022 12:31:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7D8043858403 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pf1-x432.google.com with SMTP id e68so9158274pfe.1 for ; Thu, 22 Sep 2022 05:31:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date; bh=GfOnUr25qo/cVSen4C4gHdb/qO70rob/ckCq1O8NPoM=; b=hIzjnDUND0pAJOmmYza4aFujak9rsrS6rYvQiD+EdXKgW/eUcr/FzuM0Ebje8vGRmT Kk/GhMEhYohWTVU6/I4L8eO8Lx7NyaZNGi+GgtSaFEr+02QDlHNX9+SNL/+9tiXKSFvP aLf+5kEBpokBG7sgkPELpvhUX1ZM2D3319Ei+38YJwi0oReWVqfzIM2M7S0lkm4B7Bbc F0AUWTWXEas6dxLvFsTKtL8g1HmfkztE2WSl8MN4ef5eHRM8UEKf6uzgq/oJxHfvEQVV BL7+aYP1tYRuwIPA5mWfBV7DHcoXPR1VmYWmT9n2jKjRz/Cc7jt/mOFDaa2yl+GcUrdU Iv3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date; bh=GfOnUr25qo/cVSen4C4gHdb/qO70rob/ckCq1O8NPoM=; b=khH/ntBnywo6Xs7ZJfWDpOyU3M/JD7cAxLFHna8m1RhWAK9E4v6kNV/XzWKHyHkSr1 MR+d0RyjoAU8p/gfawBHYOUC3fV/kBEpCXSDgBC+KtNcLpIaRvqFI91pAlXBC+UN1PgP mmzft5WGMhNokOdk0Gyg7wndl3GlD2IU7yic0TGA09QMOy9/jtwCzGgHc0LhawRgVdLN ijQaQ6vJnkvHSiMg8ihbtTxPDpNeDo/JNuUrou6pMe1g/3y79ggHWmntpTgh0rItOWAV 6HXNaqwFqEtkrh1BW0j21qTDT2U58PsQQ7CDamu8X+CCxAVBsfhJjxJ3Dp+gcDcK0SIe r8Rw== X-Gm-Message-State: ACrzQf35EAVCPp6pzSJp+z6/ZudtVwlsQIA3ZcPIa3BRyc0XCBTfxsGC z8JR5G/s5Ly1aT+HmdfNxt3KX3HK63nAcFOv7Mdy+PvZ X-Google-Smtp-Source: AMsMyM59V1tGN8d6JXOX8GTJV8PDr7pR426HAfsfHzDYTK/jSBqx2OYRYtn7hAg5/DmRtZmmyMootn8uNS8d3GOmrn8= X-Received: by 2002:a62:b612:0:b0:553:1bfb:966b with SMTP id j18-20020a62b612000000b005531bfb966bmr3486461pff.53.1663849899422; Thu, 22 Sep 2022 05:31:39 -0700 (PDT) MIME-Version: 1.0 From: Godmar Back Date: Thu, 22 Sep 2022 08:31:27 -0400 Message-ID: Subject: What are the option for overriding system calls GNU libc calls? To: William Tambe via Libc-help Content-Type: multipart/alternative; boundary="00000000000036f9c905e9433e86" X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --00000000000036f9c905e9433e86 Content-Type: text/plain; charset="UTF-8" Hi, I have a question. Say I wanted to override the `write()` system call in an application so that when I compile and link it, my version of `write()` is called by both the application program as well as by GNU libc, for instance, from puts or printf. To what extent is this supported? I'm aware of the following options: - (a) link statically. In this case, if I provide a strong definition of `write()`, the application will pick it up. GNU libc, otoh, uses `__write()` Overriding `__write` with a strong definition works and gets libc to call my __write. - (b) link dynamically and use `LD_PRELOAD`. In this case, I can get the application to call my `write`, but libc will continue to call `__write`; I believe; I haven't tried if I can provide a __write and have libc pick up on it since (I thought) that libc resolves these symbols internally or from a dynamic library on its link chain. In any event, my question is: is there a sanctioned or semi-sanctioned way to override system calls for both the static and dynamic linking process? - Godmar --00000000000036f9c905e9433e86--