From patchwork Mon Oct 17 19:38:56 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Asaf Fisher X-Patchwork-Id: 55222 Return-Path: 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 7FECD3858293 for ; Mon, 17 Oct 2022 19:39:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7FECD3858293 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1666035572; bh=JGoOlE3XglVAlnU3z0P4k5SLCGbzOD71+JUBASRQskc=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=qIAq//e5/4xZgRtNd4rv7HotAb/x4mbXpqmA6FuLnljdI8bMc7OpJpoaMe2EBCMNa 6CENwSsRFaAjIUv2+OjRaADNU1ygu6fWujlRjOIS5OJDBPa1a1a+NPiy1FyhkXTw9+ jd7tDe4/pIn+P/tCdy2GcUWX7fFmNqf2APEq2E6w= X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) by sourceware.org (Postfix) with ESMTPS id D9A913858D3C for ; Mon, 17 Oct 2022 19:39:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D9A913858D3C Received: by mail-ed1-x530.google.com with SMTP id b12so17539237edd.6 for ; Mon, 17 Oct 2022 12:39:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JGoOlE3XglVAlnU3z0P4k5SLCGbzOD71+JUBASRQskc=; b=SQa5vfPzDBJpRfPFMCK8n0DV5SF/gObvPMjwMEImTQ7IcF4bKANY+3wuWzrqJ21Gov uglpjedB2BwQwm/82BdtKTCeYeMX1CQKCYQTSAS4HnHG9fko/TNaRhUtQtRESU/9m0L+ Y8yioDA9gDh5wiUbnL+iYOGGZTWvZq9veIlCuDt3Mg9zcE5iPsemGcJuKPUxtkjN+wP9 7moDn6xC5AD/6RmGwYXQCqOuhSp8pPFE+w2K/nXWVBZfLnIAmjV0za0YL0JdhW52ilei HQeoeIR2tQkxoLvl3MGLneUZqunLFZTRs/Qh5ufTPITI3bmXGDwbCiLu9xwcmxcO/BFs fMBQ== X-Gm-Message-State: ACrzQf39B3O2+gpKXc0FnWsZbGZl6F/eewvhHZwrhAXPH6Dc8y4EfYUN s+4IRjrNc99hhcCcQ/pvrerdjFw9bLLm0rm2 X-Google-Smtp-Source: AMsMyM5E95m7wDybYoky23vUemIlo240X+/GYJnTXYhMF0lbm7412/+xegrtOles23p0etE0EASALQ== X-Received: by 2002:a05:6402:ca5:b0:459:3fb0:c157 with SMTP id cn5-20020a0564020ca500b004593fb0c157mr11427924edb.389.1666035542596; Mon, 17 Oct 2022 12:39:02 -0700 (PDT) Received: from codespaces-99e6ae.mo2cupmyp0zuvhb2b0itoyabtg.ax.internal.cloudapp.net ([20.160.121.11]) by smtp.gmail.com with ESMTPSA id p11-20020a170906604b00b0078df3b4464fsm6699544ejj.19.2022.10.17.12.39.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Oct 2022 12:39:02 -0700 (PDT) To: gdb-patches@sourceware.org Subject: [PATCH 0/2][PR < shlibs/29586>] GDB hangs when trying to resolve memory mapped shared libraries of an inferior under /proc/self/fd/* Date: Mon, 17 Oct 2022 19:38:56 +0000 Message-Id: <20221017193858.3006-1-asaffisher.dev@gmail.com> X-Mailer: git-send-email 2.38.0 MIME-Version: 1.0 X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Asaf Fisher via Gdb-patches From: Asaf Fisher Reply-To: Asaf Fisher Cc: Asaf Fisher Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org Sender: "Gdb-patches" Hello! If any of you will try to dlopen a memory mapped file in the following way:`dlopen("/proc/self/fd/4"....)` The operation will trigger GDB's hook on dlopen and will try to load the file "/proc/self/fd/4". Obviously GDB's process has different FD's on `/proc/self`, and will read from an arbitrary opened file. Most likely it will open a pipe which will cause GDB to hang. Here is a rust snippet that will hang GDB once being debugged: ``` use std::{os::unix::prelude::{AsFd, AsRawFd}, io::Write}; use memfd; use dlopen_derive::{self, WrapperApi}; #[macro_use] use dlopen::wrapper::{Container,WrapperApi}; #[derive(WrapperApi)] struct Api<'a> {     example_rust_fun: fn(arg: i32) -> u32,     example_c_fun: unsafe extern "C" fn(),     example_reference: &'a mut i32, } fn main() {     let opts = memfd::MemfdOptions::default().allow_sealing(true);     let mfd = opts.create("hellooo").unwrap();     let buff = std::fs::read("/usr/lib64/ld-linux-x86-64.so.2").unwrap();     mfd.as_file().write(buff.as_slice()).unwrap();     let fd = mfd.as_file().as_fd().as_raw_fd();     let fm = format!("/proc/self/fd/{}", fd);     println!("{}", fm);     let mut cont: Container =         unsafe { Container::load(fm) }.expect("Could not open library or load symbols"); } ``` To fix the problem I added a function to `solib-svr4.c` that will resolve `/proc/self/fd/[num]` to `/proc/[inferior_pid]/fd/[num]`. To test it I added a test that simply checks if the warning printed by GDB when resolving the path is correct. Asaf Fisher (2): Add test to check GDB handles dlopen of /proc/self/fd/[num] correctly Make GDB resolve dlopen of memory mapped shared libraries gdb/solib-svr4.c | 58 ++++++++++++++- gdb/testsuite/gdb.base/solib-proc-self.cc | 72 ++++++++++++++++++ gdb/testsuite/gdb.base/solib-proc-self.exp | 86 ++++++++++++++++++++++ 3 files changed, 214 insertions(+), 2 deletions(-) create mode 100644 gdb/testsuite/gdb.base/solib-proc-self.cc create mode 100644 gdb/testsuite/gdb.base/solib-proc-self.exp