From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from alt22.smtp-out.videotron.ca (alt22.smtp-out.videotron.ca [70.80.0.73]) by sourceware.org (Postfix) with ESMTPS id C69F23951868 for ; Fri, 13 Nov 2020 22:18:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C69F23951868 Received: from [192.168.0.100] ([96.20.238.10]) by Videotron with SMTP id dhP1kGDx4sO2gdhP3kDbL0; Fri, 13 Nov 2020 17:18:46 -0500 X-Authority-Analysis: v=2.3 cv=BMfNU2YG c=1 sm=1 tr=0 a=IvhzMnQCxHlOtQqA98XSUg==:117 a=IvhzMnQCxHlOtQqA98XSUg==:17 a=IkcTkHD0fZMA:10 a=x7bEGLp0ZPQA:10 a=rvM64S1SdSMA:10 a=9g3MdOiTfH4q0ECqq8cA:9 a=QEXdDO2ut3YA:10 Subject: Re: what is the dlopen criterion used to decide if library needs to be loaded? To: Florian Weimer , Daniel Villeneuve via Libc-help References: <878sb5rl2q.fsf@oldenburg2.str.redhat.com> From: Daniel Villeneuve Message-ID: <19c7f6df-e4ff-94e9-1925-305747c1cb8b@gmail.com> Date: Fri, 13 Nov 2020 17:18:43 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <878sb5rl2q.fsf@oldenburg2.str.redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-CMAE-Envelope: MS4wfP3B1yEID2zIgvKTSV/uPJ8WkgP9QDmxJylFE1Nm0s+i6QL+1X75WKlKpp3ijX01VWhjERlCr6ubx/uuu9mMArfxhpTuGWQjzk2m/pr9wFCMRz2G18BP r++5Yh+F8xufq0NpwcGm0SBzxisFUJkRC8be5GoRw9b7PTlWYMaOjH45Xa7Nw1JKMLGFgEtO0FYHgUOiPjVE3JLAvu8vD8/ohlA= X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, FORGED_GMAIL_RCVD, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, KAM_DMARC_NONE, KAM_DMARC_STATUS, NICE_REPLY_A, NML_ADSP_CUSTOM_MED, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_SOFTFAIL, TXREP autolearn=no 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: Fri, 13 Nov 2020 22:18:49 -0000 On 11/13/20 4:41 PM, Florian Weimer wrote: > * Daniel Villeneuve via Libc-help: > >> By looking at the code in glibc, there seems to be a test using inode/xdev, which does not rely on the name. However, inodes can be reused immediately after unlink, so it seems fragile to infer equality of contents just comparing inodes. > The files are stilled mapped while the objects are still loaded, so they > must exist unnamed in the the file system. Their content is also > accessible via /proc/PID/map_files. I believe the inode/device pair is > indeed unique under these circumstances. Ok, thanks. >> In the end, I've rebuilt the library using the same name (not being >> sure whether the inode would be the same or not), and before dlopen, I >> create a hard link with a new unique name on the library and use that >> as arg to dlopen (and then delete the hard link). >> >> Is this a safe way to ensure a newly built library is really loaded? > It depends on what the soname of the library is. If you set it to a > fixed value, the new library may be opened, but not loaded eventually > because the soname is already known to the system. This internal test about soname (dlopen skipping loading a library) is new to me. So loading two different library files, with different names, could end up in skipping the second load because of same soname? My tests show that even with the same soname, dlopen/dlsym use the new library (loaded with the unique name). My understanding of ld -hSONAME is for registering at link-time in an executable which arg to use for an eventual dlopen. Not sure about the connection with calling dlopen on a specific path... Regards, -- Daniel Villeneuve