From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) by sourceware.org (Postfix) with ESMTPS id A57DF3858C50 for ; Tue, 18 Oct 2022 14:38:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A57DF3858C50 Received: by mail-io1-xd33.google.com with SMTP id b79so11722673iof.5 for ; Tue, 18 Oct 2022 07:38:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Y44YIanIo5/uqH7B/L1CfUAKBrHExQg2yMHRNPKKY3k=; b=rL6JHv5RW219xIQyu2l+ggX5bUwvck/W2gASCjM0gm7cZLfnnVp5ojuIMF0vYr0toH g4Syl9N0o+f40l8D5ubvL3pd1xFgmR7Ghcv4SDnUKF3tMjTu+DdS7euCTYeD+uwhG+Kl AFhbt2/aDXAfsSXHGejOEXtnhH3S93MPq5RdglGZ577eSRoWYl+s0zNNs98jC5U0kVue 17TFBG+x7zFuVXHUKGY95he5eyHlXf8w0kuHfWuH3lNmnUtBzu/mHuEP1i0zJJ6ylosX ezOAKXcDHe9G3vzMpFXnW+JinsRS/EAw+ERThoaXOnT0LKAsD8s+fDQPLXAappUF80Va Cx4Q== X-Gm-Message-State: ACrzQf3Xfd11gCMqJSUdADDkFJ4PZmqZ04Gu2gVFTQHOyelNC8mzfUJW SYNKm4FGV6DpKq4BB4/3EXgm8Q== X-Google-Smtp-Source: AMsMyM7o6GPzr4D1FdUWxUKLtSBhVbf37aV4EyuanTnD6I4vt+XOV48KrLtrB7VCD3QXeVDJ111d7g== X-Received: by 2002:a02:8804:0:b0:35b:7425:82af with SMTP id r4-20020a028804000000b0035b742582afmr1972092jai.21.1666103916914; Tue, 18 Oct 2022 07:38:36 -0700 (PDT) Received: from murgatroyd (71-211-181-169.hlrn.qwest.net. [71.211.181.169]) by smtp.gmail.com with ESMTPSA id y16-20020a926410000000b002eb3b43cd63sm1046665ilb.18.2022.10.18.07.38.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Oct 2022 07:38:36 -0700 (PDT) From: Tom Tromey To: "Metzger, Markus T" Cc: Tom Tromey , "gdb-patches@sourceware.org" Subject: Re: 4b610737f02 Handle copy relocations References: X-Attribution: Tom Date: Tue, 18 Oct 2022 08:38:35 -0600 In-Reply-To: (Markus T. Metzger's message of "Tue, 18 Oct 2022 13:25:28 +0000") Message-ID: <87v8ohi4d0.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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-List-Received-Date: Tue, 18 Oct 2022 14:38:40 -0000 > 4b610737f02 Handle copy relocations > With linker namespaces, however, it may cause a wrong address to be > read after symbol lookup actually found the correct symbol. This can > be seen, for example, with gdb.base/dlmopen.exp when compiled with > clang. > Do you maybe see a different way of supporting copy relocations that > would not require fixing up the symbol when querying its address? I'm not really sure how this ought to work when there are linker namespaces, but basically what gdb needs to do is mimic whatever ldd does in this situation. I think copy relocations by their nature require some kind of symbol search. Tom