From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) by sourceware.org (Postfix) with ESMTPS id 1B08B3894433 for ; Fri, 7 May 2021 21:44:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1B08B3894433 Received: by mail-qv1-xf2b.google.com with SMTP id g17so5552258qvl.9 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=b2Lzed2IgVdxTN/4vWgv+Env1fNtTzp/+btr93C8O3XpVAYzEgIb/kCxEDrUC4dN4e rLQIJOg6XpznSAKK27pE0fIdnBAnQ4/pnm7WilihNep8SYNjpa48QD07gt1StpgRr3vp 1m5zyIgRxbl6fL9A2lORCX6vedV+WA5E2qJBJOmzjGtInGJ2f8xqcgVuAXAdh89uhvhe Vf+vv7sYGqN4eG7JVYSFxfD9FNkJdPBUa6EK1u1cu9HIZWLNysQugWJH6G4ey7tvivh9 EFaphJko0HulUzital2rV4jAh6DW5T7UuycllutVk8M3pcuD9Atn2by5DXJbUym/ffL4 JNNw== X-Gm-Message-State: AOAM5312khAnxoOs5RmAlwCcDN9FJh71BHHUgKwc5K/Z7tZVcm34Xdl3 5U7A80zVwjp7IG15B9qs9spkTQ== 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=-4.9 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: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb 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 >