From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9CE903858C53; Mon, 27 Mar 2023 07:12:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9CE903858C53 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1679901143; bh=OgtgrpSgBGxES8/1waUPvFNo46EMvLaLg32NyqpvT8I=; h=From:To:Subject:Date:In-Reply-To:References:From; b=CkZcEvEz3kn1INcMe0vr3QdZAjKHKzaWY/StL3KsfXlvATYya1r8YzqeGWQ3qZQRV 71pxIqf8T7CH1o0X7Rn9DhFpKEKg4rlt+ge0FKXq/aKb7wiQdHv22V9CaQ6DCVtmdo 5RKxWtGmDi1JvzOJ11V9Xd9NIPf5XFOxyIOdM/30= From: "stsp at users dot sourceforge.net" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/30007] rfe: dlopen to specified address Date: Mon, 27 Mar 2023 07:12:22 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: stsp at users dot sourceforge.net X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30007 --- Comment #22 from Stas Sergeev --- Hi guys, so what is the status of all this? If my patches would never be looked into, no matter what, then perhaps you should tell me that right here, so that I stop wasting my and other's time. In any other case I have the following questions: 1. Have we passed the stage where my use-case is explained and clarified? 2. Have we passed the stage where I kept presented with an "alternative solutions" like "intercept all mmap (and perhaps also mprotect) syscalls and do some weird thing on them"? My last conclusion was that such "solution" doesn't work for unaligned SHT_NOBITS sections. 3. If we passed 1 and 2, then I think the next step is to discuss an API, so here's the API: dlfcn.h addition: /* Callback for dlmem. */ typedef void * (dlmem_premap_t) (void *mappref, size_t maplength, size_t mapalign, void *cookie); /* Do not replace destination mapping. dlmem() will then use memcpy(). */ #define DLMEM_DONTREPLACE 1 struct dlmem_args { /* Optional name to associate with the loaded object. */ const char *soname; /* Namespace where to load the object. */ Lmid_t nsid; /* dlmem-specific flags. */ unsigned flags; /* Optional premap callback. */ dlmem_premap_t *premap; /* Optional argument for premap callback. */ void *cookie; }; /* Like `dlmopen', but loads shared object from memory buffer. */ extern void *dlmem (const unsigned char *buffer, size_t size, int mode, struct dlmem_args *dlm_args); Does anyone know if its a good or bad API, and how should it be improved? It allows to implement dlopen_with_offset() in a couple of lines, it preserves the file-based mappings so that /proc/self/maps or /proc/self/map_files are valid, and it allows to specify the solib name, so it handles the file-based mmaps, like dlopen_with_offset(), rather perfectly. I wish I could have a separate libdl, but so far that looks very difficult. If you have any suggestions how can I have the separate libdl, then that would indeed be a perfect alternative solution that will eliminate any need to patch glibc sources. Or maybe some simple hooks can be added to aid a standalone libdl? Let me know and I will work in that direction then. But "no reply" is a bit inconclusive. --=20 You are receiving this mail because: You are on the CC list for the bug.=