From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) by sourceware.org (Postfix) with ESMTPS id 7ACB23858D29 for ; Mon, 22 Mar 2021 17:32:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7ACB23858D29 Received: by mail-qk1-x736.google.com with SMTP id y5so9842557qkl.9 for ; Mon, 22 Mar 2021 10:32:27 -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:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1cdE6CTc9EgJ17zGs6zIpPYQKS28OQgqr2I6tQzG79o=; b=DeiFdTJZIyzCWuFj0+Lgm9c3hu33kUagMoHn9vojoRdTtJtS/CE3fswm1T3Xcaw4ER BV7Yn3CX2bshAEQTX4e2zFiB2zYaChIwp41tuDhdFhR7m44djoStPfm49IjqVydoPgxp /t5mPn8yoJqH/pHnId/DDojguB5JHbRh23wde5z8QWtdOwv+RwNLp+43A+JwScwCUT8e ZhuO3NFQJAKABYxk0DpianfRnmtcN2n0k2tlxYXRf6idR/hJZVYp716Xfnl44yC6NXFL TnvwQVUvg9x+CPul/kKTt7OOq5ngoxFKoLQQoQk4X2rOyAkr5hCMxKOZxr2ltTTRVFiT 0Vtw== X-Gm-Message-State: AOAM5338m4vXScjgPBowcNejaUga8uTpgprJeUkLggR75asDGM0iXoOa i3iWODY6C1XgSe46yFOqrVVXcCaySL8BhQ== X-Google-Smtp-Source: ABdhPJxmSAYDAIkGAdp23/Rb7aW0OtyNjxpu9oTs+5CIP7HoLTSZxGOk1B1i2+D00F+Zm+rsQP2Kaw== X-Received: by 2002:a05:620a:22b5:: with SMTP id p21mr1187175qkh.196.1616434347039; Mon, 22 Mar 2021 10:32:27 -0700 (PDT) Received: from ?IPv6:2804:7f0:4841:2841:2c21:ec8a:30f3:55a6? ([2804:7f0:4841:2841:2c21:ec8a:30f3:55a6]) by smtp.gmail.com with ESMTPSA id f8sm11399858qkk.23.2021.03.22.10.32.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Mar 2021 10:32:26 -0700 (PDT) Subject: Re: 64-bit Addresses in remote protocol To: joel@rtems.org, gdb@sourceware.org References: From: Luis Machado Message-ID: Date: Mon, 22 Mar 2021 14:32:24 -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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.3 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, 22 Mar 2021 17:32:28 -0000 Hi, On 3/22/21 1:55 PM, Joel Sherrill wrote: > Hi > > Over at RTEMS, we are looking at some warnings in our debug > server and wondering if fields described as "addr" in the gdb > protocol should be treated 64-bits when that target has 64-bit > addresses like the aarch64. If the inferior is using 64-bit addresses, then the remote protocol will also use 64-bit addresses. If we have a 32-bit inferior running on aarch64 hardware, we'll have 32-bit addresses over the remote protocol as well. Even when we're using 64-bit addresses, the remote protocol may not pad it with zeroes to make it 64-bit, but it should still be handled as 64-bit. Does that help? > > Technically, we are looking at sweeping through our gdb server > and using uintptr_t for addresses where uint32_t has been > ok before. > > But I wanted to make sure that our assumption that "addr" means > a valid target address which means it can be 32- or 64- bits based > on the target. > > Thanks. > > --joel > RTEMS >