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.129.124]) by sourceware.org (Postfix) with ESMTPS id 4C7123857705 for ; Wed, 11 Oct 2023 08:47:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4C7123857705 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1697014040; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=jh7Eu/kYjGMYv72R4LFqUN5dvo9JPQou/3sAlBntiYw=; b=DaYDGFtfC3pM8umh5P93FLWyL5fRv4XaHpgegN4K3wgLlgp3JFWPrJ6ZYVfX3hNYt2Jkqg UrVMKyqCuwcU0JFmmyTXzAYspEfgUBlu5FKF9aCV+MCUsQjEPg6KnJtYxctriOrGyNTH2F a7Qw5spOkpwGw2qrPIKWrs1Ot42RV/o= Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-303-ScW2SIg2OZS-sgqdlW6OEA-1; Wed, 11 Oct 2023 04:47:10 -0400 X-MC-Unique: ScW2SIg2OZS-sgqdlW6OEA-1 Received: by mail-ej1-f71.google.com with SMTP id a640c23a62f3a-9a5d86705e4so547039266b.1 for ; Wed, 11 Oct 2023 01:47:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697014030; x=1697618830; h=mime-version:message-id:date:subject:cc:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=jh7Eu/kYjGMYv72R4LFqUN5dvo9JPQou/3sAlBntiYw=; b=scRI7ROe6fFeCQhumiiCpdy+/tU/tuFXnfy2MSINX/XdYcuOwSI//zN1NgVheZhD+F zsdZrPxmWTRuWO30zmz8w/t6LQyBzMsUoSDrJf31oTrmer8db3X0Ka0hTFp0+V3MOtCT Rz1uOgcSFAxYP8pqDw9eVCidUHere7o2PULPRc/xGbXXI7gyGcHbytqwZ1j9XAMJvvUi AcOqBoENbnMc7gosXFzEEasYivOszCizC4HZIVplgFEuedu3EnHAhLwomLYMk+FmK/Am 92JmaF1HGfKzcDcxMOw4fUcoOAAOj8QtaX5fVA58TYXOb+o710ytOXBk1zVET2FHDMQI V86Q== X-Gm-Message-State: AOJu0YxN6TqBzPicbqNZBWa64MwGuywesWOnjk+SEEv6L86cIV0cQgEj yjcT/xHXFhTjP4hTj8mhcjDW3272Kmou1nI9L4S9xteoEmMr62py4VY9XA1asGW/TK/13hhAgpy b+bHb+BVc93Q= X-Received: by 2002:a17:907:9724:b0:9b2:a7db:9662 with SMTP id jg36-20020a170907972400b009b2a7db9662mr22240903ejc.12.1697014029813; Wed, 11 Oct 2023 01:47:09 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEg9OpESIMZK8AnR23Y1SCA9OohLBJyof9XP7ZYBuvEp8Uo84+wjYNXdvw5/JM7xGy9CWsCzA== X-Received: by 2002:a17:907:9724:b0:9b2:a7db:9662 with SMTP id jg36-20020a170907972400b009b2a7db9662mr22240889ejc.12.1697014029468; Wed, 11 Oct 2023 01:47:09 -0700 (PDT) Received: from localhost ([31.111.84.209]) by smtp.gmail.com with ESMTPSA id y23-20020a1709064b1700b009aa292a2df2sm9422971eju.217.2023.10.11.01.47.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Oct 2023 01:47:09 -0700 (PDT) From: Andrew Burgess To: Luis Machado Cc: gdb@sourceware.org Subject: Thread Specific Architectures And Python Unwinder API Date: Wed, 11 Oct 2023 09:47:08 +0100 Message-ID: <87bkd5czqr.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=-5.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Luis, While working on something else I was looking at the Python Unwinder API code, and I suspect that the thread-specific architectures support might (currently) break the Python Unwinder support. If it is, then I think the fix is pretty simple, but before I posted it, I wondered if you could confirm that things are indeed, currently broken. Attached at the end of this email is a Python unwinder. You'll need to supply your own test program that makes use of sve/sme, and thus uses thread-specific architectures. What you'll need to do is: $ gdb -q test_file_that_uses_sve_sme Reading symbols from .... etc ... (gdb) source ./unwinder.py (gdb) break function_where_a_thread_specific_arch_will_be_in_use Breakpoint 1 at ... etc ... (gdb) run Starting program: ... etc ... Now at this point, when you stop, you should see at least one instance of the banner: *********************************** * Have executed the test unwinder * *********************************** being printed, probably more. As you step though the function you should see more instances of the banner being printed. To reveal the bug then it is important that when GDB stops in function_where_a_thread_specific_arch_will_be_in_use, the per-thread gdbarch that it creates _must_ be different from the inferior wide, top-level gdbarch. If you don't see the banner then my suspicion is correct, and the Python Unwinder API was broken when the thread-specific architecture support was added. The problem (I think) is that the Python unwinder is registered on each gdbarch as a result of the gdb::observers::architecture_changed.notify() call in set_target_gdbarch (though Simon has recently moved, or is about to move, this code, but not in a way that will fix this problem). Thus, the Python unwinder is only registered on the top-level (inferior wide) gdbarch, not on each of the different per-thread architectures. I have a patch here that removes the 'architecture_changed' observer, and replaces it with a 'new_architecture' observer, which I propose to move up into gdbarch_find_by_info. Thanks, Andrew --- from gdb.unwinder import Unwinder, FrameId class test_unwinder(Unwinder): def __init__(self): super().__init__("test_unwinder") def __call__(self,pending_frame): print("") print("***********************************") print("* Have executed the test unwinder *") print("***********************************") return None gdb.unwinder.register_unwinder(None, test_unwinder(), replace=True)