| Message ID | cover.1640284721.git.fweimer@redhat.com |
|---|---|
| Headers |
Return-Path: <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 745AF3858012 for <patchwork@sourceware.org>; Thu, 23 Dec 2021 18:43:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 745AF3858012 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1640285012; bh=Fd3ozoXbTkaCvNemMhooqsThAKFD2nefVWmCpKOlSbc=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=Xoh60JimuYkeqZjvzVdlcq416fsZ87BzQ/Cb/mapqMdO1aKziND+M4tDLhayA3VBI LyMsAU3SYjkzra68PmWlDwN8h62KvM4Afh9ePVvke+jhrxAmdo6ET7ufGuHazglLVS wkXTD2kOAHT1O4MTvC0IE6I0Kf3cUmIm4eyZTNcE= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 5848C3858418 for <libc-alpha@sourceware.org>; Thu, 23 Dec 2021 18:43:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5848C3858418 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-191-voiZjbeYOca1lwy54Gb6jg-1; Thu, 23 Dec 2021 13:43:10 -0500 X-MC-Unique: voiZjbeYOca1lwy54Gb6jg-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D678C1023F4E for <libc-alpha@sourceware.org>; Thu, 23 Dec 2021 18:43:09 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.104]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3B19A1037F5C for <libc-alpha@sourceware.org>; Thu, 23 Dec 2021 18:43:08 +0000 (UTC) To: libc-alpha@sourceware.org Subject: [PATCH 0/4] _r_debug copy relocation support X-From-Line: 3476c853788916a9a189ca0a9d31234cc05bb27d Mon Sep 17 00:00:00 2001 Message-Id: <cover.1640284721.git.fweimer@redhat.com> Date: Thu, 23 Dec 2021 19:43:07 +0100 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> From: Florian Weimer via Libc-alpha <libc-alpha@sourceware.org> Reply-To: Florian Weimer <fweimer@redhat.com> Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> |
| Series | _r_debug copy relocation support | |
Message
Florian Weimer
Dec. 23, 2021, 6:43 p.m. UTC
I implemented this because we received a bug that the _r_debug extension mechanism broke dyninst. But it turns out it wasn't because of a copy relocation: dyninst has its own interposing *definition* of _r_debug, so the patch series doesn't solve this. It can only handle an interposing definition in the main executable, not one in shared object (although I guess in theory we could fix this). The first two patches are independently useful, and the second two patches could be used if we ever need to implement copy relocation support for _r_debug. Tested on i686-linux-gnu and x86_64-linux-gnu. Thanks, Florian Florian Weimer (4): elf: Introduce separate _r_debug_array variable elf: Introduce _dl_debug_change_state elf: Support version-less lookup in _dl_lookup_direct elf: Restore support for _r_debug copy relocations elf/Makefile | 8 +++ elf/dl-close.c | 6 +- elf/dl-debug.c | 138 ++++++++++++++++++++++++++----------- elf/dl-load.c | 6 +- elf/dl-lookup-direct.c | 5 ++ elf/dl-open.c | 5 +- elf/rtld.c | 10 +-- elf/tst-dlmopen4-nonpic.c | 2 + elf/tst-dlmopen4-pic.c | 2 + elf/tst-dlmopen4.c | 22 ++++++ sysdeps/generic/ldsodefs.h | 27 ++++++-- 11 files changed, 168 insertions(+), 63 deletions(-) create mode 100644 elf/tst-dlmopen4-nonpic.c create mode 100644 elf/tst-dlmopen4-pic.c base-commit: 9702a7901e18460e8ffc5f56a493d41294a8e936
Comments
On Thu, Dec 23, 2021 at 10:43 AM Florian Weimer via Libc-alpha <libc-alpha@sourceware.org> wrote: > > I implemented this because we received a bug that the _r_debug extension > mechanism broke dyninst. But it turns out it wasn't because of a copy > relocation: dyninst has its own interposing *definition* of _r_debug, so > the patch series doesn't solve this. It can only handle an interposing > definition in the main executable, not one in shared object (although I > guess in theory we could fix this). Why doesn't GDB suffer from this issue? > The first two patches are independently useful, and the second two > patches could be used if we ever need to implement copy relocation > support for _r_debug. > > Tested on i686-linux-gnu and x86_64-linux-gnu. > > Thanks, > Florian > > Florian Weimer (4): > elf: Introduce separate _r_debug_array variable > elf: Introduce _dl_debug_change_state > elf: Support version-less lookup in _dl_lookup_direct > elf: Restore support for _r_debug copy relocations > > elf/Makefile | 8 +++ > elf/dl-close.c | 6 +- > elf/dl-debug.c | 138 ++++++++++++++++++++++++++----------- > elf/dl-load.c | 6 +- > elf/dl-lookup-direct.c | 5 ++ > elf/dl-open.c | 5 +- > elf/rtld.c | 10 +-- > elf/tst-dlmopen4-nonpic.c | 2 + > elf/tst-dlmopen4-pic.c | 2 + > elf/tst-dlmopen4.c | 22 ++++++ > sysdeps/generic/ldsodefs.h | 27 ++++++-- > 11 files changed, 168 insertions(+), 63 deletions(-) > create mode 100644 elf/tst-dlmopen4-nonpic.c > create mode 100644 elf/tst-dlmopen4-pic.c > > > base-commit: 9702a7901e18460e8ffc5f56a493d41294a8e936 > -- > 2.33.1 >
* H. J. Lu: > On Thu, Dec 23, 2021 at 10:43 AM Florian Weimer via Libc-alpha > <libc-alpha@sourceware.org> wrote: >> >> I implemented this because we received a bug that the _r_debug extension >> mechanism broke dyninst. But it turns out it wasn't because of a copy >> relocation: dyninst has its own interposing *definition* of _r_debug, so >> the patch series doesn't solve this. It can only handle an interposing >> definition in the main executable, not one in shared object (although I >> guess in theory we could fix this). > > Why doesn't GDB suffer from this issue? I expect that GDB uses DT_DEBUG, and that's not subject to interposition, as before. Thanks, Florian
On Thu, Dec 23, 2021 at 11:59 AM Florian Weimer <fweimer@redhat.com> wrote: > > * H. J. Lu: > > > On Thu, Dec 23, 2021 at 10:43 AM Florian Weimer via Libc-alpha > > <libc-alpha@sourceware.org> wrote: > >> > >> I implemented this because we received a bug that the _r_debug extension > >> mechanism broke dyninst. But it turns out it wasn't because of a copy > >> relocation: dyninst has its own interposing *definition* of _r_debug, so > >> the patch series doesn't solve this. It can only handle an interposing > >> definition in the main executable, not one in shared object (although I > >> guess in theory we could fix this). > > > > Why doesn't GDB suffer from this issue? > > I expect that GDB uses DT_DEBUG, and that's not subject to > interposition, as before. > Can dyninst also use DT_DEBUG?
* H. J. Lu: > On Thu, Dec 23, 2021 at 11:59 AM Florian Weimer <fweimer@redhat.com> wrote: >> >> * H. J. Lu: >> >> > On Thu, Dec 23, 2021 at 10:43 AM Florian Weimer via Libc-alpha >> > <libc-alpha@sourceware.org> wrote: >> >> >> >> I implemented this because we received a bug that the _r_debug extension >> >> mechanism broke dyninst. But it turns out it wasn't because of a copy >> >> relocation: dyninst has its own interposing *definition* of _r_debug, so >> >> the patch series doesn't solve this. It can only handle an interposing >> >> definition in the main executable, not one in shared object (although I >> >> guess in theory we could fix this). >> > >> > Why doesn't GDB suffer from this issue? >> >> I expect that GDB uses DT_DEBUG, and that's not subject to >> interposition, as before. > > Can dyninst also use DT_DEBUG? Not easily. They can keep using _r_debug if they just remove their local definition. Thanks, Florian
On Thu, Dec 23, 2021 at 1:00 PM Florian Weimer <fweimer@redhat.com> wrote: > > * H. J. Lu: > > > On Thu, Dec 23, 2021 at 11:59 AM Florian Weimer <fweimer@redhat.com> wrote: > >> > >> * H. J. Lu: > >> > >> > On Thu, Dec 23, 2021 at 10:43 AM Florian Weimer via Libc-alpha > >> > <libc-alpha@sourceware.org> wrote: > >> >> > >> >> I implemented this because we received a bug that the _r_debug extension > >> >> mechanism broke dyninst. But it turns out it wasn't because of a copy > >> >> relocation: dyninst has its own interposing *definition* of _r_debug, so > >> >> the patch series doesn't solve this. It can only handle an interposing > >> >> definition in the main executable, not one in shared object (although I > >> >> guess in theory we could fix this). > >> > > >> > Why doesn't GDB suffer from this issue? > >> > >> I expect that GDB uses DT_DEBUG, and that's not subject to > >> interposition, as before. > > > > Can dyninst also use DT_DEBUG? > > Not easily. They can keep using _r_debug if they just remove their > local definition. DT_DEBUG is easily accessible. I'd rather fix dyninst than add hacks in ld.so.