From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) by sourceware.org (Postfix) with ESMTP id EFC613851C22 for ; Tue, 25 May 2021 03:10:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org EFC613851C22 Received: from vapier (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 96E44335DC3; Tue, 25 May 2021 03:10:35 +0000 (UTC) Date: Mon, 24 May 2021 23:10:35 -0400 From: Mike Frysinger To: =?utf-8?B?6IKW6bmP?= Cc: libc-help@sourceware.org Subject: Re: glibc interception problems Message-ID: Mail-Followup-To: =?utf-8?B?6IKW6bmP?= , libc-help@sourceware.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2021 03:10:39 -0000 On 25 May 2021 10:30, 肖鹏 via Libc-help wrote: > I'm developping a library for a distributed file system, using LD_PRELOAD to intercept file related calls to glibc. > Programs directly using unbuffered IO (close/open/read/write) work well with my library. But programs using buffered IO (fclose/fopen/fread/fwrite) will call unbuffered functions of glibc instead of my library. > The reason is that in glibc, buffered IO depend on internal symbols, which cannot be intercepted. > I can see two ways to work around this: > 1. Implement buffered IO in my library. > 2. Modify glibc buffered IO to use public symbols, and maintain a custom version of glibc. > Both ways have drawbacks. Do you have any suggestions about this? what is your end goal ? is this a research project ? are you developing an open source project that you want to share with others ? something else ? if it's a short-term project (e.g. for research), (2) might be your best bet. it's hacky, but if it gathers the info you need, it's not that bad. if it's a long-term project you want to share with others, i'd recommend not using LD_PRELOAD at all. maybe FUSE would be better. -mike