From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) by sourceware.org (Postfix) with ESMTPS id 9D1D1396D83F for ; Mon, 10 May 2021 14:16:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9D1D1396D83F Received: by mail-qk1-x732.google.com with SMTP id q127so15452846qkb.1 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=evg3QI+T8jaD1Pnqbn0rJvPsTB93ZPRaIZ33V2yOsxj9smJsxerj/iBNIG7czkSeLa qTsqZktDzc4aRb5v5zpvY6PDOFpq8QoBGS7IBpTP2X1W2/DO/8UFhkVkr3ZulAbrdwph 73uhzkx4PqTCNHIrq41e1wJ+w5LUNj/UnPAD6TZFdB4kSRb7b9Jvhe08sa8gX+SA0BVO v0/wcQLIWnmQqtHBtTm1x4vmVXxeYlJ38NSuZ3WLe2Md4FzNTX22chIPyiSnks/RrSbw 7QfbjgGGV8YP7YPtO8NWRgGZOjNWkSqPMaNl+uguHun8xkzh3j8909/coBNqjYRjaazV uPCg== X-Gm-Message-State: AOAM532SqTSkpKTj32t0nHaR7+yZaTTh1AO+psz2qFT1K/nsy4kjli8H vU3UJ6jG+9UMaH8jYe+ou+hQ5A== 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.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: 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.