From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) by sourceware.org (Postfix) with ESMTPS id 19871385840F for ; Thu, 17 Mar 2022 15:54:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 19871385840F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f52.google.com with SMTP id b19so7934619wrh.11 for ; Thu, 17 Mar 2022 08:54:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=AAz0j4XrnvBEDFdLyLZn/U0QOLC3mpaE7o3k6RxNkIA=; b=G40Rc4OJvlA4B7w1twNFSeEXxYiuDdmL7fedWEcKgOnRApIhnI4IXgTI8ZoNW7ZoA3 LJ7KkXTDCfqsR5nycZls05HDjNB2rXkqznalsBZ9/2wRmEEaIhAj6Uq+wZX0+jdVn0dI bbm7aUYwYXH9rIRB87tk3O1djAqaA7RAUGRJbSaKiL0CeZpZqWVLvOb8WxSc0rlOh+vc eamlG3NOAYbaxaWP9yKoHX85TLssg0CLoI3XHXt6UerCyUgbgg1BObimpbTgtzaLhBZH I4LJYuKPgL7JuZpljzKLrObv7E7FySEScnzcq1ZVqpGfLx+VfYB5S83Jma09t1V+iMWC c1ZQ== X-Gm-Message-State: AOAM531Eg/HF2cHdAehMItBeTadX7cITY0p0inOv75znak77R5/+mC6z pHdKSVfFQWMmsCHeerK7CCI= X-Google-Smtp-Source: ABdhPJyqBcwtii8cEoXDXmH4Aw5J4ZRfEDYlGu9C/LkO9tE9NjYGHfkfdP+Qivr5KxexN0hq5ZaPEQ== X-Received: by 2002:a5d:5846:0:b0:203:6b34:37af with SMTP id i6-20020a5d5846000000b002036b3437afmr4940296wrf.58.1647532490728; Thu, 17 Mar 2022 08:54:50 -0700 (PDT) Received: from ?IPV6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id n1-20020a5d5981000000b00203d8ea8c94sm4912032wri.84.2022.03.17.08.54.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Mar 2022 08:54:49 -0700 (PDT) Message-ID: <705bb6c9-6175-0d6d-7c3a-bcabade3f664@palves.net> Date: Thu, 17 Mar 2022 15:54:48 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCHv2] gdb/x86: handle stap probe arguments in xmm registers Content-Language: en-US To: Tom Tromey , Andrew Burgess via Gdb-patches Cc: Andrew Burgess References: <20220315105446.3348835-1-aburgess@redhat.com> <20220316141316.465293-1-aburgess@redhat.com> <871qz1ke0r.fsf@tromey.com> From: Pedro Alves In-Reply-To: <871qz1ke0r.fsf@tromey.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Thu, 17 Mar 2022 15:54:58 -0000 On 2022-03-16 17:23, Tom Tromey wrote: > Andrew> This is because GDB doesn't currently support placing non-scalar types > Andrew> on the agent expression evaluation stack. Solving this is clearly > Andrew> related to the original problem, but feels a bit like a second > Andrew> problem. I'd like to get feedback on whether my approach to solving > Andrew> the original problem is acceptable or not before I start looking at > Andrew> how to handle xmm registers within agent expressions. > > Note that there are many things that can't be represented in agent > expressions. I recall filing a bug report about this -- there are some > DWARF expressions that can't be translated, and IIRC, floating point > isn't handled at all. So, I wouldn't worry too much about this. My > sense is that tracepoints aren't used a whole lot. Yeah. They were definitely being used in production a few years back when we were revamping them, adding support to gdbserver, etc. But it seems like users stopped using them since. It's possible that the fact that more and more DWARF expressions can't be converted carries some weight. Or users simply started using other tools for the job. In any case, if I were to tackle the whole problem set today, instead of extending agent expressions bytecode to be able to do more of what DWARF can do, I'd be looking at expressing what should be collected via DWARF expressions/locations. I mean, send DWARF expressions to the target side to be evaluated.