From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) by sourceware.org (Postfix) with ESMTPS id 72EE93858010 for ; Wed, 4 May 2022 10:14:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 72EE93858010 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-f54.google.com with SMTP id u3so1346278wrg.3 for ; Wed, 04 May 2022 03:14: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:references:from:in-reply-to :content-transfer-encoding; bh=ME1oilm9+QE8QExEVMuCGDWW3whbgw9NntAS5CNpf1Y=; b=n5t/bPuQblFYBxmADcOeQkFrD1oCfvVrj85q2qGcjicWmUHa3Z4VaLJBsjGyOM2qoM UdvAVlB+DISrZhxwLGD0EKPY3nzQm3J4ltfNOURFzTqWOi+Rj6TNrBslqt8sOOw1+q3m RKpKmA9Mlf78TmMZvfNpKelnxFOHegNLtsHiPvRHD1pLPa6JliQ3OY9TryveH9T4QbyU WLJwssQU2cbIspeY099Ib1l0FzuYN/ug47fOfQQtvmAX5q6/KuRL8erg/BXJ6cwYVhey N/ixb+5sH6s08It/SeypwHIPho3b2GU6b47XMGz6mUUWCdD5K8WiawZ3aR2JBLmfxhzw 2HFA== X-Gm-Message-State: AOAM533WCshrN6hY+ey2SICOL49PyN87RZYfoj2pxpxoqxZ+RDX5znKc acEOqVHETIp2UKBjcyFzZDEornc1SSo= X-Google-Smtp-Source: ABdhPJxViIwjiGfnnZnACciKh/rBj4cHu7p7pI8zU1F92EttCmRfv6sD6OisqjZvrkcwIZRIuUbvDA== X-Received: by 2002:a5d:6908:0:b0:20a:d71b:f4af with SMTP id t8-20020a5d6908000000b0020ad71bf4afmr15081260wru.527.1651659291226; Wed, 04 May 2022 03:14:51 -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 o30-20020adfa11e000000b0020c5253d8cbsm11181115wro.23.2022.05.04.03.14.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 May 2022 03:14:50 -0700 (PDT) Message-ID: <1b41b921-b79b-6168-96b1-58b9dea5508f@palves.net> Date: Wed, 4 May 2022 11:14:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH 0/2] Fix gdbserver/linux memory access regression Content-Language: en-US To: Luis Machado , gdb-patches@sourceware.org References: <20220419224739.3029868-1-pedro@palves.net> <26ee78d5-d9ff-3ec3-5767-c6ae8cd5afa0@palves.net> <082d3a0a-f6a4-0e40-4e27-623a9949186c@arm.com> <51c7d9e9-7d84-f826-be2d-be559847da9b@palves.net> <48db3b2b-46e3-1f30-2443-7d4b406b4c46@arm.com> From: Pedro Alves In-Reply-To: <48db3b2b-46e3-1f30-2443-7d4b406b4c46@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-11.0 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, GIT_PATCH_0, 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, WEIRD_PORT 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: Wed, 04 May 2022 10:14:54 -0000 On 2022-05-04 10:52, Luis Machado wrote: > On 5/4/22 10:45, Pedro Alves wrote: >> Can you show a backtrace?  If this is when reading memory, what code cares whether it's 64-bit?  Reading memory >> out of /proc/pid/mem should not care about that. > > Here it is: > > #0  thread_regcache_data (thread=thread@entry=0x0) at ../../../repos/binutils-gdb/gdbserver/inferiors.cc:120 > #1  0x0000aaaaaaabf0e8 in get_thread_regcache (thread=0x0, fetch=fetch@entry=0) at ../../../repos/binutils-gdb/gdbserver/regcache.cc:31 > #2  0x0000aaaaaaad785c in is_64bit_tdesc () at ../../../repos/binutils-gdb/gdbserver/linux-aarch64-low.cc:194 > #3  0x0000aaaaaaad8a48 in aarch64_target::sw_breakpoint_from_kind (this=, kind=4, size=0xffffffffef04) at ../../../repos/binutils-gdb/gdbserver/linux-aarch64-low.cc:3226 > #4  0x0000aaaaaaabe220 in bp_size (bp=0xaaaaaab6f3d0) at ../../../repos/binutils-gdb/gdbserver/mem-break.cc:226 > #5  check_mem_read (mem_addr=187649984471104, buf=buf@entry=0xaaaaaab625d0 "\006", mem_len=mem_len@entry=56) at ../../../repos/binutils-gdb/gdbserver/mem-break.cc:1862 > #6  0x0000aaaaaaacc660 in read_inferior_memory (memaddr=, myaddr=0xaaaaaab625d0 "\006", len=56) at ../../../repos/binutils-gdb/gdbserver/target.cc:93 > #7  0x0000aaaaaaac3d9c in gdb_read_memory (len=56, myaddr=0xaaaaaab625d0 "\006", memaddr=187649984471104) at ../../../repos/binutils-gdb/gdbserver/server.cc:1071 > #8  gdb_read_memory (memaddr=187649984471104, myaddr=0xaaaaaab625d0 "\006", len=56) at ../../../repos/binutils-gdb/gdbserver/server.cc:1048 > #9  0x0000aaaaaaac82a4 in process_serial_event () at ../../../repos/binutils-gdb/gdbserver/server.cc:4307 > #10 handle_serial_event (err=, client_data=) at ../../../repos/binutils-gdb/gdbserver/server.cc:4520 > #11 0x0000aaaaaaafbcd0 in gdb_wait_for_event (block=block@entry=1) at ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:700 > #12 0x0000aaaaaaafc0b0 in gdb_wait_for_event (block=1) at ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:596 > #13 gdb_do_one_event () at ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:237 > #14 0x0000aaaaaaacacb0 in start_event_loop () at ../../../repos/binutils-gdb/gdbserver/server.cc:3518 > #15 captured_main (argc=4, argv=) at ../../../repos/binutils-gdb/gdbserver/server.cc:3998 > #16 0x0000aaaaaaab66dc in main (argc=, argv=) at ../../../repos/binutils-gdb/gdbserver/server.cc:4084 > > -- > > This sequence of functions is invoked due to a series of conditions: > > 1 - The probe-based breakpoint mechanism failed (for some reason) so ... > 2 - ... gdbserver has to know what type of architecture it is dealing with so it can pick the right breakpoint kind, so it wants to check if we have a 64-bit target > 3 - To determine the size of a register, we need to fetch the register cache, and we do so through a thread point, which is now nullptr. > Thanks. I believe the patch below should fix that particular instance. Note that the thread's tdesc is itself filled from the process's tdesc, so this should be equivalent: struct regcache * get_thread_regcache (struct thread_info *thread, int fetch) { struct regcache *regcache; regcache = thread_regcache_data (thread); ... if (regcache == NULL) { struct process_info *proc = get_thread_process (thread); gdb_assert (proc->tdesc != NULL); regcache = new_register_cache (proc->tdesc); set_thread_regcache_data (thread, regcache); } ... There may be other spots that require similar treatments. >From 28f784b14bcd5b435de0a764a6a1e11df5e131c9 Mon Sep 17 00:00:00 2001 From: Pedro Alves Date: Wed, 4 May 2022 11:09:07 +0100 Subject: [PATCH] fix Change-Id: Ibc809d7345e70a2f058b522bdc5cdbdca97e2cdc --- gdbserver/linux-aarch64-low.cc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/gdbserver/linux-aarch64-low.cc b/gdbserver/linux-aarch64-low.cc index 0091f998c63..c947f2bcac1 100644 --- a/gdbserver/linux-aarch64-low.cc +++ b/gdbserver/linux-aarch64-low.cc @@ -191,9 +191,9 @@ struct arch_process_info static int is_64bit_tdesc (void) { - struct regcache *regcache = get_thread_regcache (current_thread, 0); - - return register_size (regcache->tdesc, 0) == 8; + /* We may not have a current thread at this point, so go straight to + the process's target description. */ + return register_size (current_process ()->tdesc) == 8; } static void base-commit: 7f8acedeebe295fc8cc1d11ed971cbfc1942618c -- 2.36.0