From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) by sourceware.org (Postfix) with ESMTPS id 1A89B386EC4D for ; Fri, 7 May 2021 21:44:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1A89B386EC4D Received: by mail-qv1-xf35.google.com with SMTP id u7so5533549qvv.12 for ; Fri, 07 May 2021 14:44:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=T1hsJE++JqicNScKjNxXMinEF6CopDUpMjiWKfLSfMM=; b=kvCK7no4FIEKUaJGSuOwxuP3tlANsrXlfNmd4vm5OEyK7vVc1ucUWXeztS+OBDbS4l z50W5gyfEYSXy+8OYBr8Qo4TwJl14VjQ6xl4i9jDX6lmulHDZswQcMjVCuAgK1NoqISH LwXP76cTKU4PpLcKSWIOWvw7TzlHNuGoBz+90M/p6ed5IrMCI6qloLO+XEn8Ov0LzHC6 TlLJ7j3s03uVFk6mVppI5Z9SsVfipev8db6KBqkA/r56YFsL86KtjmcdWoEXIxfOCEA9 QdlSgM0LFXSB8kmE8EawvzH3iNKGFNzAXxonQysE6yBoiXS2MQuVooXcFbVk5qE2LtH9 ADHQ== X-Gm-Message-State: AOAM5337kVCihSxxnJ9xYclXp/Fjiqz7hS5brm7YRihsCaEoMS9fIGeC MSi0YMK9itwzApRtgil6Gh8R8g== X-Google-Smtp-Source: ABdhPJy+NTzeOnto/ZnsgX2BIzjB8Rn5liP5NT8XlPR/028pb+lo93yhjUUZOtT5bXj8q+wH5Z0/Vw== X-Received: by 2002:a0c:f901:: with SMTP id v1mr11839577qvn.26.1620423890591; Fri, 07 May 2021 14:44:50 -0700 (PDT) Received: from ?IPv6:2804:7f0:4841:40ad:2455:cbab:c687:242e? ([2804:7f0:4841:40ad:2455:cbab:c687:242e]) by smtp.gmail.com with ESMTPSA id 129sm5774286qkn.44.2021.05.07.14.44.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 07 May 2021 14:44:50 -0700 (PDT) Subject: Re: GDB shared library tracking with stap probes x _dl_debug_state To: Florian Weimer , Luis Machado via Libc-alpha Cc: "gdb@sourceware.org" , doko@debian.org References: <878s4qb7fj.fsf@oldenburg.str.redhat.com> From: Luis Machado Message-ID: <07b03137-a083-dada-68da-965779cd41ff@linaro.org> Date: Fri, 7 May 2021 18:44:47 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <878s4qb7fj.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2021 21:44:52 -0000 On 5/7/21 5:44 PM, Florian Weimer wrote: > * Luis Machado via Libc-alpha: > >> That's all fine, but there is one small detail that doesn't work for >> armhf, and that is discovering if we're dealing with a PC that is arm >> mode or thumb mode. > > Is it possible to recognize Arm mode vs thumb mode based on the NOP > encoding at the probe address? > If we know the instruction is a NOP, it might be possible. But the function that checks this, arm_pc_is_thumb (...), is generic and gets called to determine if arbitrary PC's are arm or thumb. It would be somewhat hacky to do it this way. It would be more natural to let arm_pc_is_thumb figure out symbols on its own without corner cases. (gdb) maint info br Num Type Disp Enb Address What -1 shlib events keep n 0xb6fd7b5a inf 1 (gdb) show arm force-mode The current execution mode assumed (even when symbols are available) is "auto". (gdb) x/i 0xb6fd7b5a 0xb6fd7b5a: ; instruction: 0xf8dfbf00 (gdb) set arm force-mode thumb (gdb) x/i 0xb6fd7b5a 0xb6fd7b5a: nop >> 2 - Not stripping ld.so/glibc. I can't determine the impact of this >> choice, but distros strip binaries for a reason. Having to carry all >> symbols for a particular library may not be desirable. > > We are switching Fedora to not strip ld.so, primarily for introspection > purposes in Systemtap. > > (In Fedora, we've preserved the symbol table for ages, to make valgrind > work.) That's good information, and a more reasonable approach to solve this problem from GDB's point of view. > > Thanks, > Florian >