From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) by sourceware.org (Postfix) with ESMTPS id A2B29396E47F for ; Mon, 10 May 2021 14:16:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A2B29396E47F Received: by mail-qk1-x730.google.com with SMTP id q136so15397562qka.7 for ; Mon, 10 May 2021 07:16: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=cbsQAQGcx0IcDZKRJlq5mIn/WcihUYFPt2XDZWuL56Q=; b=sWdKbZz8HxLzeupKzrI7Xf9bJaty3v0ZrRl9MSYVfGOGSmqRosBEakwMJm8ncaRJKG 98rDNmcXS9XwuNIJrm2wjI7+KoMYbHWMEyXdYsWJfB5NMH0Y9KzfJMSp6W6/LNnhxrwk X/XkHtmtauEmhVfjT4/JeEaB0k8fTxPx9WoiNMxxwqd7x/4Eb0K2nxUA2D8rPtfPk97Z gEY6zRGBgxlafD026Oku3RtC/9vCXEJY+ScwQPJRlVdwUR+QjgptP3um2EEf8WjWEb8H r8dEUdUcdW2fC6PJEvj5ZXdnN20F7f7S4op3Cowd5QKQ/iOUNJ0L5aK1dOYR175msQxK l+cQ== X-Gm-Message-State: AOAM533XiSVHtItfBkCLD4idO7xvsQqLTAWKYIGCpBKws+X7vKQIg/o0 6+1tsaWATWmW1GqUW05HjEF5qA== X-Google-Smtp-Source: ABdhPJw9sFXHCvaluydnSN0bjkiKwj1wtp3d+yP2OV1tTJTbVWcpr279RZbKyxXYRMhiFxs7kCB8/w== X-Received: by 2002:a37:558:: with SMTP id 85mr19154861qkf.173.1620656211122; Mon, 10 May 2021 07:16:51 -0700 (PDT) Received: from ?IPv6:2804:7f0:4841:40ad:217f:b952:3363:7baf? ([2804:7f0:4841:40ad:217f:b952:3363:7baf]) by smtp.gmail.com with ESMTPSA id 123sm4724569qkg.0.2021.05.10.07.16.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 May 2021 07:16:50 -0700 (PDT) Subject: Re: GDB shared library tracking with stap probes x _dl_debug_state To: Florian Weimer , systemtap Cc: Sergio Durigan Junior , Luis Machado via Gdb , Luis Machado via Libc-alpha , doko@debian.org, "Maciej W. Rozycki" , Ulrich Weigand References: <878s4qb7fj.fsf@oldenburg.str.redhat.com> <07b03137-a083-dada-68da-965779cd41ff@linaro.org> <87bl9mi4xi.fsf@paluero> <87tunda403.fsf@oldenburg.str.redhat.com> From: Luis Machado Message-ID: <22cab26b-8931-ffc0-5324-bff640773924@linaro.org> Date: Mon, 10 May 2021 11:16:46 -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: <87tunda403.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.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: systemtap@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Systemtap mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2021 14:16:53 -0000 cc-ing Maciej and Ulrich for feedback about MIPS / rs6000. I see both architectures rely on marking some symbols as special, for different purposes. On 5/8/21 7:55 AM, Florian Weimer wrote: > * Sergio Durigan Junior: > >> On Friday, May 07 2021, Luis Machado via Gdb wrote: >> >>> 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. >> >> I think it's guaranteed that the instruction is always going to be a >> NOP. That's good, but ... > > Maybe we can add a comment to that effect to the Systemtap sources? > > Start of the thread is here: > > > > I think there are four distinct two-byte patterns at the probe > addressing, depending on endianess and thumb/non-thumb mode. Looking at > the instruction has the clear advantage that it works with today's > binaries. ... the way the breakpoint selection works doesn't take into account additional input like this. It would be a non-trivial change. Not too complex, but still not trivial. If this is to be implemented, it would be nice to make sure there are other architectures affected by this problem and that this sort of solution also works for them. Maciej, do you think MIPS will run into the same issue? If so, is this an acceptable solution? I still think having the symbol information is a cleaner solution.