From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 9DF083858D20 for ; Tue, 15 Mar 2022 17:28:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9DF083858D20 Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-638-3S6kHMFENzatlmaN1VfNgg-1; Tue, 15 Mar 2022 13:28:05 -0400 X-MC-Unique: 3S6kHMFENzatlmaN1VfNgg-1 Received: by mail-wr1-f69.google.com with SMTP id j44-20020adf912f000000b00203a5a55817so1882894wrj.13 for ; Tue, 15 Mar 2022 10:28:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=1pS5UZ+QL1jipjxnWOQP/djk/XGAESA+OmTO+zpgd/8=; b=goFsllXkZbwTPd5ZiHEzVVk33XV8oP5eEHWzRDVTKSZ4p/XlTE5BRKQm0aJkDWO4kn sZGWu698PUE1BcR2SL5VjEdInFcOKk/f1dN86bFUkvh3URG1uDtxZby7unO0LXXBvfMV MEvB/xD0Kov67wjfhcRJ7KGtZfpAGtmazLj0HY43YAXmyQYZRXiPTAwa0mBB7L0v/Nd7 ldTLWJ2mBaLM4V/5dGuZPOwQl2dpQ/XwWKsYINlh72bFS4xNiYHsvhiczpW262cFzgyG sse9ntqSc5HPbu6+jB3V/H+EySxzdZHyjTiNQBVOL/WtkJ7MBCb3xoTT1IYsy2oEdNfa /CfQ== X-Gm-Message-State: AOAM533oYlrePvesc/l1AO7weK+lThr1BA8XHAbONiUDBlFqukKosHyu jrdFJwxWvyRveaZ3nC0Bd7+JDmgUG7edqtI39owqi2njG1kxKYIiEF8ThRhBcylETUqVhXYMoAm htZllecFGVD0RrkDAN5xdUg== X-Received: by 2002:a5d:5191:0:b0:1f1:e5ee:e819 with SMTP id k17-20020a5d5191000000b001f1e5eee819mr20615869wrv.384.1647365283743; Tue, 15 Mar 2022 10:28:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy/hS5VIUwkTusersG49/1buFl8FTHpfSscp8BcAKNWK0s4AgdUqyv7LR/Rm+Ez1Nfgn5f4TQ== X-Received: by 2002:a5d:5191:0:b0:1f1:e5ee:e819 with SMTP id k17-20020a5d5191000000b001f1e5eee819mr20615860wrv.384.1647365283549; Tue, 15 Mar 2022 10:28:03 -0700 (PDT) Received: from localhost (host109-154-72-186.range109-154.btcentralplus.com. [109.154.72.186]) by smtp.gmail.com with ESMTPSA id w6-20020adfee46000000b001e4bf01bdfbsm15812110wro.46.2022.03.15.10.28.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Mar 2022 10:28:03 -0700 (PDT) From: Andrew Burgess To: "Metzger\, Markus T" Cc: "gdb-patches\@sourceware.org" Subject: RE: [PATCH] gdb/x86: handle stap probe arguments in xmm registers In-Reply-To: References: <20220315105446.3348835-1-aburgess@redhat.com> Date: Tue, 15 Mar 2022 17:28:02 +0000 Message-ID: <87ilsfunvh.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-12.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham 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: Tue, 15 Mar 2022 17:28:08 -0000 "Metzger, Markus T via Gdb-patches" writes: > Hello Andrew, > >>On x86 machines with xmm register, and with recent versions of >>systemtap (and gcc?), it can occur that stap probe arguments will be >>placed into xmm registers. > > I ran into the same problem with solib probes > > stapsdt 0x00000042 NT_STAPSDT (SystemTap probe descriptors) > Provider: rtld > Name: unmap_complete > Location: 0x0000000000002d88, Base: 0x000000000002ecdb, Semaphore: 0x0000000000000000 > Arguments: -8@-112(%rbp) 8@%xmm1 > > which results in > > Invalid cast. > warning: Probes-based dynamic linker interface failed. > Reverting to original interface. > > on dlclose() and can be observed with gdb.base/unload.exp. It doesn't lead > to a FAIL but the test could easily be extended to catch this. > > I extended gdb_continue_to_breakpoint to catch this case for another test I > wrote for linker namespaces. > > diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp > index a35d08a05de..ab7058121e5 100644 > --- a/gdb/testsuite/lib/gdb.exp > +++ b/gdb/testsuite/lib/gdb.exp > @@ -729,6 +729,12 @@ proc gdb_continue_to_breakpoint {name {location_pattern .*}} { > > set kfail_pattern "Process record does not support instruction 0xfae64 at.*" > gdb_test_multiple "continue" $full_name { > + -re "Corrupted shared library list.*$gdb_prompt $" { > + fail "$full_name: shared library list corrupted" > + } > + -re "Invalid cast\.\r\nwarning: Probes-based dynamic linker interface failed.*$gdb_prompt $" { > + fail "$full_name: probes interface failure" > + } > -re "(?:Breakpoint|Temporary breakpoint) .* (at|in) $location_pattern\r\n$gdb_prompt $" { > pass $full_name > } I wonder if these checks would be better added within gdb_test_multiple itself? > > >>My second plan involves adding a new expression type to GDB called >>unop_extract_operation. This new expression takes a value and a type, >>during evaluation the value contents are fetched, and then a new value >>is extracted from the value contents (based on type). This is similar >>to the following C expression: >> >> result_value = *((output_type *) &input_value); >> >>Obviously we can't actually build this expression in this case, as the >>input_value is in a register, but hopefully the above makes it clearer >>what I'm trying to do. > > The extract approach looks good to me and I can confirm that your patch > fixes the issue I've seen with dlclose() and the probe interface. That's great news. > > I was about to try changing the register operator to provide the > expected type but then I started wondering why we would want to > assign a type to registers, at all. A register provides storage but > the actual interpretation of that storage is left to the instructions > that operate on the register and, as we can see here, compilers > may use that storage in novel ways. > > I see how it might be nice to have some default display type for > printing values in 'info reg'. But also that has become a challenge > with vector registers where we interpret the bits as vectors of > different length and element type. > > Maybe we should leave it completely to the command that prints > register values (e.g. 'info reg') to define the type in which to interpret > the bits (e.g. via a set of options) and leave register values themselves > untyped. I think I'd need to understand more about how the proposed UI would work, the current mechanism has the advantage of being pretty intuitive (I think) for users. I guess if the vector registers were presented as a single scalar and the user had to cast to the vector type, or set some options, I fear this might be harder to figure out. Thanks, Andrew