From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 5298 invoked from network); 8 May 2022 19:38:35 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 8 May 2022 19:38:35 -0000 Received: (qmail 27934 invoked by uid 550); 8 May 2022 19:38:32 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 27900 invoked from network); 8 May 2022 19:38:31 -0000 Date: Sun, 8 May 2022 21:38:14 +0200 From: Szabolcs Nagy To: Pablo Galindo Salgado Cc: Rich Felker , Markus Wichmann , musl@lists.openwall.com Message-ID: <20220508193814.GO1320090@port70.net> Mail-Followup-To: Pablo Galindo Salgado , Rich Felker , Markus Wichmann , musl@lists.openwall.com References: <20220508113910.GC7958@voyager> <20220508135444.GD7074@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [musl] Why the entries in the dynamic section are not always relocated? * Pablo Galindo Salgado [2022-05-08 15:23:29 +0100]: > Thanks for all the answers to this! Here are some clarifications > and context. > > > It appears to me that whatever you are trying to do is not possible > > portibly on Linux at this time. Could you fill us in? > > As part of writing profiling and debugging tools, I am trying to rewrite > the PLT > table to hook into some symbols of shared libraries. This technique is > quite common > and is already used in a considerable number of debuggers, profilers and > elf inspection > tools. Currently, the way this is handled is "not at all" or "checking > against the base > address and heuristically assuming that is an offset if the address is less > than the base", > which is suboptimal. This use case may sound "advanced" or "hacky" but this > is quite a > common technique for doing profilers, debuggers, state inspection tools and > other related > tooling. > > Notice that the lack of anything predictable here makes these tools be more > unreliable > across libc implementations (most people assume it "works" based on what > glibc does > but even old glibcs seem to be inconsistent with this). note: in glibc the internal macro DL_RO_DYN_SECTION controls if the dynamic section is relocated or not. on mips and riscv it is set so there the dynamic section is not relocated. i guess gdb decides based on the target how to find the debug info. but clearly relocating the dynamic section is not compatible with having it exposed as part of the public abi (the libc does not know about future dynamic tags, unknown tags are ignored, not relocated). if user code needs to access the dynamic section at runtime then it can hard code glibc specific knowledge (decide based on glibc version and target) or use another, supported libc interface. (e.g. glibc supports plt hooks via LD_AUDIT). thanks for the example links, those were interesting.